From: Brian Norris <briannorris@chromium.org>
To: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-rockchip@lists.infradead.org,
Jeffy Chen <jeffy.chen@rock-chips.com>
Subject: Re: [PATCH] PCI: rockchip: check link status when validating device
Date: Tue, 23 May 2017 11:44:01 -0700 [thread overview]
Message-ID: <20170523184359.GB115572@google.com> (raw)
In-Reply-To: <1495177107-203736-1-git-send-email-shawn.lin@rock-chips.com>
I forgot, I had one more comment:
On Fri, May 19, 2017 at 02:58:27PM +0800, Shawn Lin wrote:
> This patch checks the link status before reading and
> writing configure space of devices attached to the RC.
> If the link status is down, we shouldn't try to access
> the devices.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
>
> drivers/pci/host/pcie-rockchip.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index 0e020b6..1e64227 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -275,9 +275,21 @@ static void rockchip_pcie_update_txcredit_mui(struct rockchip_pcie *rockchip)
> rockchip_pcie_write(rockchip, val, PCIE_CORE_TXCREDIT_CFG1);
> }
>
> +static inline bool rockchip_pcie_link_up(struct rockchip_pcie *rockchip)
> +{
> + return PCIE_LINK_UP(rockchip_pcie_read(rockchip,
> + PCIE_CLIENT_BASIC_STATUS1));
> +}
> +
> static int rockchip_pcie_valid_device(struct rockchip_pcie *rockchip,
> struct pci_bus *bus, int dev)
> {
> + /* do not access the devices if the link isn't completed */
> + if (bus->number != rockchip->root_bus_nr) {
> + if (!rockchip_pcie_link_up(rockchip))
> + return 0;
Not exactly a criticism of this patch directly, but the error handling
sequence that this triggers is strange, and I think it's inconsistent.
A 0 result here becomes PCIBIOS_DEVICE_NOT_FOUND for either the read or
write conf helpers. But the high level code doesn't handle this
consistently. See, e.g., pci_read_config_byte() which can return regular
Linux error codes (like -ENODEV), except it also passes up the return
code of pci_read_config_byte() (a PCIBIOS_* code) directly.
So callers don't really know whether to treat the value from
pci_read_config_<foo>() as a PCIBIOS_* code (which should be translated
with pcibios_err_to_errno()) or as a standard Linux errno.
But then, there are relatively few callers (less than 10% of
pci_read_config_<foo>(); even fewer for writes) that actually check the
error codes...
Maybe the "fix" is to replace -ENODEV with PCIBIOS_DEVICE_NOT_FOUND for
the inconsistent cases (pci_{read,write}_config_{byte,word,dword}()).
Brian
> + }
> +
> /* access only one slot on each root port */
> if (bus->number == rockchip->root_bus_nr && dev > 0)
> return 0;
> --
> 1.9.1
>
>
next prev parent reply other threads:[~2017-05-23 18:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-19 6:58 [PATCH] PCI: rockchip: check link status when validating device Shawn Lin
2017-05-23 18:00 ` Brian Norris
2017-05-24 0:54 ` Shawn Lin
2017-05-24 1:00 ` Brian Norris
2017-05-24 1:14 ` Shawn Lin
2017-05-24 1:25 ` Brian Norris
2017-05-23 18:44 ` Brian Norris [this message]
2017-05-23 19:36 ` [PATCH] PCI: Make error code types consistent in pci_{read,write}_config_* Brian Norris
2017-05-25 6:50 ` Keith Busch
[not found] ` <20170523193655.GA144183-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2017-05-26 21:40 ` Bjorn Helgaas
2017-05-23 19:44 ` [PATCH] PCI: rockchip: check link status when validating device Bjorn Helgaas
[not found] ` <20170523194443.GD7241-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2017-05-24 1:04 ` Shawn Lin
2017-05-24 1:15 ` Brian Norris
2017-05-24 21:33 ` Bjorn Helgaas
2017-05-24 21:43 ` Brian Norris
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=20170523184359.GB115572@google.com \
--to=briannorris@chromium.org \
--cc=bhelgaas@google.com \
--cc=jeffy.chen@rock-chips.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=shawn.lin@rock-chips.com \
/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