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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On Mon, Aug 12, 2013 at 09:04:00PM -0400, Alan Stern wrote:

> 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?

I'd expect that we're just looking at hooks around connection and
disconnection here here - if we're looking at much more it seems like we
must be doing something wrong.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

On Wed, 14 Aug 2013, Mark Brown wrote:

> On Mon, Aug 12, 2013 at 09:04:00PM -0400, Alan Stern wrote:
> 
> > 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?
> 
> I'd expect that we're just looking at hooks around connection and
> disconnection here here - if we're looking at much more it seems like we
> must be doing something wrong.

Connection and disconnection of what?

In the example mentioned earlier, the GPIOs to power an on-board USB
hub would have to be initialized when the host controller was started.  
You wouldn't want to wait for the on-board hub to be detected, because
without those GPIOs set properly, it never would be discovered on the
USB bus.  Right?

Perhaps the platform-level code would need to hook into the places
where the discoverable bus is registered and unregistered.

Alan Stern

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote:
> On Wed, 14 Aug 2013, Mark Brown wrote:

> > I'd expect that we're just looking at hooks around connection and
> > disconnection here here - if we're looking at much more it seems like we
> > must be doing something wrong.

> Connection and disconnection of what?

The device on the bus.

> In the example mentioned earlier, the GPIOs to power an on-board USB
> hub would have to be initialized when the host controller was started.  
> You wouldn't want to wait for the on-board hub to be detected, because
> without those GPIOs set properly, it never would be discovered on the
> USB bus.  Right?

Yes, so you'd want callbacks when the device actually appears and
disappears.

> Perhaps the platform-level code would need to hook into the places
> where the discoverable bus is registered and unregistered.

We'd need some way to get information to the drivers still, and to
handle drivers that want to stop and start things.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

On Wed, 14 Aug 2013, Mark Brown wrote:

> On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote:
> > On Wed, 14 Aug 2013, Mark Brown wrote:
> 
> > > I'd expect that we're just looking at hooks around connection and
> > > disconnection here here - if we're looking at much more it seems like we
> > > must be doing something wrong.
> 
> > Connection and disconnection of what?
> 
> The device on the bus.
> 
> > In the example mentioned earlier, the GPIOs to power an on-board USB
> > hub would have to be initialized when the host controller was started.  
> > You wouldn't want to wait for the on-board hub to be detected, because
> > without those GPIOs set properly, it never would be discovered on the
> > USB bus.  Right?
> 
> Yes, so you'd want callbacks when the device actually appears and
> disappears.

No, no -- this is exactly the point I was trying to make.  The on-board
hub _won't_ appear on the USB bus until the GPIOs are set.  Therefore
the callback to set the GPIOs needs to be at a different place, not
when the device appears.

> > Perhaps the platform-level code would need to hook into the places
> > where the discoverable bus is registered and unregistered.
> 
> We'd need some way to get information to the drivers still, and to
> handle drivers that want to stop and start things.

Um...  What exactly does this mean?  It's so generic, it could apply to
anything under drivers/.  After all, what driver doesn't want to stop
and start things?

Alan Stern

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

[Stephen Warren]

On 08/14/2013 10:14 AM, Alan Stern wrote:
> On Wed, 14 Aug 2013, Mark Brown wrote:
> 
>> On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote:
>>> On Wed, 14 Aug 2013, Mark Brown wrote:
>>
>>>> I'd expect that we're just looking at hooks around connection and
>>>> disconnection here here - if we're looking at much more it seems like we
>>>> must be doing something wrong.
>>
>>> Connection and disconnection of what?
>>
>> The device on the bus.
>>
>>> In the example mentioned earlier, the GPIOs to power an on-board USB
>>> hub would have to be initialized when the host controller was started.  
>>> You wouldn't want to wait for the on-board hub to be detected, because
>>> without those GPIOs set properly, it never would be discovered on the
>>> USB bus.  Right?
>>
>> Yes, so you'd want callbacks when the device actually appears and
>> disappears.
> 
> No, no -- this is exactly the point I was trying to make.  The on-board
> hub _won't_ appear on the USB bus until the GPIOs are set.  Therefore
> the callback to set the GPIOs needs to be at a different place, not
> when the device appears.

