[PATCH 0/2] gpio: realtek-otto: make the driver work with SWAP_IO_SPACE

[PATCH 0/2] gpio: realtek-otto: make the driver work with SWAP_IO_SPACE

[Rustam Adilov]

This patch series changes gpio-realtek-otto to be functional around
SWAP_IO_SPACE config.

Firstly the ioread32 and iowrite32 in realtek_gpio_update_line_imr()
have to be changed to their __raw variants as it is the only point in
the driver where both devices with ports reversed and without meet.

Secondly, the bank_read/write and the flag for generic gpio config
have to be separated from GPIO_PORTS_REVERSED as they have to be
changed to the opposite one when SWAP_IO_SPACE is enabled. The
device_is_big_endian() function seem to be a good choice for it.
That does mean the rtl838x, rtl839x and rtl931x has to add
big-endian property to their gpio controller nodes for gpio to be
operational without SWAP_IO_SPACE.

I have tested it on my RTL9607C machine with SWAP_IO_SPACE enabled
and with big-endian property set under gpio controller node and it
was working fine.

Rustam Adilov (2):
  gpio: realtek-otto: use __raw_readl/writel in
    realtek_gpio_update_line_imr()
  gpio: realtek-otto: decide bank_read/write by device endianness

 drivers/gpio/gpio-realtek-otto.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

-- 
2.55.0

[PATCH 1/2] gpio: realtek-otto: use __raw_readl/writel in realtek_gpio_update_line_imr()

[Rustam Adilov]

In preparation for upcoming changes to how bank reads and writes
are defined in this driver, change the ioread32 and iowrite32 to
their __raw variants. The realtek_gpio_update_line_imr() function
is used by all devices regardless of GPIO_PORTS_REVERSED flag and
thus this is the only place where there shouldn't be any byte
swapping whether SWAP_IO_SPACE config is enabled or not and that
is only possible with __raw_readl and __raw_writel.

Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
 drivers/gpio/gpio-realtek-otto.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
index 4a606bad5848..491fde846d46 100644
--- a/drivers/gpio/gpio-realtek-otto.c
+++ b/drivers/gpio/gpio-realtek-otto.c
@@ -176,10 +176,10 @@ static void realtek_gpio_update_line_imr(struct realtek_gpio_ctrl *ctrl, unsigne
 	u32 reg_val;
 
 	reg += 4 * (line_shift / 32);
-	reg_val = ioread32(reg);
+	reg_val = __raw_readl(reg);
 	reg_val &= ~(REALTEK_GPIO_IMR_LINE_MASK << shift);
 	reg_val |= (irq_type & irq_mask & REALTEK_GPIO_IMR_LINE_MASK) << shift;
-	iowrite32(reg_val, reg);
+	__raw_writel(reg_val, reg);
 }
 
 static void realtek_gpio_irq_ack(struct irq_data *data)
-- 
2.55.0

Re: [PATCH 1/2] gpio: realtek-otto: use __raw_readl/writel in realtek_gpio_update_line_imr()

[Sander Vanheule]

Hi,

Adding linux-mips as SWAP_IO_SPACE is mostly a MIPS thing, and some lists/people
for your other pending patches.

On Fri, 2026-07-10 at 23:34 +0500, Rustam Adilov wrote:
> In preparation for upcoming changes to how bank reads and writes
> are defined in this driver, change the ioread32 and iowrite32 to
> their __raw variants. The realtek_gpio_update_line_imr() function
> is used by all devices regardless of GPIO_PORTS_REVERSED flag and
> thus this is the only place where there shouldn't be any byte
> swapping whether SWAP_IO_SPACE config is enabled or not and that
> is only possible with __raw_readl and __raw_writel.
> 
> Signed-off-by: Rustam Adilov <adilov@disroot.org>
> ---
>  drivers/gpio/gpio-realtek-otto.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-
> otto.c
> index 4a606bad5848..491fde846d46 100644
> --- a/drivers/gpio/gpio-realtek-otto.c
> +++ b/drivers/gpio/gpio-realtek-otto.c
> @@ -176,10 +176,10 @@ static void realtek_gpio_update_line_imr(struct
> realtek_gpio_ctrl *ctrl, unsigne
>  	u32 reg_val;
>  
>  	reg += 4 * (line_shift / 32);
> -	reg_val = ioread32(reg);
> +	reg_val = __raw_readl(reg);
>  	reg_val &= ~(REALTEK_GPIO_IMR_LINE_MASK << shift);
>  	reg_val |= (irq_type & irq_mask & REALTEK_GPIO_IMR_LINE_MASK) <<
> shift;
> -	iowrite32(reg_val, reg);
> +	__raw_writel(reg_val, reg);
>  }
>  
>  static void realtek_gpio_irq_ack(struct irq_data *data)

