Linux Watchdog driver development
 help / color / mirror / Atom feed
From: Rustam Adilov <adilov@disroot.org>
To: Sander Vanheule <sander@svanheule.net>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Wim Van Sebroeck <wim@linux-watchdog.org>,
	linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/1] watchdog: realtek-otto: Make use of regmap API
Date: Sat, 04 Jul 2026 15:13:15 +0000	[thread overview]
Message-ID: <9362a24cca55f60f89157ca9537a5eab@disroot.org> (raw)
In-Reply-To: <6cb55a3e4876ec7955c99f1ea29862b38448491a.camel@svanheule.net>

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

  reply	other threads:[~2026-07-04 15:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19 18:23 [PATCH v2 0/1] watchdog: realtek-otto: Make use of regmap API Rustam Adilov
2026-05-19 18:23 ` [PATCH v2 1/1] watchdog: realtek-otto: Change to use " Rustam Adilov
2026-05-19 18:56   ` sashiko-bot
2026-05-19 19:00   ` Sander Vanheule
2026-05-19 19:25     ` Guenter Roeck
2026-05-26 20:23       ` Rustam Adilov
2026-06-20 11:23 ` [PATCH v2 0/1] watchdog: realtek-otto: Make use of " Rustam Adilov
2026-06-23 18:44   ` Guenter Roeck
2026-06-23 20:44     ` Sander Vanheule
2026-07-01 18:48       ` Rustam Adilov
2026-07-04 14:00         ` Sander Vanheule
2026-07-04 15:13           ` Rustam Adilov [this message]
2026-07-04 16:05             ` Sander Vanheule

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9362a24cca55f60f89157ca9537a5eab@disroot.org \
    --to=adilov@disroot.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=sander@svanheule.net \
    --cc=wim@linux-watchdog.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox