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

[Mark Brown]

On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote:
> On Thu, 15 Aug 2013, Mark Brown wrote:

> So why not bring the device to full power as soon as possible during
> boot, and have it registered on the bus in the usual way?  Once that's
> done, the ordinary runtime PM mechanism will allow the device to go
> back off-line.

That could be done, and is likely to happen anyway as a result of device
initialisation.  I'm not sure it buys much to force it to happen
immediately, though.

> > I've also mentioned the devices that need platform data which is a part
> > of this too; one reason for knowing that the device is there before it
> > appears is so that we can pass platform data/DT/whatever to it.

> Can you pass this "whatever" data to the device as part of the initial 
> bring-it-to-full-power procedure?

It is often going to be required as part of the bring it to full power
procedure.

> By the way, you mentioned something earlier that some of this platform
> data might duplicate information that could be discovered through the
> usual bus probing mechanisms (for example, USB descriptors).  IMO
> that's a bad idea.  Not only is it wasteful, it also has the potential

If you check the discussion it pretty much consisted of everyone saying
that duplicating enumerable information was a terrible idea.

> > >      A: Devising a mechanism for platform code to do things involving
> > > 	devices that are dynamically registered on discoverable buses.

> > If we need random platform code then we're failing, half the point of
> > things like DT and ACPI is to avoid writing random board code.  we do
> > want to pass data to devices for their drivers to use but having to have
> > random bits of per board code would be really sad.

> At the level of abstraction in this discussion, there's no need to 
> discriminate between code and data.  Just imagine that I simply wrote 
> "platform", meaning platform code and/or data.

There's a big difference between random glue outside the drivers and
something the drivers know about themselves, it's important to be clear
on this.  Bodges for this often involve writing a bit of board code that
the drivers don't know anything about.

> > >      B: Telling the subsystem and driver code for a discoverable bus
> > > 	that a particular device is present before it has been 
> > > 	detected.

> > I think the solutions for these overlap so much they're the same thing.
> > The situation we're in in in your case B is just the idle case for
> > condition C - if we know about the device before it's been detected then
> > if it's been removed we just go back into the situation where we know
> > about it but it isn't powered.

> I imagine that teaching a subsystem to know about a device before it 
> has been detected would require significant changes.  My suggestion -- 
> powering up the device, detecting it, and then powering it back down -- 
> fits in very cleanly with existing designs and would require 
> comparatively little work.  Case B then becomes unnecessary; all the 
> important stuff will be handled under Case C.

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.  A bus could insist on this if it
needed the information from enumeration for some reason but really it
seems like an implementation detail.

> There's one important factor to keep in mind: Are devices on the bus
> physically removable?  If not, the situation is pretty straightforward.  
> You just remember that the device used to be present, and reuse the old
> data structures when it reappears.

Not the ones I'm talking about, though other removable devices may
possibly be present on the same bus.  My interest is in the case where
we know the chip is there because we can see it soldered to the board.

Attachment: signature.asc
Description: Digital signature