From: Niklas Cassel <cassel@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: "Shawn Lin" <shawn.lin@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Brian Norris" <briannorris@chromium.org>,
linux-pci@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, mhi@lists.linux.dev,
stable@vger.kernel.org, "Slark Xiao" <slark_xiao@163.com>
Subject: Re: [PATCH] PCI: rockchip: Use GPIOD_OUT_LOW flag while requesting ep_gpio
Date: Tue, 16 Apr 2024 08:49:53 +0200 [thread overview]
Message-ID: <Zh4fkbQTh0Z1GNGK@ryzen> (raw)
In-Reply-To: <20240416-pci-rockchip-perst-fix-v1-1-4800b1d4d954@linaro.org>
On Tue, Apr 16, 2024 at 11:12:35AM +0530, Manivannan Sadhasivam wrote:
> Rockchip platforms use 'GPIO_ACTIVE_HIGH' flag in the devicetree definition
> for ep_gpio. This means, whatever the logical value set by the driver for
> the ep_gpio, physical line will output the same logic level.
>
> For instance,
>
> gpiod_set_value_cansleep(rockchip->ep_gpio, 0); --> Level low
> gpiod_set_value_cansleep(rockchip->ep_gpio, 1); --> Level high
>
> But while requesting the ep_gpio, GPIOD_OUT_HIGH flag is currently used.
> Now, this also causes the physical line to output 'high' creating trouble
> for endpoint devices during host reboot.
>
> When host reboot happens, the ep_gpio will initially output 'low' due to
> the GPIO getting reset to its POR value. Then during host controller probe,
> it will output 'high' due to GPIOD_OUT_HIGH flag. Then during
> rockchip_pcie_host_init_port(), it will first output 'low' and then 'high'
> indicating the completion of controller initialization.
>
> On the endpoint side, each output 'low' of ep_gpio is accounted for PERST#
> assert and 'high' for PERST# deassert. With the above mentioned flow during
> host reboot, endpoint will witness below state changes for PERST#:
>
> (1) PERST# assert - GPIO POR state
> (2) PERST# deassert - GPIOD_OUT_HIGH while requesting GPIO
> (3) PERST# assert - rockchip_pcie_host_init_port()
> (4) PERST# deassert - rockchip_pcie_host_init_port()
>
> Now the time interval between (2) and (3) is very short as both happen
> during the driver probe(), and this results in a race in the endpoint.
> Because, before completing the PERST# deassertion in (2), endpoint got
> another PERST# assert in (3).
>
> A proper way to fix this issue is to change the GPIOD_OUT_HIGH flag in (2)
> to GPIOD_OUT_LOW. Because the usual convention is to request the GPIO with
> a state corresponding to its 'initial/default' value and let the driver
> change the state of the GPIO when required.
>
> As per that, the ep_gpio should be requested with GPIOD_OUT_LOW as it
> corresponds to the POR value of '0' (PERST# assert in the endpoint). Then
> the driver can change the state of the ep_gpio later in
> rockchip_pcie_host_init_port() as per the initialization sequence.
>
> This fixes the firmware crash issue in Qcom based modems connected to
> Rockpro64 based board.
>
> Cc: <stable@vger.kernel.org> # 4.9
> Reported-by: Slark Xiao <slark_xiao@163.com>
> Closes: https://lore.kernel.org/mhi/20240402045647.GG2933@thinkpad/
> Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
Reviewed-by: Niklas Cassel <cassel@kernel.org>
I sent a similar fix for the DWC-based rockchip driver a few weeks ago:
https://lore.kernel.org/linux-pci/20240327152531.814392-1-cassel@kernel.org/
If your fix is picked up, it would be nice if mine got picked up as well,
such that both drivers get fixed.
Kind regards,
Niklas
next prev parent reply other threads:[~2024-04-16 6:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 5:42 [PATCH] PCI: rockchip: Use GPIOD_OUT_LOW flag while requesting ep_gpio Manivannan Sadhasivam
2024-04-16 6:49 ` Niklas Cassel [this message]
2024-04-16 9:15 ` Manivannan Sadhasivam
2024-05-15 21:18 ` Bjorn Helgaas
2024-05-17 11:21 ` Krzysztof Wilczyński
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=Zh4fkbQTh0Z1GNGK@ryzen \
--to=cassel@kernel.org \
--cc=bhelgaas@google.com \
--cc=briannorris@chromium.org \
--cc=heiko@sntech.de \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mhi@lists.linux.dev \
--cc=robh@kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=slark_xiao@163.com \
--cc=stable@vger.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