sd8688 firmware location

[Bing Zhao]

Hi Dan,

> > 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?

SD8688 is a combo chip with different device IDs for WLAN (function 1) and BT (function 2). WLAN + BT together are connected to the bus with a single SDIO interface. Both libertas and btmrvl drivers can be loaded at the same time, and WLAN & BT functions work concurrently. Of course the SDIO bus is shared between WLAN and BT.

The firmware image can be downloaded from host to device by either libertas or btmrvl driver whoever becomes the winner from firmware downloading perspective.

Regards,
Bing

> 
> 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.
> 
> Dan