linux-kernel - Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

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: <1455699834.7626.4.camel@suse.com>
Date:	Wed, 17 Feb 2016 10:03:54 +0100
From:	Oliver Neukum <oneukum@...e.com>
To:	Heikki Krogerus <heikki.krogerus@...ux.intel.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 2/3] usb: type-c: USB Type-C Connector System Software
 Interface

On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> > On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > > > That question has not been answered. It would be awkward for the OS
> > > > to find itself in the slave role, which it is ill equipped for. So
> > > > the data role should be switched before the new device is announced
> > > > to user space. How is that handled?
> > > 
> > > In the class driver, once we add support for preselecting the role,
> > > when the connection happens we compare the initial role to the
> > > preselected one and execute swap if it differs. Only after that we
> > > notify userspace.
> > 
> > Yes, but we need an API. We can't keep adding to it. So if that
> > is to be supported, it needs to be defined now.
> 
> When you say API, do you mean the API the class provides to the
> drivers? Or did you mean ABI which would be the sysfs in this case?

The API to user space. That is the point. We cannot break user space.
Once this sysfs API is upstream we are stuck with it.

> For the sysfs I would image we can manage with the current files,
> current_data_role and current_power_role. If somebody writes to them
> when we are disconnected, we still callback the dr_swap or pr_swap
> hooks, and make a rule that when disconnected, it means we are
> setting the "preferred" roles.
> 
> Would that be OK? Or did I still misunderstood your question?

That would be absolutely OK, but that function needs to be decided on
and documented as all files in sysfs are. And likewise it needs to be
documented that alternate modes behave differently.

	Regards
		Oliver