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:	Mon, 12 Aug 2013 21:04:00 -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@...nel.org>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: Non-enumerable devices on USB and other enumerable buses

On Mon, 12 Aug 2013, Mark Brown wrote:

> On Mon, Aug 12, 2013 at 01:50:07PM -0700, Greg Kroah-Hartman wrote:
> > On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote:
> 
> > > I don't think they're bus specific - the main issue with a lot of this
> > > is that they're outside the infrastructure that the bus standardises so
> > > we should have a general way of understanding this.  There will be bits
> > > where the bus needs to get involved but the overall pattern is generic.
> 
> > The "pattern" is generic, yes, we've been dealing with that for well
> > over a decade now (pci hotplug controllers are "out of line" and control
> > when/if a PCI is device is added/removed.)
> 
> > I'd argue that each bus needs special logic to handle this, just like
> > PCI hotplug did it with their hotplug controller logic.  Due to the
> > nature of this type of thing, it's all out-of-line hardware that is
> > custom to each device type / bus.
> 
> I agree that the bus will need some logic to handle this and I also
> think Stephen is right that there are going to be some common patterns
> for some device classes.  However I do think that this is a common
> problem for pretty much all buses so we should be factoring out as much
> as possible from the buses so they only have to deal with their bit of
> things.  Most of the stuff that's worrying me is not anything the bus
> should have any idea about beyond tunnelling the data to the device.

In theory, the matching of device IDs can be done in the driver core, 
provided the IDs are assigned based on the bus topology (as is the 
case for USB).  But what should happen when there's a match?

The bus code would need hooks installed wherever the platform wants to 
do something extra.  This could end up growing to a lot of hooks.  How 
can the whole thing be done in a reasonable fashion?

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/