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: <20110323105335.GB778@opensource.wolfsonmicro.com>
Date:	Wed, 23 Mar 2011 10:53:35 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	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,
	roger.quadros@...ia.com, greg@...ah.com, grant.likely@...retlab.ca
Subject: Re: RFC: Platform data for onboard USB assets

On Wed, Mar 23, 2011 at 09:38:47AM +0000, Alan Cox wrote:

> > Generally speaking, this wouldn't make sense.  but this is a case where 
> > a generically probed device happens to be used in a very specific 
> > hardware design with its own quirks.  in that very particular case then 
> > it certainly makes some sense.

> If it's a very specific hardware design it can do its own very specific
> internal private kernel patch, or little config app in user space. There
> isn't a valid reason to inflict that complexity on the other 99.999999%
> of users.

Just to be clear this sort of stuff is not, in general, a particularly
obscure problem for embedded systems.  General good practice in hardware
design is to remove components to achieve cost savings and improvements
in manufacturability and things like configuration SEPROMs tend to be
among the first things to go.  Vendors producing reference boards for
these markets will tend go for the cost downs on such devices even if
the volumes are relatively low to ensure that their reference designs
are directly usable in end projects, and reference designs tend to be
disproportionately visible to people working with the kernel.

In the specific case of MACs and device names for network adaptors we
have userspace solutions which are obscuring the discussion but there
are other things which get configured this way which one would usually
expect to be handled in kernel.
--
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/