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: <1358730796.24121.229.camel@deadeye.wl.decadent.org.uk>
Date:	Mon, 21 Jan 2013 01:13:16 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Dan Williams <dcbw@...hat.com>
Cc:	Lubomir Rintel <lkundrak@...sk>,
	David Woodhouse <dwmw2@...radead.org>,
	libertas-dev@...ts.infradead.org, linux-bluetooth@...r.kernel.org,
	Gustavo Padovan <gustavo@...ovan.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	Johan Hedberg <johan.hedberg@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: sd8688 firmware location

On Wed, 2013-01-09 at 16:45 -0600, Dan Williams wrote:
> On Wed, 2013-01-09 at 00:56 +0100, Lubomir Rintel wrote:
> > Hi!
> > 
> > btmrvl_sdio and libertas_sdio both use firmware files sd8688.bin and
> > sd8688_helper.bin. In linux-firmware, they're present in libertas/ tree and
> > (since 3d32a58b) libertas_sdio perfers loading it from there, while it is able
> > to fallback to load it from linux-firmware root. btmrvl_sdio, on the other hand
> > only looks in the root and ends up not being successful.
> > 
> > Obviously, there are two solutions to the problem -- either teach btmrvl_sdio
> > to look into libertas/, or move the files in linux-firmware tree. I don't
> > really have a strong preference, though it probably makes less sense to keep in
> > in libertas/, since the bluetooth hardware is not really marketed as "Libertas."
> > 
> > I'm following up with patches to linux and linux-firmware and I'd be very
> > thankful if you could pick one (not both of them).
> 
> So the BT part and the wifi part have different SDIO IDs; are they
> actually connected separately to the SDIO bus?  Or is the chip only in
> one mode at one time or something like that?  Is there a problem with
> having both libertas and btmrvl loaded at the same time since they're
> essentially the same chip?
> 
> I don't really mind moving stuff to mrvl/ out of libertas/ for these
> devices, but I do want some backwards compat code in libertas for that.
> Unless, of course, Marcel was talking about symlinks in the
> linux-firmware git tree, which would be fine with me.  The important
> point is that simply updating your linux-firmware package or install or
> whatever *should not* result in a failed firmware load.

The general policy for linux-firmware.git has been that all filenames
required by all mainline kernel releases will be supported indefinitely.
There is already precedent for compatibility symlinks.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