linux-kernel - Re: [PATCH 1/3] usb: USB Type-C Connector Class

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160218132541.GM1859@kuha.fi.intel.com>
Date:	Thu, 18 Feb 2016 15:25:41 +0200
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Oliver Neukum <oneukum@...e.com>
Cc:	Felipe Balbi <balbi@...nel.org>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH 1/3] usb: USB Type-C Connector Class

Hi,

On Thu, Feb 18, 2016 at 10:35:41AM +0100, Oliver Neukum wrote:
> On Thu, 2016-02-18 at 10:47 +0200, Heikki Krogerus wrote:
> 
> Hi,
> 
> > P.S. That reminds me, here's my current draft for the
> > Documentation/ABI/. Could you take a look?
> 
> And I am afraid, that I have a few remarks not bound
> to a specific entry.
> 
> We have port directories for port power switching. How is
> the connector directory linked to them?

I'm sorry, I don't think I understand this point.

> Likewise, if we have USB PD, we have to know how that
> is linked to the connector directory.

So you mean when we have USB PD PHY or controller, right? That
will be the parent of the connector device if we have one on the
platform.

I think I'm misunderstanding this point as well..

> In addition, writes to those files have results. We need
> the error codes to be described.

Yes, I need to document those.

> Furthermore, do these files support poll?
> 
> And lastly we can get "Attention" as a message connected
> with a connector in an alternate mode. How does user space
> learn about that?

The class should notify the userspace with uevent on
connection/disconnection regardless what is being connected, or what
mode the connector enters initially.

So do you want to see that explained in the ABI document?

The uevent does not contain any details, but I thought that it's OK to
expect the userspace to read that separately. If this is not OK, let's
add a new uevent variable that specifies what was just connected.

I hope I did not misunderstand also this one.

> I am sorry to be this obnoxious, but this is an API which
> will be with us for a long time, so we better get it right.

I would not say you are being obnoxious. If you are, feel free :).
Your input is most welcome. Thanks a lot for that. And I agree, we
need to make this solid from the beginning.

Thanks,

-- 
heikki