Re: [PATCH v2 0/1] watchdog: realtek-otto: Make use of regmap API

On 2026-07-04 14:00, Sander Vanheule wrote:
> On Wed, 2026-07-01 at 18:48 +0000, Rustam Adilov wrote:
>> Hello,
>> On 2026-06-23 20:44, Sander Vanheule wrote:
>> > Given the reason is endianess issues, does the GPIO driver (gpio-realtek-
>> > otto.c)
>> > using ioread32()/iowrite32() still work correctly? If you have the wrong
>> > endianess there, you would only really see issues with the GPIO interrupt
>> > handling.
>> > 
>> > If GPIO works correctly with CONFIG_SWAP_IO_SPACE enabled, then I suppose
>> > the
>> > watchdog driver needs to be amended. Otherwise perhaps the USB peripheral
>> > driver
>> > should be compensating for its endianess?
>> 
>> Actually, it is other way around. GPIO works correctly when
>> CONFIG_SWAP_IO_SPACE
>> is not enabled. When i do enable it, i need to patch the driver to make it
>> work.
>> The dirty patch is here [1], which simply changes ioread32()/iowrite32() to
>> their __raw variants inside gpio_bank_read and gpio_bank_write the and what is
>> also important, the GPIO_GENERIC_BIG_ENDIAN_BYTE_ORDER flag needs to be set.
>> And also, i can't simply use the compatibles without GPIO_PORTS_REVERSED
>> because
>> the realtek_gpio_line_imr_pos is required for correct functionality.
>> 
>> This patch obviously won't cut as it is going to break rtl9300 without
>> SWAP_IO_SPACE.
>> Maybe we could make of gpio-regmap to handle swapping and stuff? I don't know
>> of
>> any other elegant solutions to this problem.
>> 
>> [1] -
>> https://github.com/jameywine/openwrt/blob/bb94712cb6faccf082c5a9fcebfabddf837a16bb/target/linux/realtek/patches-6.18/814-gpio-realtek-otto-change-read-write-functions.patch
> 
> Looking at the full patch (*), I see you're not only modifying the GPIO,
> watchdog and timer drivers, but also some very basic reset and pinctrl code to
> have a functional system with SWAP_IO_SPACE. If SWAP_IO_SPACE requires you to
> avoid byte-swapping in so many drivers, then you're just working around
> SWAP_IO_SPACE. In other words, AFAICT it shouldn't be selected.
>
> (*) https://github.com/jameywine/openwrt/commit/053aba620b12c6215e6760d8a613b4ebe05d452b

I would say it is more of working around limitation of big endian MIPS with little
endian USB controller but more on that in the message below.

> If there is a single new USB peripheral driver that only works with
> SWAP_IO_SPACE, then I suggest you update that driver instead of enabling and
> bypassing the effects of SWAP_IO_SPACE everywhere else.

Sadly it is not much to do with a single USB driver (technically yes if you count
ohci-platform and ehci-platform) but everything to do with the reads and writes
functions in ehci.h and ohci.h files. If we don't select SWAP_IO_SPACE, we have to
basically change them to perform a byte swap as we can't use readl nor readl_be
functions for that. You can check how that would look like in [1] but that would
not be acceptable by upstream nor any other similar modifications to those header
files i don't think.

And that is a crux of the problem. That same can be seen with rtl930x and rtl931x
in [2]. SWAP_IO_SPACE as far as i can see, is the only solution to be upstreamable.

[1] https://github.com/openwrt/openwrt/commit/ba48e61e9da58b38d69fc58f90f9fcd93c11862b
[2] https://github.com/openwrt/openwrt/pull/23508

Best,
Rustam