From: Bjorn Helgaas <helgaas@kernel.org>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH] PCI: Update pci_find_capability() stub return values
Date: Thu, 28 Mar 2024 11:18:31 -0500 [thread overview]
Message-ID: <20240328161831.GA1568357@bhelgaas> (raw)
In-Reply-To: <a144b96b-6ec4-4a62-b2ab-1ed631d81544@linux.intel.com>
On Wed, Mar 27, 2024 at 02:49:34PM -0700, Kuppuswamy Sathyanarayanan wrote:
> On 3/27/24 11:02 AM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas <bhelgaas@google.com>
> >
> > f646c2a0a668 ("PCI: Return u8 from pci_find_capability() and similar") and
> > ee8b1c478a9f ("PCI: Return u16 from pci_find_ext_capability() and similar")
> > updated the return type of the extern declarations, but neglected to update
> > the type of the stubs used CONFIG_PCI is not enabled.
> >
> > Update them to match the extern declarations.
> >
> > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> > ---
>
> This change looks fine to me.
>
> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Thanks for reviewing it!
> But the callers of these functions still seems to use int
> declaration to store the output. Any reason for not changing them?
> Like the usages in drivers/pci/pci.c?
This patch is just to make the extern declarations match the stubs.
No particular reason not to change users other than I didn't want to
change the users before the declarations (to avoid warnings about
assigning an int to a u8 or u16), and there's not a lot of value in
changing local variables, where an int is just on the stack and works
fine.
Changing stored values in a struct would have more benefit. I took a
quick look and found these possibilities:
struct controller.cap_offset (drivers/pci/hotplug/shpchp.h SHPC cap)
struct pci_sriov.pos (drivers/pci/pci.h SR-IOV ext cap)
struct altera_pcie_data.cap_offset (drivers/pci/controller/pcie-altera.c PCIe cap)
struct tg3.msi_cap (broadcom/tg3.h MSI cap)
struct tg3.pcix_cap (broadcom/tg3.h PCI-X cap)
struct bnx2.pm_cap (broadcom/bnx2.h PM cap)
struct bnx2.pcix_cap (broadcom/bnx2.h PCI-X cap)
struct bnx2x_sriov.cap (broadcom/bnx2x/bnx2x_sriov.h SR-IOV ext cap)
struct amd8111e_priv.pm_cap (amd/amd8111e.c, removed [1])
struct pci_params.pm_cap (qlogic/qed/qed.h, removed [2])
struct qed_hw_sriov_info.cap (qlogic/qed/qed_sriov.h SR-IOV ext cap)
struct eeh_dev.pcix_cap (powerpc/include/asm/eeh.h PCI-X cap)
struct eeh_dev.pcie_cap (powerpc/include/asm/eeh.h PCIe cap)
struct eeh_dev.aer_cap (powerpc/include/asm/eeh.h AER ext cap)
struct eeh_dev.af_cap (powerpc/include/asm/eeh.h AF cap)
struct icm.vnd_cap (drivers/thunderbolt/icm.c VNDR ext cap)
[1] https://lore.kernel.org/all/20240325220633.1453180-1-helgaas@kernel.org/
[2] https://lore.kernel.org/all/20240325224931.1462051-1-helgaas@kernel.org/
Bjorn
next prev parent reply other threads:[~2024-03-28 16:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 18:02 [PATCH] PCI: Update pci_find_capability() stub return values Bjorn Helgaas
2024-03-27 18:12 ` Bjorn Helgaas
2024-03-27 21:49 ` Kuppuswamy Sathyanarayanan
2024-03-28 16:18 ` Bjorn Helgaas [this message]
2024-03-28 22:36 ` Kuppuswamy Sathyanarayanan
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=20240328161831.GA1568357@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.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