Thread (12 messages) 12 messages, 3 authors, 2021-12-10

Re: [PATCH 0/5] acpi: Store _PLD information and convert users

From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date: 2021-12-10 09:26:39
Also in: linux-acpi, lkml

On Thu, Dec 09, 2021 at 11:45:27AM -0800, Prashant Malani wrote:
Hey Heikki,

On Thu, Dec 9, 2021 at 2:06 AM Heikki Krogerus
[off-list ref] wrote:
quoted
Hi,

Thanks for testing these..

On Wed, Dec 08, 2021 at 07:45:26PM -0800, Prashant Malani wrote:
quoted
Hi Heikki,

On Tue, Dec 7, 2021 at 6:37 AM Heikki Krogerus
[off-list ref] wrote:
quoted
Hi,

This removes the need for the drivers to always separately evaluate
the _PLD. With the USB Type-C connector and USB port mapping this
allows us to start using the component framework and remove the custom
APIs.

So far the only users of the _PLD information have been the USB
drivers, but it seems it will be used also at least in some camera
drivers later. These nevertheless touch mostly USB drivers.

Rafael, is it still OK if Greg takes these?

Prashant, can you test these?
I've applied the patches to a system with the requisite _PLD entries
in firmware, and I'm not sure I can see the connectors getting created
correctly.

My setup is:

Chromebook ------> Dell WD19TB dock (in USB+DisplayPort Alternate
Mode) ----> USB Thumb drive.

Here is the lsusb -t output before connecting the dock (omitting
unrelated busses):
localhost ~ # lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/3p, 10000M/x2

Here is the lsusb -t output (omitting unrelated busses):
localhost ~ # lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/3p, 10000M/x2
    |__ Port 2: Dev 15, If 0, Class=Hub, Driver=hub/4p, 10000M
        |__ Port 3: Dev 16, If 0, Class=Hub, Driver=hub/4p, 5000M
            |__ Port 3: Dev 18, If 0, Class=Mass Storage,
Driver=usb-storage, 5000M
        |__ Port 4: Dev 17, If 0, Class=Vendor Specific Class,
Driver=r8152, 5000M

I see the connector symlink for the root hub:

localhost ~ # cd /sys/bus/usb/devices
localhost /sys/bus/usb/devices # ls 2-2/port/connector
data_role  device  firmware_node  port1-cable  port1-partner  power
power_operation_mode  power_role  preferred_role  subsystem
supported_accessory_modes  uevent  usb2-port2  usb3-port2
usb_power_delivery_revision  usb_typec_revision  vconn_source

But for none of the children devices:

localhost /sys/bus/usb/devices # ls 2-2.3/port/connector
ls: cannot access '2-2.3/port/connector': No such file or directory
localhost /sys/bus/usb/devices # ls 2-2.3.3/port/connector
ls: cannot access '2-2.3.3/port/connector': No such file or directory
localhost /sys/bus/usb/devices # ls 2-2.3\:1.0/port/connector
ls: cannot access '2-2.3:1.0/port/connector': No such file or directory
localhost /sys/bus/usb/devices # ls 2-2.3.3\:1.0/port/connector
ls: cannot access '2-2.3.3:1.0/port/connector': No such file or directory

Is this as you intended with the series? My interpretation was that
each connected usb device would get a "connector" symlink, but I may
have misinterpreted this.
It is as intended. The usb ports on the board will have the connector
symlink, not the devices attached to them - the firmware is only aware
of the connectors on the board of course. It looks like this series is
working as it should.
Thanks for clarifying my understanding here.
quoted
If you want to extend this solution so that also every device in the
usb topology will have the link to the connector on board, then that
should be now possible, but that is out side of the scope of this
series. You need to propose that separately.

But I must ask, why can't you just walk down the topology until you
reach the on-board ports that will have the connector links?
Right, we can certainly do that; having it in each device is just
convenient. But as you said, that's the subject of another series.

You mentioned there would be a v2, so I'll add my Tested-By then.
Great!

I don't know does this help you, or if this is exactly what you had in
mind, but I am planning to link the USB device attached to the
connector to the USB Type-C partner device that we have (the USB
device attached to the connector is the Type-C partner).

So in your example, the Dell dock USB hub will have the symlink to
the Type-C partner device, but the USB mass storage device attached to
the dock will not (because it's not our USB Type-C partner - the dock
is our USB Type-C partner).

But I want to do that separately, as the next step in any case.

thanks,

-- 
heikki
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help