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

[Sander Vanheule <sander@svanheule.net>]

Hi Rustam,

On Sat, 2026-07-04 at 15:13 +0000, Rustam Adilov wrote:
> On 2026-07-04 14:00, Sander Vanheule wrote:
> > 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

Thanks for the extra details. From a quick glance, I have to say that the extra
OHCI/EHCI quirks from [1] don't look too offensive, but I'm not familiar with
the USB subsystem.

Those USB frameworks already have quirks for mixed-endian systems, so maybe the
issue is more that nobody has had the need to support your situation yet. If you
(or Carlo) are not sure how to clean that up, you can submit those changes as an
RFC to get some feedback without a full blown review. Maybe also involve linux-
mips then.

Best,
Sander