linux-kernel - Re: RFC: Platform data for onboard USB assets

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LFD.2.00.1103231044510.11889@xanadu.home>
Date:	Wed, 23 Mar 2011 10:55:55 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	andy.green@...aro.org, andy@...mcat.com,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jaswinder Singh <jaswinder.singh@...aro.org>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>, arnd@...db.de,
	broonie@...nsource.wolfsonmicro.com, roger.quadros@...ia.com,
	greg@...ah.com, grant.likely@...retlab.ca
Subject: Re: RFC: Platform data for onboard USB assets

On Wed, 23 Mar 2011, Alan Cox wrote:

> Much of this depends upon what the data is and what it changes. Things
> like interface names for example shouldn't be kernel mangled on the whim
> of random board vendors. They follow a unified behaviour *across*
> platforms, which is what matters most in the bigger picture.

And that's exactly what we're trying to restore on the Panda.  It 
happens that the Panda has an ethernet connector backed by an USB to 
Ethernet bridge, but the kernel currently decides to rename its network 
device from eth%d to usb%d, and assign it a random MAC address on each 
boot.  What we want _is_ a more unified behaviour with other platforms.

> Other stuff is to all intents and purposes sometimes hard coded into
> drivers because while they are USB drivers they are checking specific
> vendor id fields and changing behaviour on them. In some cases those
> vendor id fields are actually a specific hardwired device.

Here we're talking about a plain standard chipset but which happens in 
this case to be soldered directly on the board without the usual EEPROM 
which would have been used to distinguish this particular case 
otherwise.  All we have left is the board specific code where the kernel 
knows on which board it is dealing with, from where we can tell that one 
particular instance of that USB device should be used in some unexpected 
way in order to present user space with an unified behaviour with other 
similar platforms.

Nicolas

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