From: Rustam Adilov <adilov@disroot.org>
To: Sander Vanheule <sander@svanheule.net>
Cc: Linus Walleij <linusw@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mips@vger.kernel.org, linux-watchdog@vger.kernel.org,
Guenter Roeck <linux@roeck-us.net>,
markus.stockhausen@gmx.de,
Daniel Lezcano <daniel.lezcano@kernel.org>,
Thomas Gleixner <tglx@kernel.org>
Subject: Re: [PATCH 1/2] gpio: realtek-otto: use __raw_readl/writel in realtek_gpio_update_line_imr()
Date: Tue, 21 Jul 2026 17:16:22 +0000 [thread overview]
Message-ID: <67b04e0f531c3d7a295cc5fc37b62a21@disroot.org> (raw)
In-Reply-To: <d27c366d6e28a5f50ddcdfe456bf844cbaab9d0a.camel@svanheule.net>
Hello,
On 2026-07-20 16:32, Sander Vanheule wrote:
> Hi,
>
> Adding linux-mips as SWAP_IO_SPACE is mostly a MIPS thing, and some lists/people
> for your other pending patches.
I think linux-mips would have been enough but that's fine.
> 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.
Yes, i did claim it and the lack of attempt is my fault which i should have done
right away when i sent out the patches to phy-rtk-usb2.c [5] back in March.
I've just set the expectations that to me seem very logical but didn't get to
check them in practice. Though really my reasoning comes down to "We are trying
to recreate what readl() and writel() should supposedly do and SWAP_IO_SPACE is
only way to make them work".
I don't think it is necessary specific to USB as the same would have happened if
some other peripheral were to be in "little endian" mode. That is because our
realtek chips are big endian MIPS and kernel has an interesting ways of going
about their io.
There is however an ongoing patch series in linux-usb [6] that could be of use
if SWAP_IO_SPACE turns out to be a wrong approach after all.
[5] https://lore.kernel.org/linux-phy/20260326193419.48419-1-adilov@disroot.org/
[6] https://lore.kernel.org/linux-usb/20260713122205.1350933-1-daniel@thingy.jp/
> 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
Best,
Rustam
next prev parent reply other threads:[~2026-07-21 17:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 18:34 [PATCH 0/2] gpio: realtek-otto: make the driver work with SWAP_IO_SPACE Rustam Adilov
2026-07-10 18:34 ` [PATCH 1/2] gpio: realtek-otto: use __raw_readl/writel in realtek_gpio_update_line_imr() Rustam Adilov
2026-07-20 16:32 ` Sander Vanheule
2026-07-21 17:16 ` Rustam Adilov [this message]
2026-07-25 9:39 ` Linus Walleij
2026-07-10 18:34 ` [PATCH 2/2] gpio: realtek-otto: decide bank_read/write by device endianness Rustam Adilov
2026-07-15 9:39 ` Bartosz Golaszewski
2026-07-15 19:00 ` Rustam Adilov
2026-07-17 10:39 ` Bartosz Golaszewski
2026-07-19 4:17 ` Rustam Adilov
2026-07-20 14:00 ` Bartosz Golaszewski
2026-07-25 9:28 ` Linus Walleij
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=67b04e0f531c3d7a295cc5fc37b62a21@disroot.org \
--to=adilov@disroot.org \
--cc=brgl@kernel.org \
--cc=daniel.lezcano@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=markus.stockhausen@gmx.de \
--cc=sander@svanheule.net \
--cc=tglx@kernel.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
Powered by JetHome