- RTW8723DS, RTW8723DU is unsupported/deprecated/obsolete by the author since kernel 6.7 in favor of RTW88, so deprecate it for kernel >=6.8
- RTL88x2cs specifically says in its repo: "USE RTW88 NOT THIS DRIVER", so deprecate in favor of RTW88, except for meson64 family
- move random RTL88x2cs hook specific for meson64 family in drivers_network.sh to their family config
Also add commit dates to make life prettier and easier
The following drivers have been updated with fixes for 6.8
- driver_rtl8811CU_rtl8821C
- driver_rtl88x2bu
- driver_rtl8811_rtl8812_rtl8814_rtl8821
The following drivers have been updated without specific 6.8 patches:
- driver_rtl8189ES (patches for 6.7, deleted two upstreamed patches)
- driver_rtl8189FS (patches for 6.7, deleted four upstreamed patches)
- this should make drivers hash consistent, at the expense of being moar tiresome
- _any_ changes at _any_ patches or drivers-related bash code will cause _all_ kernels to be rebuilt
- opposed to "some changes caused all kernels to be rebuilt"
There are many changes in this file and its impossible to cover this with a patch for now current and all kernels back
We are using same hack in UWE drivers.
This is just a cosmetic change. Patches have been consolidated
into one patch within each corresponding linux version directory.
Added: linux-6.6 (RC-1)
Removed: linux-6.2/6.3
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Co-authored-by: Patrick Yavitz <pyavitz@xxxxx.com>
Also added some cleanup fixes to silence some of the compiler warnings,
fixes for issues during inserting and removing xradio module and fixes
for possible data corruption on vmmaped stack.
All of these fixes were taken from https://github.com/fifteenhex/xradio
* patch: misc: rtw88: wireless-next: 2023-08-25
Updated: 6.1 / 6.4
Added: 6.5
For doc sake, this update makes 6.1 slightly differrent than 6.4 and
6.5 in one particular area of main.c.
As shown here:
7746e2fa87
6.1 requires we use del_timer_sync, where the above releases use
timer_delete_sync.
Tested-on: ODROID-C4 X96-AIR BPI-CM4 (linux 6.x.y)
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
* driver_rtw88: `linux-version compare "${version}" ge 6.1`
Suggested-by: @viraniac
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
---------
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Co-authored-by: Patrick Yavitz <pyavitz@xxxxx.com>
- this should avoid (late) patching errors that might happen during a point release bump like `6.4.5` -> `6.4.6` cos we'd be using the wrong cached drivers patch
- using the SHA1 will instead (possibly) trigger the "real patching failure", during drivers-harness when building a new driver patch cache
- also try to cleanup old caches in the old format so we've not many leftovers -- each patch is ~150mb
With this change, setting EXTRAWIFI=no will disable all wireless
patches applied within drivers_network.sh script. Also since #5265
the rtl88x2cs patches were suppose to be not applied to 6.1+ kernel
onwards, instead they were disabled entirely. As this was done by
adding EXTRAWIFI=no, its now replaced with kernel version limit.
Keeping EXTRAWIFI=no there would have made those patches to apply
which would have changed the meaning of the flag.
Cope with the fix in stable 6.3.13 bf353116d1bf and 6.5-rc1 e8c2af660ba0
"wifi: cfg80211: fix regulatory disconnect with OCB/NAN".
That is the removal of REGULATORY_IGNORE_STALE_KICKOFF
from the wireless regulator internal API to fix any driver
that allowed OCB/NAN.
Note this code will need to be expanded once and if 6.4 include the
above fixup.
Signed-off-by: Alban Browaeys <alban.browaeys@gmail.com>
Use multiple consecutive reads in rtw_sdio_read_port() to limit the number of bytes which are copied by the host from the card in one MMC/SDIO transfer. This allows receiving a buffer that's larger than the hosts max_req_size (number of bytes which can be transferred in one MMC/SDIO transfer). As a result of this the skb_over_panic error is gone as the rtw88 driver is now able to receive more than 1536 bytes from the card (either because the incoming packet is larger than that or because multiple packets have been aggregated).
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
This brings the patch set up to 2023-06-22 wireless-next
Drivers tested;
8822CS. 8821CU and 8723DS
Notables;
Not seeing random dmesg spam `rtw_8822cs failed to get tx report from firmware` which I would see on both the CS and CU from time to time.
Signed-off-by: Patrick Yavitz <pyavitz@gmail.com>
Patch set includes a complete backport of RTW88 as it currently stands, along with extras
Extra:
Patch: RTL8723DS (SDIO)
Patch: _rtw_download_firmware() warn: missing unwind goto?
Hack: SDIO RX Aggregation Limiting
I only have two units available to me with an 8822CS module and in my testing this is only required on the BPI-CM4IO. With out LIMITING the unit will either kernel panic or not be able to send or receive.
This is currently being looked into:
https://lore.kernel.org/linux-wireless/CAFBinCBaXtebixKbjkWKW_WXc5k=NdGNaGUjVE8NCPNxOhsb2g@mail.gmail.com/T/#u
It may be possible to just set LIMITING across all builds, but that to me seems like a poor choice. This requires testing.
Signed-off-by: Patrick Yavitz <pyavitz@gmail.com>
```
# Brief detour. Turns out that HardKernel's vendor odroidxu4 kernel already has this driver
# "slipstreamed" into it, complete with a bunch of PDF files and other junk.
# See https://github.com/hardkernel/linux/tree/odroid-5.4.y/drivers/net/wireless/rtl8812au
# If we remove them here, the resulting patch will contain binary diffs which are unsupported by patch(1).
# So if building for the odroidxu4/current, we'll leave the original files in place, and just overwrite
# the possibly-updated source files (not PDFs and such). Thanks, HardKernel.
```
- even Rich'er patch output by colorizing certain strings green/yellow/red
- BASE_GIT_TAG now very sneakily also accepts a branch name
- IMPORTANT: this includes: BREAKING CHANGE: patches failing to apply now break the build. fixes#4958
- also break on legacy `process_patch_file()` failure, remove `EXIT_PATCHING_ERROR`
- all interactive commands now **don't build the artifact** anymore; just patches/.configs are produced and then build ends
- user is required to put the produced patches in the right place and build again, for full consistency
- split ATF and U-BOOT manual patching process; use CLI command `atf-patch` to patch ATF, and `uboot-patch` to patch u-boot
- non-interactive artifact builds are now 100% sans-stdin
- introduce `uboot-config` CLI command; still experimental, only produces a defconfig and not a patch
- reworked `userpatch_create()` to be (hopefully) more useful:
- detects a previous patch and offers to apply it before continuing
- enters a loop showing the diff, and only proceeds when user indicates he's happy with the patch
- produces `mbox`-formatted patches via `format-patch` and standard Armbian parameters
- uses MAINTAINER and MAINTAINERMAIL instead of git configuration (so it works in containers)
- don't allow image builds with any patching or configuring _at all_ (it has been deprecated with a warning for months already, and results are inconsistent)