The device Mark was talking about is the controller end of the bus (EHCI
controller, or hub's downstream port) not the device end of the bus (any
USB device's upstream port).

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Wed, Aug 14, 2013 at 10:30:44AM -0600, Stephen Warren wrote:
> On 08/14/2013 10:14 AM, Alan Stern wrote:

> > No, no -- this is exactly the point I was trying to make.  The on-board
> > hub _won't_ appear on the USB bus until the GPIOs are set.  Therefore
> > the callback to set the GPIOs needs to be at a different place, not
> > when the device appears.

> The device Mark was talking about is the controller end of the bus (EHCI
> controller, or hub's downstream port) not the device end of the bus (any
> USB device's upstream port).

Actually it genuinely is a hub - it's not part of the controller, though
the startup does need to be synchronised with the controller.  It ends
up parenting some other devices but that's not suchan issue.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Wed, Aug 14, 2013 at 12:14:06PM -0400, Alan Stern wrote:
> On Wed, 14 Aug 2013, Mark Brown wrote:

> > Yes, so you'd want callbacks when the device actually appears and
> > disappears.

> No, no -- this is exactly the point I was trying to make.  The on-board
> hub _won't_ appear on the USB bus until the GPIOs are set.  Therefore
> the callback to set the GPIOs needs to be at a different place, not
> when the device appears.

What I'm proposing is that we have a way of telling buses that devices
exist via a mechanism other than their actually being visible on the bus
at the current time.  If you're doing that the driver can be running
prior to the hardware being there, just like it does with all the
non-enumerable buses.

> > > Perhaps the platform-level code would need to hook into the places
> > > where the discoverable bus is registered and unregistered.

> > We'd need some way to get information to the drivers still, and to
> > handle drivers that want to stop and start things.

> Um...  What exactly does this mean?  It's so generic, it could apply to
> anything under drivers/.  After all, what driver doesn't want to stop
> and start things?

It means that there are situations where a driver wants to take the
hardware offline but still offer services to userspace which will
require the hardware to be brought on line again.  The fact that this is
a very generic thing is exactly why I'm raising this as a generic issue.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

On Wed, 14 Aug 2013, Mark Brown wrote:

> On Wed, Aug 14, 2013 at 12:14:06PM -0400, Alan Stern wrote:
> > On Wed, 14 Aug 2013, Mark Brown wrote:
> 
> > > Yes, so you'd want callbacks when the device actually appears and
> > > disappears.
> 
> > No, no -- this is exactly the point I was trying to make.  The on-board
> > hub _won't_ appear on the USB bus until the GPIOs are set.  Therefore
> > the callback to set the GPIOs needs to be at a different place, not
> > when the device appears.
> 
> What I'm proposing is that we have a way of telling buses that devices
> exist via a mechanism other than their actually being visible on the bus
> at the current time.  If you're doing that the driver can be running
> prior to the hardware being there, just like it does with all the
> non-enumerable buses.

This may work for other buses, but it isn't feasible for USB.  Not only
do many of the drivers need to communicate with their device during
their probe routine, the subsystem itself needs to communicate with the
device before many of the important data structures can be constructed.  
Without these structures, the device can't be bound to a driver.  We 
wouldn't even know which driver to bind it to!

My impression is that much of what you want could be handled by a
platform callback invoked when a particular bus -- i.e., one whose
upstream controller is a particular platform device -- is registered.  
Is that correct?  For example, in the USB case, the on-board hub's
GPIOs could be set when the USB bus is registered (or perhaps when the
bus's root hub is registered).

> It means that there are situations where a driver wants to take the
> hardware offline but still offer services to userspace which will
> require the hardware to be brought on line again.  The fact that this is
> a very generic thing is exactly why I'm raising this as a generic issue.

This is a separate issue, more or less independent of whether the
platform needs to carry out special actions for the device in question.  
If you're suggesting these off-line/on-line transitions are appropriate
places for a platform hook, then yes, that makes sense.

Alan Stern

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]

On Wed, Aug 14, 2013 at 02:35:07PM -0400, Alan Stern wrote:
> On Wed, 14 Aug 2013, Mark Brown wrote:

> > What I'm proposing is that we have a way of telling buses that devices
> > exist via a mechanism other than their actually being visible on the bus
> > at the current time.  If you're doing that the driver can be running
> > prior to the hardware being there, just like it does with all the
> > non-enumerable buses.

> This may work for other buses, but it isn't feasible for USB.  Not only
> do many of the drivers need to communicate with their device during
> their probe routine, the subsystem itself needs to communicate with the
> device before many of the important data structures can be constructed.  
> Without these structures, the device can't be bound to a driver.  We 
> wouldn't even know which driver to bind it to!

The identification information for the device would of course have to be
provided as part of registering that the device was going to appear -
I'd expect to provide the same information that's read out of the
hardware during enumeration, with enumeration checking to see if it
knows about the device already.

> My impression is that much of what you want could be handled by a
> platform callback invoked when a particular bus -- i.e., one whose
> upstream controller is a particular platform device -- is registered.  
> Is that correct?  For example, in the USB case, the on-board hub's
> GPIOs could be set when the USB bus is registered (or perhaps when the
> bus's root hub is registered).

That sort of bodge is probably adequate for basic "power this on" stuff
but it's not going to scale to a general solution, especially where the
driver wants to use some of the information at runtime.  Currently
systems are doing things like bodging callbacks into controller drivers
which is basically what you're talking about here.

> > It means that there are situations where a driver wants to take the
> > hardware offline but still offer services to userspace which will
> > require the hardware to be brought on line again.  The fact that this is
> > a very generic thing is exactly why I'm raising this as a generic issue.

> This is a separate issue, more or less independent of whether the
> platform needs to carry out special actions for the device in question.  
> If you're suggesting these off-line/on-line transitions are appropriate
> places for a platform hook, then yes, that makes sense.

I think in the general case it's the same issue - grab all the resources
and enable them at probe time is the simplest implementation but it's
not the only one by a long stretch.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

On Wed, 14 Aug 2013, Mark Brown wrote:

> On Wed, Aug 14, 2013 at 02:35:07PM -0400, Alan Stern wrote:
> > On Wed, 14 Aug 2013, Mark Brown wrote:
> 
> > > What I'm proposing is that we have a way of telling buses that devices
> > > exist via a mechanism other than their actually being visible on the bus
> > > at the current time.  If you're doing that the driver can be running
> > > prior to the hardware being there, just like it does with all the
> > > non-enumerable buses.
> 
> > This may work for other buses, but it isn't feasible for USB.  Not only
> > do many of the drivers need to communicate with their device during
> > their probe routine, the subsystem itself needs to communicate with the
> > device before many of the important data structures can be constructed.  
> > Without these structures, the device can't be bound to a driver.  We 
> > wouldn't even know which driver to bind it to!
> 
> The identification information for the device would of course have to be
> provided as part of registering that the device was going to appear -
> I'd expect to provide the same information that's read out of the
> hardware during enumeration, with enumeration checking to see if it
> knows about the device already.

I don't see the point of all this.  Obviously the device can't be used
until it physically appears on the bus.  What benefit do you get from
registering it and making it available to userspace before that?

> > My impression is that much of what you want could be handled by a
> > platform callback invoked when a particular bus -- i.e., one whose
> > upstream controller is a particular platform device -- is registered.  
> > Is that correct?  For example, in the USB case, the on-board hub's
> > GPIOs could be set when the USB bus is registered (or perhaps when the
> > bus's root hub is registered).
> 
> That sort of bodge is probably adequate for basic "power this on" stuff
> but it's not going to scale to a general solution, especially where the
> driver wants to use some of the information at runtime.  Currently
> systems are doing things like bodging callbacks into controller drivers
> which is basically what you're talking about here.

Well, basic "power this on" stuff is pretty much all we have discussed 
in this thread so far.  What other sorts of things are going to be 
needed for a general solution?

> > > It means that there are situations where a driver wants to take the
> > > hardware offline but still offer services to userspace which will
> > > require the hardware to be brought on line again.  The fact that this is
> > > a very generic thing is exactly why I'm raising this as a generic issue.
> 
> > This is a separate issue, more or less independent of whether the
> > platform needs to carry out special actions for the device in question.  
> > If you're suggesting these off-line/on-line transitions are appropriate
> > places for a platform hook, then yes, that makes sense.
> 
> I think in the general case it's the same issue - grab all the resources
> and enable them at probe time is the simplest implementation but it's
> not the only one by a long stretch.

Now I'm getting confused.  It seems we're talking about at least three
very different things here:

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

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

     C: Implementing a mechanism whereby drivers can take a device
	off-line while still pretending to userspace that the device
	is still present, by bringing it back on-line as needed.

I don't see much connection between these things.  Perhaps you can
explain in more detail.

(BTW, it's worth mentioning that C has already been done, in the form
of runtime PM.  The difference may be that you propose to take the
device so far off-line that it disappears from the bus.  AFAICS, this
would be purely a private matter to be arranged between the subsystem
and the driver; it does not need to be handled at the level of the
device-model or PM core.)

Alan Stern

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

[Paul Zimmerman]

> From: Alan Stern
> Sent: Wednesday, August 14, 2013 12:39 PM

> Now I'm getting confused.  It seems we're talking about at least three
> very different things here:
> 
>      A: Devising a mechanism for platform code to do things involving
> 	devices that are dynamically registered on discoverable buses.
> 
>      B: Telling the subsystem and driver code for a discoverable bus
> 	that a particular device is present before it has been
> 	detected.
> 
>      C: Implementing a mechanism whereby drivers can take a device
> 	off-line while still pretending to userspace that the device
> 	is still present, by bringing it back on-line as needed.
> 
> I don't see much connection between these things.  Perhaps you can
> explain in more detail.
> 
> (BTW, it's worth mentioning that C has already been done, in the form
> of runtime PM.  The difference may be that you propose to take the
> device so far off-line that it disappears from the bus.  AFAICS, this
> would be purely a private matter to be arranged between the subsystem
> and the driver; it does not need to be handled at the level of the
> device-model or PM core.)

Mark's original complaint about USB was this:

> One example that's bugging me right now is that on the Insignal Arndale
> platform there's a USB hub connected to one of the USB ports on the SoC
> (not as a PHY, it seems we also need the internal PHY running to talk to
> the device).  The hub needs to be "plugged" into the SoC after the SoC
> USB controller has started with some GPIOs so we need to tell the system
> that the hub exists and needs to be synchronised with the USB controller.

This sounds to me like the normal discovery mechanism for USB isn't getting
kicked off because no Connect Status Change is being triggered on the root
port when the hub is brought online using the GPIOs. Maybe the port has
been runtime suspended because no device was attached originally?

So maybe the only thing needed for USB is a way to tell the parent port to
frob its port control bits to try to determine if a device is now present.
(set Wake on Connect Enable? Do a Port Reset? Cycle the Port Power bit if
possible?)

-- 
Paul

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

On Wed, Aug 14, 2013 at 08:16:56PM +0000, Paul Zimmerman wrote:

> Mark's original complaint about USB was this:
> 
> > the device).  The hub needs to be "plugged" into the SoC after the SoC
> > USB controller has started with some GPIOs so we need to tell the system
> > that the hub exists and needs to be synchronised with the USB controller.

> This sounds to me like the normal discovery mechanism for USB isn't getting
> kicked off because no Connect Status Change is being triggered on the root
> port when the hub is brought online using the GPIOs. Maybe the port has
> been runtime suspended because no device was attached originally?

> So maybe the only thing needed for USB is a way to tell the parent port to
> frob its port control bits to try to determine if a device is now present.
> (set Wake on Connect Enable? Do a Port Reset? Cycle the Port Power bit if
> possible?)

No, that's not required in this case - the case is the opposite one to
the one you describe.  Host starting first then hub works fine, if the
host does go into a low power mode it seems to notice the hub appearing
just fine.  Hub then host fails for some reason which I don't know.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 4126 bytes --]

On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote:

> I don't see the point of all this.  Obviously the device can't be used
> until it physically appears on the bus.  What benefit do you get from
> registering it and making it available to userspace before that?

Two things.  One is that some devices have the ability to perform useful
functions when powered down sufficiently that they can't run a complex
bus, providing notification when they need to wake up (or being woken up
if the power on comes from userspace).  The other is that then userspace
can just see the device and start using it when it needs it without
having to have a mechanism to discover that there's something there with
manual power control.

This can also be an issue in cases where we compose multiple physical
devices into composite ones for userspace (embedded audio and video do
this a lot for example).  A given bit of hardware may only be useful in
some circumstances.

> Well, basic "power this on" stuff is pretty much all we have discussed 
> in this thread so far.  What other sorts of things are going to be 
> needed for a general solution?

If you look elsewhere at the stuff I've been saying about Slimbus that's
the nastiest case I'm aware of in terms of the bus itself - that's got
the devices with low power modes that do useful things with the device
(and bus) mostly powered off and things like that.  Things like activity
detection of various kinds where the device is monitoring for activity
in a low power state.

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.

> Now I'm getting confused.  It seems we're talking about at least three
> very different things here:

>      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.

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

>      C: Implementing a mechanism whereby drivers can take a device
> 	off-line while still pretending to userspace that the device
> 	is still present, by bringing it back on-line as needed.

> I don't see much connection between these things.  Perhaps you can
> explain in more detail.

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.

> (BTW, it's worth mentioning that C has already been done, in the form
> of runtime PM.  The difference may be that you propose to take the
> device so far off-line that it disappears from the bus.  AFAICS, this
> would be purely a private matter to be arranged between the subsystem
> and the driver; it does not need to be handled at the level of the
> device-model or PM core.)

Actually runtime PM is actually already used for completely offlining
devices on buses that are too blind to notice - it's only an issue on
buses that can notice insertion and removal and want to do something
about it.  The use cases I'm describing already happen in mainline today
for devices on the dumber buses.

I think if we've got something which the hardware engineers can do on
multiple buses then they probably will so we should have at least a
pattern for how it's going to work over multiple buses rather than
having to handle different models for different buses.  I'll try to have
a think about what that pattern might be at some point (in my copious
free time).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

On Thu, 15 Aug 2013, Mark Brown wrote:

> On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote:
> 
> > I don't see the point of all this.  Obviously the device can't be used
> > until it physically appears on the bus.  What benefit do you get from
> > registering it and making it available to userspace before that?
> 
> Two things.  One is that some devices have the ability to perform useful
> functions when powered down sufficiently that they can't run a complex
> bus, providing notification when they need to wake up (or being woken up
> if the power on comes from userspace).  The other is that then userspace
> can just see the device and start using it when it needs it without
> having to have a mechanism to discover that there's something there with
> manual power control.
> 
> This can also be an issue in cases where we compose multiple physical
> devices into composite ones for userspace (embedded audio and video do
> this a lot for example).  A given bit of hardware may only be useful in
> some circumstances.
> 
> > Well, basic "power this on" stuff is pretty much all we have discussed 
> > in this thread so far.  What other sorts of things are going to be 
> > needed for a general solution?
> 
> If you look elsewhere at the stuff I've been saying about Slimbus that's
> the nastiest case I'm aware of in terms of the bus itself - that's got
> the devices with low power modes that do useful things with the device
> (and bus) mostly powered off and things like that.  Things like activity
> detection of various kinds where the device is monitoring for activity
> in a low power state.

Okay.  Previously we agreed that a device on one of these buses could
remain off-line except when the system needs to bring it to full power.  
To me, discovery and enumeration on the bus seem like a legitimate 
need.

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.

> 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?

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
for causing confusion if the two sets of data should disagree for any
reason.  When possible, it's always better to get info about the 
hardware from the hardware itself.

> > Now I'm getting confused.  It seems we're talking about at least three
> > very different things here:
> 
> >      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.

> >      B: Telling the subsystem and driver code for a discoverable bus
> > 	that a particular device is present before it has been 
> > 	detected.
> 
> >      C: Implementing a mechanism whereby drivers can take a device
> > 	off-line while still pretending to userspace that the device
> > 	is still present, by bringing it back on-line as needed.
> 
> > I don't see much connection between these things.  Perhaps you can
> > explain in more detail.
> 
> 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.

> > (BTW, it's worth mentioning that C has already been done, in the form
> > of runtime PM.  The difference may be that you propose to take the
> > device so far off-line that it disappears from the bus.  AFAICS, this
> > would be purely a private matter to be arranged between the subsystem
> > and the driver; it does not need to be handled at the level of the
> > device-model or PM core.)
> 
> Actually runtime PM is actually already used for completely offlining
> devices on buses that are too blind to notice - it's only an issue on
> buses that can notice insertion and removal and want to do something
> about it.  The use cases I'm describing already happen in mainline today
> for devices on the dumber buses.

Which means eliminating case B will be all that much easier for these 
buses.

> I think if we've got something which the hardware engineers can do on
> multiple buses then they probably will so we should have at least a
> pattern for how it's going to work over multiple buses rather than
> having to handle different models for different buses.  I'll try to have
> a think about what that pattern might be at some point (in my copious
> free time).

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.

If devices are removable then things are a lot more complicated.  The 
usb-storage driver used to do what you are talking about, back in the 
days of the 2.4 kernels.  When a mass-storage device was unplugged, 
the driver would remember it and reuse the data structures when the 
device was plugged back in and reprobed.  Linus himself told us this 
was a mistake, so we removed the feature.

The USB subsystem now supports this feature in a very limited form.  
If the hardware session gets dropped while the computer is suspended,
then at resume time the system will try to verify that the device
present at that bus address is the same device that was there before
the suspend.  If it is, we will continue to use it as if the connection
had never dropped.

Alan Stern

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 4107 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

On Thu, 15 Aug 2013, Mark Brown wrote:

> 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.

Not necessarily immediately, then.  Let's say at the time when you
would have wanted to tell the bus about the device's existence, even
though it hadn't yet been detected.

> 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.

Of course.  Glue outside of drivers is very significant, whether that 
glue takes the form of code or data.

> > 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.

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.

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?

(Were you thinking of the case where the device's IRQ signal doesn't go
over the bus but uses a different platform mechanism?  I don't quite 
see how this can work.  What about devices on the bus that aren't known 
to the platform beforehand?  How do they send their IRQ signals?)

>  A bus could insist on this if it
> needed the information from enumeration for some reason but really it
> seems like an implementation detail.

It isn't an implementation detail.  The "power-up for initial
detection" scheme is a general solution to the problem of setting up a
complicated communication path between the bus and the platform.  
(I.e., it gives a simple way to avoid the need for this communication,
that can be used on any discoverable bus.)  It also is a general 
solution for avoiding the problem of registering a device on a bus 
before that device has been discovered and enumerated.

Alan Stern

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3136 bytes --]

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.

> 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.  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.

> (Were you thinking of the case where the device's IRQ signal doesn't go
> over the bus but uses a different platform mechanism?  I don't quite 
> see how this can work.  What about devices on the bus that aren't known 
> to the platform beforehand?  How do they send their IRQ signals?)

Either the bus doesn't support anything like interrupts at all or they'd
use the standard bus mechanisms.  Typical reasons for bypassing the bus
include things like latency and power, or excessive cost for
implementation on the device side.

> >  A bus could insist on this if it
> > needed the information from enumeration for some reason but really it
> > seems like an implementation detail.

> It isn't an implementation detail.  The "power-up for initial
> detection" scheme is a general solution to the problem of setting up a
> complicated communication path between the bus and the platform.  
> (I.e., it gives a simple way to avoid the need for this communication,
> that can be used on any discoverable bus.)  It also is a general 
> solution for avoiding the problem of registering a device on a bus 
> before that device has been discovered and enumerated.

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3290 bytes --]

On Thu, Aug 15, 2013 at 04:42:01PM -0400, Alan Stern wrote:

> 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.

I think this is pretty essential - there is no point in having platform
data if you can't pass it to the device.  It needs to make it to the
driver at the very least by the time the probe function runs.

> > 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.

Right, but my contention would be that if it's not the driver for the
device that is being instantiated it's probably not going to be
anything scalable since that's where we generally put our knowledge of a
given bit of silicon.

> >  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

For a bus controller of course, they should be totally out of this.

> 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!

No, this really is something that's very much generic to the device and
will apply to anywhere the silicon is used.  The power on process for a
device isn't something that changes, the mapping of resources that might
be used in that sequence is but we've got good abstractions for pretty
much all the resources that a device might need - clocks, power, GPIOs
and so on - which do the mapping of those resources onto the device at
board level so neither the provider not the user need to know about it.
That's just data and is much easier to encode in DT or equivalent than
actual sequences.

We've got a bunch of existing drivers in the kernel which do this sort
of stuff, they ask for resources and then know what to do with them and
can also make use of these resources at runtime if they want.

> > 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.

Like I say device power management isn't system specific, it's silicon
specific - think of what's in the driver as being the power up sequence
from the datasheet.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

On Fri, 16 Aug 2013, Mark Brown wrote:

> > The difficulty with the first proposal is that subsystems aren't
> > designed to allow that sort of thing.  They expect to be able to
> > communicate with the devices they manage, during enumeration and
> > probing at least.  The difficulty with the second proposal is that it
> > requires duplicating the power-on code.
> 
> > My feeling is that the second answer involves less work and less
> > complexity than the first.  Both proposals require additional
> > "run-once" code (to do the partial instantiations or the initial
> > power-ons), but the first proposal also requires the subsystem's 
> > detection and enumeration routines to be adjusted so that they can work 
> > even when the device is incommunicado.
> 
> Right, but like I say I'm not sure that the modifications required are
> substantially different to those for handling a device powering up and
> down on the bus

I believe they are.  At the very least, a larger set of modifications
would be needed, because the subsystem's device-init and enumeration
routines would have to be changed to work with a powered-down device,
as would the driver's probe routine.  Whereas handling a device
powering up and down on the bus merely requires the subsystem's
connection-change routine to be modified.

>  or those for getting platform data to a device when it
> does enumerate.

?  I can't make any sense out of that comment.  For one thing, why do
you need to send platform data to a device?  (It's obvious that a
_driver_ would need to use platform data; it's not so clear that a
_device_ would.)

But even assuming you really do need to send platform data to the
device when it enumerates, don't the subsystem and driver already take
care of sending this data?  If they didn't then presumably the device
wouldn't be usable.  Therefore it seems that _no_ modifications should
be needed for this purpose.

>  I'd also not be so sure about the run once code, that
> is only the case for devices that can't completely idle themselves at
> runtime.
> 
> > (The second proposal also has the advantage that the power-on code may 
> > be shared between the driver and the subsystem.)
> 
> Can you explain in more detail please, I don't follow?

Let's say the subsystem powers up the device when the bus is first
registered, so that the device can be detected and enumerated.  Let's
also say that the driver wants to power-off and power-on the device
from time to time, as part of normal runtime PM.  Then instead of
having its own power-on routine (which would be code duplication), the
driver can simply call the subsystem's power-on routine.  (Of course,
this would mean that the routine would no longer be run-once.)

