Re: [RFC PATCH 1/4] PLATFORM: introduce structure to bind async platformdata to a dev path name

[Andy Green]

On 03/13/2011 04:14 PM, Somebody in the thread at some point said:

Hi -

> You CAN NOT GUARANTEE the USB device ordering of bus numbers or device
> numbers.  It's that simple.
>
> > If the platform / board definition file is registering the USB hosts
> > synchronously at boot time, the driver is composed into the
> > monolithic kernel, there are no PCI busses or whatever on the SoC,
> > the bus indexing is totally deterministic.
>
> Not true, it could change for a number of reasons, not the least being
> your kernel version changed.
>
> So again NEVER rely on this, bad things could happen in the field when
> you least expect it.

Okay, I can't see how and you did not explain how, but let's agree with 
what you are saying.

Unlike the Shiny Device Tree path where the binding device path string 
is in the bootloader, with this patch series the binding device path is 
in the board definition file, ie, part of the same kernel.  If an 
upgrade breaks it, the guy can look in /sys on his new broken kernel, 
find the new path and uplevel it to that and he's consistent again.  If 
he goes back to an older kernel, it still works consistently (unlike if 
he updated his bootloader that now only knows the new way).

However as I said to Rafael if he thought bus name part of this path was 
too shaky, and you also think it is, it can be changed to use a pointer 
to the host controller since that's also coming from platform or board 
definition file directly in this kind of SoC implementation and is 
available.

-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/