On Sun, Oct 06, 2024 at 07:22:42PM +0300, Dmitry Baryshkov wrote: > On Fri, Oct 04, 2024 at 05:04:37PM GMT, Heikki Krogerus wrote: > > This attribute file shows the supported USB modes (USB 2.0, > > USB 3.0 and USB4) of the partner, and the currently active > > mode. > > > > The active mode is determined primarily by checking the > > speed of the enumerated USB device. When USB Power Delivery > > is supported, the active USB mode should be always the mode > > that was used with the Enter_USB Message, regardless of the > > result of the USB enumeration. The port drivers can > > separately assign the mode with a dedicated API. > > > > If USB Power Delivery Identity is supplied for the partner > > device, the supported modes are extracted from it. > > > > Signed-off-by: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> > > --- > > Documentation/ABI/testing/sysfs-class-typec | 14 +++ > > drivers/usb/typec/class.c | 123 +++++++++++++++++++- > > drivers/usb/typec/class.h | 2 + > > include/linux/usb/typec.h | 5 + > > 4 files changed, 140 insertions(+), 4 deletions(-) > > I think the use of port->usbN_dev is racy and not always obviouos. > For example on Qualcomm devices I ended up with no partner's > usb_capability and just 'usb2' in usb_mode even though the partner uses > USB3 mode. Maybe it's better to hide usb_mode completely if we can not > properly determine the actual mode? > > (On Qualcomm devices there is no working ACPI, so there is no USB <-> > typec correlationship (yet)). Sure. Let's keep it hidden in that case. thanks, -- heikki
