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: <1299881249.22236.646.camel@pasglop>
Date:	Sat, 12 Mar 2011 09:07:29 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	andy.green@...aro.org
Cc:	Greg KH <greg@...ah.com>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: RFC: Platform data for onboard USB assets

On Fri, 2011-03-11 at 16:41 +0000, Andy Green wrote:
> >> Is it true that for on-board devices, it can sometimes be legitimate
> >> and useful to be able to deliver platform_data from the board file
> >> through to stuff on a USB bus, same as you would for memory mapped,
> >> I2C, other busses?
> >>
> >> Or is that it since it is USB, it can never be useful or legitimate,
> >> no matter what different kind of wired-up on-board USB device it is,
> >> to have the board definition file configure the driver for that
> >> instantiation?
> >
> > Since it is USB, it is always discoverable, so it doesn't make any sense
> > to have this type of thing.
> >
> > And since your only example was a network device, I think you proved
> > your point :)

Actually there are reasons to pass that sort of static informations for
"discoverable" devices, essentially when such devices are wired on a
board. MAC addresses come to mind (how many on-board NICs don't have a
MAC SEEPROM wired to them ? Even on PCI we've seen that...) etc...

However, the device-tree would deal with that quite nicely. It doesn't
require you to represent discoverable devices but you -can- do it, and
it's typically a good idea for soldered devices for that reason.

The USB binding for device-trees uses physical port numbers in Hubs as
the primary addressing scheme so it would work just fine to represent
the USB devices soldered on the board as well.

And here you get your transport. The USB core wouldn't need more than a
handful of lines of code to generically update the usb_device's struct
device embedded device_node pointer when a match exists, so the driver
only needs to check if the device is linked to a device-tree node, and
if it is, fetch informations from there.

As to how the device-tree is constructed, all the usual stuff applies
here, can be in flash, can be "fixed up" by FW or platform code (to
stick a unique MAC address from flash for example or calculated from a
serial number etc....).

But you have you "transport" mechanism sorted.

Cheers,
Ben.

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