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 09:47:20 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	andy.green@...aro.org
Cc:	andy@...mcat.com,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Nicolas Pitre <nicolas.pitre@...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

> There is no udev solution for what is being done currently by the async 
> platform_data patchset with SDIO WLAN.  The patches are out there and in 
> use already.  The only reason I don't post them here as round 2 of the 
> RFC yet is because Grant wanted a couple of days and politically it's 
> expedient for me to agree to that.

Kernel policy has always been that just because some vendor has deployed
an interface doesn't mean we care one iota about it or consider it an
argument for the solution. In some cases in fact it bcomes the working
demo of why it was a bad idea.

> But there are a huge number of users of platform_data in mainline 
> already we can agree.  Are you talking about a mass conversion of those 
> to eliminating platform_data so they use your preferred token query model?

Ultimately that will probably be worth doing once we have some kind of
meaningful model. We've actually been slowly beating platform devices
into making more use of the resource data it does have when possible, and
we have various parsers between platform data and device specific
platform data structs that are horrible glue-together jobs that it would
be nice to stomp on.

> I think the first additional effort needs to start at home on that one 
> and think through Device Tree and kernel policy on interoperation with 
> existing driver implementations using platform_data.  Just being sniffy 
> about platform_data for reasons you can't back up when challenged won't 
> cut it IMO.

Much of this depends upon what the data is and what it changes. Things
like interface names for example shouldn't be kernel mangled on the whim
of random board vendors. They follow a unified behaviour *across*
platforms, which is what matters most in the bigger picture.

Other stuff is to all intents and purposes sometimes hard coded into
drivers because while they are USB drivers they are checking specific
vendor id fields and changing behaviour on them. In some cases those
vendor id fields are actually a specific hardwired device.

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