Alan Stern

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Fri, Aug 16, 2013 at 03:27:58PM -0400, Alan Stern wrote:
> On Fri, 16 Aug 2013, Mark Brown wrote:

> >  or those for getting platform data to a device when it
> > does enumerate.

> ?  I can't make any sense out of that comment.  For one thing, why do
> you need to send platform data to a device?  (It's obvious that a
> _driver_ would need to use platform data; it's not so clear that a
> _device_ would.)

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

> > > (The second proposal also has the advantage that the power-on code may 
> > > be shared between the driver and the subsystem.)

> > Can you explain in more detail please, I don't follow?

> Let's say the subsystem powers up the device when the bus is first
> registered, so that the device can be detected and enumerated.  Let's
> also say that the driver wants to power-off and power-on the device
> from time to time, as part of normal runtime PM.  Then instead of
> having its own power-on routine (which would be code duplication), the
> driver can simply call the subsystem's power-on routine.  (Of course,
> this would mean that the routine would no longer be run-once.)

Oh, OK.  I don't think that's a meaningful difference, the driver is
going to have the code and be able to reuse it one way or another
anyway.  In many cases if the device has been in a low power idle mode a
slightly difference sequence would be needed anyway.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

On Fri, 16 Aug 2013, Mark Brown wrote:

> On Fri, Aug 16, 2013 at 03:27:58PM -0400, Alan Stern wrote:
> > On Fri, 16 Aug 2013, Mark Brown wrote:
> 
> > >  or those for getting platform data to a device when it
> > > does enumerate.
> 
> > ?  I can't make any sense out of that comment.  For one thing, why do
> > you need to send platform data to a device?  (It's obvious that a
> > _driver_ would need to use platform data; it's not so clear that a
> > _device_ would.)
> 
> 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".

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.

Alan Stern

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

On Fri, 16 Aug 2013, Mark Brown wrote:

> > 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.

I agree.  In fact, there's no choice but to use this device concept
during startup.  Otherwise there's no way to get the platform data to
the driver when it is needed, because there's no way to tell which
device the data applies to.  The question is how elaborate the concept
needs to be and how it gets used.

Aong those lines, I would like to point out that the device concept
embodied in the kernel's data structures can be pretty thin.  For
example, it might be little more than a port number or bus address.

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

Hopefully this discussion has given you some ideas for alternative 
approachs, or at least helped to solidify your ideas.

Alan Stern

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

[Ming Lei]

On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 16 Aug 2013, Mark Brown wrote:
>
>> > 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.
>
> I agree.  In fact, there's no choice but to use this device concept
> during startup.  Otherwise there's no way to get the platform data to
> the driver when it is needed, because there's no way to tell which
> device the data applies to.  The question is how elaborate the concept
> needs to be and how it gets used.
>
> Aong those lines, I would like to point out that the device concept
> embodied in the kernel's data structures can be pretty thin.  For
> example, it might be little more than a port number or bus address.

Maybe the principle behind drivers/usb/core/usb-acpi.c is helpful
for the problem, and DT may refer to ACPI to describe on-board
USB devices, and the way to retrieve platform data too.

>> Anyway, I think it's time to try to implement something rather than talk
>> about it.
>
> Hopefully this discussion has given you some ideas for alternative
> approachs, or at least helped to solidify your ideas.


Thanks,
-- 
Ming Lei

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Mon, Aug 19, 2013 at 08:17:53PM +0800, Ming Lei wrote:
> On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern <stern@rowland.harvard.edu> wrote:

> > Aong those lines, I would like to point out that the device concept
> > embodied in the kernel's data structures can be pretty thin.  For
> > example, it might be little more than a port number or bus address.

> Maybe the principle behind drivers/usb/core/usb-acpi.c is helpful
> for the problem, and DT may refer to ACPI to describe on-board
> USB devices, and the way to retrieve platform data too.

I can't parse this at all well - why would DT want to refer to ACPI, do
you mean people may wish to look at the code as an example?  As Grant
noted DT already has some mechanisms for enumerable buses which looking
at the code appears to be broadly what that's doing.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Ming Lei]

On Tue, Aug 20, 2013 at 12:01 AM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Aug 19, 2013 at 08:17:53PM +0800, Ming Lei wrote:
>> On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
>
>> > Aong those lines, I would like to point out that the device concept
>> > embodied in the kernel's data structures can be pretty thin.  For
>> > example, it might be little more than a port number or bus address.
>
>> Maybe the principle behind drivers/usb/core/usb-acpi.c is helpful
>> for the problem, and DT may refer to ACPI to describe on-board
>> USB devices, and the way to retrieve platform data too.
>
> I can't parse this at all well - why would DT want to refer to ACPI, do
> you mean people may wish to look at the code as an example?  As Grant

