[PATCH] arm64: booting: Require placement within 48-bit addressable memory

[PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Ard Biesheuvel]

Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
placement of the kernel image outside of the 48-bit addressable region,
but given that the loader has no way of knowing whether or not the image
in question supports LVA/LPA, it currently has no choice but to place it
below the 48-bit mark.

Once we add support for LPA2, which allows 52-bit physical and virtual
addressing when using 4k or 16k pages, but in way that relies on
increasing the number of paging levels, there will be more variety in
the configurations that may or may not support this.

So repaint bit #3 in the Image header as 'must be placed within 48-bit
addressable memory', as this is the current de facto meaning, and add
bits that we may set later to allow placement outside of that.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 Documentation/arm64/booting.rst | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 8c324ad638de2b27..9919e1a107add655 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -114,16 +114,21 @@ Header notes:
 			* 1 - 4K
 			* 2 - 16K
 			* 3 - 64K
-  Bit 3		Kernel physical placement
+  Bit 3-4	Kernel physical placement
 
 			0
 			  2MB aligned base should be as close as possible
 			  to the base of DRAM, since memory below it is not
 			  accessible via the linear mapping
 			1
+			  2MB aligned base such that base plus image_size is
+			  entirely within the 48-bit addressable range
+			2
+			  Reserved
+			3
 			  2MB aligned base may be anywhere in physical
 			  memory
-  Bits 4-63	Reserved.
+  Bits 5-63	Reserved.
   ============= ===============================================================
 
 - When image_size is zero, a bootloader should attempt to keep as much
-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Mark Rutland]

On Mon, Nov 14, 2022 at 12:58:10PM +0100, Ard Biesheuvel wrote:
> Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
> placement of the kernel image outside of the 48-bit addressable region,
> but given that the loader has no way of knowing whether or not the image
> in question supports LVA/LPA, it currently has no choice but to place it
> below the 48-bit mark.
> 
> Once we add support for LPA2, which allows 52-bit physical and virtual
> addressing when using 4k or 16k pages, but in way that relies on
> increasing the number of paging levels, there will be more variety in
> the configurations that may or may not support this.
> 
> So repaint bit #3 in the Image header as 'must be placed within 48-bit
> addressable memory', as this is the current de facto meaning, and add
> bits that we may set later to allow placement outside of that.

Could we just clean up the definition of bit 3 for now, then add the other bits
when we actually set them?

> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  Documentation/arm64/booting.rst | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
> index 8c324ad638de2b27..9919e1a107add655 100644
> --- a/Documentation/arm64/booting.rst
> +++ b/Documentation/arm64/booting.rst
> @@ -114,16 +114,21 @@ Header notes:
>  			* 1 - 4K
>  			* 2 - 16K
>  			* 3 - 64K
> -  Bit 3		Kernel physical placement
> +  Bit 3-4	Kernel physical placement
>  
>  			0
>  			  2MB aligned base should be as close as possible
>  			  to the base of DRAM, since memory below it is not
>  			  accessible via the linear mapping
>  			1
> +			  2MB aligned base such that base plus image_size is
> +			  entirely within the 48-bit addressable range

This seems to assume text_offset is zero (which is the case today, but this is
the first part of booting.txt that assumes that); as a matter of policy are we
sure that we'll never use a non-zero offset again? If so, we probably want to
mention that in the "header notes" section, or come up with some wording to
include it here.

Otherwise, this looks good; I'm certainly in favour of explicitly mentioning
the 48-bit restriction.

Thanks,
Mark.

> +			2
> +			  Reserved
> +			3
>  			  2MB aligned base may be anywhere in physical
>  			  memory
> -  Bits 4-63	Reserved.
> +  Bits 5-63	Reserved.
>    ============= ===============================================================
>  
>  - When image_size is zero, a bootloader should attempt to keep as much
> -- 
> 2.35.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Ard Biesheuvel]

On Mon, 14 Nov 2022 at 13:10, Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Mon, Nov 14, 2022 at 12:58:10PM +0100, Ard Biesheuvel wrote:
> > Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
> > placement of the kernel image outside of the 48-bit addressable region,
> > but given that the loader has no way of knowing whether or not the image
> > in question supports LVA/LPA, it currently has no choice but to place it
> > below the 48-bit mark.
> >
> > Once we add support for LPA2, which allows 52-bit physical and virtual
> > addressing when using 4k or 16k pages, but in way that relies on
> > increasing the number of paging levels, there will be more variety in
> > the configurations that may or may not support this.
> >
> > So repaint bit #3 in the Image header as 'must be placed within 48-bit
> > addressable memory', as this is the current de facto meaning, and add
> > bits that we may set later to allow placement outside of that.
>
> Could we just clean up the definition of bit 3 for now, then add the other bits
> when we actually set them?
>

