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, 15 Aug 2013 16:42:01 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Mark Brown <broonie@...nel.org>
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 Thu, 15 Aug 2013, Mark Brown wrote:

> On Thu, Aug 15, 2013 at 01:55:18PM -0400, Alan Stern wrote:
> > On Thu, 15 Aug 2013, Mark Brown wrote:
> > > On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote:
> 
> > > To be honest I don't see how that helps much if you're going to handle
> > > the case where platform data is required to enumerate the device.  You
> > > need to know about the device prior to enumeration in order to get the
> > > platform data to the driver when it does enumerate and you can't
> > > enumerate it until you do that anyway.
> 
> > You're a little imprecise here.  Which driver do you mean?  The driver
> > that will ultimately bind to the device, or the driver that will
> > discover and enumerate it (which generally is bound to the device's
> > upstream parent)?  I'll assume the latter.
> 
> The driver that's binding to the device - obviously going through
> teaching all controller drivers about how to start up any random child
> device they might encounter is not going to be a good idea, this should
> be encapsulated in the child driver.

Okay.  Here's a restatement of what you wrote above:

	In the case where platform data is required to enumerate the
	device, you need to know about the device prior to enumeration.

Obviously true.

	You need to get the platform data to the driver when it does
	enumerate.

Not necessarily; see below.

> > Under what circumstances is platform data required to enumerate a
> > device on a discoverable bus?  We're assuming the platform has already
> > taken care of everything required to make the device appear on the bus
> > in the usual manner (such as bringing it to full power).  Can you give
> > an example where something more is needed?
> 
> Powering on the device is exactly the sort of thing I'm talking about
> here.

So something needs to power-on the device.  But what?  The driver that
enumerates it, or some other part of the kernel?

If some other part of the kernel takes care of this then you _don't_
have to get the platform data to the driver when it enumerates.

>  I'm not sure what you think "the platform" is here but it sounds
> awfully like the sort of random board specific bodge code that people
> currently use - something has got to know what's needed to get the
> device up and running and how to do it and the device driver seems like
> the sensible place to do that.

Just the reverse.  The driver should deal with things it knows about:  
how to discover and enumerate devices on its bus.  It should not
contain anything platform-specific.  Adding this in would be a
logistical nightmare -- you'd have to stuff power-on procedures for all
sorts of different platforms into this one poor driver!

> I think I completely misunderstood what you mean by powering up on
> initial use.  If you're saying that we should have some platform code
> for doing this I don't think that's a scalable solution.

How can it be avoided?  The powering-up operation is platform-specific.  
By definition, whatever code carries out the operation is platform
code.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