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-next>] [day] [month] [year] [list]

Date:	Wed, 23 Mar 2011 08:08:45 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Jaswinder Singh <jaswinder.singh@...aro.org>
Cc:	andy.green@...aro.org, Andy Green <andy@...mcat.com>,
	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,
	Nicolas Pitre <nicolas.pitre@...aro.org>
Subject: Re: RFC: Platform data for onboard USB assets

> Q(b) If yes, what 'key' is most suitable for identifying the right
> device
>   to attach the data to ?

We already pointed out that in the case of soldered-in device, the
"path" as in the series of -physical- ports leading to the device is
going to be stable.

For anything else, there's no solution. If the device doesn't have a
unique ID, you are toast, period.

On the other hand, I still think platform_data suck big time. Grant made
some good points about the lack of proper typing for example. I believe
that a device-tree based approach is much better in the long run (and
more flexible) despite Andy odd quasi-religious aversion for it.

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/