Sure

> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >  Documentation/arm64/booting.rst | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
> > index 8c324ad638de2b27..9919e1a107add655 100644
> > --- a/Documentation/arm64/booting.rst
> > +++ b/Documentation/arm64/booting.rst
> > @@ -114,16 +114,21 @@ Header notes:
> >                       * 1 - 4K
> >                       * 2 - 16K
> >                       * 3 - 64K
> > -  Bit 3              Kernel physical placement
> > +  Bit 3-4    Kernel physical placement
> >
> >                       0
> >                         2MB aligned base should be as close as possible
> >                         to the base of DRAM, since memory below it is not
> >                         accessible via the linear mapping
> >                       1
> > +                       2MB aligned base such that base plus image_size is
> > +                       entirely within the 48-bit addressable range
>
> This seems to assume text_offset is zero (which is the case today, but this is
> the first part of booting.txt that assumes that); as a matter of policy are we
> sure that we'll never use a non-zero offset again? If so, we probably want to
> mention that in the "header notes" section, or come up with some wording to
> include it here.
>

How about:

2MB aligned base such that all image_size bytes
counted from the start of the image are within
the 48-bit addressable range

?

> Otherwise, this looks good; I'm certainly in favour of explicitly mentioning
> the 48-bit restriction.
>
> Thanks,
> Mark.
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Mark Rutland]

On Mon, Nov 14, 2022 at 02:33:52PM +0100, Ard Biesheuvel wrote:
> On Mon, 14 Nov 2022 at 13:10, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Mon, Nov 14, 2022 at 12:58:10PM +0100, Ard Biesheuvel wrote:
> > > +  Bit 3-4    Kernel physical placement
> > >
> > >                       0
> > >                         2MB aligned base should be as close as possible
> > >                         to the base of DRAM, since memory below it is not
> > >                         accessible via the linear mapping
> > >                       1
> > > +                       2MB aligned base such that base plus image_size is
> > > +                       entirely within the 48-bit addressable range
> >
> > This seems to assume text_offset is zero (which is the case today, but this is
> > the first part of booting.txt that assumes that); as a matter of policy are we
> > sure that we'll never use a non-zero offset again? If so, we probably want to
> > mention that in the "header notes" section, or come up with some wording to
> > include it here.
> >
> 
> How about:
> 
> 2MB aligned base such that all image_size bytes
> counted from the start of the image are within
> the 48-bit addressable range
> 
> ?

Sounds good to me, thanks!

Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Ard Biesheuvel]

Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
placement of the kernel image outside of the 48-bit addressable region,
but given that the loader has no way of knowing whether or not the image
in question supports LVA/LPA, it currently has no choice but to place it
below the 48-bit mark.

Once we add support for LPA2, which allows 52-bit physical and virtual
addressing when using 4k or 16k pages, but in way that relies on
increasing the number of paging levels, there will be more variety in
the configurations that may or may not support this.

So redefine bit #3 in the Image header as 'must be placed within 48-bit
addressable memory', as this is the current de facto meaning.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 Documentation/arm64/booting.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 8c324ad638de2b27..5a764fabfea821f0 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -121,8 +121,9 @@ Header notes:
 			  to the base of DRAM, since memory below it is not
 			  accessible via the linear mapping
 			1
-			  2MB aligned base may be anywhere in physical
-			  memory
+			  2MB aligned base such that all image_size bytes
+			  counted from the start of the image are within
+			  the 48-bit addressable range of physical memory
   Bits 4-63	Reserved.
   ============= ===============================================================
 
-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Ard Biesheuvel]

On Tue, 22 Nov 2022 at 18:02, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
> placement of the kernel image outside of the 48-bit addressable region,
> but given that the loader has no way of knowing whether or not the image
> in question supports LVA/LPA, it currently has no choice but to place it
> below the 48-bit mark.
>
> Once we add support for LPA2, which allows 52-bit physical and virtual
> addressing when using 4k or 16k pages, but in way that relies on
> increasing the number of paging levels, there will be more variety in
> the configurations that may or may not support this.
>
> So redefine bit #3 in the Image header as 'must be placed within 48-bit
> addressable memory', as this is the current de facto meaning.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---

Note that this is a v2 addressing prior feedback from Mark.

>  Documentation/arm64/booting.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
> index 8c324ad638de2b27..5a764fabfea821f0 100644
> --- a/Documentation/arm64/booting.rst
> +++ b/Documentation/arm64/booting.rst
> @@ -121,8 +121,9 @@ Header notes:
>                           to the base of DRAM, since memory below it is not
>                           accessible via the linear mapping
>                         1
> -                         2MB aligned base may be anywhere in physical
> -                         memory
> +                         2MB aligned base such that all image_size bytes
> +                         counted from the start of the image are within
> +                         the 48-bit addressable range of physical memory
>    Bits 4-63    Reserved.
>    ============= ===============================================================
>
> --
> 2.35.1
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Mark Rutland]

