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, 2 Jun 2016 11:02:33 +0300
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Oliver Neukum <oneukum@...e.com>
Cc:	Guenter Roeck <linux@...ck-us.net>,
	Andy Shevchenko <andy.shevchenko@...il.com>,
	Rajaram R <rajaram.officemail@...il.com>,
	Felipe Balbi <felipe.balbi@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > Just noticed that the "active" file is for now read only, but it needs
> > to be changed to writable. That file will of course provide means for
> > the userspace to Exit and Enter modes. But please note that the
> > responsibility of the dependencies between the modes, say, if a plug
> > needs to be in one mode or the other in order for the partner to enter
> > some specific mode, will fall on the Alternate Mode specific drivers
> > once we have the altmode bus. I remember there were concerns about
> > this in the original thread.
> 
> There's one thing we haven't touched upon yet. And I cannot really find
> an answer in the spec.
> 
> What do we do if we return from S4 or S3? I think we need to restore
> the ALternate Mode because our display may be running over that
> Alternate Mode.
> If we want to support USB persist we also need to restore data role
> after S4.

It would make sense.. What are all the things we need to consider with
that? An example, how do we know if the attached device has changed,
etc.

I'll try to put somekind of suspend and resume hooks to the API, but
this needs some thinking.

Does this have an effect on the interface, meaning would this be
something we could potentially add later? We need to document the
expected behaviour from the beginning, i.e. the roles and the modes
should be restored when resuming, in any case I think.


Thanks,

-- 
heikki

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