Re: [PATCH] pinctrl: single: add big endian support

[Rustam Adilov <adilov@disroot.org>]

On 2026-10-10 16:32, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] api: undefined readl_be/writel_be macros break generic build
> --
> 
> commit 37f4a78fd7a9ab63fc123070591147a5473d3fdf
> Author: Rustam Adilov <adilov@disroot.org>
> 
> pinctrl: single: add big endian support
> 
> This commit adds big-endian support for pinctrl-single to handle big-endian
> device tree properties. It implements custom I/O accessor functions for 
> big-endian MMIO access, intended to support MIPS platforms like RTL930X.
> 
>> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
>> index e0eb7240a9859..001a0c157d6a0 100644
>> --- a/drivers/pinctrl/pinctrl-single.c
>> +++ b/drivers/pinctrl/pinctrl-single.c
>> @@ -265,6 +265,26 @@ static void pcs_writel(unsigned int val, void __iomem *reg)
>>  	writel(val, reg);
>>  }
>>  
>> +static unsigned int pcs_readw_be(void __iomem *reg)
>> +{
>> +	return readw_be(reg);
>> +}
>> +
>> +static unsigned int pcs_readl_be(void __iomem *reg)
>> +{
>> +	return readl_be(reg);
>> +}
>> +
>> +static void pcs_writew_be(unsigned int val, void __iomem *reg)
>> +{
>> +	writew_be(val, reg);
>> +}
>> +
>> +static void pcs_writel_be(unsigned int val, void __iomem *reg)
>> +{
>> +	writel_be(val, reg);
>> +}
> 
> [Severity: Low]
> Will this break the build on architectures like ARM and ARM64?
> 
> The macros readw_be, readl_be, writew_be, and writel_be are strictly
> architecture-specific and do not exist in standard generic headers like
> <asm-generic/io.h>. Since pinctrl-single is a generic driver heavily used on
> architectures like ARM and ARM64, compiling these macros will result in build
> failures due to undefined reference or implicit declaration errors.
> 
> Should this use the generic kernel APIs ioread32be / iowrite32be (and their
> 16-bit equivalents ioread16be / iowrite16be) for big-endian MMIO access
> instead?

Interesting that these macros are not in generic files... Why then this is a
low severity if it will cause build issue on some architectures is questionable
to me but i will change the patch to use the the mentioned functions instead.