summaryrefslogtreecommitdiffstats
path: root/sys/dev/usb/if_bwfm_usb.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* TX packets, which can be either Ethernet or control packets, must bepatrick2018-07-171-50/+46
| | | | | | | | | sent in order. Otherwise it is possible that the key is set before we send out the EAPOL packet, or that packets are sent out before the key is set. Thus modify the SDIO backend to put both types into the same internal TX queue, which will be sent asynchronously. Discussed with bluhm@
* Don't leak the RX pipe in case we have issues opening the TX pipe.patrick2018-05-231-2/+2
|
* Implement a separate initialization stage so that we can still usepatrick2018-05-231-15/+37
| | | | | | | and initialize bwfm(4) later in the case that the firmware was not available on bootup and was only later installed. ok stsp@
* Correct order of free(9) in an error case.patrick2018-05-161-2/+2
|
* Implement a BCDC control packet mechanism based on the command requestpatrick2018-05-161-47/+65
| | | | | | | | | ids. So far we were only able to have one command in flight at a time and race conditions could easily lead to unexpected behaviour, especia- lly combined with a slow bus and timeouts. With this rework we send or enqueue a control packet command and wait for replies to happen. Thus we can have multiple control packets in flight and a reply with the correct id will wake us up.
* Since the BCDC header has a variable data offset, so the ethernet packetpatrick2018-02-111-2/+1
| | | | | alignment can be variable, it's better to move taking care of alignment into the BCDC receive code.
* Move bwfm(4) from ifq begin/commit/rollback semantics to the newerpatrick2018-02-081-3/+15
| | | | | | | | | | | | | | | ifq dequeue semantics. This basically means we need to check for available space before dequeuing a packet. As soon as we dequeue a packet we commit to it. On the PCIe backend this check can not be done easily since the flowring depends on the packet contents and we cannot take a peek. When there is no flowring we cache the mbuf and send it out as soon as the flowring opened up. Then the ifq can be restarted and traffic can flow. Typically we usually run out of packet ids, which can be checked without consulting the packet. The flowring probably never becomes full as the bwfm(4) firmware takes the packets off the ring without actually sending them out. Discussed with dlg@
* Move parsing the BCDC header on RX into a protocol specific RXpatrick2018-02-071-15/+4
| | | | function so it can be shared with the SDIO attachment driver.
* Do not print that the firmware was successfully loaded in the USB backendpatrick2018-01-241-2/+1
| | | | | | | driver. It is only useful to know if firmware loading has failed. This means fewer clutter in dmesg(8). Spotted by and ok stsp@
* Fix indentation.patrick2018-01-081-2/+2
|
* Since the PCI attachment code already uses mbufs for RX packets, we canpatrick2018-01-031-2/+31
| | | | | push the mbuf allocation down into the USB attachment code and now pass an mbuf to the bwfm(4) receive function.
* Initialize all fields in the BCDC protocol, otherwise the controllerpatrick2017-10-211-1/+3
| | | | | | | behaves erratically and drops packets on TX. Found the hard way by Jared McNeill. While there, also set the priority field. ok stsp@
* Don't just return but setup and resubmit the transfer if we're notpatrick2017-10-191-5/+4
| | | | | | | getting the data we expect to be getting. Otherwise the firmware can starve our USB RX descriptors using invalid packets. Caught by Jared McNeill.
* Don't forget to free the firmware in the error path, and make sure topatrick2017-10-191-2/+3
| | | | | | pass the proper size. Caught by Jared McNeill.
* Similar to other USB based backend drivers, have a list of TX/RXpatrick2017-10-151-54/+171
| | | | | | | | buffers. By storing the pointer of the TX mbuf in the TX buffer, we can make sure to free the mbuf properly after TX completed. This also seems to speed up the WiFi scan. previous version ok stsp@
* Add bwfm(4), a driver for Broadcom FullMAC WiFi controllers. Thepatrick2017-10-111-0/+698
FullMAC, in comparison to SoftMAC, does most WiFi handling in the firmware that's running on the controller. This means we have to work around the net80211 stack while still implementing all the WiFi interfaces to userland. This driver is still in early development. So far it can connect to open WiFis over the USB bus. SDIO and PCIe support, for devices like the Raspberry Pi 3 or the Macbooks, is not yet implemented. Also mbufs on the transmit path leak and are not yet freed. ok stsp@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.