[Bug 283896] iwmbtfw(8): [PATCH] Check firmware exists before trying to upload it

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283896

            Bug ID: 283896
           Summary: iwmbtfw(8): [PATCH] Check firmware exists before
                    trying to upload it
           Product: Base System
           Version: 15.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: gavin@FreeBSD.org
             Flags: mfc-stable14+

Created attachment 256486
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256486&action=edit
Patch against head

TLDR: Device disconnects and reconnects to the USB bus twice a second.

iwmbtfw is the tool used to upload Bluetooth firmware to iwm(4) Intel WiFi
cards.  It is called from devd(4) via the rules in /etc/devd/iwmbtfw.conf when
the device appears.

In the case of an Intel 7260 device, the device needs to be put into something
called "manufacturer mode" before the firmware is uploaded.  The firmware is
then upladed, and the card is taken out of this mode, at which point it
disconnects and reconnects to the USB bus, and is at that point usable.

However, iwmbtfw(8) puts the device into manufacturer mode before verifying
that there exists a copy of the firmware to upload.  As a result, in the case
where there is no firmware, the device is put into manufacturer mode, the
firmware can't be found so isn't uplaoded, and the card is brought out of
manufacturer mode, so it disconnects and reconnects to the USB bus.

Enter devd(8).  There are rules in /etc/devd/iwmbtfw.conf to call iwmbtfw(8)
when the device appears.  When there's no firmware on disk, devd will call
iwmbtfw, iwmbtfw will do its thing and fail, the device will dis/reconnect, and
devd will notice and start the whole loop again.  Result of this is:

Jan  6 18:47:32 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
Jan  6 18:47:32 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
(disconnected)
Jan  6 18:47:32 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
Jan  6 18:47:32 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
(disconnected)
Jan  6 18:47:33 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
Jan  6 18:47:33 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
(disconnected)
Jan  6 18:47:33 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
Jan  6 18:47:33 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
(disconnected)
Jan  6 18:47:34 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
Jan  6 18:47:34 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
(disconnected)
Jan  6 18:47:34 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
Jan  6 18:47:34 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
(disconnected)
Jan  6 18:47:35 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
Jan  6 18:47:35 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
(disconnected)
Jan  6 18:47:35 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
Jan  6 18:47:35 omega kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at usbus0
(disconnected)

Fix (attached) is to verify that the firmware exists before putting the device
into its special mode.  The fix only changes things for the 7260 and not the
other chips supported, I can't easily test those so don't know if the problem
exists there or not but I suspect not as those do not need to be switched into
manufacturer mode before uplading.

This needs backporting to stable/14 (confirmed, I see the same behaviour) and
stable/13 (suspected, not confirmed).

-- 
You are receiving this mail because:
You are the assignee for the bug.