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]
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

Powered by blists - more mailing lists