[PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device

[Bartosz Golaszewski]

On Fri, 12 Jun 2026 07:46:26 +0200, Chen-Yu Tsai <wenst at chromium.org> said:
> On Fri, Jun 12, 2026 at 3:54 AM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
>>
>> On Thu, Jun 11, 2026 at 06:48:56PM +0300, Heikki Krogerus wrote:
>> > On Thu, Jun 11, 2026 at 11:35:13AM +0200, Bartosz Golaszewski wrote:
>> > > On Thu, Jun 11, 2026 at 10:37 AM Andy Shevchenko
>> > > <andriy.shevchenko at linux.intel.com> wrote:
>> > > > On Thu, Jun 11, 2026 at 04:20:58AM -0400, Bartosz Golaszewski wrote:
>> > > > > On Wed, 10 Jun 2026 16:16:12 +0200, Andy Shevchenko
>> > > > > <andriy.shevchenko at linux.intel.com> said:
>> > > > > > On Wed, Jun 10, 2026 at 04:40:39PM +0800, Chen-Yu Tsai wrote:
>> > > > > >> When a USB hub port is connected to a connector in a firmware node
>> > > > > >> graph, the port itself has a node in the graph.
>> > > > > >>
>> > > > > >> Associate the port's firmware node with the USB port's device,
>> > > > > >> usb_port::dev. This is used in later changes for the M.2 slot power
>> > > > > >> sequencing provider to match against the requesting port.
>> > > > > >
>> > > > > > Okay, would this affect ACPI-based systems? if so, how?
>> > > > > > Can you elaborate on that, please?
>> > > > >
>> > > > > Is it possible that there's an ACPI device node associated with the port like
>> > > > > on some DT systems? I don't think so and there should be no impact IMO but I
>> > > > > also don't know enough about ACPI.
>> >
>> > There are device nodes for the USB ports in ACPI, and I think they get
>> > always assigned in drivers/usb/core/usb-acpi.c.
>> >
>> > > > The API is agnostic. There is a possibility to have software nodes associated
>> > > > with the port. I think the best is to be sure that ACPI-aware people who are
>> > > > experts in USB will check this (Heikki?).
>> >
>> > I can't say what's the impact from this patch - I'm not an expert with
>> > this side of USB. Is there a danger that we end up overwriting the
>> > ACPI node for the port, or something else?
>>
>> Exactly this one is my worrying, but I haven't checked the actual flow.
>
> Looking through ACPI code, ACPI_COMPANION_SET() is used, which boils
> down to
>
>     set_primary_fwnode(dev, acpi_fwnode_handle(acpi_dev))
>
> This is called through
>
> usb_hub_create_port_device()
>   device_register()
>     device_add()
>       device_platform_notify()
>         acpi_device_notify()
>           usb_acpi_find_companion()
>             usb_acpi_find_companion_for_port()
>           acpi_bind_one()
>             ACPI_COMPANION_SET()
>               set_primary_fwnode()
>
> Looking at device_add_software_node(), all swnodes are secondary.
>
> set_primary_fwnode() seems to be able to make the ACPI handle / fwnode
> the primary, keeping any existing fwnode as the secondary. However
> if we do end up assigning a primary fwnode to the device using
> device_set_node() as in this patch, set_primary_fwnode() is going
> to complain loudly.
>
> On another front, the ACPI representation of the USB ports looks nothing
> like the OF graphs, at least on my X1 Carbon:
>
> For a usb port device on the root hub such as
>
>   /sys/bus/usb/devices/4-0:1.0/usb4-port1/firmware_node/path
>
> looks like
>
>   \_SB_.PC00.XHCI.RHUB.SS01
>
> while a usb port's firmware node link
>
>   /sys/bus/usb/devices/4-0:1.0/usb4-port1//firmware_node
>
> resolves to
>
>   /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/device:1a/device:29
>
> Neither looks anything like the graph "port" / "endpoint" node names.
> So maybe we're in the clear here.
>
> Besides the loud warning from set_primary_fwnode(), the major issue stemming
> from a wrong node is that power management (through ACPI) is likely to fail.
>
> If we're still concerned, I think we can skip the assignment if the fwnode
> is an ACPI node, i.e. check it with is_acpi_node().
>

Agreed, I think this is a good compromise.

Bart

>
> I've never worked on ACPI systems, so this is just me checking the code.
>
>
> Thanks
> ChenYu
>