Age | Commit message (Collapse) | Author |
|
Spotted by Andreas Schnebinger
|
|
provide a buffer of random bytes to the device on initialization.
|
|
using the new sets of registers.
|
|
names.
|
|
firmare names on Apple M1 Pro/Max and Apple T2 Macs.
|
|
|
|
bindings.
|
|
|
|
and close flowrings using bwfm_do_async().
Reported by and ok kettenis@
|
|
data. Also add the MAC address to the nvram data when there is a
"local-mac-address" property in the device tree. This makes bwfm(4) work
with the firmware/nvram/clm_blob files provided with MacOS on the Apple
M1 Macs.
ok patrick@
|
|
device into D3 and do a hot-resume if possible. Otherwise we need to clean
up the resources to allow complete HW re-initialization to take place.
|
|
not considered initialized anymore.
|
|
a suspend/resume cycle, the values are set to a sane default.
|
|
by a suspend/resume cycle, the pointers are set to a sane default.
|
|
even got there in the first place. I've been wondering why I have
seen a bit of mbuf corruption here and there since I put the bwfm(4)
M.2 PCIe card into my arm64 machine. Well, duh.
|
|
nvram files used for the different Apple devices. The device tree and
the OTP hold the information which of those we will have to use. For
now this information will simply be printed, but depending on how we
choose to do the firmare distribution we could use it for loadfirmware().
|
|
|
|
to use a different set of PCIE2REG registers. Accessing the "old" ones
even leads to faults. There are two surprises though. One is that it
seems that the interrupt status register always returns 0, and the other
one is that we receive the interrupts way too early, but both can be
worked around for now.
|
|
this already on previous chips, which only started giving us packets when
handing over at least 128 of them. Apparently some now require 256, which
seems to get the Apple M1's WiFi going.
|
|
used in the wifi firmware to ensure responses can be received.
|
|
initialized.
|
|
to load the CLM blob like the SDIO backend already does. Additionally it
is also helpful for the PCIe backend to try a file named after the device
tree compatible. Thus refactor the SDIO code and make it available for
both SDIO and PCIe.
|
|
|
|
While the for-loop checks that thie value has changed since we wrote to
it, the timeout-condition checked for non-zero, which is wrong. This
means that we didn't realize the firmware wasn't started. While there,
make sure the shared DRAM address is inside the chip's address space.
|
|
the same time.
|
|
on the rx/tx complete rings has increased slightly to accomodate possible
new features.
|
|
the first cut of this diff was made with coccinelle using this spatch:
@rule@
type caddr_t;
expression m, off, len, cp;
@@
-m_copydata(m, off, len, (caddr_t)cp)
+m_copydata(m, off, len, cp)
i had fix it's opinionated idea of formatting by hand though, so
i'm not sure it was worth it.
ok deraadt@ bluhm@
|
|
little bit more to do though before it can be enabled.
|
|
OK dlg@, bluhm@
No Opinion mpi@
Not against it claudio@
|
|
this is a step toward deprecating softclock based livelock detection.
|
|
reduces the amount of duplicated lines per chip, and allows us to ship per-
board files in the future.
Based on a diff from jsg@
ok kurt@
|
|
external tool to pre-process the NVRAM, even though it's simple to
do ourselves. This allows easier firmware distribution, especially
since on some x86 machines the NVRAM is stored in an EFI variable.
|
|
This reduces drops caused by the ifq pressure drop mechanism and hence
increases throughput.
ok tobhe@
|
|
task and interrupt try to concurrently submit messages on the
control ring.
|
|
an offset to make sure they start from 1.
|
|
the hardware is processing them, the write index can catch up to the
read index. We must make sure that our write index stays smaller
than the hardware's read index, thus the difference between both has
to be bigger than 1.
ok tobhe@
|
|
ok bluhm@
|
|
error cases.
|
|
ok deraadt
|
|
ok kettenis@
|
|
request 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. With this rework we send and 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.
|
|
is synced properly before the CPU or the WiFi chip access the supplied
memory. Makes PCIe-connected bwfm(4) work on ARM-based machines.
|
|
32-bit platforms without the compiler complaining. In the end the
value will turn out as 0 anyway. Allows enabling bwfm(4) on 32-bit
platforms.
ok stsp@
|
|
Tested by mlarkin@
|
|
binary. In case we have an (optional) NVRAM binary, copy it to the
end of the chip's memory.
Tested by mlarkin@ on his GPD Pocket.
|
|
and initialize bwfm(4) later in the case that the firmware was not
available on bootup and was only later installed.
ok stsp@
|
|
BARs, where the second one is much larger than the first. Both need
to be properly aligned in the given extent. Since the first one is
smaller, it will "unalign" the next free space and thus create a gap
so that the second BAR cannot be properly aligned in the given space.
By mapping the second BAR first, it will automatically have proper
alignment. The first BAR, which has fewer alignment requirements,
fits well after the initial allocation. Fixes bwfm(4) on APU 1.
Debugged and solved by kettenis@
|
|
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.
|
|
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@
|
|
function so it can be shared with the SDIO attachment driver.
|