#14265: iprowifi3945 may not power ON wifi adapter
--------------------------------------------+------------------------------
Reporter: cocobean | Owner: waddlesplash
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: Drivers/Network/iprowifi3945 | Version: R1/Development
Resolution: | Keywords: iprowifi3945,
| wpi
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
--------------------------------------------+------------------------------
Comment (by cocobean):
Updated for hrev53404 x86_gcc2:
Ok, I may go back and try hrev50465 (was mentioned to work previously). I
noticed the Haiku wpi code had some small changes (29) versus the FreeBSD
wpi code so I'd took more time to breeze through the wpi code. Noted some
TX/RX handling and AES disable changes. FreeBSD updated the wpi code to
Fix ieee80211_radiotap(9) usage in the wireless drivers.
One thing that I'm pondering:
{{{
* The 3945ABG network adapter doesn't use traditional hardware as
* many other adaptors do. Instead at run time the eeprom is set into a
known
* state and told to load boot firmware. The boot firmware loads an init
and a
* main binary firmware image into SRAM on the card via DMA.
* Once the firmware is loaded, the driver/hw then
* communicate by way of circular dma rings via the SRAM to the firmware.
*
* There is 6 memory rings. 1 command ring, 1 rx data ring & 4 tx data
rings.
* The 4 tx data rings allow for prioritization QoS.
*
* The rx data ring consists of 32 dma buffers. Two registers are used to
* indicate where in the ring the driver and the firmware are up to. The
* driver sets the initial read index (reg1) and the initial write index
(reg2),
* the firmware updates the read index (reg1) on rx of a packet and fires
an
* interrupt. The driver then processes the buffers starting at reg1
indicating
* to the firmware which buffers have been accessed by updating reg2. At
the
* same time allocating new memory for the processed buffer.
*
* A similar thing happens with the tx rings. The difference is the
firmware
* stop processing buffers once the queue is full and until confirmation
* of a successful transmition (tx_done) has occurred.
*
* The command ring operates in the same manner as the tx queues.
*
* All communication direct to the card (ie eeprom) is classed as Stage1
* communication
*
* All communication via the firmware to the card is classed as State2.
* The firmware consists of 2 parts. A bootstrap firmware and a runtime
* firmware. The bootstrap firmware and runtime firmware are loaded
* from host memory via dma to the card then told to execute. From this
point
* on the majority of communications between the driver and the card goes
* via the firmware.
}}}
{{{
ic->ic_cryptocaps =
IEEE80211_CRYPTO_AES_CCM;
/*
* Read in the eeprom and also setup the channels for
* net80211. We don't set the rates as net80211 does this for us
*/
if ((error = wpi_read_eeprom(sc, ic->ic_macaddr)) != 0) {
device_printf(dev, "could not read EEPROM, error %d\n",
error);
goto fail;
}
}}}
I don't see any significant changes in the current FreeBSD wpi code and
FreeBSD 11.x/12.0 works on this laptop.
--
Ticket URL: <https://dev.haiku-os.org/ticket/14265#comment:18>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
