[Bug 2013027] Re: Issues over broadcom brcmfmac43455 firmware

[Sergio Callegari]

** Attachment added: "my brcmfmac43455-sdio.clm_blob"
   https://bugs.launchpad.net/ubuntu/+source/linux-firmware-raspi2/+bug/2013027/+attachment/5681265/+files/brcmfmac43455-sdio.clm_blob

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to linux-firmware-raspi2 in
Ubuntu.
https://bugs.launchpad.net/bugs/2013027

Title:
  Issues over broadcom brcmfmac43455 firmware

Status in linux-firmware package in Ubuntu:
  New
Status in linux-firmware-raspi2 package in Ubuntu:
  New

Bug description:
  Hi, I have a Kodlix Z83-II minicomputer that employs a broadcom
  chipset for WIFI.

  The only way to make wifi on that PC work is to use the firmware from
  the windows image, even if that chipset is apparently managed in
  ubuntu.

  With the firmware files provided by ubuntu you get no 5GHz for wifi.
  The problem is that every time ubuntu updates the firmware package,
  firmware files dropped in /lib/firmware get overwritten, linking to
  some file in the cypress sub-directory.

  - Ideally, Ubuntu should provide all the firmware files that might be
  needed. Maybe this is not possible as there is a too large variety of
  different firmwares for broadcom chipsets or licesing issues
  preventing distribution.

  - As a second possibility, there should be a way to drop files in
  /lib/firmware 'side to side' to the distro ones, without having the
  risk of finding the manually added files rewritten. This implies that
  different pieces of hardware use firmware files with different
  filenames. Don't know if this is truly possible, as I do not know how
  the linux kernel decides the name of the firmware to load.

  - In cases like mine, it seems that the ubuntu firmware package puts
  in place symlinks to have brcmfmac43455 files point to the
  corresponding cypress cyfmac43455 files. Possibly, the package could
  avoid creating the symlinks if a brcmfmac43455 file is manually placed
  in lib/firmware.

  - As a last resort, I think that the documentation in
  `/usr/share/doc/linux-firmware` should be augmented to describe the
  most appropriate way to prevent custom firmware files from being
  rewritten: marking files not-writable? introducing diversions?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2013027/+subscriptions