From: Lukas Wunner <lukas@wunner.de>
To: Esther Shimanovich <eshimanovich@chromium.org>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
"Rajat Jain" <rajatja@google.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
iommu@lists.linux.dev,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] PCI: Detect and trust built-in Thunderbolt chips
Date: Thu, 29 Aug 2024 11:32:47 +0200 [thread overview]
Message-ID: <ZtBAP4TayLmdiya_@wunner.de> (raw)
In-Reply-To: <CA+Y6NJE1p-nidmCZzJ7j-mJAmCLmC2q2meUf-5FFSWofWES-qA@mail.gmail.com>
On Wed, Aug 28, 2024 at 05:15:24PM -0400, Esther Shimanovich wrote:
> On Sun, Aug 25, 2024 at 10:49???AM Lukas Wunner <lukas@wunner.de> wrote:
> > On Fri, Aug 23, 2024 at 04:53:16PM +0000, Esther Shimanovich wrote:
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.c
> > > +static bool pcie_has_usb4_host_interface(struct pci_dev *pdev)
> > > +{
> > > + struct fwnode_handle *fwnode;
> > > +
> > > + /*
> > > + * For USB4, the tunneled PCIe root or downstream ports are marked
> > > + * with the "usb4-host-interface" ACPI property, so we look for
> > > + * that first. This should cover most cases.
> > > + */
> > > + fwnode = fwnode_find_reference(dev_fwnode(&pdev->dev),
> > > + "usb4-host-interface", 0);
> >
> > This is all ACPI only, so it should either be #ifdef'ed to CONFIG_ACPI
> > or moved to drivers/pci/pci-acpi.c.
> >
> > Alternatively, it could be moved to arch/x86/pci/ because ACPI can also
> > be enabled on arm64 or riscv but the issue seems to only affect x86.
>
> Thanks for the feedback! Adding an #ifdef to CONFIG_ACPI seems more
> straightforward, but I do like the idea of not having unnecessary code
> run on non-x86 systems.
>
> I'd appreciate some guidance here. How would I move a portion of a
> function into a completely different location in the kernel src?
> Could you show me an example?
One way to do this would be to move pcie_is_tunneled(),
pcie_has_usb4_host_interface() and pcie_switch_directly_under()
to arch/x86/pci/acpi.c.
Rename pcie_is_tunneled() to arch_pci_dev_is_removable() and remove
the "static" declaration specifier from that function.
Add a function declaration for arch_pci_dev_is_removable() to
include/linux/pci.h.
Add a __weak arch_pci_dev_is_removable() function which just returns
false in drivers/pci/probe.c right above pci_set_removable().
And that's it.
See pcibios_device_add() for an example.
That's one way to do it. It ensures that the code is only compiled
on x86 and only if CONFIG_ACPI=y. Basically the linker picks the
arch_pci_dev_is_removable() in arch/x86/pci/acpi.c, or the empty
__weak function of the same name on !x86 or if CONFIG_ACPI=n.
An alternative approach would involve using an empty static inline.
I think the difference is that an empty static inline is optimized
away by the compiler, whereas the empty __weak function is not
optimized away by the compiler, but may be optimized away by the
linker if CONFIG_LTO=y.
For the static inline it's basically the same but you omit the
__weak arch_pci_dev_is_removable() in drivers/pci/probe.c and
instead constrain the function declaration in include/linux/pci.h to:
#if defined(CONFIG_X86) && defined(CONFIG_ACPI)
...and the #else branch would contain the empty static inline
which just returns false.
See pci_mmcfg_early_init() for an example.
Maybe the empty static inline is better because then the entire
"if (arch_pci_dev_is_removable(...))" clause can be optimized away
without reliance on CONFIG_LTO=y.
I hope I haven't confused you completely.
Thanks,
Lukas
next prev parent reply other threads:[~2024-08-29 9:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-23 16:53 [PATCH v4] PCI: Detect and trust built-in Thunderbolt chips Esther Shimanovich
2024-08-23 21:12 ` Bjorn Helgaas
2024-08-24 4:26 ` Mika Westerberg
2024-08-24 16:20 ` Bjorn Helgaas
2024-08-26 4:31 ` Mika Westerberg
2024-08-28 21:05 ` Esther Shimanovich
2024-09-30 18:23 ` Esther Shimanovich
2024-08-25 14:42 ` Lukas Wunner
2024-08-28 21:15 ` Esther Shimanovich
2024-08-29 9:32 ` Lukas Wunner [this message]
2024-10-23 20:58 ` Bjorn Helgaas
2024-10-23 21:06 ` Bjorn Helgaas
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=ZtBAP4TayLmdiya_@wunner.de \
--to=lukas@wunner.de \
--cc=bhelgaas@google.com \
--cc=eshimanovich@chromium.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rajatja@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.