diff mbox

ARM: omap: fix warning with LPAE build

Message ID 1384325630-26998-1-git-send-email-olof@lixom.net (mailing list archive)
State New, archived
Headers show

Commit Message

Olof Johansson Nov. 13, 2013, 6:53 a.m. UTC
Some omap3 code is throwing a warning:
arch/arm/mach-omap2/pm34xx.c: In function 'omap3_save_secure_ram_context':
arch/arm/mach-omap2/pm34xx.c:123:32: warning: cast to pointer from
  integer of different size [-Wint-to-pointer-cast]

In reality this code will never actually execute with LPAE=y, since
Cortex-A8 doesn't support it. So downcasting the __pa() is safe in
this case.

Signed-off-by: Olof Johansson <olof@lixom.net>
---

Tony, queue up if you have a fixes branch please, otherwise I can apply
directly.

 arch/arm/mach-omap2/pm34xx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Tony Lindgren Nov. 13, 2013, 8:05 p.m. UTC | #1
* Olof Johansson <olof@lixom.net> [131112 22:53]:
> Some omap3 code is throwing a warning:
> arch/arm/mach-omap2/pm34xx.c: In function 'omap3_save_secure_ram_context':
> arch/arm/mach-omap2/pm34xx.c:123:32: warning: cast to pointer from
>   integer of different size [-Wint-to-pointer-cast]
> 
> In reality this code will never actually execute with LPAE=y, since
> Cortex-A8 doesn't support it. So downcasting the __pa() is safe in
> this case.
> 
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
> 
> Tony, queue up if you have a fixes branch please, otherwise I can apply
> directly.
> 
>  arch/arm/mach-omap2/pm34xx.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 93b80e5..1f3770a 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -120,7 +120,7 @@ static void omap3_save_secure_ram_context(void)
>  		 * will hang the system.
>  		 */
>  		pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
> -		ret = _omap_save_secure_sram((u32 *)
> +		ret = _omap_save_secure_sram((u32 *)(unsigned long)
>  				__pa(omap3_secure_ram_storage));
>  		pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
>  		/* Following is for error tracking, it should not happen */

Hmm maybe the function prototype should be changed instead if
it takes the physical address.

How do you you reproduce this warning? I did not get it after
enabling LPAE in multi_v7_defconfig with current mainline.

Regards,

Tony
Olof Johansson Nov. 13, 2013, 8:31 p.m. UTC | #2
On Wed, Nov 13, 2013 at 12:05 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Olof Johansson <olof@lixom.net> [131112 22:53]:
>> Some omap3 code is throwing a warning:
>> arch/arm/mach-omap2/pm34xx.c: In function 'omap3_save_secure_ram_context':
>> arch/arm/mach-omap2/pm34xx.c:123:32: warning: cast to pointer from
>>   integer of different size [-Wint-to-pointer-cast]
>>
>> In reality this code will never actually execute with LPAE=y, since
>> Cortex-A8 doesn't support it. So downcasting the __pa() is safe in
>> this case.
>>
>> Signed-off-by: Olof Johansson <olof@lixom.net>
>> ---
>>
>> Tony, queue up if you have a fixes branch please, otherwise I can apply
>> directly.
>>
>>  arch/arm/mach-omap2/pm34xx.c |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index 93b80e5..1f3770a 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -120,7 +120,7 @@ static void omap3_save_secure_ram_context(void)
>>                * will hang the system.
>>                */
>>               pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
>> -             ret = _omap_save_secure_sram((u32 *)
>> +             ret = _omap_save_secure_sram((u32 *)(unsigned long)
>>                               __pa(omap3_secure_ram_storage));
>>               pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
>>               /* Following is for error tracking, it should not happen */
>
> Hmm maybe the function prototype should be changed instead if
> it takes the physical address.
>
> How do you you reproduce this warning? I did not get it after
> enabling LPAE in multi_v7_defconfig with current mainline.

Of course. No more late night patching for me. :)

I saw it in last night's -next.


-Olof
Olof Johansson Nov. 13, 2013, 9:22 p.m. UTC | #3
On Wed, Nov 13, 2013 at 12:31 PM, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Nov 13, 2013 at 12:05 PM, Tony Lindgren <tony@atomide.com> wrote:
>> * Olof Johansson <olof@lixom.net> [131112 22:53]:
>>> Some omap3 code is throwing a warning:
>>> arch/arm/mach-omap2/pm34xx.c: In function 'omap3_save_secure_ram_context':
>>> arch/arm/mach-omap2/pm34xx.c:123:32: warning: cast to pointer from
>>>   integer of different size [-Wint-to-pointer-cast]
>>>
>>> In reality this code will never actually execute with LPAE=y, since
>>> Cortex-A8 doesn't support it. So downcasting the __pa() is safe in
>>> this case.
>>>
>>> Signed-off-by: Olof Johansson <olof@lixom.net>
>>> ---
>>>
>>> Tony, queue up if you have a fixes branch please, otherwise I can apply
>>> directly.
>>>
>>>  arch/arm/mach-omap2/pm34xx.c |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>>> index 93b80e5..1f3770a 100644
>>> --- a/arch/arm/mach-omap2/pm34xx.c
>>> +++ b/arch/arm/mach-omap2/pm34xx.c
>>> @@ -120,7 +120,7 @@ static void omap3_save_secure_ram_context(void)
>>>                * will hang the system.
>>>                */
>>>               pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
>>> -             ret = _omap_save_secure_sram((u32 *)
>>> +             ret = _omap_save_secure_sram((u32 *)(unsigned long)
>>>                               __pa(omap3_secure_ram_storage));
>>>               pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
>>>               /* Following is for error tracking, it should not happen */
>>
>> Hmm maybe the function prototype should be changed instead if
>> it takes the physical address.
>>
>> How do you you reproduce this warning? I did not get it after
>> enabling LPAE in multi_v7_defconfig with current mainline.
>
> Of course. No more late night patching for me. :)

Actually, that is getting a little hairy. It's a function pointer to
an assembly function, so we'd need to make it deal with the size of
phys_addr_t there. It's probably easier to just go with the original
patch here, at least I don't see much payoff from doing it the other
way.


-Olof
Tony Lindgren Nov. 13, 2013, 9:56 p.m. UTC | #4
* Olof Johansson <olof@lixom.net> [131113 13:23]:
> On Wed, Nov 13, 2013 at 12:31 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Wed, Nov 13, 2013 at 12:05 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> * Olof Johansson <olof@lixom.net> [131112 22:53]:
> >>> Some omap3 code is throwing a warning:
> >>> arch/arm/mach-omap2/pm34xx.c: In function 'omap3_save_secure_ram_context':
> >>> arch/arm/mach-omap2/pm34xx.c:123:32: warning: cast to pointer from
> >>>   integer of different size [-Wint-to-pointer-cast]
> >>>
> >>> In reality this code will never actually execute with LPAE=y, since
> >>> Cortex-A8 doesn't support it. So downcasting the __pa() is safe in
> >>> this case.
> >>>
> >>> Signed-off-by: Olof Johansson <olof@lixom.net>
> >>> ---
> >>>
> >>> Tony, queue up if you have a fixes branch please, otherwise I can apply
> >>> directly.
> >>>
> >>>  arch/arm/mach-omap2/pm34xx.c |    2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> >>> index 93b80e5..1f3770a 100644
> >>> --- a/arch/arm/mach-omap2/pm34xx.c
> >>> +++ b/arch/arm/mach-omap2/pm34xx.c
> >>> @@ -120,7 +120,7 @@ static void omap3_save_secure_ram_context(void)
> >>>                * will hang the system.
> >>>                */
> >>>               pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
> >>> -             ret = _omap_save_secure_sram((u32 *)
> >>> +             ret = _omap_save_secure_sram((u32 *)(unsigned long)
> >>>                               __pa(omap3_secure_ram_storage));
> >>>               pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
> >>>               /* Following is for error tracking, it should not happen */
> >>
> >> Hmm maybe the function prototype should be changed instead if
> >> it takes the physical address.
> >>
> >> How do you you reproduce this warning? I did not get it after
> >> enabling LPAE in multi_v7_defconfig with current mainline.
> >
> > Of course. No more late night patching for me. :)

Ah OK so it's in next.
 
> Actually, that is getting a little hairy. It's a function pointer to
> an assembly function, so we'd need to make it deal with the size of
> phys_addr_t there. It's probably easier to just go with the original
> patch here, at least I don't see much payoff from doing it the other
> way.

OK, please go ahead and apply:

Acked-by: Tony Lindgren <tony@atomide.com>

I'm still sorting out my fixes, and so far it looks like I don't
need to touch this file.

Regards,

Tony
Olof Johansson Nov. 17, 2013, 10:30 p.m. UTC | #5
On Wed, Nov 13, 2013 at 1:56 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Olof Johansson <olof@lixom.net> [131113 13:23]:
>> On Wed, Nov 13, 2013 at 12:31 PM, Olof Johansson <olof@lixom.net> wrote:
>> > On Wed, Nov 13, 2013 at 12:05 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >> * Olof Johansson <olof@lixom.net> [131112 22:53]:
>> >>> Some omap3 code is throwing a warning:
>> >>> arch/arm/mach-omap2/pm34xx.c: In function 'omap3_save_secure_ram_context':
>> >>> arch/arm/mach-omap2/pm34xx.c:123:32: warning: cast to pointer from
>> >>>   integer of different size [-Wint-to-pointer-cast]
>> >>>
>> >>> In reality this code will never actually execute with LPAE=y, since
>> >>> Cortex-A8 doesn't support it. So downcasting the __pa() is safe in
>> >>> this case.
>> >>>
>> >>> Signed-off-by: Olof Johansson <olof@lixom.net>
>> >>> ---
>> >>>
>> >>> Tony, queue up if you have a fixes branch please, otherwise I can apply
>> >>> directly.
>> >>>
>> >>>  arch/arm/mach-omap2/pm34xx.c |    2 +-
>> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>>
>> >>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> >>> index 93b80e5..1f3770a 100644
>> >>> --- a/arch/arm/mach-omap2/pm34xx.c
>> >>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> >>> @@ -120,7 +120,7 @@ static void omap3_save_secure_ram_context(void)
>> >>>                * will hang the system.
>> >>>                */
>> >>>               pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
>> >>> -             ret = _omap_save_secure_sram((u32 *)
>> >>> +             ret = _omap_save_secure_sram((u32 *)(unsigned long)
>> >>>                               __pa(omap3_secure_ram_storage));
>> >>>               pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
>> >>>               /* Following is for error tracking, it should not happen */
>> >>
>> >> Hmm maybe the function prototype should be changed instead if
>> >> it takes the physical address.
>> >>
>> >> How do you you reproduce this warning? I did not get it after
>> >> enabling LPAE in multi_v7_defconfig with current mainline.
>> >
>> > Of course. No more late night patching for me. :)
>
> Ah OK so it's in next.
>
>> Actually, that is getting a little hairy. It's a function pointer to
>> an assembly function, so we'd need to make it deal with the size of
>> phys_addr_t there. It's probably easier to just go with the original
>> patch here, at least I don't see much payoff from doing it the other
>> way.
>
> OK, please go ahead and apply:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
>
> I'm still sorting out my fixes, and so far it looks like I don't
> need to touch this file.

I forgot to include this in the last batch, but I've applied it now.
Thanks for the ack.


-Olof
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 93b80e5..1f3770a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -120,7 +120,7 @@  static void omap3_save_secure_ram_context(void)
 		 * will hang the system.
 		 */
 		pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
-		ret = _omap_save_secure_sram((u32 *)
+		ret = _omap_save_secure_sram((u32 *)(unsigned long)
 				__pa(omap3_secure_ram_storage));
 		pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
 		/* Following is for error tracking, it should not happen */