Re: [PATCH] mtd: aspeed: fix compile warning in aspeed_smc_read_from_ahb()

[Marek Vasut <marek.vasut@gmail.com>]

On 02/10/2017 06:50 AM, Cédric Le Goater wrote:
> On 02/09/2017 04:04 PM, Marek Vasut wrote:
>> On 02/09/2017 10:59 AM, Cédric Le Goater wrote:
>>> On 02/09/2017 10:05 AM, Marek Vasut wrote:
>>>> On 02/09/2017 12:37 AM, Brian Norris wrote:
>>>>> On Thu, Jan 19, 2017 at 10:13:18AM +0100, Cédric Le Goater wrote:
>>>>>> The first argument of ioread32_rep() and ioread8_rep is not
>>>>>> const. Change aspeed_smc_read_from_ahb() prototype to fix compile
>>>>>> warning :
>>>>>>
>>>>>>    drivers/mtd/spi-nor/aspeed-smc.c: In function 'aspeed_smc_read_from_ahb':
>>>>>>    drivers/mtd/spi-nor/aspeed-smc.c:212:16: warning: passing argument 1 of 'ioread32_rep' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>>>>>>       ioread32_rep(src, buf, len >> 2);
>>>>>
>>>>> But why isn't that param constant? Seems like that's a bug in the
>>>>> ioread* APIs. Some of their implementations are const, but some are not.
>>>>>
>>>>> I see for instance that the implementation in lib/iomap.c is not const,
>>>>> where there's zero reason it shouldn't be (if we also fix, e.g., its
>>>>> mmio_insl()).
>>>>
>>>> Maybe it's worth fixing the ioread*_rep then ? Then again, that seems to
>>>> be way far off the scope of this patch.
>>>
>>> Looking closer at where this comes from, the compile warning was 
>>> reported on x86 which pulls a different file for the definitions 
>>> of the ioread routines.
>>
>> Well yes, intel is a special snowflake in the io accessor area.
>>
>>> On x86, arch/x86/include/asm/io.h includes <asm-generic/iomap.h>
>>> which contains prototypes of the ioread routines without 'const'.
>>>
>>> On ARM, arch/arm/include/asm/io.h includes <asm-generic/io.h>
>>> which contains the 'const' definitions.
>>
>> Can you check if any of those arches needs it without const ?
> 
> ok. I have checked over ppc, all defconfigs compile fine. 
> I will send a patch to linuxppc to see how we can merged it 
> in powerpc-next. The other arches would then be checked 
> by the Intel 0-day bot.

Great :)

-- 
Best regards,
Marek Vasut