From: Prashant Malani <pmalani@chromium.org>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Benson Leung <bleung@chromium.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [RFC PATCH 2/3] usb: typec: Add product_type sysfs attribute file for partners and cables
Date: Wed, 18 Nov 2020 10:53:50 -0800 [thread overview]
Message-ID: <20201118185350.GB3652649@google.com> (raw)
In-Reply-To: <20201118150059.3419-3-heikki.krogerus@linux.intel.com>
Hi Heikki,
On Wed, Nov 18, 2020 at 06:00:58PM +0300, Heikki Krogerus wrote:
> USB Power Delivery Specification defines a set of product
> types for partners and cables. The product type is defined
> in the ID Header VDO, which is the first object in the
> response to the Discover Identity command.
>
> This sysfs attribute file is only created for the partners
> and cables if the product type is really known in the
> driver. Some interfaces do not give access to the Discover
> Identity response from the partner or cable, but they may
> still supply the product type separately in some cases.
>
> When the product type of the partner or cable is detected,
> uevent is also raised with PRODUCT_TYPE set to show the
> actual product type (for example PRODUCT_TYPE=host).
>
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
I tried this out with the following peripherals:
- Thunderbolt 3 active cable.
- Thunderbolt 3 passive cable.
- Dell WD19TB dock.
- Type C DisplayPort enabled monitor (which advertises as AMA).
For the above, the product_type seems to be getting parsed and displayed
correctly, so FWIW:
Tested-by: Prashant Malani <pmalani@chromium.org>
> ---
> Documentation/ABI/testing/sysfs-class-typec | 55 ++++++++
> drivers/usb/typec/class.c | 132 ++++++++++++++++++--
> 2 files changed, 180 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-typec b/Documentation/ABI/testing/sysfs-class-typec
> index b7794e02ad205..4c09e327c62be 100644
> --- a/Documentation/ABI/testing/sysfs-class-typec
> +++ b/Documentation/ABI/testing/sysfs-class-typec
> @@ -139,6 +139,42 @@ Description:
> Shows if the partner supports USB Power Delivery communication:
> Valid values: yes, no
>
> +What: /sys/class/typec/<port>-partner/product_type
> +Date: December 2020
> +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> +Description: USB Power Delivery Specification defines a set of product types
> + for the partner devices. This file will show the product type of
> + the partner if it is known. Dual-role capable partners will have
> + both UFP and DFP product types defined, but only one that
> + matches the current role will be active at the time. If the
> + product type of the partner is not visible to the device driver,
> + this file will not exist.
> +
> + When the partner product type is detected, or changed with role
> + swap, uvevent is also raised that contains PRODUCT_TYPE=<product
> + type> (for example PRODUCT_TYPE=hub).
> +
> + Valid values:
> +
> + UFP / device role
> + ======================== ==========================
> + undefined -
> + hub PDUSB Hub
> + peripheral PDUSB Peripheral
> + psd Power Bank
> + ama Alternate Mode Adapter
> + vpd VCONN Powered USB Device
> + ======================== ==========================
> +
> + DFP / host role
> + ======================== ==========================
> + undefined -
> + hub PDUSB Hub
> + host PDUSB Host
> + power_brick Power Brick
> + amc Alternate Mode Controller
> + ======================== ==========================
> +
> What: /sys/class/typec/<port>-partner>/identity/
> Date: April 2017
> Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> @@ -202,6 +238,25 @@ Description:
> - type-c
> - captive
>
> +What: /sys/class/typec/<port>-cable/product_type
> +Date: December 2020
> +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> +Description: USB Power Delivery Specification defines a set of product types
> + for the cables. This file will show the product type of the
> + cable if it is known. If the product type of the cable is not
> + visible to the device driver, this file will not exist.
> +
> + When the cable product type is detected, uvevent is also raised
> + with PRODUCT_TYPE showing the product type of the cable.
> +
> + Valid values:
> +
> + ======================== ==========================
> + undefined -
> + active Active Cable
> + passive Passive Cable
> + ======================== ==========================
There exists a /sys/class/typec/<port>-cable/type attribute (connected
to the "active" field in struct typec_cable [1]), which is supposed
to be populated by the Type C port driver. Won't the newly introduced
attribute duplicate the same information as "type"?
[1]
https://elixir.bootlin.com/linux/v5.10-rc4/source/include/linux/usb/typec.h#L170
Thanks,
-Prashant
next prev parent reply other threads:[~2020-11-18 18:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 15:00 [RFC PATCH 0/3] usb: typec: Product Type time Heikki Krogerus
2020-11-18 15:00 ` [RFC PATCH 1/3] usb: pd: DFP product types Heikki Krogerus
2020-11-18 15:00 ` [RFC PATCH 2/3] usb: typec: Add product_type sysfs attribute file for partners and cables Heikki Krogerus
2020-11-18 15:57 ` Greg Kroah-Hartman
2020-11-18 17:48 ` Benson Leung
2020-11-19 11:11 ` Heikki Krogerus
2020-11-18 18:53 ` Prashant Malani [this message]
2020-11-19 11:05 ` Heikki Krogerus
2020-11-19 11:11 ` Prashant Malani
2020-11-19 14:12 ` Heikki Krogerus
2020-11-18 15:00 ` [RFC PATCH 3/3] usb: typec: Expose Product Type VDOs via sysfs Heikki Krogerus
2020-11-18 15:56 ` Greg Kroah-Hartman
2020-11-19 12:11 ` Heikki Krogerus
2020-11-18 18:39 ` [RFC PATCH 0/3] usb: typec: Product Type time Prashant Malani
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=20201118185350.GB3652649@google.com \
--to=pmalani@chromium.org \
--cc=bleung@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).