On Tue, Nov 22, 2022 at 06:02:49PM +0100, Ard Biesheuvel wrote:
> Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
> placement of the kernel image outside of the 48-bit addressable region,
> but given that the loader has no way of knowing whether or not the image
> in question supports LVA/LPA, it currently has no choice but to place it
> below the 48-bit mark.
> 
> Once we add support for LPA2, which allows 52-bit physical and virtual
> addressing when using 4k or 16k pages, but in way that relies on
> increasing the number of paging levels, there will be more variety in
> the configurations that may or may not support this.
> 
> So redefine bit #3 in the Image header as 'must be placed within 48-bit
> addressable memory', as this is the current de facto meaning.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

Acked-by: Mark Rutland <mark.rutland@arm.com>

Thanks for the respin!

Mark.

> ---
>  Documentation/arm64/booting.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
> index 8c324ad638de2b27..5a764fabfea821f0 100644
> --- a/Documentation/arm64/booting.rst
> +++ b/Documentation/arm64/booting.rst
> @@ -121,8 +121,9 @@ Header notes:
>  			  to the base of DRAM, since memory below it is not
>  			  accessible via the linear mapping
>  			1
> -			  2MB aligned base may be anywhere in physical
> -			  memory
> +			  2MB aligned base such that all image_size bytes
> +			  counted from the start of the image are within
> +			  the 48-bit addressable range of physical memory
>    Bits 4-63	Reserved.
>    ============= ===============================================================
>  
> -- 
> 2.35.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Anshuman Khandual]

On 11/22/22 22:33, Ard Biesheuvel wrote:
> On Tue, 22 Nov 2022 at 18:02, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
>> placement of the kernel image outside of the 48-bit addressable region,
>> but given that the loader has no way of knowing whether or not the image
>> in question supports LVA/LPA, it currently has no choice but to place it
>> below the 48-bit mark.
>>
>> Once we add support for LPA2, which allows 52-bit physical and virtual
>> addressing when using 4k or 16k pages, but in way that relies on
>> increasing the number of paging levels, there will be more variety in
>> the configurations that may or may not support this.
>>
>> So redefine bit #3 in the Image header as 'must be placed within 48-bit
>> addressable memory', as this is the current de facto meaning.
>>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> ---
> 
> Note that this is a v2 addressing prior feedback from Mark.

As you had mentioned earlier, currently [64K|52VA|52PA] can boot the vmlinux
loaded beyond 48 bits PA. Why should not the kernel header flags be extended
right away to support mentioned FEAT_LPA config and also let the kernel write
update these extended flags when applicable. Why wait for FEAT_LPA2 ? 

> 
>>  Documentation/arm64/booting.rst | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
>> index 8c324ad638de2b27..5a764fabfea821f0 100644
>> --- a/Documentation/arm64/booting.rst
>> +++ b/Documentation/arm64/booting.rst
>> @@ -121,8 +121,9 @@ Header notes:
>>                           to the base of DRAM, since memory below it is not
>>                           accessible via the linear mapping
>>                         1
>> -                         2MB aligned base may be anywhere in physical
>> -                         memory
>> +                         2MB aligned base such that all image_size bytes
>> +                         counted from the start of the image are within
>> +                         the 48-bit addressable range of physical memory
>>    Bits 4-63    Reserved.
>>    ============= ===============================================================
>>
>> --
>> 2.35.1
>>
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Ard Biesheuvel]

On Wed, 23 Nov 2022 at 07:30, Anshuman Khandual
<anshuman.khandual@arm.com> wrote:
>
>
>
> On 11/22/22 22:33, Ard Biesheuvel wrote:
> > On Tue, 22 Nov 2022 at 18:02, Ard Biesheuvel <ardb@kernel.org> wrote:
> >>
> >> Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
> >> placement of the kernel image outside of the 48-bit addressable region,
> >> but given that the loader has no way of knowing whether or not the image
> >> in question supports LVA/LPA, it currently has no choice but to place it
> >> below the 48-bit mark.
> >>
> >> Once we add support for LPA2, which allows 52-bit physical and virtual
> >> addressing when using 4k or 16k pages, but in way that relies on
> >> increasing the number of paging levels, there will be more variety in
> >> the configurations that may or may not support this.
> >>
> >> So redefine bit #3 in the Image header as 'must be placed within 48-bit
> >> addressable memory', as this is the current de facto meaning.
> >>
> >> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> >> ---
> >
> > Note that this is a v2 addressing prior feedback from Mark.
>
> As you had mentioned earlier, currently [64K|52VA|52PA] can boot the vmlinux
> loaded beyond 48 bits PA. Why should not the kernel header flags be extended
> right away to support mentioned FEAT_LPA config and also let the kernel write
> update these extended flags when applicable. Why wait for FEAT_LPA2 ?
>

