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]

Message-ID: <4D7A34F1.7070601@nokia.com>
Date:	Fri, 11 Mar 2011 16:42:57 +0200
From:	Roger Quadros <roger.quadros@...ia.com>
To:	<andy.green@...aro.org>
CC:	ext Andy Green <andy@...mcat.com>, Arnd Bergmann <arnd@...db.de>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Platform data for onboard USB assets

Hi,

On 03/11/2011 02:44 PM, ext Andy Green wrote:

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

I fail to see the problem. USB is a dynamically probed bus.
Whether the USB peripheral is hard-wired to the board or not, it is 
still dynamically probed. The board files are not expected to know 
anything about USB peripherals prior to enumeration, so platform data 
does not make sense for USB.

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

Platform data makes perfect sense for I2C because it is not a 
dynamically probed bus and board writers need to define which I2C chips 
are present on the board.

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

What do you want to set in platform data? the ethernet device name? 
Isn't that better done in user space using udev rules?

-- 
regards,
-roger
--
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/