linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Prashant Malani <pmalani@chromium.org>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	Benson Leung <bleung@chromium.org>
Subject: Re: [PATCH v3 2/2] usb: typec: Expose Product Type VDOs via sysfs
Date: Wed, 11 Nov 2020 11:21:20 +0200	[thread overview]
Message-ID: <20201111092120.GO1224435@kuha.fi.intel.com> (raw)
In-Reply-To: <X6qF7hioVJyCm/Ps@kroah.com>

Hi Greg,

On Tue, Nov 10, 2020 at 01:22:06PM +0100, Greg KH wrote:
> > I've now come to the conclusion that this is not the correct approach.
> > Instead, the whole identity, all six VDOs, should be supplied
> > separately with a "raw" sysfs attribute file after all.
> > 
> > The three attribute files that we already have - so id_header,
> > cert_stat and product - can always supply the actual VDO as is,
> > regardless of the product type, so they are fine. But these new
> > attribute files, product_type_vdoX, would behave differently as they
> > supply different information depending on the product type. That just
> > does not feel right to me.
> > 
> > So lets just add the "raw" sysfs attribute file. We can think about
> > extracting some other details from the product type VDOs once the
> > specification has settled down a bit and we can be quite certain that
> > those details will always be available.
> > 
> > Would this be OK to you? I think we should be able to dump the data to
> > the "raw" sysfs attribute file with something like hex_dump_to_buffer().
> 
> Does this mean that the value of the attributes depends on something
> external to the device?  If so, how is userspace going to know how to
> parse this any differently than the kernel could today?
> 
> And I say this as the maintainer of 'lsusb' which probably should start
> getting support for the typec attributes that are being exposed here :)

OK, this is great! I really want you opinion on this. Let me try to
explain the situation.

So USB Power Delivery specification defines a set of these product
types, as I'm sure you already know. You have your hub, alternate mode
adapter, and so on. Then there are also a couple of cable types.
Originally I though that a product type simply equals a device type
(and that still feels correct to me). Each product type can have its
own "ABI" in form of the attribute files, that really should not be a
problem, right?

The problem with that was that we do not always know the product type.
For example UCSI does not supply the operating system the response to
the Discover Identity request from the partner device that contains
this information. It would mean that depending on your system, we will
claim that, let's say a hub really is a hub, or just some kind of a
default partner device. There was discussion about this back in the
day on this mailing list, and it was considered to be at least a
little bit confusing for the user.

In the end I did not propose the separate device types for each USB PD
product type (yet). Instead we only expose the header part of the
response to the Discover Identity (when we have it) because that part
is the same for all product types. So basically we have just the
"default" partner device type for everything for now.

But since now we clearly need all the identity details, not just the
header, it's good to talk about this again. Maybe even the "raw"
attribute file is not that useful in the end, and we really should
finally introduce the separate device types for each product types?

Or maybe there is a third option that I have not even thought of?

thanks,

-- 
heikki

  reply	other threads:[~2020-11-11  9:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-23 21:43 [PATCH v3 1/2] usb: typec: Consolidate syfs ABI documentation Prashant Malani
2020-10-23 21:43 ` [PATCH v3 2/2] usb: typec: Expose Product Type VDOs via sysfs Prashant Malani
2020-11-04 17:49   ` Prashant Malani
2020-11-06  7:36     ` Heikki Krogerus
2020-11-10 11:54   ` Heikki Krogerus
2020-11-10 12:22     ` Greg KH
2020-11-11  9:21       ` Heikki Krogerus [this message]
2020-11-12  2:40     ` Prashant Malani
2020-11-12 12:43       ` Heikki Krogerus
2020-11-12 16:50         ` Prashant Malani
2020-11-13 14:34           ` Heikki Krogerus
2020-11-24 13:28   ` Heikki Krogerus
2020-11-10 10:52 ` [PATCH v3 1/2] usb: typec: Consolidate syfs ABI documentation Heikki Krogerus
2020-11-24 13:23 ` Heikki Krogerus
2020-11-24 20:13   ` 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=20201111092120.GO1224435@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=bleung@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=pmalani@chromium.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).