All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sander Vanheule <sander@svanheule.net>
To: linux-gpio@vger.kernel.org, Bartosz Golaszewski <brgl@bgdev.pl>,
	Linus Walleij <linus.walleij@linaro.org>
Cc: linux-kernel@vger.kernel.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Luiz Angelo Daros de Luca <luizluca@gmail.com>,
	Birger Koblitz <mail@birger-koblitz.de>,
	Jan Hoffmann <jan@3e8.eu>, Paul Cercueil <paul@crapouillou.net>
Subject: Re: [PATCH v2] gpio: realtek-otto: switch to 32-bit I/O
Date: Tue, 26 Jul 2022 09:41:28 +0200	[thread overview]
Message-ID: <d64b0d239972ed7b42a201d81ee1a7c4be96ece9.camel@svanheule.net> (raw)
In-Reply-To: <20220724113141.51646-1-sander@svanheule.net>

On Sun, 2022-07-24 at 13:31 +0200, Sander Vanheule wrote:
> By using 16-bit I/O on the GPIO peripheral, which is apparently not safe
> on MIPS, the IMR can end up containing garbage. This then results in
> interrupt triggers for lines that don't have an interrupt source
> associated. The irq_desc lookup fails, and the ISR will not be cleared,
> keeping the CPU busy until reboot, or until another IMR operation
> restores the correct value. This situation appears to happen very
> rarely, for < 0.5% of IMR writes.
> 
> Instead of using 8-bit or 16-bit I/O operations on the 32-bit memory
> mapped peripheral registers, switch to using 32-bit I/O only, operating
> on the entire bank for all single bit line settings. For 2-bit line
> settings, with 16-bit port values, stick to manual (un)packing.
> 
> This issue has been seen on RTL8382M (HPE 1920-16G), RTL8391M (Netgear
> GS728TP v2), and RTL8393M (D-Link DGS-1210-52 F3, Zyxel GS1900-48).
> 
> Reported-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> # DGS-1210-52
> Reported-by: Birger Koblitz <mail@birger-koblitz.de> # GS728TP
> Reported-by: Jan Hoffmann <jan@3e8.eu> # 1920-16G
> Cc: Paul Cercueil <paul@crapouillou.net>
> Signed-off-by: Sander Vanheule <sander@svanheule.net>
> ---

...

> @@ -307,16 +308,17 @@ static int realtek_gpio_irq_set_affinity(struct irq_data
> *data,
>  static int realtek_gpio_irq_init(struct gpio_chip *gc)
>  {
>         struct realtek_gpio_ctrl *ctrl = gpiochip_get_data(gc);
> -       unsigned int port;
> +       u32 mask_all = GENMASK(gc->ngpio, 0);

This should be GENMASK(gc->ngpio - 1, 0).

I'll wait a bit more for other comments before sending a v3.

Best,
Sander


      reply	other threads:[~2022-07-26  7:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-24 11:31 [PATCH v2] gpio: realtek-otto: switch to 32-bit I/O Sander Vanheule
2022-07-26  7:41 ` Sander Vanheule [this message]

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=d64b0d239972ed7b42a201d81ee1a7c4be96ece9.camel@svanheule.net \
    --to=sander@svanheule.net \
    --cc=andy.shevchenko@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=jan@3e8.eu \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luizluca@gmail.com \
    --cc=mail@birger-koblitz.de \
    --cc=paul@crapouillou.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.