Age | Commit message (Collapse) | Author |
|
Make sure uvm_obj_init() is only called once. Call uvm_obj_destroy()
when we release the GEM object that wraps an uvm object for which we
called uvm_obj_init().
ok mpi@, jsg@
|
|
fixes instability issues seen on X1 carbon gen3 (hw rev 0x210) by
anton@, mpi@ and myself.
diff from stsp@
ok mpi@ stsp@
|
|
ic_bss->ni_bssid has already been overwritten once we enter
iwx_newstate_task() to perform the state transitions necessary
for roaming to our new access point (RUN->AUTH->ASSOC->RUN).
We do however use the BSSID in commands sent to firmware.
Cache our BSSID in struct iwx_node such that firmware commands
keep using the old BSSID while we are still tearing things down.
Switch to the new BSSID only once we start back up in iwx_auth().
This should be consistent from the firmware's point of view.
Same fix as committed for iwm(4) recently.
|
|
This is similar to a recent fix committed to iwm(4).
Unlike iwm(4) we do not need to disable Tx aggregation queues in iwx(4).
Attempting to do so would cause fatal firmware errors.
Tested by jmc@ and myself.
|
|
Tested with cc-a0-63 and QuZ-a0-hr-b0-63 firmware by myself.
Tested with Qu-c0-hr-b0-63 firmware by Fredrik Engberg.
|
|
According to 11n MCS index tables our maximum data rate is now
300 Mbit/s at MCS 15, excluding protocol overhead. I have measured
up to 200Mbit/s of effective throughput on clean 5GHz channels.
The driver enables use of 40MHz channels automatically as long as the
access point announces support for such channels in its beacons.
In case 40MHz transmissions fail we ask firmware to retry with a
20MHz transmission.
There is no integration with ifconfig yet, so use of 40MHz is not yet
displayed there. In the meantime, tcpdump(8) can be used to check if
the current access point supports 40MHz:
tcpdump -n -i iwm0 -v -y IEEE802_11_RADIO -s 4096 type mgt and subtype beacon
Channel width is displayed in the HT operation information element, where
a 40MHz channels looks like this: htop=<40MHz chan X:Y ...>
Tested:
7260: florian, bcallah
7265: landry
8260: bket
8265: stsp, abieber, Matthias Schmidt, Josh Rickmar, empee on mastodon
9560: stsp
|
|
For the moment we use either the 40MHz rate set or the 20 MHz one,
depending on whether our peer supports 40MHz channels.
If this turns out to be suboptimal we could probe the 40MHz and 20MHz
rate sets separately to detect which one works better.
The same applies to use of the short guard interval (SGI), which is
either always on or off at the moment. Again, probing for this could
be added later if needed.
|
|
implemented but have that call return NOT_SUPPORTED. Makes no sense,
but the SMCCC standard documents this and tells us to treat this as v1.0.
Change the code accordingly. Turn a few checks that should always be true
into KASSERTs to keep the control flow simple.
ok patrick@
|
|
but other circumstances are also bad, so let's block all vnd on top of vnd.
While here, fix some toctou multiple-copyin of the path, and restructure
the ioctl defer all softc updates to the end.
ok mpi
|
|
from Brad
|
|
machine at least; let's see how others are; ok ratchov@
|
|
ic_bss->ni_bssid has already been overwritten once we enter
iwm_newstate() to perform the state transitions necessary for
roaming to our new access point (RUN->AUTH->ASSOC->RUN).
We do however use the BSSID in commands sent to firmware.
Cache our BSSID in struct iwm_node such that firmware commands
keep using the old BSSID while we are still tearing things down.
Switch to the new BSSID only once we start back up in iwm_auth().
This should be consistent from the firmware's point of view.
ok mpi@
|
|
From Matthew Auld
d35d95e8b9da638d27bce9552262e0c486138343 in linux 5.10.y/5.10.71
c83ff0186401169eb27ce5057d820b7a863455c3 in mainline linux
|
|
From Hawking Zhang
9f382e1edf90ae03be43dbd4976c2a332cd7ce2d in linux 5.10.y/5.10.71
9f52c25f59b504a29dda42d83ac1e24d2af535d4 in mainline linux
|
|
From Charlene Liu
c331fad63b6d527193ae8b7c056b2f10fef53c81 in linux 5.10.y/5.10.71
d942856865c733ff60450de9691af796ad71d7bc in mainline linux
|
|
AUTH->AUTH state transitions happen if the access point uses band-steering.
This was originally implemented to fix interop with some Aruba APs, and
was probably broken by my recent CVS commit XeKkqPoaUCklmgtC ("prevent
attempts to transition towards the same state").
ok mpi@
|
|
Non-data frames are not supposed to use HT.
This change is for code correctness and does not fix any known issue.
And it applies only if the Tx rate has been fixed for testing purposes
with a command such as 'ifconfig iwm0 media HT-MCS13 mode 11n'.
ok mpi@
|
|
Stop BA sessions directly in iwm_run_stop() and disable Tx agg queues
when leaving RUN state. Otherwise Tx agg queues do not work properly
after switching APs and Tx performance drops to about 2 Mbit/s with
excessive retries being reported to RA.
Tested:
7260: florian
8260: bket
8265: stsp
9260: florian
9560: stsp
|
|
Restrictions" document exists that discusses an errata #251 in section
"3.12 PCIe Completion Timeout" and suggests that setting the DIS_ORD_CHK
flag in the Debug Mux Control register is necessary as a workaround:
https://lore.kernel.org/linux-pci/20210624222621.4776-6-pali@kernel.org
This workaround is still being discussed by the Linux developers, but it
does fix an issue I am seeing with athn(4), where an external abort
happens under load. So apply this workaround since its potential side
effects seem to be significantly less severe than provoking an
external abort that hangs the machine.
ok patrick@
|
|
We have to install the files with new filenames (removal of "fw" from each of
the filenames) and change the driver to use the new filenames,
such that the package becomes irrelevant.
Discussed with deraadt@ and sthen@
ok deraadt@
|
|
After deraadt@ explained why the Realtek firmware cannot be put into our tree,
I reached out to Realtek to explain the situation.
According to the LICENCE.rtlwifi_firmware.txt [1], the rules permitted adding
their non-open-source firmware into open source operating systems but such
an addition (ironically) makes that open source operating system not entirely
open source. Realtek understood the irony, and change the license.
Thanks to Realtek for this change which lets us put the firmware .h file
into our tree, this means Realtek wireless will work without requiring
a firmware download (which is difficult over a non-working Realtek network :)
[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.rtlwifi_firmware.txt?id=0f863ff1b388ad5b0f7d25decdbb642#n22
ok deraadt@
|
|
that are marked "ok". Linux has some workarounds for this and checks whether
the status word has error bits set in it regardless of the bit that marks
the frame as "ok". Adapt this workaround to our driver and drop the frame
after setting input errors. This doesn't filter out all corrupted frames,
but it does keep things down to a level where it doesn't fill up the node
cache anymore when athn(4) is used in hostap mode.
Seen with:
athn0 at pci1 dev 0 function 0 "Atheros AR9281" rev 0x01: intx
athn0: AR9280 rev 2 (2T2R), ROM rev 16, address xx:xx:xx:xx:xx:xx
ok stsp@
|
|
which can have these busses, might as well make these distributable firmwares
available in case the drivers find devices.
ok kettenis
|
|
as asavvycomputist@disroot.org reported this occurs on gm45 (gen 4).
|
|
work that is already handled by state transitions involving AUTH or RUN.
|
|
work that is already handled by state transitions involving AUTH or RUN.
|
|
Uncomfortable bug found the hard way by deraadt@
|
|
From Simon Ser
526261c1b706fec0ea80ce9f14c8fe8468bee34d in linux 5.10.y/5.10.70
7bbee36d71502ab9a341505da89a017c7ae2e6b2 in mainline linux
|
|
From Sami Tolvanen
55e6f8b3c0f5cc600df12ddd0371d2703b910fd7 in linux 5.10.y/5.10.70
4f0f586bf0c898233d8f316f471a21db2abd522d in mainline linux
|
|
From Lijo Lazar
68d4fbe6220cd1f3d07cab0a4901e62f8c12cc68 in linux 5.10.y/5.10.70
ab39d3cef526ba09c4c6923b4cd7e6ec1c5d4faa in mainline linux
|
|
in cases where this would result in a redundant or illegal state transition.
jmc@ observed ASSOC -> ASSOC transitions which would result in a hang.
Such transitions are invalid and never intentionally triggered by net80211.
They imply a race between the Rx interrupt handler and the newstate task.
Tested by jmc@ on AX200 for a week and several known issues seem to be fixed.
|
|
ok jcs@
|
|
|
|
From Alex Deucher
8f0c93f454bd7ab04eaec1d3c436c4c7c2378f07 in mainline linux
|
|
|
|
fix strings in some other graphics devices as well
|
|
|
|
includes amd codenames for codenames so subject to change
|
|
From Koba Ko
45bd9dd1bee8aedc4cbd409b1ba7f9b4f941eea6 in linux 5.10.y/5.10.69
b3dc549986eb7b38eba4a144e979dc93f386751f in mainline linux
|
|
From Ernst Sjoestrand
8f95553f0016c3994d9c022b5af4a1a433d6714e in linux 5.10.y/5.10.68
67a44e659888569a133a8f858c8230e9d7aad1d5 in mainline linux
|
|
From Jerry (Fangzhi) Zuo
b80a99e048275d566d63f2463a2f640065ccbf75 in linux 5.10.y/5.10.67
a7a9d11e12fcc32160d55e8612e72e5ab51b15dc in mainline linux
|
|
From Aurabindo Pillai
583c4f3d09c3e980a683b59febbb0c775bdff1db in linux 5.10.y/5.10.67
0bbf06d888734041e813b916d7821acd4f72005a in mainline linux
|
|
From Andrey Grodzovsky
7b1abace16a9dff6804d4eb94750beb60d9502b4 in linux 5.10.y/5.10.67
ea7acd7c5967542353430947f3faf699e70602e5 in mainline linux
|
|
From Rajkumar Subbiah
bb693c114e8b53e3e0b8228be218d907d35959a5 in linux 5.10.y/5.10.67
92bd92c44d0d9be5dcbcda315b4be4b909ed9740 in mainline linux
|
|
From Sean Keely
0e9f4492219f8f991163691aad43897da8478c4e in linux 5.10.y/5.10.67
1ec06c2dee679e9f089e78ed20cb74ee90155f61 in mainline linux
|
|
From Tuo Li
83449db3aac0895147eac723bf23d0739720b968 in linux 5.10.y/5.10.67
554594567b1fa3da74f88ec7b2dc83d000c58e98 in mainline linux
|
|
access in amdgpu_i2c_router_select_ddc_port()
From Tuo Li
2254383788ff93a423e20068333b9f8376d56cb4 in linux 5.10.y/5.10.67
a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 in mainline linux
|
|
From Roy Chan
63ebc1f1df813ebb40d19449c356480555008166 in linux 5.10.y/5.10.67
781e1e23131cce56fb557e6ec2260480a6bd08cc in mainline linux
|
|
From Roy Chan
d763afc4ea2b251217ec87cf4c1e006c9f0aef99 in linux 5.10.y/5.10.67
82367e7f22d085092728f45fd5fbb15e3fb997c0 in mainline linux
|
|
From Anson Jacob
6f51f4241253974a6a147daecd5c20beb7450330 in linux 5.10.y/5.10.67
1a394b3c3de2577f200cb623c52a5c2b82805cec in mainline linux
|