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:	Wed, 23 Mar 2011 11:11:26 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc:	andy.green@...aro.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, Benjamin Herrenschmidt wrote:

> Among ideas that have been proposed have been the idea of having stubs
> generating pseudo-device nodes from platform_data for devices in order
> to enable the drivers to use a single interface for example. That didn't
> really go through tho. However, whatever the final approach will be, the
> point remains that for drivers that have not so far been "contaminated"
> by the platform_data paradigm, we have the opportunity to try something
> better, which can then, maybe, be retro-fitted on a case by case basis
> to platform drivers, for example as such drivers get converted to also
> be capable of using the device-tree.
> 
> This is where I'm trying to propose a middle ground with the idea of
> named properties. It goes toward the direction that platform_device has
> been trying to to with the struct resource, but there's only so much you
> can do with these and they are showing their limits when it comes to
> expose arbitrary informations. MAC addresses are an example but there
> are many more, from clock bindings, power control, PHY data, connector
> informations, yadadada... which all can potentially apply to on-board
> USB or PCI based devices.

I think your middle ground proposal is more than that.  Conceptually, it 
positions DT as one of the possible device configuration backends 
instead of making DT the sanctioned configuration frontend.  To me this 
is very important as I don't want to be stuck with DT support where it 
would simply be an unwanted burden and overhead.  By having this generic 
abstraction in the middle, it is then possible to decouple DT from the 
actual drivers, and then use DT because it makes sense and not just 
because there is no way around it.  And who knows when some other non-DT 
configuration scheme may appear in the industry where the simple 
addition of another backend would make things more straight forward than 
having to construct synthetic FTDs on the fly.


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/