[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <051fdbe1-e5d9-4d5d-bc1a-921d8d3d4a9e@kernel.org>
Date: Mon, 23 Sep 2024 11:44:25 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: Florian Fainelli <florian.fainelli@...adcom.com>,
linux-serial@...r.kernel.org
Cc: Jim Quinlan <james.quinlan@...adcom.com>,
Kevin Cernekee <cernekee@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
John Ogness <john.ogness@...utronix.de>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
"open list:TTY LAYER AND SERIAL DRIVERS" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tty: rp2: Fix reset with non forgiving PCIe host bridges
On 07. 09. 24, 0:54, Florian Fainelli wrote:
> The write to RP2_GLOBAL_CMD followed by an immediate read of
> RP2_GLOBAL_CMD in rp2_reset_asic() is intented to flush out the write,
> however by then the device is already in reset and cannot respond to a
> memory cycle access.
>
> On platforms such as the Raspberry Pi 4 and others using the
> pcie-brcmstb.c driver, any memory access to a device that cannot respond
> is met with a fatal system error, rather than being substituted with all
> 1s as is usually the case on PC platforms.
>
> Swapping the delay and the read ensures that the device has finished
> resetting before we attempt to read from it.
>
> Fixes: 7d9f49afa451 ("serial: rp2: New driver for Comtrol RocketPort 2 cards")
> Suggested-by: Jim Quinlan <james.quinlan@...adcom.com>
> Signed-off-by: Florian Fainelli <florian.fainelli@...adcom.com>
> ---
> drivers/tty/serial/rp2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/rp2.c b/drivers/tty/serial/rp2.c
> index 4132fcff7d4e..8bab2aedc499 100644
> --- a/drivers/tty/serial/rp2.c
> +++ b/drivers/tty/serial/rp2.c
> @@ -577,8 +577,8 @@ static void rp2_reset_asic(struct rp2_card *card, unsigned int asic_id)
> u32 clk_cfg;
>
> writew(1, base + RP2_GLOBAL_CMD);
> - readw(base + RP2_GLOBAL_CMD);
> msleep(100);
> + readw(base + RP2_GLOBAL_CMD);
The read was there to force PCI posting to really flush the write to the
device before the sleep (and not to post). How is this ensured now? (In
fact, instead of the move, you could have deleted it completely.)
Can you actually read another register which a resetting device would reply?
thanks,
--
js
suse labs
Powered by blists - more mailing lists