Linux-USB Archive on
 help / color / Atom feed
From: Guenter Roeck <>
To: Heikki Krogerus <>
Cc: Hans de Goede <>,
Subject: Re: [PATCH 1/7] usb: typec: Copy everything from struct typec_capability during registration
Date: Wed, 2 Oct 2019 20:51:32 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On 10/2/19 12:16 PM, Heikki Krogerus wrote:
> On Wed, Oct 02, 2019 at 07:06:55PM +0300, Heikki Krogerus wrote:
>> This is a bit off topic, but that attribute file is really horrible.
>> Right now there is no way to know the actual capability of the
>> port in user space. If something changes a DRP port into sink or
>> source, there is no way to know after that that the port is actually
>> DRP capable.
> That statement is not correct. I'm sorry. I don't know why did I put
> it that way.
> I wanted to say that now the userpsace is forced to keep track of a
> specific sysfs file in order to be sure of the currently supported
> role, That alone is wrong, but there is no way to guarantee that
> one day we would not need to support another capability in a similar
> fashion, and that would mean another sysfs file, and we just forced
> the userspace to be modified. The capabilities of the port really need
> to be static.

I assume you refer to port_type. If I remember correctly, this is actually
used by Android userspace code to specifically select if a port can be
source, sink, or drp. I am not sure if it is a good idea to enforce
port removal and re-registration in conjunction with this - the port
can, after all, be connected to some storage device or to a monitor.
I am not sure how we could "sell" to users the idea that if they change
the port type, their screen will go dark for a few seconds.

Am I missing something ?


> We can handle the capability changes like I propose below without
> affecting the userspace.
>> So that ABI is "buggy", but even without the problem, I still really
>> think that allowing the capabilities to be changed like that in
>> general is completely wrong. I don't have a problem with changing the
>> capabilities, but IMO it should be handled at one level higher, at the
>> controller device level. If the capabilities of a port need to be
>> changed, the old port should be removed, and a new with the new
>> capabilities registered. That is the only way to handle it without
>> making things unnecessarily difficult for the user space.
>> I'm pretty sure that that was my counter proposal already at the time
>> when the attribute file was introduced, but I don't remember why
>> wasn't it accepted at the time? My protest against adding that
>> attribute file was in any case ignored :-(. In any case, my plan was
>> to later propose a new sysfs group that we offer to the parent
>> controller devices instead assigning it to the port devices, and that
>> group is meant to allow port capability changes the way I explained
>> above. Unless of course you are against it?
>> thanks,
>> -- 
>> heikki

  reply index

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01  9:48 [PATCH 0/7] usb: typec: Small API improvement Heikki Krogerus
2019-10-01  9:48 ` [PATCH 1/7] usb: typec: Copy everything from struct typec_capability during registration Heikki Krogerus
2019-10-01 13:08   ` Guenter Roeck
2019-10-02 16:06     ` Heikki Krogerus
2019-10-02 16:36       ` Guenter Roeck
2019-10-02 18:29         ` Heikki Krogerus
2019-10-03  3:45           ` Guenter Roeck
2019-10-03  8:03             ` Heikki Krogerus
2019-10-02 19:16       ` Heikki Krogerus
2019-10-03  3:51         ` Guenter Roeck [this message]
2019-10-03 13:29           ` Heikki Krogerus
2019-10-01  9:48 ` [PATCH 2/7] usb: typec: Introduce typec_get_drvdata() Heikki Krogerus
2019-10-01  9:48 ` [PATCH 3/7] usb: typec: Separate the operations vector Heikki Krogerus
2019-10-01 13:22   ` Guenter Roeck
2019-10-04  8:45     ` Heikki Krogerus
2019-10-01  9:48 ` [PATCH 4/7] usb: typec: tcpm: Start using struct typec_operations Heikki Krogerus
2019-10-01 13:30   ` Guenter Roeck
2019-10-04  8:46     ` Heikki Krogerus
2019-10-01  9:48 ` [PATCH 5/7] usb: typec: tps6598x: " Heikki Krogerus
2019-10-01 13:34   ` Guenter Roeck
2019-10-01 13:35   ` Guenter Roeck
2019-10-04  8:49     ` Heikki Krogerus
2019-10-01  9:48 ` [PATCH 6/7] usb: typec: ucsi: " Heikki Krogerus
2019-10-01 13:35   ` Guenter Roeck
2019-10-01  9:48 ` [PATCH 7/7] usb: typec: Remove the callback members from struct typec_capability Heikki Krogerus
2019-10-01 13:37   ` Guenter Roeck

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-USB Archive on

Archives are clonable:
	git clone --mirror linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ \
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone