From: Al Stone ahs3@redhat.com
Modify the kernel configuration so that if ARM is selected, then ACPI_REDUCED_HARDWARE is also selected.
Signed-off-by: Al Stone al.stone@linaro.org --- drivers/acpi/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 099ca81..23522b4 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -5,6 +5,7 @@ config ACPI_ARM bool select EARLY_IOREMAP + select ACPI_REDUCED_HARDWARE
menuconfig ACPI bool "ACPI (Advanced Configuration and Power Interface) Support"
Al
I am not sure about this.
What if one day we have ARM vendors showing up with x86-like fake registers just to be fully fixed hw profile compliant and feeling they could be safer than with the resuced hw profile, for whichever reason?
I would suggest we have two flags, which would be both set in 99.9% of ARM platforms but maybe there could be a 0.1% where it is ARM and fixed profile one day?
Thanks Andrea
On Wednesday, November 13, 2013, wrote:
From: Al Stone <ahs3@redhat.com javascript:;>
Modify the kernel configuration so that if ARM is selected, then ACPI_REDUCED_HARDWARE is also selected.
Signed-off-by: Al Stone <al.stone@linaro.org javascript:;>
drivers/acpi/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 099ca81..23522b4 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -5,6 +5,7 @@ config ACPI_ARM bool select EARLY_IOREMAP
select ACPI_REDUCED_HARDWAREmenuconfig ACPI bool "ACPI (Advanced Configuration and Power Interface) Support" -- 1.8.3.1
Linaro-acpi mailing list Linaro-acpi@lists.linaro.org javascript:; http://lists.linaro.org/mailman/listinfo/linaro-acpi
On 2013-11-13 15:59, Andrea Gallo wrote:
Al
I am not sure about this.
What if one day we have ARM vendors showing up with x86-like fake registers just to be fully fixed hw profile compliant and feeling they could be safer than with the resuced hw profile, for whichever reason?
I would suggest we have two flags, which would be both set in 99.9% of ARM platforms but maybe there could be a 0.1% where it is ARM and fixed profile one day?
I agree with Andrea. we can't just let ARM = HW-reduced, some OEM vendors may implement ACPI hardware one day.
Thanks Hanjun
On 11/13/2013 01:44 AM, Hanjun Guo wrote:
On 2013-11-13 15:59, Andrea Gallo wrote:
Al
I am not sure about this.
What if one day we have ARM vendors showing up with x86-like fake registers just to be fully fixed hw profile compliant and feeling they could be safer than with the resuced hw profile, for whichever reason?
I would suggest we have two flags, which would be both set in 99.9% of ARM platforms but maybe there could be a 0.1% where it is ARM and fixed profile one day?
I agree with Andrea. we can't just let ARM = HW-reduced, some OEM vendors may implement ACPI hardware one day.
Thanks Hanjun
Hrm. I was unaware that some vendors were already going down the path of full ACPI hardware. In that case, we should leave things as they are and if a particular vendor wants to have reduced HW the default (or not), then they can do that in their specific Kconfig items. So, I'm withdrawing this patch as unneeded.
On Wed, Nov 13, 2013 at 01:08:25PM -0700, Al Stone wrote:
On 11/13/2013 01:44 AM, Hanjun Guo wrote:
On 2013-11-13 15:59, Andrea Gallo wrote:
Al
I am not sure about this.
What if one day we have ARM vendors showing up with x86-like fake registers just to be fully fixed hw profile compliant and feeling they could be safer than with the resuced hw profile, for whichever reason?
I would suggest we have two flags, which would be both set in 99.9% of ARM platforms but maybe there could be a 0.1% where it is ARM and fixed profile one day?
I agree with Andrea. we can't just let ARM = HW-reduced, some OEM vendors may implement ACPI hardware one day.
Thanks Hanjun
Hrm. I was unaware that some vendors were already going down the path of full ACPI hardware. In that case, we should leave things as they are and if a particular vendor wants to have reduced HW the default (or not), then they can do that in their specific Kconfig items. So, I'm withdrawing this patch as unneeded.
I very much disagree with Andrea and Hanjun, we cannot design software for an infinite number of "what if?". Especially when its a complex system which requires testing. I very much doubt someone will come up with an emulated non reduced hardware platform on arm that just works on first boot. Considering they will have to do a lot of testing and probably code changes then one line in a config file is not a major extra bit of work.
Also consider if we do not push this patch we will be answering the question approximately once a day of why our ARM acpi code core dumps due to random memory access because someone forgot to set that flag in their .config.
Graeme
On 14.11.2013 10:10, Graeme Gregory wrote:
On Wed, Nov 13, 2013 at 01:08:25PM -0700, Al Stone wrote:
On 11/13/2013 01:44 AM, Hanjun Guo wrote:
On 2013-11-13 15:59, Andrea Gallo wrote:
Al
I am not sure about this.
What if one day we have ARM vendors showing up with x86-like fake registers just to be fully fixed hw profile compliant and feeling they could be safer than with the resuced hw profile, for whichever reason?
I would suggest we have two flags, which would be both set in 99.9% of ARM platforms but maybe there could be a 0.1% where it is ARM and fixed profile one day?
I agree with Andrea. we can't just let ARM = HW-reduced, some OEM vendors may implement ACPI hardware one day.
Thanks Hanjun
Hrm. I was unaware that some vendors were already going down the path of full ACPI hardware. In that case, we should leave things as they are and if a particular vendor wants to have reduced HW the default (or not), then they can do that in their specific Kconfig items. So, I'm withdrawing this patch as unneeded.
I very much disagree with Andrea and Hanjun, we cannot design software for an infinite number of "what if?". Especially when its a complex system which requires testing. I very much doubt someone will come up with an emulated non reduced hardware platform on arm that just works on first boot. Considering they will have to do a lot of testing and probably code changes then one line in a config file is not a major extra bit of work.
Also consider if we do not push this patch we will be answering the question approximately once a day of why our ARM acpi code core dumps due to random memory access because someone forgot to set that flag in their .config.
Graeme
I also would like to see hardware reduce selected along with ARM. This way vendors are somehow forced to implement new feature in generic way, what means all flavour of ARM platforms can use it (eventual others platforms too). Personally, my feeling is that fixed version of ACPI is only for x86 and hardware reduce is right direction.
Tomasz
On 11/14/2013 03:27 AM, Tomasz Nowicki wrote:
On 14.11.2013 10:10, Graeme Gregory wrote:
On Wed, Nov 13, 2013 at 01:08:25PM -0700, Al Stone wrote:
On 11/13/2013 01:44 AM, Hanjun Guo wrote:
On 2013-11-13 15:59, Andrea Gallo wrote:
Al
I am not sure about this.
What if one day we have ARM vendors showing up with x86-like fake registers just to be fully fixed hw profile compliant and feeling they could be safer than with the resuced hw profile, for whichever reason?
I would suggest we have two flags, which would be both set in 99.9% of ARM platforms but maybe there could be a 0.1% where it is ARM and fixed profile one day?
I agree with Andrea. we can't just let ARM = HW-reduced, some OEM vendors may implement ACPI hardware one day.
Thanks Hanjun
Hrm. I was unaware that some vendors were already going down the path of full ACPI hardware. In that case, we should leave things as they are and if a particular vendor wants to have reduced HW the default (or not), then they can do that in their specific Kconfig items. So, I'm withdrawing this patch as unneeded.
I very much disagree with Andrea and Hanjun, we cannot design software for an infinite number of "what if?". Especially when its a complex system which requires testing. I very much doubt someone will come up with an emulated non reduced hardware platform on arm that just works on first boot. Considering they will have to do a lot of testing and probably code changes then one line in a config file is not a major extra bit of work.
Also consider if we do not push this patch we will be answering the question approximately once a day of why our ARM acpi code core dumps due to random memory access because someone forgot to set that flag in their .config.
Graeme
I also would like to see hardware reduce selected along with ARM. This way vendors are somehow forced to implement new feature in generic way, what means all flavour of ARM platforms can use it (eventual others platforms too). Personally, my feeling is that fixed version of ACPI is only for x86 and hardware reduce is right direction.
Tomasz
I think I may have answered in haste (it has been a *long* week already and I've been tired).
The more I think about this, I realize I have to withdraw my withdrawal :). The issue is that the reduced HW profile is meant to be more architecturally neutral, while the full ACPI profile is actually x86-dependent. Not only is it x86 specific, it carries with it a whole raft of baggage from pre-ACPI 5.0 legacy systems (there are Atom systems using reduced HW mode just to avoid this cruft).
As the most egregious example, if an ARM vendor is to make an SoC that implements the full ACPI profile, they *must* implement an NMI interrupt line that behaves like a real NMI (none of this priority stuff). If they do, is that really an ARM processor? I don't think so -- it's some sort of hybrid beast. The same problem exists for SCI, and possibly MCE and others that are very specific to x86 *and* impose HW requirements on the SoC vendors to step outside of a normal ARM implementation.
The next layer is that the FACS table would also impose the requirement to implement various registers with very specific semantics, again specific to x86, and outside the definition of ARM.
The final thought that occurs to me is that without reduced HW profile, we *must* implement a single global lock in ACPI. That lock could be abused in a bazillion different ways that would end up creating a single global lock in the kernel. Since there is by definition no ACPI global lock in reduced HW, that cannot happen.
So, now that I think about it more, we *must* link reduced HW and ARM ACPI unless we want to force HW requirements on SoC vendors that would (a) force them to add x86-specific features to their ARM hardware, and (b) force them to support legacy x86 hardware features that even Intel is moving away from.
Hi Al,
I fully share your thoughts, my suggestion was to have the two compile options independent though both must be set to run on current ARM platforms.
I have anyway no problem to accept your current withdrawal of your previous withdrawal and look at further withdrawal only when any ARM vendor may come up with such hybrid beasts, if any.
Thanks for your guidance and also for your patience :-)
/Andrea
On 14 November 2013 18:31, Al Stone al.stone@linaro.org wrote:
On 11/14/2013 03:27 AM, Tomasz Nowicki wrote:
On 14.11.2013 10:10, Graeme Gregory wrote:
On Wed, Nov 13, 2013 at 01:08:25PM -0700, Al Stone wrote:
On 11/13/2013 01:44 AM, Hanjun Guo wrote:
On 2013-11-13 15:59, Andrea Gallo wrote:
Al
I am not sure about this.
What if one day we have ARM vendors showing up with x86-like fake registers just to be fully fixed hw profile compliant and feeling they could be safer than with the resuced hw profile, for whichever reason?
I would suggest we have two flags, which would be both set in 99.9% of ARM platforms but maybe there could be a 0.1% where it is ARM and fixed profile one day?
I agree with Andrea. we can't just let ARM = HW-reduced, some OEM vendors may implement ACPI hardware one day.
Thanks Hanjun
Hrm. I was unaware that some vendors were already going down the path of full ACPI hardware. In that case, we should leave things as they are and if a particular vendor wants to have reduced HW the default (or not), then they can do that in their specific Kconfig items. So, I'm withdrawing this patch as unneeded.
I very much disagree with Andrea and Hanjun, we cannot design software for an infinite number of "what if?". Especially when its a complex system which requires testing. I very much doubt someone will come up with an emulated non reduced hardware platform on arm that just works on first boot. Considering they will have to do a lot of testing and probably code changes then one line in a config file is not a major extra bit of work.
Also consider if we do not push this patch we will be answering the question approximately once a day of why our ARM acpi code core dumps due to random memory access because someone forgot to set that flag in their .config.
Graeme
I also would like to see hardware reduce selected along with ARM. This way vendors are somehow forced to implement new feature in generic way, what means all flavour of ARM platforms can use it (eventual others platforms too). Personally, my feeling is that fixed version of ACPI is only for x86 and hardware reduce is right direction.
Tomasz
I think I may have answered in haste (it has been a *long* week already and I've been tired).
The more I think about this, I realize I have to withdraw my withdrawal :). The issue is that the reduced HW profile is meant to be more architecturally neutral, while the full ACPI profile is actually x86-dependent. Not only is it x86 specific, it carries with it a whole raft of baggage from pre-ACPI 5.0 legacy systems (there are Atom systems using reduced HW mode just to avoid this cruft).
As the most egregious example, if an ARM vendor is to make an SoC that implements the full ACPI profile, they *must* implement an NMI interrupt line that behaves like a real NMI (none of this priority stuff). If they do, is that really an ARM processor? I don't think so -- it's some sort of hybrid beast. The same problem exists for SCI, and possibly MCE and others that are very specific to x86 *and* impose HW requirements on the SoC vendors to step outside of a normal ARM implementation.
The next layer is that the FACS table would also impose the requirement to implement various registers with very specific semantics, again specific to x86, and outside the definition of ARM.
The final thought that occurs to me is that without reduced HW profile, we *must* implement a single global lock in ACPI. That lock could be abused in a bazillion different ways that would end up creating a single global lock in the kernel. Since there is by definition no ACPI global lock in reduced HW, that cannot happen.
So, now that I think about it more, we *must* link reduced HW and ARM ACPI unless we want to force HW requirements on SoC vendors that would (a) force them to add x86-specific features to their ARM hardware, and (b) force them to support legacy x86 hardware features that even Intel is moving away from.
-- ciao, al
Al Stone Software Engineer Linaro Enterprise Group al.stone@linaro.org
Linaro-acpi mailing list Linaro-acpi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-acpi
On 11/14/2013 10:38 AM, Andrea Gallo wrote:
Hi Al,
I fully share your thoughts, my suggestion was to have the two compile options independent though both must be set to run on current ARM platforms.
Aha. There are separate CONFIG_ACPI and CONFIG_ACPI_REDUCED_HARDWARE options. The patch only says if you choose ACPI, *and* you choose an ARM architecture, CONFIG_ACPI_REDUCED_HARDWARE is automatically set true. It's also a one line change in the Kconfig should anyone ever wish to remove that restriction (though I may have to slap them for suggesting it :).
I have anyway no problem to accept your current withdrawal of your previous withdrawal and look at further withdrawal only when any ARM vendor may come up with such hybrid beasts, if any.
LOL. Um, yeah. I _think_ I followed that :).
Graeme: once acked, could you please apply? Thanks.
Thanks for your guidance and also for your patience :-)
/Andrea
On 14 November 2013 18:31, Al Stone <al.stone@linaro.org mailto:al.stone@linaro.org> wrote:
On 11/14/2013 03:27 AM, Tomasz Nowicki wrote: On 14.11.2013 10:10, Graeme Gregory wrote: On Wed, Nov 13, 2013 at 01:08:25PM -0700, Al Stone wrote: On 11/13/2013 01:44 AM, Hanjun Guo wrote: On 2013-11-13 15:59, Andrea Gallo wrote: Al I am not sure about this. What if one day we have ARM vendors showing up with x86-like fake registers just to be fully fixed hw profile compliant and feeling they could be safer than with the resuced hw profile, for whichever reason? I would suggest we have two flags, which would be both set in 99.9% of ARM platforms but maybe there could be a 0.1% where it is ARM and fixed profile one day? I agree with Andrea. we can't just let ARM = HW-reduced, some OEM vendors may implement ACPI hardware one day. Thanks Hanjun Hrm. I was unaware that some vendors were already going down the path of full ACPI hardware. In that case, we should leave things as they are and if a particular vendor wants to have reduced HW the default (or not), then they can do that in their specific Kconfig items. So, I'm withdrawing this patch as unneeded. I very much disagree with Andrea and Hanjun, we cannot design software for an infinite number of "what if?". Especially when its a complex system which requires testing. I very much doubt someone will come up with an emulated non reduced hardware platform on arm that just works on first boot. Considering they will have to do a lot of testing and probably code changes then one line in a config file is not a major extra bit of work. Also consider if we do not push this patch we will be answering the question approximately once a day of why our ARM acpi code core dumps due to random memory access because someone forgot to set that flag in their .config. Graeme I also would like to see hardware reduce selected along with ARM. This way vendors are somehow forced to implement new feature in generic way, what means all flavour of ARM platforms can use it (eventual others platforms too). Personally, my feeling is that fixed version of ACPI is only for x86 and hardware reduce is right direction. Tomasz I think I may have answered in haste (it has been a *long* week already and I've been tired). The more I think about this, I realize I have to withdraw my withdrawal :). The issue is that the reduced HW profile is meant to be more architecturally neutral, while the full ACPI profile is actually x86-dependent. Not only is it x86 specific, it carries with it a whole raft of baggage from pre-ACPI 5.0 legacy systems (there are Atom systems using reduced HW mode just to avoid this cruft). As the most egregious example, if an ARM vendor is to make an SoC that implements the full ACPI profile, they *must* implement an NMI interrupt line that behaves like a real NMI (none of this priority stuff). If they do, is that really an ARM processor? I don't think so -- it's some sort of hybrid beast. The same problem exists for SCI, and possibly MCE and others that are very specific to x86 *and* impose HW requirements on the SoC vendors to step outside of a normal ARM implementation. The next layer is that the FACS table would also impose the requirement to implement various registers with very specific semantics, again specific to x86, and outside the definition of ARM. The final thought that occurs to me is that without reduced HW profile, we *must* implement a single global lock in ACPI. That lock could be abused in a bazillion different ways that would end up creating a single global lock in the kernel. Since there is by definition no ACPI global lock in reduced HW, that cannot happen. So, now that I think about it more, we *must* link reduced HW and ARM ACPI unless we want to force HW requirements on SoC vendors that would (a) force them to add x86-specific features to their ARM hardware, and (b) force them to support legacy x86 hardware features that even Intel is moving away from. -- ciao, al ------------------------------__----- Al Stone Software Engineer Linaro Enterprise Group al.stone@linaro.org <mailto:al.stone@linaro.org> ------------------------------__----- _________________________________________________ Linaro-acpi mailing list Linaro-acpi@lists.linaro.org <mailto:Linaro-acpi@lists.linaro.org> http://lists.linaro.org/__mailman/listinfo/linaro-acpi <http://lists.linaro.org/mailman/listinfo/linaro-acpi>
I think after all the discussion on this and the fact that Al and I both seem to agree that non HW reduced mode on arm/arm64 is a non trivial task that it should be seen as almost like a new project.
We are having a hard enough time testing HW reduced mode on non-existent hardware. Members of the SC should not be misled into thinking something should work by it being configurable even when it is not currently sane.
Graeme
On Thu, Nov 14, 2013 at 01:34:48PM -0700, Al Stone wrote:
On 11/14/2013 10:38 AM, Andrea Gallo wrote:
Hi Al,
I fully share your thoughts, my suggestion was to have the two compile options independent though both must be set to run on current ARM platforms.
Aha. There are separate CONFIG_ACPI and CONFIG_ACPI_REDUCED_HARDWARE options. The patch only says if you choose ACPI, *and* you choose an ARM architecture, CONFIG_ACPI_REDUCED_HARDWARE is automatically set true. It's also a one line change in the Kconfig should anyone ever wish to remove that restriction (though I may have to slap them for suggesting it :).
I have anyway no problem to accept your current withdrawal of your previous withdrawal and look at further withdrawal only when any ARM vendor may come up with such hybrid beasts, if any.
LOL. Um, yeah. I _think_ I followed that :).
Graeme: once acked, could you please apply? Thanks.
Thanks for your guidance and also for your patience :-)
/Andrea
On 14 November 2013 18:31, Al Stone <al.stone@linaro.org mailto:al.stone@linaro.org> wrote:
On 11/14/2013 03:27 AM, Tomasz Nowicki wrote:
On 14.11.2013 10:10, Graeme Gregory wrote: On Wed, Nov 13, 2013 at 01:08:25PM -0700, Al Stone wrote: On 11/13/2013 01:44 AM, Hanjun Guo wrote: On 2013-11-13 15:59, Andrea Gallo wrote: Al I am not sure about this. What if one day we have ARM vendors showing up with x86-like fake registers just to be fully fixed hw profile compliant and feeling they could be safer than with the resuced hw profile, for whichever reason? I would suggest we have two flags, which would be both set in 99.9% of ARM platforms but maybe there could be a 0.1% where it is ARM and fixed profile one day? I agree with Andrea. we can't just let ARM = HW-reduced, some OEM vendors may implement ACPI hardware one day. Thanks Hanjun Hrm. I was unaware that some vendors were already going down the path of full ACPI hardware. In that case, we should leave things as they are and if a particular vendor wants to have reduced HW the default (or not), then they can do that in their specific Kconfig items. So, I'm withdrawing this patch as unneeded. I very much disagree with Andrea and Hanjun, we cannot design software for an infinite number of "what if?". Especially when its a complex system which requires testing. I very much doubt someone will come up with an emulated non reduced hardware platform on arm that just works on first boot. Considering they will have to do a lot of testing and probably code changes then one line in a config file is not a major extra bit of work. Also consider if we do not push this patch we will be answering the question approximately once a day of why our ARM acpi code core dumps due to random memory access because someone forgot to set that flag in their .config. Graeme I also would like to see hardware reduce selected along with ARM. This way vendors are somehow forced to implement new feature in generic way, what means all flavour of ARM platforms can use it (eventual others platforms too). Personally, my feeling is that fixed version of ACPI is only for x86 and hardware reduce is right direction. TomaszI think I may have answered in haste (it has been a *long* week already and I've been tired).
The more I think about this, I realize I have to withdraw my withdrawal :). The issue is that the reduced HW profile is meant to be more architecturally neutral, while the full ACPI profile is actually x86-dependent. Not only is it x86 specific, it carries with it a whole raft of baggage from pre-ACPI 5.0 legacy systems (there are Atom systems using reduced HW mode just to avoid this cruft).
As the most egregious example, if an ARM vendor is to make an SoC that implements the full ACPI profile, they *must* implement an NMI interrupt line that behaves like a real NMI (none of this priority stuff). If they do, is that really an ARM processor? I don't think so -- it's some sort of hybrid beast. The same problem exists for SCI, and possibly MCE and others that are very specific to x86 *and* impose HW requirements on the SoC vendors to step outside of a normal ARM implementation.
The next layer is that the FACS table would also impose the requirement to implement various registers with very specific semantics, again specific to x86, and outside the definition of ARM.
The final thought that occurs to me is that without reduced HW profile, we *must* implement a single global lock in ACPI. That lock could be abused in a bazillion different ways that would end up creating a single global lock in the kernel. Since there is by definition no ACPI global lock in reduced HW, that cannot happen.
So, now that I think about it more, we *must* link reduced HW and ARM ACPI unless we want to force HW requirements on SoC vendors that would (a) force them to add x86-specific features to their ARM hardware, and (b) force them to support legacy x86 hardware features that even Intel is moving away from.
-- ciao, al ------------------------------__----- Al Stone Software Engineer Linaro Enterprise Group al.stone@linaro.org mailto:al.stone@linaro.org ------------------------------__-----
Linaro-acpi mailing list Linaro-acpi@lists.linaro.org mailto:Linaro-acpi@lists.linaro.org http://lists.linaro.org/__mailman/listinfo/linaro-acpi http://lists.linaro.org/mailman/listinfo/linaro-acpi
-- ciao, al
Al Stone Software Engineer Linaro Enterprise Group al.stone@linaro.org
Linaro-acpi mailing list Linaro-acpi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-acpi
On 2013-11-15 19:09, Graeme Gregory wrote:
I think after all the discussion on this and the fact that Al and I both seem to agree that non HW reduced mode on arm/arm64 is a non trivial task that it should be seen as almost like a new project.
We are having a hard enough time testing HW reduced mode on non-existent hardware. Members of the SC should not be misled into thinking something should work by it being configurable even when it is not currently sane.
After a long discussion, It makes HW reduced mode clearer for us now, I agree with this patch and withdraw my previous opinion, So with this patch:
Acked-by: Hanjun Guo hanjun.guo@linaro.org
Graeme
On Thu, Nov 14, 2013 at 01:34:48PM -0700, Al Stone wrote:
On 11/14/2013 10:38 AM, Andrea Gallo wrote:
Hi Al,
I fully share your thoughts, my suggestion was to have the two compile options independent though both must be set to run on current ARM platforms.
Aha. There are separate CONFIG_ACPI and CONFIG_ACPI_REDUCED_HARDWARE options. The patch only says if you choose ACPI, *and* you choose an ARM architecture, CONFIG_ACPI_REDUCED_HARDWARE is automatically set true. It's also a one line change in the Kconfig should anyone ever wish to remove that restriction (though I may have to slap them for suggesting it :).
I have anyway no problem to accept your current withdrawal of your previous withdrawal and look at further withdrawal only when any ARM vendor may come up with such hybrid beasts, if any.
LOL. Um, yeah. I _think_ I followed that :).
Graeme: once acked, could you please apply? Thanks.
Thanks for your guidance and also for your patience :-)
-
Al Stone -
al.stone＠linaro.org
-
Andrea Gallo -
Graeme Gregory -
Hanjun Guo -
Tomasz Nowicki