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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 11 Mar 2011 12:44:11 +0000
From:	Andy Green <andy@...mcat.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Platform data for onboard USB assets

On 03/11/2011 12:31 PM, Somebody in the thread at some point said:

Hi -

>> platform_data is a well established way in Linux to pass configuration
>> data up to on-board assets from a machine file like mach-xyz.c.  It's
>> also supported to pass platform_data up to devices that are probed
>> asynchronously from busses like i2c as well, which is very handy.
>>
>> However AFAIK it's not possible to bind platform_data to probed USB
>> devices as it stands.
>>
>> There are now boards which have on-board USB assets, for example OMAP4
>> Panda which has a USB<->  Ethernet bridge wired up permanently.  It'd be
>> convenient to also be able to pass optional platform_data to these
>> devices when they are asynchronously probed.
>
> Sorry, but I think it's a bad idea to use platform data for this.
> USB is a bus that we can reasonably probe, while we use platform_data
> only for stuff that we can by definition not probe at all.

...

> One relatively easy solution would be to allow passing a MAC address
> to this particular device driver as a module parameter, and generating
> a fixed MAC address in the regular vendor space when installing the
> boot loader. That would also solve the problem that a DHCP server
> currently assigns a new IP address to a panda board at every boot.

I suggested this myself on #15 of the bug you linked to.  However, it 
seems to me there is a generic issue here and it is not to do with 
whether stuff can be discovered on the bus or not; bugging the usbnet 
guys to accept devname-based commandline params and solving it for 
usbnet only would be covering up the actual issue.

The I2C implementation does not limit itself to providing I2C addresses 
and binding to driver names so it can be probed, it also provides for 
sending platform_data into the device when it is instantiated.  That is 
very useful and I don't think the I2C guys will be accepting patches to 
remove that capability.

There is no reason I can see that onboard USB assets should continue to 
be treated differently to miss out on the same capability because they 
are USB and not I2C, particularly as a permanently NULL platform_data 
pointer is already sitting there in the usb_device's .dev already 
exactly for this use.

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