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]

Message-ID: <20130816224654.GV30073@sirena.org.uk>
Date:	Fri, 16 Aug 2013 23:46:54 +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 04:39:47PM -0400, Alan Stern wrote:
> On Fri, 16 Aug 2013, Mark Brown wrote:

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

> It's kind of difficult to understand what you're saying.  Obviously the
> literal meaning is not what you had in mind, because a device can't be
> a driver (or even a running instance of a driver).  Maybe you meant
> that the word "device" above should have been the word "driver".

I don't think using device to refer to an instance of the running driver
is that obscure a usage to be honest...

> So you seem to be saying that significant modifications would be needed 
> to get platform information to the driver.  I don't see why.  Lots and 
> lots of drivers use platform information right now.

> Besides, you need to get the platform information to the driver in any 
> case, no matter how you decide to solve the chicken-and-egg problem.  
> It shouldn't be a factor in deciding which solution to use.

It's not that this is hard, it's that I don't see how if you already
have some concept of the device in the kernel data structures (which you
must have in order to be able to provide platform data when it's needed)
anything is gained by not using that when dealing with bootstrapping
issues.

Anyway, I think it's time to try to implement something rather than talk
about it.

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