I am not suggesting to wait for FEAT_LPA2.

I am suggesting to only support kernels loaded into 48 bit addressable
physical memory. There is simply no point, as no system is likely to
ever exist that relies on this, so this will be dead code that only
ever gets tested if someone bothers to run it on a doctored emulator
that has all its memory outside of that region.

By the same reasoning, there is really no point in updating the ID map
extension code to account for this: that feature was specifically
intended for being able to boot AMD seattle with a 39-bit VA 4k pages
kernel at a time when the only alternative we had was 42-bit 64k
pages. Also, given that LPA2 is defined as a single feature that
covers both virtual and physical addressing up to 52 bits, and that
the virtual addressing part requires the physical addressing part, I
don't see a point in supporting 52-bit physical addressing without
52-bit virtual addressing, which means the ID map extension case
simply ceases to exist for LPA2.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Anshuman Khandual]

On 11/22/22 22:32, Ard Biesheuvel wrote:
> Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
> placement of the kernel image outside of the 48-bit addressable region,
> but given that the loader has no way of knowing whether or not the image
> in question supports LVA/LPA, it currently has no choice but to place it
> below the 48-bit mark.
> 
> Once we add support for LPA2, which allows 52-bit physical and virtual
> addressing when using 4k or 16k pages, but in way that relies on
> increasing the number of paging levels, there will be more variety in
> the configurations that may or may not support this.
> 
> So redefine bit #3 in the Image header as 'must be placed within 48-bit
> addressable memory', as this is the current de facto meaning.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---

Regardless of possible vmlinux beyond 48 bits physical address discussion,
this patch looks good, and complete in itself.

Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>

>  Documentation/arm64/booting.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
> index 8c324ad638de2b27..5a764fabfea821f0 100644
> --- a/Documentation/arm64/booting.rst
> +++ b/Documentation/arm64/booting.rst
> @@ -121,8 +121,9 @@ Header notes:
>  			  to the base of DRAM, since memory below it is not
>  			  accessible via the linear mapping
>  			1
> -			  2MB aligned base may be anywhere in physical
> -			  memory
> +			  2MB aligned base such that all image_size bytes
> +			  counted from the start of the image are within
> +			  the 48-bit addressable range of physical memory
>    Bits 4-63	Reserved.
>    ============= ===============================================================
>  

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Will Deacon]

On Tue, 22 Nov 2022 18:02:49 +0100, Ard Biesheuvel wrote:
> Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
> placement of the kernel image outside of the 48-bit addressable region,
> but given that the loader has no way of knowing whether or not the image
> in question supports LVA/LPA, it currently has no choice but to place it
> below the 48-bit mark.
> 
> Once we add support for LPA2, which allows 52-bit physical and virtual
> addressing when using 4k or 16k pages, but in way that relies on
> increasing the number of paging levels, there will be more variety in
> the configurations that may or may not support this.
> 
> [...]

Applied to arm64 (for-next/mm), thanks!

[1/1] arm64: booting: Require placement within 48-bit addressable memory
      https://git.kernel.org/arm64/c/453dfcee70c5

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory

[Ard Biesheuvel]

On Fri, 25 Nov 2022 at 14:24, Will Deacon <will@kernel.org> wrote:
>
> On Tue, 22 Nov 2022 18:02:49 +0100, Ard Biesheuvel wrote:
> > Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
> > placement of the kernel image outside of the 48-bit addressable region,
> > but given that the loader has no way of knowing whether or not the image
> > in question supports LVA/LPA, it currently has no choice but to place it
> > below the 48-bit mark.
> >
> > Once we add support for LPA2, which allows 52-bit physical and virtual
> > addressing when using 4k or 16k pages, but in way that relies on
> > increasing the number of paging levels, there will be more variety in
> > the configurations that may or may not support this.
> >
> > [...]
>
> Applied to arm64 (for-next/mm), thanks!
>
> [1/1] arm64: booting: Require placement within 48-bit addressable memory
>       https://git.kernel.org/arm64/c/453dfcee70c5
>

In the discussion with Ryan Roberts regarding my LPA2 series, it
became clear that this necessarily applies to the FDT and initrd as
well, given that the bootloader must not assume that the kernel can
access anything residing beyond the 48-bit PA limit.

Unless anyone disagrees with that, I'll prepare a follow up patch to
clarify this too.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel