Non-enumerable devices on USB and other enumerable buses

Non-enumerable devices on USB and other enumerable buses

[Mark Brown]

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

Looking at the enumerable buses in the kernel I don't see any which have
real support for any kind of registration of devices prior to their
enumeration.  Similarly currently all the DT bindings in the kernel I've
been able to notice cover only non-enumerable buses.  This generally
makes sense where enumerable buses are used in standard fashions since
the binding would be at best redundant and at worst inaccurate.  However
there are often corner cases in embedded systems where hardware has been
hooked up outside of the normal enumeration mechanisms, for example with
software power control or extra signals wired.

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.

Another case that's going to be problematic once it's in mainline is
Slimbus - this is a bus used in some embedded audio subsystems which is
enumerable in a similar manner to USB but where the devices on the bus
are normally powered up only on demand (causing them to hotplug when
used and unplug when idle) and have at least interrupt lines wired to
the SoC using a normal interrupt outside the enumerable bus.

I know there's been some discussion of this topic but do we have any
general consensus on how to handle such things both from a Linux driver
model point of view and from a DT/ACPI point of view?

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

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

[Grant Likely]

On Sun, Aug 11, 2013 at 8:08 PM, Mark Brown <broonie@kernel.org> wrote:
> I know there's been some discussion of this topic but do we have any
> general consensus on how to handle such things both from a Linux driver
> model point of view and from a DT/ACPI point of view?

There is precedence for describing enumerated device in the device
tree. Real OpenFirmware platforms can and will enumerate the PCI and
USB busses and pass a full tree to the OS. I don't think we want to
full enumerating like that with either ACPI or FDT, but we could allow
for sparse population of devices when something is fixed like a
soldered down USB hub or USB Ethernet MAC.

To make it work would probably require a hook in the USB enumeration
path to look for matching nodes in DT/ACPI and attach it to the struct
device.

g.

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

[Alan Stern]

On Sun, 11 Aug 2013, Mark Brown wrote:

> Looking at the enumerable buses in the kernel I don't see any which have
> real support for any kind of registration of devices prior to their
> enumeration.  Similarly currently all the DT bindings in the kernel I've
> been able to notice cover only non-enumerable buses.  This generally
> makes sense where enumerable buses are used in standard fashions since
> the binding would be at best redundant and at worst inaccurate.  However
> there are often corner cases in embedded systems where hardware has been
> hooked up outside of the normal enumeration mechanisms, for example with
> software power control or extra signals wired.
> 
> 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.

On the surface, this seems like a particularly simple case.  Why wait 
until the SoC's USB controller has started?  Why not "plug in" the hub 
via the GPIOs right from the beginning?

> Another case that's going to be problematic once it's in mainline is
> Slimbus - this is a bus used in some embedded audio subsystems which is
> enumerable in a similar manner to USB but where the devices on the bus
> are normally powered up only on demand (causing them to hotplug when
> used and unplug when idle) and have at least interrupt lines wired to
> the SoC using a normal interrupt outside the enumerable bus.

That is indeed more difficult, because it requires geniune cooperation 
between the bus and platform subsystems.

> I know there's been some discussion of this topic but do we have any
> general consensus on how to handle such things both from a Linux driver
> model point of view and from a DT/ACPI point of view?

The discussion involved some sort of pattern matching based on the
device name and the bus, but nothing was ever settled.

Alan Stern

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

[Greg Kroah-Hartman]

On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote:
> Looking at the enumerable buses in the kernel I don't see any which have
> real support for any kind of registration of devices prior to their
> enumeration.  Similarly currently all the DT bindings in the kernel I've
> been able to notice cover only non-enumerable buses.  This generally
> makes sense where enumerable buses are used in standard fashions since
> the binding would be at best redundant and at worst inaccurate.  However
> there are often corner cases in embedded systems where hardware has been
> hooked up outside of the normal enumeration mechanisms, for example with
> software power control or extra signals wired.

Not just "embedded", the Macbooks have this same issue as well I'm
pretty sure, it's just that we don't know where those GPIOs are in order
to be able to use them...

> 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.
> 
> Another case that's going to be problematic once it's in mainline is
> Slimbus - this is a bus used in some embedded audio subsystems which is
> enumerable in a similar manner to USB but where the devices on the bus
> are normally powered up only on demand (causing them to hotplug when
> used and unplug when idle) and have at least interrupt lines wired to
> the SoC using a normal interrupt outside the enumerable bus.
> 
> I know there's been some discussion of this topic but do we have any
> general consensus on how to handle such things both from a Linux driver
> model point of view and from a DT/ACPI point of view?

As these are usually bus-specific things, and really, platform-specific
things, I'd fall back and just recommend a "platform driver" that
"knows" about where these gpios are, and how/when to enable them, which
will cause the discoverable bus logic to kick in now that it notices a
device is present/removed.

Perhaps a semi-generic "platform" driver could be created, that knows
how to handle these settings in the DT, but odds are, that might be
difficult to make generic enough to cover a wide range of boards, but
without specifics, it's hard to tell.

thanks,

greg k-h

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

[Mark Brown]

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

On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote:
> On Sun, 11 Aug 2013, Mark Brown wrote:

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

> On the surface, this seems like a particularly simple case.  Why wait 
> until the SoC's USB controller has started?  Why not "plug in" the hub 
> via the GPIOs right from the beginning?

I tried that, it doesn't seem to work - for some reason it seems that
the hub is only successfully enumerated if it starts after its parent is
running.  I don't know enough about USB to speculate on why that might
be, the GPIOs are brining the device out of reset not applying power or
anything.

> > Another case that's going to be problematic once it's in mainline is
> > Slimbus - this is a bus used in some embedded audio subsystems which is
> > enumerable in a similar manner to USB but where the devices on the bus
> > are normally powered up only on demand (causing them to hotplug when
> > used and unplug when idle) and have at least interrupt lines wired to
> > the SoC using a normal interrupt outside the enumerable bus.

> That is indeed more difficult, because it requires geniune cooperation 
> between the bus and platform subsystems.

Yeah.  You might want to do the same with for example a USB network
controller when you're in flight only mode, that seems to be one of the
more common reasons for doing this sort of thing with USB.

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

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

[Mark Rutland]

[Adding Olof]

On Mon, Aug 12, 2013 at 10:51:36AM +0100, Mark Brown wrote:
> On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote:
> > On Sun, 11 Aug 2013, Mark Brown wrote:
> 
> > > 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.
> 
> > On the surface, this seems like a particularly simple case.  Why wait 
> > until the SoC's USB controller has started?  Why not "plug in" the hub 
> > via the GPIOs right from the beginning?
> 
> I tried that, it doesn't seem to work - for some reason it seems that
> the hub is only successfully enumerated if it starts after its parent is
> running.  I don't know enough about USB to speculate on why that might
> be, the GPIOs are brining the device out of reset not applying power or
> anything.
> 
> > > Another case that's going to be problematic once it's in mainline is
> > > Slimbus - this is a bus used in some embedded audio subsystems which is
> > > enumerable in a similar manner to USB but where the devices on the bus
> > > are normally powered up only on demand (causing them to hotplug when
> > > used and unplug when idle) and have at least interrupt lines wired to
> > > the SoC using a normal interrupt outside the enumerable bus.
> 
> > That is indeed more difficult, because it requires geniune cooperation 
> > between the bus and platform subsystems.
> 
> Yeah.  You might want to do the same with for example a USB network
> controller when you're in flight only mode, that seems to be one of the
> more common reasons for doing this sort of thing with USB.

As I understand it, the wifi chip on the Snow Chromebook has a similar
issue -- it hangs off of a probeable SDIO bus, but needs a regulator
poked for it to turn on and become probeable (see
exynos_wifi_bt_set_power in [1]).

Thanks,
Mark.

[1] http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=blob;f=arch/arm/mach-exynos/mach-exynos5-dt.c;h=d131241ea78b7d89df21e676e284ddfd369b4da0;hb=refs/heads/chromeos-3.4

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

[Mark Brown]

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

On Sun, Aug 11, 2013 at 07:02:57PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote:

> > I know there's been some discussion of this topic but do we have any
> > general consensus on how to handle such things both from a Linux driver
> > model point of view and from a DT/ACPI point of view?

> As these are usually bus-specific things, and really, platform-specific

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.

> things, I'd fall back and just recommend a "platform driver" that
> "knows" about where these gpios are, and how/when to enable them, which
> will cause the discoverable bus logic to kick in now that it notices a
> device is present/removed.

This doesn't work in general.  These things aren't really platform
specific at all, they're features of the devices that apply to any
system using them and while for some use cases (like WiFi and BT power)
an external thing that just manually applies power will be enough in
other cases we want to know about the device even while it's off and the
driver might be able to do extra things at runtime if it knows about for
example having some control over signals to the device.

For example in the Slimbus case we're normally talking about audio
CODECs.  In order to preserve the userspace API the device has to appear
to be present at all times, the driver will remember the settings the
user is making to be applied when it actually powers up and indeed the
powering up should be kicked off as a result of userspac acting on the
apparently present device.

Another example here (including USB devices) is interrupt signals wired
directly back to the processor, completely outside of the bus.

> Perhaps a semi-generic "platform" driver could be created, that knows
> how to handle these settings in the DT, but odds are, that might be
> difficult to make generic enough to cover a wide range of boards, but
> without specifics, it's hard to tell.

There's things like the rfkill stuff already, and the reset controller
on the way, but again this only covers a fairly small subset of the
issues.

[-- 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: 475 bytes --]

On Mon, Aug 12, 2013 at 12:07:14PM +0100, Mark Rutland wrote:

> As I understand it, the wifi chip on the Snow Chromebook has a similar
> issue -- it hangs off of a probeable SDIO bus, but needs a regulator
> poked for it to turn on and become probeable (see
> exynos_wifi_bt_set_power in [1]).

Yes, that's another example - this stuff is really common in practical
systems, especially the power control for radios since that's how rfkill
tends to end up being implemented.

[-- 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: 876 bytes --]

On Sun, Aug 11, 2013 at 11:08:37PM +0100, Grant Likely wrote:

> full enumerating like that with either ACPI or FDT, but we could allow
> for sparse population of devices when something is fixed like a
> soldered down USB hub or USB Ethernet MAC.

I agree, there's no point in listing things that can be done
automatically - it's just introducing potential for error.

> To make it work would probably require a hook in the USB enumeration
> path to look for matching nodes in DT/ACPI and attach it to the struct
> device.

Yes, that was where I was heading too.  Have a mechanism for matching up
hotplugged devices with pre-registered ones which appear from firmware
or wherever if their IDs match.  It'd need some mechanism for drivers to
opt into being bound to devices that aren't physically there I think so
that normal drivers for enumerated devices don't get confused.

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

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

[Stephen Warren]

On 08/12/2013 05:07 AM, Mark Rutland wrote:
> [Adding Olof]
> 
> On Mon, Aug 12, 2013 at 10:51:36AM +0100, Mark Brown wrote:
>> On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote:
>>> On Sun, 11 Aug 2013, Mark Brown wrote:
>>
>>>> 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.
...
> As I understand it, the wifi chip on the Snow Chromebook has a similar
> issue -- it hangs off of a probeable SDIO bus, but needs a regulator
> poked for it to turn on and become probeable (see
> exynos_wifi_bt_set_power in [1]).

In this case, I wonder if it makes sense to model the extra requirements
as part of the bus/socket/... itself rather than as part of the device
that's attached to the bus.

It seems quite common for SDIO-based WiFi devices to need a few things:
* Regulator
* 32KHz clock
* Enable GPIO (-> rfkill?)
* Perhaps a reset GPIO

Physically, these are provided to the socket into which the WiFi device
plugs in. Perhaps we should try to explicitly model the socket (which I
guess is really the SDIO bus in a way) rather than attaching these new
resources to the controller or the device itself.

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.

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.

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

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

[Greg Kroah-Hartman]

On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote:
> On Sun, Aug 11, 2013 at 07:02:57PM -0700, Greg Kroah-Hartman wrote:
> > On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote:
> 
> > > I know there's been some discussion of this topic but do we have any
> > > general consensus on how to handle such things both from a Linux driver
> > > model point of view and from a DT/ACPI point of view?
> 
> > As these are usually bus-specific things, and really, platform-specific
> 
> 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.

> > things, I'd fall back and just recommend a "platform driver" that
> > "knows" about where these gpios are, and how/when to enable them, which
> > will cause the discoverable bus logic to kick in now that it notices a
> > device is present/removed.
> 
> This doesn't work in general.  These things aren't really platform
> specific at all, they're features of the devices that apply to any
> system using them and while for some use cases (like WiFi and BT power)
> an external thing that just manually applies power will be enough in
> other cases we want to know about the device even while it's off and the
> driver might be able to do extra things at runtime if it knows about for
> example having some control over signals to the device.

No, the device isn't platform specific, but the logic needed to turn
on/off is platform specific, otherwise the device would "just work"
properly as the bus is self-discoverable.

Much like rfkill is, as you point out.  Those are all platform specific.

> For example in the Slimbus case we're normally talking about audio
> CODECs.  In order to preserve the userspace API the device has to appear
> to be present at all times, the driver will remember the settings the
> user is making to be applied when it actually powers up and indeed the
> powering up should be kicked off as a result of userspac acting on the
> apparently present device.

That's some horrible hardware, who thought of that?

> Another example here (including USB devices) is interrupt signals wired
> directly back to the processor, completely outside of the bus.

Like rfkill switches that just power on/off a USB device built onto the
laptop motherboard :)

> > Perhaps a semi-generic "platform" driver could be created, that knows
> > how to handle these settings in the DT, but odds are, that might be
> > difficult to make generic enough to cover a wide range of boards, but
> > without specifics, it's hard to tell.
> 
> There's things like the rfkill stuff already, and the reset controller
> on the way, but again this only covers a fairly small subset of the
> issues.

"small subset"?  How common is this type of thing?

thanks,

greg k-h

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

[Mark Brown]

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

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.

> > This doesn't work in general.  These things aren't really platform
> > specific at all, they're features of the devices that apply to any
> > system using them and while for some use cases (like WiFi and BT power)
> > an external thing that just manually applies power will be enough in
> > other cases we want to know about the device even while it's off and the
> > driver might be able to do extra things at runtime if it knows about for
> > example having some control over signals to the device.

> No, the device isn't platform specific, but the logic needed to turn
> on/off is platform specific, otherwise the device would "just work"
> properly as the bus is self-discoverable.

> Much like rfkill is, as you point out.  Those are all platform specific.

This is not just about power control - that's one of the simpler
applications but you're talking about essentially anything that might be
handled by platform data (or by the configuration SEPROMs on a
freestanding device for that matter, why would you put down an extra
part to configure the device when you can just load things from the AP).

> > For example in the Slimbus case we're normally talking about audio
> > CODECs.  In order to preserve the userspace API the device has to appear
> > to be present at all times, the driver will remember the settings the
> > user is making to be applied when it actually powers up and indeed the
> > powering up should be kicked off as a result of userspac acting on the
> > apparently present device.

> That's some horrible hardware, who thought of that?

It's actually pretty nice hardware in many regards; the bus is a bit
underspecified for maximum bandwidth in modern systems but it gives you
standardised multi-drop data streaming over two wires muxed with control
which helps with the pin counts and with simplifying the system hardware
design.

The disappearing from the bus thing is because you're aiming to hit low
power idle (but still functioning) states consuming very small numbers
of microamps, even having a clock running is measurable.

> > > Perhaps a semi-generic "platform" driver could be created, that knows
> > > how to handle these settings in the DT, but odds are, that might be
> > > difficult to make generic enough to cover a wide range of boards, but
> > > without specifics, it's hard to tell.

> > There's things like the rfkill stuff already, and the reset controller
> > on the way, but again this only covers a fairly small subset of the
> > issues.

> "small subset"?  How common is this type of thing?

Well, for Slimbus it's absolutely the norm, I've never seen a Slimbus
device that didn't have a need for platform data.  The small subset
there is of the problems rather than the devices - you'll cover a large
set of devices with a common helper like rfkill but trying to handle
everything with that pattern doesn't seem like it'll work.

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

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

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

[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

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

[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

[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

[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

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

[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

[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

[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

[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

[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 Thu, 15 Aug 2013, Mark Brown wrote:

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

Okay, let's see if I understand your problem.  You've got a driver that
knows how to manage its devices, including how to power them on and
off.  But the driver can't bind to one of these devices until the
device has appeared on the bus and been enumerated, and that won't
happen until the device has been powered on.  It's a chicken-and-egg
sort of thing.

You know about the existence of these devices beforehand because that
knowledge is encapsulated in platform information somewhere.  The
question is how best to use this information to solve the
chicken-and-egg problem.

Is that it?

One possible answer is to use the platform information to (partially)  
instantiate the device before it has been detected, so that the driver
can bind to it.  Another is to use the platform information to perform
an initial power-up of the device, so that it can be detected,
enumerated, and probed in the normal manner.

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.

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

Alan Stern

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

[Mark Brown]

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

On Fri, Aug 16, 2013 at 10:42:10AM -0400, Alan Stern wrote:

> Okay, let's see if I understand your problem.  You've got a driver that
...
> Is that it?

Yes, I think that's it.

> 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 or those for getting platform data to a device when it
does enumerate.  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?

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

[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

[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

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