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: <20110317214042.GQ31411@opensource.wolfsonmicro.com>
Date:	Thu, 17 Mar 2011 21:40:42 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Greg KH <greg@...ah.com>
Cc:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Arnd Bergmann <arnd@...db.de>, andy.green@...aro.org,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Platform data for onboard USB assets

On Thu, Mar 17, 2011 at 02:31:08PM -0700, Greg KH wrote:
> On Thu, Mar 17, 2011 at 09:24:49PM +0000, Mark Brown wrote:

> > The way this is normally done is that the ethernet controller can be
> > attached to a SEPROM which it reads when it powers on.  This will
> > contain a number of device configuration parameters, including the
> > vendor IDs and the MAC address, which will be configured before the
> > device makes itself available on the bus.  If the system integrator has
> > omitted the SEPROM then the device will come up with defaults, usually
> > something like all zeros.

> Ok, then again, let's deal with this on a case-by-case basis please, as
> this is going to be a "rare" thing in the real world.  I don't want to
> encourage _any_ engineers to think that this is ok to do for USB
> devices.

It's really not at all rare in the embedded world - the overwhelming
majority of the systems I've worked on have omitted the SEPROMS for
components that are soldered down in the system.  It'd be pretty insane
to do it for things that are distinct USB devices but that's not the
case.

There are good solid engineering reasons for doing things this way if
you've got any prospect of shifting any kind of volume, as well as the
cost saving achieved by removing a component you also simplify and most
likely speed up the production process as you can reduce the number of
components that need to be programmed on each system that gets built.

> Patches to fix this, for this specific PandaBoard controller are gladly
> accepted.  What's odd is this is explicitly a Linux development board,
> so you would think that this could have been caught, and fixed, in the
> hardware a long time ago, right?

The way everyone resolves this stuff is by patching their kernel
locally.
--
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/