Date:   Wed, 17 Nov 2021 17:58:12 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Naveen Naidu <naveennaidu479@...il.com>
Cc:     bhelgaas@...gle.com,
        Krzysztof Wilczyński <kw@...ux.com>,
        linux-hyperv@...r.kernel.org, Heiko Stuebner <heiko@...ech.de>,
        linux-pci@...r.kernel.org, Shawn Lin <shawn.lin@...k-chips.com>,
        Binghui Wang <wangbinghui@...ilicon.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Oliver O'Halloran <oohall@...il.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Russell Currey <ruscur@...sell.cc>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Toan Le <toan@...amperecomputing.com>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Nirmal Patel <nirmal.patel@...ux.intel.com>,
        Marek Vasut <marek.vasut+renesas@...il.com>,
        Rob Herring <robh@...nel.org>, Wei Liu <wei.liu@...nel.org>,
        linux-samsung-soc@...r.kernel.org, Marc Zyngier <maz@...nel.org>,
        Joyce Ooi <joyce.ooi@...el.com>,
        Dexuan Cui <decui@...rosoft.com>,
        Jianjun Wang <jianjun.wang@...iatek.com>,
        linux-rockchip@...ts.infradead.org,
        "maintainer:BROADCOM IPROC ARM ARCHITECTURE" 
        <bcm-kernel-feedback-list@...adcom.com>,
        Jonathan Derrick <jonathan.derrick@...ux.dev>,
        Xiaowei Song <songxiaowei@...ilicon.com>,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        Robert Richter <rric@...nel.org>,
        Sean V Kelley <sean.v.kelley@...el.com>,
        Ray Jui <rjui@...adcom.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Ryder Lee <ryder.lee@...iatek.com>,
        linux-mediatek@...ts.infradead.org,
        Matthias Brugger <matthias.bgg@...il.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        linux-arm-kernel@...ts.infradead.org,
        Qiuxu Zhuo <qiuxu.zhuo@...el.com>,
        Scott Branden <sbranden@...adcom.com>,
        linuxppc-dev@...ts.ozlabs.org,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        Lukas Wunner <lukas@...ner.de>,
        Jingoo Han <jingoohan1@...il.com>,
        Shawn Guo <shawn.guo@...aro.org>,
        Pali Rohár <pali@...nel.org>
Subject: Re: [PATCH v3 01/25] PCI: Add PCI_ERROR_RESPONSE and it's related
 definitions

On Thu, Oct 21, 2021 at 08:37:26PM +0530, Naveen Naidu wrote:
> An MMIO read from a PCI device that doesn't exist or doesn't respond
> causes a PCI error.  There's no real data to return to satisfy the
> CPU read, so most hardware fabricates ~0 data.
> 
> Add a PCI_ERROR_RESPONSE definition for that and use it where
> appropriate to make these checks consistent and easier to find.
> 
> Also add helper definitions SET_PCI_ERROR_RESPONSE and
> RESPONSE_IS_PCI_ERROR to make the code more readable.
> 
> Suggested-by: Bjorn Helgaas <bhelgaas@...gle.com>
> Signed-off-by: Naveen Naidu <naveennaidu479@...il.com>
> ---
>  include/linux/pci.h | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index cd8aa6fce204..689c8277c584 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -154,6 +154,15 @@ enum pci_interrupt_pin {
>  /* The number of legacy PCI INTx interrupts */
>  #define PCI_NUM_INTX	4
>  
> +/*
> + * Reading from a device that doesn't respond typically returns ~0.  A
> + * successful read from a device may also return ~0, so you need additional
> + * information to reliably identify errors.
> + */
> +#define PCI_ERROR_RESPONSE     (~0ULL)
> +#define SET_PCI_ERROR_RESPONSE(val)    (*(val) = ((typeof(*(val))) PCI_ERROR_RESPONSE))
> +#define RESPONSE_IS_PCI_ERROR(val) ((val) == ((typeof(val)) PCI_ERROR_RESPONSE))

Beautiful!  I really like this.

I would prefer the macros to start with "PCI_", e.g.,
PCI_SET_ERROR_RESPONSE().

I think "RESPONSE_IS_PCI_ERROR()" is too strong because (as the
comment says), ~0 *may* indicate an error.  Or it may be a successful
read of a register that happens to contain ~0.

Possibilities to convey the idea that this isn't definitive:

  PCI_POSSIBLE_ERROR_RESPONSE(val)  # a little long
  PCI_LIKELY_ERROR(val)             # we really have no idea whether
  PCI_PROBABLE_ERROR(val)           #   likely or probable
  PCI_POSSIBLE_ERROR(val)           # promising?

Can you rebase to my "main" branch (v5.16-rc1), tweak the above, and
collect up the acks/reviews?

We should also browse drivers outside drivers/pci for places we could
use these.  Not necessarily as part of this series, although if
authors there object, it would be good to learn that earlier than
later.

Drivers that implement pci_error_handlers might be a fruitful place to
start.  But you've done a great job finding users of ~0 and 0xffff...
in drivers/pci/, too.

> +
>  /*
>   * pci_power_t values must match the bits in the Capabilities PME_Support
>   * and Control/Status PowerState fields in the Power Management capability.
> -- 
> 2.25.1
> 
> _______________________________________________
> Linux-kernel-mentees mailing list
> Linux-kernel-mentees@...ts.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

Powered by blists - more mailing lists