linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: refactormyself@gmail.com
Cc: bjorn@helgaas.com, yangyicong@hisilicon.com,
	skhan@linuxfoundation.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH RFC 1/2] pci: Make return value of pcie_capability_*() consistent
Date: Mon, 4 May 2020 19:06:26 -0500	[thread overview]
Message-ID: <20200505000626.GA303564@bjorn-Precision-5520> (raw)
In-Reply-To: <20200504051812.22662-2-refactormyself@gmail.com>

Wherever you're working in the tree, pay attention to the existing
style of code, comments, and commit logs and make yours match.  For
example,

  $ git log --oneline drivers/pci/access.c
  af65d1ad416b PCI/AER: Save AER Capability for suspend/resume
  984998e3404e PCI: Make pcie_downstream_port() available outside of access.c
  5180fd913558 PCI: Uninline PCI bus accessors for better ftracing
  df62ab5e0f75 PCI: Tidy comments
  f0eb77ae6b85 PCI/VPD: Move VPD access code to vpd.c
  ab8c609356fb Merge branch 'pci/spdx' into next
  7328c8f48d18 PCI: Add SPDX GPL-2.0 when no license was specified
  7506dc798993 PCI: Add wrappers for dev_printk()

So your subject needs to be something like:

  PCI: Make return value of pcie_capability_*() consistent

On Mon, May 04, 2020 at 07:18:11AM +0200, refactormyself@gmail.com wrote:
> From: Bolarinwa Olayemi Saheed <refactormyself@gmail.com>
> 
> pcie_capability_{read|write}_*() could return 0, -EINVAL, or any of the
> PCIBIOS_* error codes. This is behaviour is now changed to ONLY return a
> PCIBIOS_* error code or -ERANGE on error.
> This has now been made consistent across all accessors. Callers now have
> a consistent way for checking which error has occurred.
> 
> An audit of the callers of these functions was made and no contradicting
> case was found in the examined call chains.
> 
> Signed-off-by: Bolarinwa Olayemi Saheed <refactormyself@gmail.com>
> Suggested-by: Bjorn Helgaas <bjorn@helgaas.com>
> ---
>  drivers/pci/access.c | 64 +++++++++++++++++++++++++++++++++++---------
>  1 file changed, 51 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> index 79c4a2ef269a..10c771079e35 100644
> --- a/drivers/pci/access.c
> +++ b/drivers/pci/access.c
> @@ -402,6 +402,8 @@ static bool pcie_capability_reg_implemented(struct pci_dev *dev, int pos)
>   * Note that these accessor functions are only for the "PCI Express
>   * Capability" (see PCIe spec r3.0, sec 7.8).  They do not apply to the
>   * other "PCI Express Extended Capabilities" (AER, VC, ACS, MFVC, etc.)
> + *
> + * Return 0 on success, otherwise a negative value

Actually, a negative *error value*.

>  int pcie_capability_read_word(struct pci_dev *dev, int pos, u16 *val)
>  {
> @@ -409,7 +411,7 @@ int pcie_capability_read_word(struct pci_dev *dev, int pos, u16 *val)
>  
>  	*val = 0;
>  	if (pos & 1)
> -		return -EINVAL;
> +		return PCIBIOS_BAD_REGISTER_NUMBER;

This does not match the commit log or the function comment.  I know
the *next* patch will make it true, but the commit log and function
comment must describe the code at this point.  Everything must be
consistent and buildable after every commit because future patches may
not ever be applied.

I think there's no reason to change these pcie_capability_*() return
values.  I think the end state we want to get to would be to deprecate
the PCIBIOS_* #defines and use the -E* definitions instead.

>  int pci_read_config_byte(const struct pci_dev *dev, int where, u8 *val)
>  {
> +	int ret;
>  	if (pci_dev_is_disconnected(dev)) {

Nit: style is to leave a blank line between local variables and the
first line of executable code.

>  		*val = ~0;
>  		return PCIBIOS_DEVICE_NOT_FOUND;
>  	}
> -	return pci_bus_read_config_byte(dev->bus, dev->devfn, where, val);
> +
> +	ret = pci_bus_read_config_byte(dev->bus, dev->devfn, where, val);
> +
> +	if (ret > 0)
> +		ret = -ERANGE;

I don't understand what you're doing here.  pci_bus_read_config_byte()
returns things like PCIBIOS_BAD_REGISTER_NUMBER,
PCIBIOS_FUNC_NOT_SUPPORTED, PCIBIOS_BAD_VENDOR_ID, etc.

These are all positive at this point, so this collapses all of them to
-ERANGE, which throws away the information about the different types
of errors, which is not what we want.

Another coding style nit: normally a check for error would be
immediately after the function call, so omit the blank line in this
case.  Generally you can learn things like this by looking at the
existing code and following the same style.

> +	return ret;
>  }

  reply	other threads:[~2020-05-05  0:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-04  5:18 [PATCH RFC 0/2] pci: Make return value of pcie_capability_*() consistent refactormyself
2020-05-04  5:18 ` [PATCH RFC 1/2] " refactormyself
2020-05-05  0:06   ` Bjorn Helgaas [this message]
2020-05-04  5:18 ` [PATCH RFC 2/2] pci: Set all PCIBIOS_* error codes to generic error codes refactormyself

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=20200505000626.GA303564@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=bjorn@helgaas.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=refactormyself@gmail.com \
    --cc=skhan@linuxfoundation.org \
    --cc=yangyicong@hisilicon.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;
as well as URLs for NNTP newsgroup(s).