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

[Sander Vanheule]

On Tue, 2026-06-23 at 11:44 -0700, Guenter Roeck wrote:
> On 6/20/26 04:23, Rustam Adilov wrote:
> > Hello,
> > 
> > I have noticed the status for this patch series is "Changes Requested"
> > in the patchwork site but the maintainer opposes the requested changes
> > by Sander in [1], so what do i do here? It is just one the roadblocks
> > to get USB stuff supported for Realtek chips.
> > 
> > I have already sent a reply week later in [2] but didn't get a response
> > back. Maybe this email could be served as a gentle remainder.
> > 
> 
> I said:
> 	So this is now a NACK if unnecessary error handling is indeed added,
> 	unless someone convinces me that this would add some benefits that I
> 	am unable to see.
> 
> Your response did not explain the benefits of adding the unnecessary error
> handling. I did not see a rationale from Sander either.

I mainly brought it up because I have been asked elsewhere [1] to check the
regmap return codes. Although that was for a device on an MDIO bus, which I
suppose is more likely to actually generate errors.

[1] https://lore.kernel.org/linux-leds/CAMRc=Mdb7CWB9PmzXJyfvGjvG0iwuwUgfLuKJuMweRFvAhAoHg@xxxxxxxxxxxxxx/

> On top of that, your patch did not explain the real reason for the patch,
> as stated in your reply. This means that, for me, it was just a patch making
> no functional changes for no good reason other than to potentially _increase_
> code complexity by adding unnecessary error handling while at the same time
> claiming that code complexity would be reduced.

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?

> Also, I do not recall even an attempt to address (or even comment on) the
> actual problem with the driver as reported by Sashiko.

I did have a look at this report [2], but I didn't manage to figure out if the
behavior I see matches the reasoning by the bot. Since I didn't get any
feedback, I left it as is.

[2] https://lore.kernel.org/linux-watchdog/d0b159eefa6bc5abf0d1531acde568396f480500.camel@xxxxxxxxxxxxx/

Best,
Sander