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

[Alan Stern]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/