As per my earlier message on your watchdog patch [1], I'm still not convinced
converting all existing drivers [2, 3] to work around an issue with the USB
framework is the right thing to do. You claim the required USB changes are not
upstreamable, but I have not seen you make an attempt at doing so.

Can the people from linux-mips shine their light on whether using __raw_*() to
work around the effects of SWAP_IO_SPACE is reasonable? My gut feeling is this
indicates SWAP_IO_SPACE shouldn't be enabled. Markus has apparently made the
same remark [4].

[1] https://lore.kernel.org/all/ebdcb8c5563ceff723f3e4a3c4fdfe9bf87d42fa.camel@svanheule.net/
[2] https://lore.kernel.org/linux-watchdog/20260710074316.46643-1-adilov@disroot.org/
[3] https://lore.kernel.org/all/20260511131520.98420-1-adilov@disroot.org/
[4] https://lore.kernel.org/all/016d01dce49a$36b7bd60$a4273820$@gmx.de/

Best,
Sander

[PATCH 2/2] gpio: realtek-otto: decide bank_read/write by device endianness

[Rustam Adilov]

In order to have a working gpio controller with SWAP_IO_SPACE,
the way bank_read and bank_write are defined must be changed and
separated from GPIO_PORTS_REVERSED flag. That also includes the
flags parameter used by gpio_generic_chip_config.

To achieve it, use the device_is_big_endian() to decide the
bank_read/write parameter and the flag.

Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
 drivers/gpio/gpio-realtek-otto.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
index 491fde846d46..f96072fbce92 100644
--- a/drivers/gpio/gpio-realtek-otto.c
+++ b/drivers/gpio/gpio-realtek-otto.c
@@ -393,16 +393,19 @@ static int realtek_gpio_probe(struct platform_device *pdev)
 
 	raw_spin_lock_init(&ctrl->lock);
 
-	if (dev_flags & GPIO_PORTS_REVERSED) {
-		gen_gc_flags = 0;
-		ctrl->bank_read = realtek_gpio_bank_read;
-		ctrl->bank_write = realtek_gpio_bank_write;
+	if (dev_flags & GPIO_PORTS_REVERSED)
 		ctrl->line_imr_pos = realtek_gpio_line_imr_pos;
-	} else {
+	else
+		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
+
+	if (device_is_big_endian(dev)) {
 		gen_gc_flags = GPIO_GENERIC_BIG_ENDIAN_BYTE_ORDER;
 		ctrl->bank_read = realtek_gpio_bank_read_swapped;
 		ctrl->bank_write = realtek_gpio_bank_write_swapped;
-		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
+	} else {
+		gen_gc_flags = 0;
+		ctrl->bank_read = realtek_gpio_bank_read;
+		ctrl->bank_write = realtek_gpio_bank_write;
 	}
 
 	config = (struct gpio_generic_chip_config) {
-- 
2.55.0

Re: [PATCH 2/2] gpio: realtek-otto: decide bank_read/write by device endianness

[Bartosz Golaszewski]

On Fri, 10 Jul 2026 20:34:39 +0200, Rustam Adilov <adilov@disroot.org> said:
> In order to have a working gpio controller with SWAP_IO_SPACE,
> the way bank_read and bank_write are defined must be changed and
> separated from GPIO_PORTS_REVERSED flag. That also includes the
> flags parameter used by gpio_generic_chip_config.
>
> To achieve it, use the device_is_big_endian() to decide the
> bank_read/write parameter and the flag.
>
> Signed-off-by: Rustam Adilov <adilov@disroot.org>
> ---
>  drivers/gpio/gpio-realtek-otto.c | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
> index 491fde846d46..f96072fbce92 100644
> --- a/drivers/gpio/gpio-realtek-otto.c
> +++ b/drivers/gpio/gpio-realtek-otto.c
> @@ -393,16 +393,19 @@ static int realtek_gpio_probe(struct platform_device *pdev)
>
>  	raw_spin_lock_init(&ctrl->lock);
>
> -	if (dev_flags & GPIO_PORTS_REVERSED) {
> -		gen_gc_flags = 0;
> -		ctrl->bank_read = realtek_gpio_bank_read;
> -		ctrl->bank_write = realtek_gpio_bank_write;
> +	if (dev_flags & GPIO_PORTS_REVERSED)
>  		ctrl->line_imr_pos = realtek_gpio_line_imr_pos;
> -	} else {
> +	else
> +		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
> +
> +	if (device_is_big_endian(dev)) {
>  		gen_gc_flags = GPIO_GENERIC_BIG_ENDIAN_BYTE_ORDER;
>  		ctrl->bank_read = realtek_gpio_bank_read_swapped;
>  		ctrl->bank_write = realtek_gpio_bank_write_swapped;
> -		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
> +	} else {
> +		gen_gc_flags = 0;
> +		ctrl->bank_read = realtek_gpio_bank_read;
> +		ctrl->bank_write = realtek_gpio_bank_write;
>  	}
>
>  	config = (struct gpio_generic_chip_config) {
> --
> 2.55.0
>
>

Can you look at the sashiko report? I think it's right about this change
possibly breaking existing devicetrees. Can we keep big-endian as the
default?

Bart

Re: [PATCH 2/2] gpio: realtek-otto: decide bank_read/write by device endianness

[Rustam Adilov]

Hello,
On 2026-07-15 09:39, Bartosz Golaszewski wrote:
> On Fri, 10 Jul 2026 20:34:39 +0200, Rustam Adilov <adilov@disroot.org> said:
>> In order to have a working gpio controller with SWAP_IO_SPACE,
>> the way bank_read and bank_write are defined must be changed and
>> separated from GPIO_PORTS_REVERSED flag. That also includes the
>> flags parameter used by gpio_generic_chip_config.
>>
>> To achieve it, use the device_is_big_endian() to decide the
>> bank_read/write parameter and the flag.
>>
>> Signed-off-by: Rustam Adilov <adilov@disroot.org>
>> ---
>>  drivers/gpio/gpio-realtek-otto.c | 15 +++++++++------
>>  1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
>> index 491fde846d46..f96072fbce92 100644
>> --- a/drivers/gpio/gpio-realtek-otto.c
>> +++ b/drivers/gpio/gpio-realtek-otto.c
>> @@ -393,16 +393,19 @@ static int realtek_gpio_probe(struct platform_device *pdev)
>>
>>  	raw_spin_lock_init(&ctrl->lock);
>>
>> -	if (dev_flags & GPIO_PORTS_REVERSED) {
>> -		gen_gc_flags = 0;
>> -		ctrl->bank_read = realtek_gpio_bank_read;
>> -		ctrl->bank_write = realtek_gpio_bank_write;
>> +	if (dev_flags & GPIO_PORTS_REVERSED)
>>  		ctrl->line_imr_pos = realtek_gpio_line_imr_pos;
>> -	} else {
>> +	else
>> +		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
>> +
>> +	if (device_is_big_endian(dev)) {
>>  		gen_gc_flags = GPIO_GENERIC_BIG_ENDIAN_BYTE_ORDER;
>>  		ctrl->bank_read = realtek_gpio_bank_read_swapped;
>>  		ctrl->bank_write = realtek_gpio_bank_write_swapped;
>> -		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
>> +	} else {
>> +		gen_gc_flags = 0;
>> +		ctrl->bank_read = realtek_gpio_bank_read;
>> +		ctrl->bank_write = realtek_gpio_bank_write;
>>  	}
>>
>>  	config = (struct gpio_generic_chip_config) {
>> --
>> 2.55.0
>>
>>
> 
> Can you look at the sashiko report? I think it's right about this change
> possibly breaking existing devicetrees. Can we keep big-endian as the
> default?
> 
> Bart

Oh i didn't know sashiko was looking after this subsystem too.
But yes, it does require the rtl8380-gpio, rtl8390-gpio, rtl9310-gpio
to append big-endian or native-endian (as they are all big endian chips).

I was thinking earlier whatever it is appropriate to make changes to
the arch/mips/boot/dts/realtek in this commit because it is different
subsystem entirely but i guess this (previous sentence) answers the
question, doesn't it.

Also, what exactly do you mean by "Can we keep big-endian as the
default?" ? My only reading off is to change the if statement
so that the big endian flag and the _swapped functions to be
under the else part, is it correct?

Best,
Rustam

Re: [PATCH 2/2] gpio: realtek-otto: decide bank_read/write by device endianness

[Bartosz Golaszewski]

On Wed, 15 Jul 2026 21:00:45 +0200, Rustam Adilov <adilov@disroot.org> said:
> Hello,
> On 2026-07-15 09:39, Bartosz Golaszewski wrote:
>> On Fri, 10 Jul 2026 20:34:39 +0200, Rustam Adilov <adilov@disroot.org> said:
>>> In order to have a working gpio controller with SWAP_IO_SPACE,
>>> the way bank_read and bank_write are defined must be changed and
>>> separated from GPIO_PORTS_REVERSED flag. That also includes the
>>> flags parameter used by gpio_generic_chip_config.
>>>
>>> To achieve it, use the device_is_big_endian() to decide the
>>> bank_read/write parameter and the flag.
>>>
>>> Signed-off-by: Rustam Adilov <adilov@disroot.org>
>>> ---
>>>  drivers/gpio/gpio-realtek-otto.c | 15 +++++++++------
>>>  1 file changed, 9 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
>>> index 491fde846d46..f96072fbce92 100644
>>> --- a/drivers/gpio/gpio-realtek-otto.c
>>> +++ b/drivers/gpio/gpio-realtek-otto.c
>>> @@ -393,16 +393,19 @@ static int realtek_gpio_probe(struct platform_device *pdev)
>>>
>>>  	raw_spin_lock_init(&ctrl->lock);
>>>
>>> -	if (dev_flags & GPIO_PORTS_REVERSED) {
>>> -		gen_gc_flags = 0;
>>> -		ctrl->bank_read = realtek_gpio_bank_read;
>>> -		ctrl->bank_write = realtek_gpio_bank_write;
>>> +	if (dev_flags & GPIO_PORTS_REVERSED)
>>>  		ctrl->line_imr_pos = realtek_gpio_line_imr_pos;
>>> -	} else {
>>> +	else
>>> +		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
>>> +
>>> +	if (device_is_big_endian(dev)) {
>>>  		gen_gc_flags = GPIO_GENERIC_BIG_ENDIAN_BYTE_ORDER;
>>>  		ctrl->bank_read = realtek_gpio_bank_read_swapped;
>>>  		ctrl->bank_write = realtek_gpio_bank_write_swapped;
>>> -		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
>>> +	} else {
>>> +		gen_gc_flags = 0;
>>> +		ctrl->bank_read = realtek_gpio_bank_read;
>>> +		ctrl->bank_write = realtek_gpio_bank_write;
>>>  	}
>>>
>>>  	config = (struct gpio_generic_chip_config) {
>>> --
>>> 2.55.0
>>>
>>>
>>
>> Can you look at the sashiko report? I think it's right about this change
>> possibly breaking existing devicetrees. Can we keep big-endian as the
>> default?
>>
>> Bart
>
> Oh i didn't know sashiko was looking after this subsystem too.
> But yes, it does require the rtl8380-gpio, rtl8390-gpio, rtl9310-gpio
> to append big-endian or native-endian (as they are all big endian chips).
>
> I was thinking earlier whatever it is appropriate to make changes to
> the arch/mips/boot/dts/realtek in this commit because it is different
> subsystem entirely but i guess this (previous sentence) answers the
> question, doesn't it.
>

That's irrelevant as there may be devicetrees out in the wild and we can't
just break them.

> Also, what exactly do you mean by "Can we keep big-endian as the
> default?" ? My only reading off is to change the if statement
> so that the big endian flag and the _swapped functions to be
> under the else part, is it correct?
>

Yes, just retain the original default behavior.

Bart

Re: [PATCH 2/2] gpio: realtek-otto: decide bank_read/write by device endianness

[Rustam Adilov]

On 2026-07-17 10:39, Bartosz Golaszewski wrote:
> On Wed, 15 Jul 2026 21:00:45 +0200, Rustam Adilov <adilov@disroot.org> said:
>> Hello,
>> On 2026-07-15 09:39, Bartosz Golaszewski wrote:
>>> On Fri, 10 Jul 2026 20:34:39 +0200, Rustam Adilov <adilov@disroot.org> said:
>>>> In order to have a working gpio controller with SWAP_IO_SPACE,
>>>> the way bank_read and bank_write are defined must be changed and
>>>> separated from GPIO_PORTS_REVERSED flag. That also includes the
>>>> flags parameter used by gpio_generic_chip_config.
>>>>
>>>> To achieve it, use the device_is_big_endian() to decide the
>>>> bank_read/write parameter and the flag.
>>>>
>>>> Signed-off-by: Rustam Adilov <adilov@disroot.org>
>>>> ---
>>>>  drivers/gpio/gpio-realtek-otto.c | 15 +++++++++------
>>>>  1 file changed, 9 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
>>>> index 491fde846d46..f96072fbce92 100644
>>>> --- a/drivers/gpio/gpio-realtek-otto.c
>>>> +++ b/drivers/gpio/gpio-realtek-otto.c
>>>> @@ -393,16 +393,19 @@ static int realtek_gpio_probe(struct platform_device *pdev)
>>>>
>>>>  	raw_spin_lock_init(&ctrl->lock);
>>>>
>>>> -	if (dev_flags & GPIO_PORTS_REVERSED) {
>>>> -		gen_gc_flags = 0;
>>>> -		ctrl->bank_read = realtek_gpio_bank_read;
>>>> -		ctrl->bank_write = realtek_gpio_bank_write;
>>>> +	if (dev_flags & GPIO_PORTS_REVERSED)
>>>>  		ctrl->line_imr_pos = realtek_gpio_line_imr_pos;
>>>> -	} else {
>>>> +	else
>>>> +		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
>>>> +
>>>> +	if (device_is_big_endian(dev)) {
>>>>  		gen_gc_flags = GPIO_GENERIC_BIG_ENDIAN_BYTE_ORDER;
>>>>  		ctrl->bank_read = realtek_gpio_bank_read_swapped;
>>>>  		ctrl->bank_write = realtek_gpio_bank_write_swapped;
>>>> -		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
>>>> +	} else {
>>>> +		gen_gc_flags = 0;
>>>> +		ctrl->bank_read = realtek_gpio_bank_read;
>>>> +		ctrl->bank_write = realtek_gpio_bank_write;
>>>>  	}
>>>>
>>>>  	config = (struct gpio_generic_chip_config) {
>>>> --
>>>> 2.55.0
>>>>
>>>>
>>>
>>> Can you look at the sashiko report? I think it's right about this change
>>> possibly breaking existing devicetrees. Can we keep big-endian as the
>>> default?
>>>
>>> Bart
>>
>> Oh i didn't know sashiko was looking after this subsystem too.
>> But yes, it does require the rtl8380-gpio, rtl8390-gpio, rtl9310-gpio
>> to append big-endian or native-endian (as they are all big endian chips).
>>
>> I was thinking earlier whatever it is appropriate to make changes to
>> the arch/mips/boot/dts/realtek in this commit because it is different
>> subsystem entirely but i guess this (previous sentence) answers the
>> question, doesn't it.
>>
> 
> That's irrelevant as there may be devicetrees out in the wild and we can't
> just break them.

So, what is the solution then? Cause relying on device tree property the
driver did not rely on before would break stuff, though realistically it
is only relevant to OpenWrt and here. If we instead just create a flag
in the driver like PORTS_REVERSED, then we would have to patch it again
when SWAP_IO_SPACE is selected in the future and that is more hassle than
simply changing device tree property. Unless i am missing something, these
are the only possible ways of going about it that i can think of.

>> Also, what exactly do you mean by "Can we keep big-endian as the
>> default?" ? My only reading off is to change the if statement
>> so that the big endian flag and the _swapped functions to be
>> under the else part, is it correct?
>>
> 
> Yes, just retain the original default behavior.
> 
> Bart

Best,
Rustam

Re: [PATCH 2/2] gpio: realtek-otto: decide bank_read/write by device endianness

[Bartosz Golaszewski]

On Sun, 19 Jul 2026 06:17:01 +0200, Rustam Adilov <adilov@disroot.org> said:
> On 2026-07-17 10:39, Bartosz Golaszewski wrote:
>> On Wed, 15 Jul 2026 21:00:45 +0200, Rustam Adilov <adilov@disroot.org> said:
>>> Hello,
>>> On 2026-07-15 09:39, Bartosz Golaszewski wrote:
>>>> On Fri, 10 Jul 2026 20:34:39 +0200, Rustam Adilov <adilov@disroot.org> said:
>>>>> In order to have a working gpio controller with SWAP_IO_SPACE,
>>>>> the way bank_read and bank_write are defined must be changed and
>>>>> separated from GPIO_PORTS_REVERSED flag. That also includes the
>>>>> flags parameter used by gpio_generic_chip_config.
>>>>>
>>>>> To achieve it, use the device_is_big_endian() to decide the
>>>>> bank_read/write parameter and the flag.
>>>>>
>>>>> Signed-off-by: Rustam Adilov <adilov@disroot.org>
>>>>> ---
>>>>>  drivers/gpio/gpio-realtek-otto.c | 15 +++++++++------
>>>>>  1 file changed, 9 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
>>>>> index 491fde846d46..f96072fbce92 100644
>>>>> --- a/drivers/gpio/gpio-realtek-otto.c
>>>>> +++ b/drivers/gpio/gpio-realtek-otto.c
>>>>> @@ -393,16 +393,19 @@ static int realtek_gpio_probe(struct platform_device *pdev)
>>>>>
>>>>>  	raw_spin_lock_init(&ctrl->lock);
>>>>>
>>>>> -	if (dev_flags & GPIO_PORTS_REVERSED) {
>>>>> -		gen_gc_flags = 0;
>>>>> -		ctrl->bank_read = realtek_gpio_bank_read;
>>>>> -		ctrl->bank_write = realtek_gpio_bank_write;
>>>>> +	if (dev_flags & GPIO_PORTS_REVERSED)
>>>>>  		ctrl->line_imr_pos = realtek_gpio_line_imr_pos;
>>>>> -	} else {
>>>>> +	else
>>>>> +		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
>>>>> +
>>>>> +	if (device_is_big_endian(dev)) {
>>>>>  		gen_gc_flags = GPIO_GENERIC_BIG_ENDIAN_BYTE_ORDER;
>>>>>  		ctrl->bank_read = realtek_gpio_bank_read_swapped;
>>>>>  		ctrl->bank_write = realtek_gpio_bank_write_swapped;
>>>>> -		ctrl->line_imr_pos = realtek_gpio_line_imr_pos_swapped;
>>>>> +	} else {
>>>>> +		gen_gc_flags = 0;
>>>>> +		ctrl->bank_read = realtek_gpio_bank_read;
>>>>> +		ctrl->bank_write = realtek_gpio_bank_write;
>>>>>  	}
>>>>>
>>>>>  	config = (struct gpio_generic_chip_config) {
>>>>> --
>>>>> 2.55.0
>>>>>
>>>>>
>>>>
>>>> Can you look at the sashiko report? I think it's right about this change
>>>> possibly breaking existing devicetrees. Can we keep big-endian as the
>>>> default?
>>>>
>>>> Bart
>>>
>>> Oh i didn't know sashiko was looking after this subsystem too.
>>> But yes, it does require the rtl8380-gpio, rtl8390-gpio, rtl9310-gpio
>>> to append big-endian or native-endian (as they are all big endian chips).
>>>
>>> I was thinking earlier whatever it is appropriate to make changes to
>>> the arch/mips/boot/dts/realtek in this commit because it is different
>>> subsystem entirely but i guess this (previous sentence) answers the
>>> question, doesn't it.
>>>
>>
>> That's irrelevant as there may be devicetrees out in the wild and we can't
>> just break them.
>
> So, what is the solution then? Cause relying on device tree property the
> driver did not rely on before would break stuff, though realistically it
> is only relevant to OpenWrt and here. If we instead just create a flag
> in the driver like PORTS_REVERSED, then we would have to patch it again
> when SWAP_IO_SPACE is selected in the future and that is more hassle than
> simply changing device tree property. Unless i am missing something, these
> are the only possible ways of going about it that i can think of.
>

I don't know the details of this use case. In general: devicetree support is
considered stable ABI. If a driver ever supported a certain property in any
release it must do so indefinitely. Any changes you propose must retain the
same behavior for existing users - even if they are missing certain DT flags,
even if they're out of tree. We don't care about breaking the code of
out-of-tree drivers but we *do* care about breaking out-of-tree devicetrees.

Bart