I mean usb-acpi provides one approach to retrieve platform data for USB device
during device enumeration, and the idea might be helpful for you to implement
similar things based on DT.

> noted DT already has some mechanisms for enumerable buses which looking
> at the code appears to be broadly what that's doing.

If the mechanism is ready now, so looks you might post code for review
and discussion?


Thanks,
-- 
Ming Lei

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

On Tue, Aug 20, 2013 at 09:19:07PM +0800, Ming Lei wrote:
> On Tue, Aug 20, 2013 at 12:01 AM, Mark Brown <broonie@kernel.org> wrote:

> > I can't parse this at all well - why would DT want to refer to ACPI, do
> > you mean people may wish to look at the code as an example?  As Grant

> I mean usb-acpi provides one approach to retrieve platform data for USB device
> during device enumeration, and the idea might be helpful for you to implement
> similar things based on DT.

Ah, OK.

> > noted DT already has some mechanisms for enumerable buses which looking
> > at the code appears to be broadly what that's doing.

> If the mechanism is ready now, so looks you might post code for review
> and discussion?

There's nothing there for the problem I'm talking about here (devices
that haven't been enumerated yet) and I don't off the top of my head
know if the enumerated case is supported by any buses in Linux yet.  It
is part of the DT specifications and has been implemented on other OSs
but I'd need to go check if Linux actually went and implemented any of
that.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

On Mon, Aug 12, 2013 at 12:08:17PM -0600, Stephen Warren wrote:

> In a similar way, I wonder if the USB case can be considered the same
> way? This seems less like a good fit since I don't expect the resources
> are always so similar there, and also there's the case of the bus being
> potentially behind a few levels of USB hub.

That won't work for the hub on Arndale in a system where it's fully
wired up - it's got an I2C interface for control and the idea is that
you bring it out of reset, write the configuration out via I2C and then
you can complete startup using a GPIO or another I2C command.

> And of course it all gets a little more messy when you get
> board-specific logic that needs setup, rather than something more common
> across multiple devices.

I think we could probably cover many cases by putting common things onto
the bus but we still need to confront the cases where the device driver
really does need to get involved in what's going on.  Things like the
SDIO WiFi cards seem very interchangable as you say and would probably
benefit a lot but there's other applications that are less regular.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]