linux-kernel - Re: [RFC PATCH 1/4] PLATFORM: introduce structure to bind async platform data to a dev path name

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 13 Mar 2011 17:26:35 +0000
From:	Andy Green <andy@...mcat.com>
To:	Greg KH <greg@...ah.com>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org, patches@...aro.org
Subject: Re: [RFC PATCH 1/4] PLATFORM: introduce structure to bind async platform
 data to a dev path name

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