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`
- split `image` apt .list deployment into `image-early` (after rootfs extract, before building) and `image-late` (after building)
- rationale: having the repo enabled during the image build can cause 'apt upgrade' and others to do inconsistent stuff depending on the (possibly random) state of the repo
- this way it's consistent across all artifacts and images
- debs-to-repo-download: fix: use DEB_STORAGE instead of hardcoding output/debs (so BETA=yes works)
also:
- fix `Duplicate oci_target` message in mapper-oci-uptodate
also:
- get rid of comments and `SUBREVISION` and `RC` variables
- better debugging in calculate_hash_for_variables() do_normalize_src_path=yes/no
- tag a few places where output/debs might wrong in face of BETA=yes/no
- some hashed variables might contain "${SRC}", so hashes never match, unless built in Docker
- this strips away SRC from all vars and adds debugging so we can detect more later.
- `artifact-uboot`: include more variables into hash, for ATF & rk stuff
- `artifact-armbian-desktop`:
- hashed vars actually contain /armbian in different context, skip normalization in this case
- include results of relevant aggregation into artifact_input_variables
- otherwise: desktops with different appgroups/configs lead to build failures in pipeline
- will cause warnings in JSON preparation step, if more than one appgroups/config combo is targeted, since repo can only have one
