linux-kernel - Re: Non-enumerable devices on USB and other enumerable buses

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:	Fri, 16 Aug 2013 21:00:09 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Felipe Balbi <balbi@...com>,
	Grant Likely <grant.likely@...aro.org>,
	devicetree@...r.kernel.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Non-enumerable devices on USB and other enumerable buses

On Fri, Aug 16, 2013 at 03:27:58PM -0400, Alan Stern wrote:
> On Fri, 16 Aug 2013, Mark Brown wrote:

> >  or those for getting platform data to a device when it
> > does enumerate.

> ?  I can't make any sense out of that comment.  For one thing, why do
> you need to send platform data to a device?  (It's obvious that a
> _driver_ would need to use platform data; it's not so clear that a
> _device_ would.)

The device in this context is a running instance of the driver.

> > > (The second proposal also has the advantage that the power-on code may 
> > > be shared between the driver and the subsystem.)

> > Can you explain in more detail please, I don't follow?

> Let's say the subsystem powers up the device when the bus is first
> registered, so that the device can be detected and enumerated.  Let's
> also say that the driver wants to power-off and power-on the device
> from time to time, as part of normal runtime PM.  Then instead of
> having its own power-on routine (which would be code duplication), the
> driver can simply call the subsystem's power-on routine.  (Of course,
> this would mean that the routine would no longer be run-once.)

Oh, OK.  I don't think that's a meaningful difference, the driver is
going to have the code and be able to reuse it one way or another
anyway.  In many cases if the device has been in a low power idle mode a
slightly difference sequence would be needed anyway.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)