linux-stable.git/include/linux/usb/typec.h, branch v6.12.85

usb: typec: Update sysfs when setting ops

2024-06-04T13:44:27+00:00

When adding altmode ops, update the sysfs group so that visibility is
also recalculated.

Reviewed-by: Heikki Krogerus 
Reviewed-by: Benson Leung 
Signed-off-by: Abhishek Pandit-Subedi 
Signed-off-by: Jameson Thies 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20240510201244.2968152-3-jthies@google.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: altmodes: add svdm version info for typec cables

2024-01-28T01:38:25+00:00

Add typec_cable_set_svdm_version and typec_get_cable_svdm version symbols.
Cables can operate under a lower PD revision than the port partner, and the
max SVDM version is tied to the PD revision. So, typec_cable maintains its
own svdm_version.

Add typec_altmode_get_cable_svdm_version to return the cable's negotiated
svdm_version for altmode drivers to use.

Signed-off-by: RD Babiera 
Reviewed-by: Heikki Krogerus 
Link: https://lore.kernel.org/r/20240108191620.987785-16-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: altmodes: add typec_cable_ops to typec_altmode

2024-01-28T01:38:25+00:00

Add typec_cable_ops struct for enter, exit, and vdm. The struct is added
to typec_altmode so port alt modes can have access to partner and cable
specific callbacks, and alt mode drivers can specify operations over SOP'
and SOP'' without modifying the existing API.

typec_port_register_cable_ops is added as a new symbol for port drivers
to use to register cable operations to their registered port alt modes.

Signed-off-by: RD Babiera 
Reviewed-by: Heikki Krogerus 
Link: https://lore.kernel.org/r/20240108191620.987785-15-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: Link enumerated USB devices with Type-C partner

2023-10-16T18:02:36+00:00

Adding functions that USB hub code can use to inform the
Type-C class about connected USB devices.

Once taken into use, it will allow the Type-C port drivers
to power off components that are not needed, for example if
USB2 device is enumerated, everything that is only relevant
for USB3 (retimers, etc.), can be powered off.

This will also create a symlink "typec" for the USB devices
pointing to the USB Type-C partner device.

Suggested-by: Benson Leung 
Tested-by: Benson Leung 
Signed-off-by: Heikki Krogerus 
Link: https://lore.kernel.org/r/20231011105825.320062-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: Add partner PD object wrapper

2022-11-29T07:56:09+00:00

Some port drivers may want to set a Type-C partner as a parent for a
USB Power Delivery object, but the Type-C partner struct isn't exposed
outside of the Type-C class driver. Add a wrapper to
usb_power_delivery_register() which sets the provided Type-C partner
as a parent to the USB PD object. This helps to avoid exposing the
Type-C partner's device struct unnecessarily.

Cc: Benson Leung 
Suggested-by: Heikki Krogerus 
Reviewed-by: Heikki Krogerus 
Signed-off-by: Prashant Malani 
Link: https://lore.kernel.org/r/20221122220538.2991775-2-pmalani@chromium.org
Signed-off-by: Greg Kroah-Hartman

usb: typec: USB Power Delivery helpers for ports and partners

2022-06-12T04:49:47+00:00

All the USB Type-C Connector Class devices are protected, so
the drivers can not directly access them. This will adds a
few helpers that can be used to link the ports and partners
to the correct USB Power Delivery objects.

For ports a new optional sysfs attribute file is also added
that can be used to select the USB Power Delivery
capabilities that the port will advertise to the partner.

Signed-off-by: Heikki Krogerus 
Link: https://lore.kernel.org/r/20220502132058.86236-3-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: Separate USB Power Delivery from USB Type-C

2022-06-12T04:49:47+00:00

Introducing a small device class for USB Power Delivery.
The idea with it is that we do not mix any more USB Power
Delivery information into the USB Type-C connectors only.
This separation will make it possible to register USB Power
Delivery devices also from other places, for example from
USB Type-C Bridges (see USB Type-C Bridge Specification).

The device class will not always deal with only the messages
and objects that were negotiated with the partner, but
instead messages and objects that can be used in the
negotiation. That allows the USB PD devices to be shared and
reconfigured. The ports can decide which objects are to be
advertised to the partner before the contract is negotiated.
It is also possible to allow the user space to make that
decision if needed.

Signed-off-by: Heikki Krogerus 
Link: https://lore.kernel.org/r/20220502132058.86236-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: Factor out non-PD fwnode properties

2022-02-17T15:21:57+00:00

Basic programmable non-PD Type-C port controllers do not need the full
TCPM library, but they share the same devicetree binding and the same
typec_capability structure. Factor out a helper for parsing those
properties which map to fields in struct typec_capability, so the code
can be shared between TCPM and basic non-TCPM drivers.

Reviewed-by: Heikki Krogerus 
Signed-off-by: Samuel Holland 
Link: https://lore.kernel.org/r/20220214050118.61015-4-samuel@sholland.org
Signed-off-by: Greg Kroah-Hartman

usb: typec: port-mapper: Convert to the component framework

2021-12-30T11:13:04+00:00

Instead of trying to keep track of the connections to the
USB Type-C connectors separately, letting the component
framework take care of that.

From now on every USB Type-C connector will register itself
as "aggregate" - component master - and anything that can be
connected to it inside the system can then simply register
itself as a generic component.

The matching of the components and the connector shall rely
on ACPI _PLD initially. Before registering itself as the
aggregate, the connector will find all other ACPI devices
that have matching _PLD crc hash with it (matching value in
the pld_crc member of struct acpi_device), and add a
component match entry for each one of them. Because only
ACPI is supported for now, the driver shall only be build
when ACPI is supported.

This removes the need for the custom API that the driver
exposed. The components and the connector can therefore
exist completely independently of each other. The order in
which they are registered, as well as are they modules or
not, is now irrelevant.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Heikki Krogerus 
Link: https://lore.kernel.org/r/20211223082422.45637-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: Add typec_port_register_altmodes()

2021-04-09T14:07:41+00:00

This can be used by Type-C controller drivers which use a standard
usb-connector fwnode, with altmodes sub-node, to describe the available
altmodes.

Note there are is no devicetree bindings documentation for the altmodes
node, this is deliberate. ATM the fwnodes used to register the altmodes
are only used internally to pass platform info from a drivers/platform/x86
driver to the type-c subsystem.

When a devicetree user of this functionally comes up and the dt-bindings
have been hashed out the internal use can be adjusted to match the
dt-bindings.

Currently the typec_port_register_altmodes() function expects
an "altmodes" child fwnode on port->dev with this "altmodes" fwnode having
child fwnodes itself with each child containing 2 integer properties:

1. A "svid" property, which sets the id of the altmode, e.g. displayport
altmode has a svid of 0xff01.

2. A "vdo" property, typically used as a bitmask describing the
capabilities of the altmode, the bits in the vdo are specified in the
specification of the altmode.

Reviewed-by: Heikki Krogerus 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20210409134033.105834-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman