Currently, ls-rcw package is being included in the individual
profile DEVICE_PACKAGES but using the feature that allows skipping their
inclusion in the end image package list if prefixed with a tilde(~) which
was added in:
377b66990b ("build: introduce support to declare skip package")
But it not added to Image Builder so currently trying to build layerscape
device images in Image Builder will fail with:
ERROR: '~ls-rcw' is not a valid world dependency, format is name(@tag)([<>~=]version)
So, instead of having to rely on support for skipping package installation
and declaring the ls-rcw package in DEVICE_PACKAGES lets select it when
layerscape/armv7 target is selected.
Fixes: #18411
Link: https://github.com/openwrt/openwrt/pull/18462
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 598a0556b7)
Currently, ls-ddr-phy package is being included in the individual
profile DEVICE_PACKAGES but using the feature that allows skipping their
inclusion in the end image package list if prefixed with a tilde(~) which
was added in:
377b66990b ("build: introduce support to declare skip package")
But it not added to Image Builder so currently trying to build layerscape
device images in Image Builder will fail with:
ERROR: '~ls-ddr-phy' is not a valid world dependency, format is name(@tag)([<>~=]version)
So, instead of having to rely on support for skipping package installation
and declaring the ls-ddr-phy package in DEVICE_PACKAGES lets select it when
layerscape/armv8_64b target is selected.
Fixes: #18412
Link: https://github.com/openwrt/openwrt/pull/18462
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 8a28ddafe7)
Currently, ls-dpl package is being included in the individual
profile DEVICE_PACKAGES but using the feature that allows skipping their
inclusion in the end image package list if prefixed with a tilde(~) which
was added in:
377b66990b ("build: introduce support to declare skip package")
But it not added to Image Builder so currently trying to build layerscape
device images in Image Builder will fail with:
ERROR: '~ls-dpl' is not a valid world dependency, format is name(@tag)([<>~=]version)
So, instead of having to rely on support for skipping package installation
and declaring the ls-dpl package in DEVICE_PACKAGES lets select it when
layerscape/armv8_64b target is selected.
Fixes: #18412
Link: https://github.com/openwrt/openwrt/pull/18462
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 84437eeec0)
Currently, ls-mc package is being included in the individual
profile DEVICE_PACKAGES but using the feature that allows skipping their
inclusion in the end image package list if prefixed with a tilde(~) which
was added in:
377b66990b ("build: introduce support to declare skip package")
But it not added to Image Builder so currently trying to build layerscape
device images in Image Builder will fail with:
ERROR: '~ls-mc' is not a valid world dependency, format is name(@tag)([<>~=]version)
So, instead of having to rely on support for skipping package installation
and declaring the ls-mc package in DEVICE_PACKAGES lets select it when
layerscape/armv8_64b target is selected.
Fixes: #18412
Link: https://github.com/openwrt/openwrt/pull/18462
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 2fb3efda0a)
Currently, fman-ucode package is being included in the individual
profile DEVICE_PACKAGES but using the feature that allows skipping their
inclusion in the end image package list if prefixed with a tilde(~) which
was added in:
377b66990b ("build: introduce support to declare skip package")
But it not added to Image Builder so currently trying to build layerscape
device images in Image Builder will fail with:
ERROR: '~fman-ucode' is not a valid world dependency, format is name(@tag)([<>~=]version)
So, instead of having to rely on support for skipping package installation
and declaring the fman-ucode package in DEVICE_PACKAGES lets select it when
layerscape/armv8_64b target is selected.
Fixes: #18412
Link: https://github.com/openwrt/openwrt/pull/18462
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 22f02beaab)
The IgniteNet SunSpot AC Wave2 comes with 2x QCA9994 ath10k chips
connected to the IPQ8068 SoC via PCIe.
Add board-2.bin for both radios on this board.
3ac4a64 qca9984: add BDFs for IgniteNet SS-W2-AC2600
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit d8303b4721)
Link: https://github.com/openwrt/openwrt/pull/19902
[Do not add ignitenet_ss-w2-ac2600]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
6953f19 wireless-regdb: Update regulatory info for Indonesia (ID) for 2025
2e8214e wireless-regdb: Permit 320 MHz bandwidth in 6 GHz band for GB
a94f685 wireless-regdb: Update regulatory info for Egypt (EG) for 2024
7628ce2 wireless-regdb: Update regulatory rules for Brazil (BR) on 6GHz
4411b39 wireless-regdb: Update regulatory info for Vietnam (VN) for 2025
490f136 wireless-regdb: Update regulatory info for Estonia (EE) for 2024
c56c663 wireless-regdb: update regulatory rules for Paraguay (PY) on 6 GHz for 2025
5a8ced5 wireless-regdb: Update regulatory info for CEPT countries for 6GHz listed by WiFi Alliance
5fd8ee3 wireless-regdb: update regulatory rules for Bosnia and Herzegovina (BA) for 6 GHz
e05260a wireless-regdb: update regulatory database based on preceding changes
Link: https://github.com/openwrt/openwrt/pull/19474
(cherry picked from commit 7fe06b7f56)
Link: https://github.com/openwrt/openwrt/pull/19538
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
A previous commit backported the ipq-wifi update to fix support for the
TP-Link Archer C6 v2 by adding the device to the package. However, it
missed adding the required TARGET_ath79 dependency, causing the
ipq-tplink_archer-c6-v2 build to fail.
The dependency was previously added in commit 4990ce613b ("ipq-wifi:
update to 2024-02-17") when several ath79 devices were introduced.
However, since this backport only fixes support for the Archer C6 v2, it
is not feasible to backport all related changes. Therefore, this commit
adds only the missing dependency to resolve the build issue without
pulling in unrelated updates.
Fixes: 0c43acc349 ("ipq-wifi: update to Git HEAD (2025-05-30)")
Signed-off-by: Nick Hainke <vincent@systemli.org>
Link: https://github.com/openwrt/openwrt/pull/19120
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RPi 5 Compute Module expects the same NVRAM as the one from RPi 4
on a different file.
Signed-off-by: Dave Marquard <dave-atx@users.noreply.github.com>
Link: https://github.com/openwrt/openwrt/pull/18722
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit 8774dd7761)
Debian Changelogs from 20240531:
local access.
- Mitigations for INTEL-SA-01079 (CVE-2024-23918)
Potential security vulnerabilities in some Intel Xeon processors
using Intel SGX may allow escalation of privilege. Intel disclosed
that some processor models were already fixed by a previous
microcode update.
- Updated mitigations for INTEL-SA-01097 (CVE-2024-24968)
Improper finite state machines (FSMs) in hardware logic in some
Intel Processors may allow an privileged user to potentially enable a
denial of service via local access.
- Mitigations for INTEL-SA-01103 (CVE-2024-23984)
A potential security vulnerability in the Running Average Power Limit
(RAPL) interface for some Intel Processors may allow information
disclosure. Added mitigations for more processor models.
* Updated Microcodes:
sig 0x000806f8, pf_mask 0x87, 2024-06-20, rev 0x2b000603, size 588800
sig 0x000806f7, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f6, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f5, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f4, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x00090672, pf_mask 0x07, 2024-05-29, rev 0x0037, size 224256
sig 0x00090675, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000b06f2, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000b06f5, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000906a3, pf_mask 0x80, 2024-06-03, rev 0x0435, size 223232
sig 0x000906a4, pf_mask 0x80, 2024-06-03, rev 0x0435
sig 0x000a06a4, pf_mask 0xe6, 2024-08-02, rev 0x0020, size 138240
sig 0x000b06a2, pf_mask 0xe0, 2024-05-29, rev 0x4123, size 220160
sig 0x000b06a3, pf_mask 0xe0, 2024-05-29, rev 0x4123
sig 0x000b06a8, pf_mask 0xe0, 2024-05-29, rev 0x4123
sig 0x000c06f2, pf_mask 0x87, 2024-06-20, rev 0x21000283, size 560128
sig 0x000c06f1, pf_mask 0x87, 2024-06-20, rev 0x21000283
* source: update symlinks to reflect id of the latest release, 20241112
* Update changelog for 3.20240910.1 and 3.20240813.1 with new information:
INTEL-SA-1103 was addressed by 3.20240813.1 for some processor models,
and not by 3.20240910. INTEL-SA-1079 was addressed by 3.20240910.1 for
some processor models.
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 14 Nov 2024 15:37:40 -0300
intel-microcode (3.20241029.1) UNRELEASED; urgency=medium
* New upstream microcode datafile 20241029
- Not relevant for operating system microcode updates
- Only when loaded from firmware, this update fixes the critical,
potentially hardware-damaging errata RPL061: Incorrect Internal
Voltage Request on Raptor Lake (Core 13th/14th gen) Intel
processors.
* Updated Microcodes:
sig 0x000b0671, pf_mask 0x32, 2024-08-29, rev 0x012b, size 211968
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 14 Nov 2024 14:49:03 -0300
intel-microcode (3.20240910.1) unstable; urgency=medium
* New upstream microcode datafile 20240910 (closes: #1081363)
- Mitigations for INTEL-SA-01097 (CVE-2024-24968)
Improper finite state machines (FSMs) in hardware logic in some
Intel Processors may allow an privileged user to potentially enable a
denial of service via local access.
- Fixes for unspecified functional issues on several processor models
- The processor voltage limit issue on Core 13rd/14th gen REQUIRES A
FIRMWARE UPDATE. It is present in this release for sig 0xb0671, but
THE VOLTAGE ISSUE FIX ONLY WORKS WHEN THE MICROCODE UPDATE IS LOADED
THROUGH THE FIT TABLE IN FIRMWARE. Contact your system vendor for a
firmware update that includes the appropriate microcode update for
your processor.
* Updated Microcodes:
sig 0x00090672, pf_mask 0x07, 2024-02-22, rev 0x0036, size 224256
sig 0x00090675, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000b06f2, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000b06f5, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000906a3, pf_mask 0x80, 2024-02-22, rev 0x0434, size 222208
sig 0x000906a4, pf_mask 0x80, 2024-02-22, rev 0x0434
sig 0x000a06a4, pf_mask 0xe6, 2024-06-17, rev 0x001f, size 137216
sig 0x000b0671, pf_mask 0x32, 2024-07-18, rev 0x0129, size 215040
sig 0x000b06a2, pf_mask 0xe0, 2024-02-22, rev 0x4122, size 220160
sig 0x000b06a3, pf_mask 0xe0, 2024-02-22, rev 0x4122
sig 0x000b06a8, pf_mask 0xe0, 2024-02-22, rev 0x4122
sig 0x000b06e0, pf_mask 0x19, 2024-03-25, rev 0x001a, size 138240
* Update changelog for 3.20240813.1 with new information
* Update changelog for 3.20240514.1 with new information
* source: update symlinks to reflect id of the latest release, 20240910
-- Henrique de Moraes Holschuh <hmh@debian.org> Sat, 21 Sep 2024 16:40:07 -0300
intel-microcode (3.20240813.2) unstable; urgency=high
* Merge changes from intel-microcode/3.20240531.1+nmu1, which were left out
from 3.20240813.1 by an oversight, regressing merged-usr. Closes: #1060200
-- Henrique de Moraes Holschuh <hmh@debian.org> Sat, 17 Aug 2024 11:31:32 -0300
intel-microcode (3.20240813.1) unstable; urgency=medium
* New upstream microcode datafile 20240813 (closes: #1078742)
- Mitigations for INTEL-SA-01083 (CVE-2024-24853)
Incorrect behavior order in transition between executive monitor and SMI
transfer monitor (STM) in some Intel Processors may allow a privileged
user to potentially enable escalation of privilege via local access.
- Mitigations for INTEL-SA-01118 (CVE-2024-25939)
Mirrored regions with different values in 3rd Generation Intel Xeon
Scalable Processors may allow a privileged user to potentially enable
denial of service via local access.
- Mitigations for INTEL-SA-01100 (CVE-2024-24980)
Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel
Xeon Processors may allow a privileged user to potentially enable
escalation of privilege via local access.
- Mitigations for INTEL-SA-01038 (CVE-2023-42667)
Improper isolation in the Intel Core Ultra Processor stream cache
mechanism may allow an authenticated user to potentially enable
escalation of privilege via local access. Intel disclosed that some
processor models were already fixed by the previous microcode update.
- Mitigations for INTEL-SA-01046 (CVE-2023-49141)
Improper isolation in some Intel Processors stream cache mechanism may
allow an authenticated user to potentially enable escalation of
privilege via local access. Intel disclosed that some processor models
were already fixed by the previous microcode update.
- Mitigations for INTEL-SA-01079 (CVE-2024-23918)
Potential security vulnerabilities in some Intel Xeon processors
using Intel SGX may allow escalation of privilege. Intel released this
information during the full disclosure for the 20241112 update.
Processor signatures 0x606a6 and 0x606c1.
- Mitigations for INTEL-SA-01103 (CVE-2024-23984)
A potential security vulnerability in the Running Average Power Limit
(RAPL) interface for some Intel Processors may allow information
disclosure. Intel released this information during the full disclosure
for the 20240910 update. Processor signatures 0x5065b, 0x606a6,
0x606c1.
- Fix for unspecified functional issues on several processor models
- Fix for errata TGL068/ADL075/ICL088/... "Processor may hang during a
microcode update". It is not clear which processors were fixed by this
release, or by one of the microcode updates from 2024-05.
- Mitigations for INTEL-SA-01213 (CVE-2024-36293)
Improper access control in the EDECCSSA user leaf function for some
Intel Processors with Intel SGX may allow an authenticated user to
potentially enable denial of service via local access. Intel released
this information during the full disclosure for the 20250211 update.
Processor signature 0x906ec (9th Generation Intel Core processor).
* Updated microcodes:
sig 0x00050657, pf_mask 0xbf, 2024-03-01, rev 0x5003707, size 39936
sig 0x0005065b, pf_mask 0xbf, 2024-04-01, rev 0x7002904, size 30720
sig 0x000606a6, pf_mask 0x87, 2024-04-01, rev 0xd0003e7, size 308224
sig 0x000606c1, pf_mask 0x10, 2024-04-03, rev 0x10002b0, size 300032
sig 0x000706e5, pf_mask 0x80, 2024-02-15, rev 0x00c6, size 114688
sig 0x000806c1, pf_mask 0x80, 2024-02-15, rev 0x00b8, size 112640
sig 0x000806c2, pf_mask 0xc2, 2024-02-15, rev 0x0038, size 99328
sig 0x000806d1, pf_mask 0xc2, 2024-02-15, rev 0x0052, size 104448
sig 0x000806e9, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806e9, pf_mask 0x10, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806ea, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 105472
sig 0x000806eb, pf_mask 0xd0, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806ec, pf_mask 0x94, 2024-02-05, rev 0x00fc, size 106496
sig 0x00090661, pf_mask 0x01, 2024-04-05, rev 0x001a, size 20480
sig 0x000906ea, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 105472
sig 0x000906eb, pf_mask 0x02, 2024-02-01, rev 0x00f6, size 106496
sig 0x000906ec, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 106496
sig 0x000906ed, pf_mask 0x22, 2024-02-05, rev 0x0100, size 106496
sig 0x000a0652, pf_mask 0x20, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0653, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 98304
sig 0x000a0655, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0660, pf_mask 0x80, 2024-02-01, rev 0x00fe, size 97280
sig 0x000a0661, pf_mask 0x80, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0671, pf_mask 0x02, 2024-03-07, rev 0x0062, size 108544
sig 0x000a06a4, pf_mask 0xe6, 2024-04-15, rev 0x001e, size 137216
* source: update symlinks to reflect id of the latest release, 20240813
* postinst, postrm: switch to dpkg-trigger to run update-initramfs
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 15 Aug 2024 14:41:50 -0300
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/18197
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit f4801cffc3)
b43aeb5 wireless-regdb: assert and correct maximum bandwidth within frequency difference
68588bf wireless-regdb: Update regulatory info for Syria (SY) for 2020
0dda57e wireless-regdb: Update regulatory info for Moldova (MD) on 6GHz for 2022
b19ab0b wireless-regdb: Update regulatory info for Azerbaijan (AZ) on 6GHz for 2024
f67f40d wireless-regdb: Update regulatory info for Oman (OM)
bd70876 wireless-regdb: Update regulatory rules for Armenia (AM) on 2.4 and 5 GHz
6c7cbcc wireless-regdb: Permit 320 MHz bandwidth in 6 GHz band in ETSI/CEPT
f9f6b30 wireless-regdb: Update regulatory rules for Austria (AT)
39b47ea wireless-regdb: Update regulatory info for Cayman Islands (KY) for 2024
3dd7ceb wireless-regdb: allow NO-INDOOR flag in db.txt
4d754a1 wireless-regdb: Update regulatory rules for Iran (IR) on both 2.4 and 5Ghz for 2021
8c8308a wireless-regdb: Update frequency range with NO-INDOOR for Oman (OM)
c2f11e2 wireless-regdb: update regulatory database based on preceding changes
Signed-off-by: Rudy Andram <rmandrad@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17957
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit da2cc98458)
Images for xrx200 8M flash are either not building due to image
size (TD-W8970, TD-W8980) or building such that the available
free space in the overlayfs is too little to be useful.
To keep images for these devices buildable, move them into a
small flash variant of the xrx200 subtarget. As these devices
are NOR flash only, remove NAND and UBI references from the
kernel config to gain some additional image size reduction.
The apparent 8M flash devices Arcadyan VGV7510KW22-brn,
Arcadyan VGV7519-brn and Lantiq Easy80920-nor seem to exist in
order to create special "factory" installation images for these
devices (which actually have larger flash: 16MB for the
Arcardyan devices; 64MB for the Lantiq device). As a
considerable amount of surgery would appear to be required to
the uboot-lantiq package structure to separate the "factory"
from the "sysupgrade" device recipes for these devices they
remain in the xrx200 target - if factory images aren't now
created, 23.05.x factory images should suffice for initial
installation.
Tested on: Netgear DM200, TP-Link TD-W8980,
AVM Fritz7490 (xrx200 subtarget: image build only)
Fixes: https://github.com/openwrt/openwrt/issues/16761
Signed-off-by: Andrew MacIntyre <andymac@pcug.org.au>
Link: https://github.com/openwrt/openwrt/pull/17113
(cherry picked from commit e63326e26a)
Link: https://github.com/openwrt/openwrt/pull/17303
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This adds firmware support for the RTL8812AU/RTL8821AU USB wireless adapters.
Signed-off-by: Marty Jones <mj8263788@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17079
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit c48a48e658)
Change the package name from intel-igpu-firmware-* to i915-firmware-*,
the prefix "intel-igpu" is misleading, i915 firmware is not only for
iGPU but also for dGPU now.
Remove the redundant "intel" as i915 is already well known.
More accurate file classification to handle following files correctly:
adlp_dmc.bin
mtl_huc.bin
mtl_huc_gsc.bin
mtl_gsc_1.bin
The pattern in regex is "([[:alnum:]]+)_([[:alnum:]]+)(_[\w-.]+)?\.bin",
where $1 is the platform, $2 is the firmware type (dmc, guc, huc, etc.),
and the optional $3 which is revision or other suffix.
Glob first to narrow down the target file set, and then split with "_"
to extract the firmware type (remove the ".bin" in case there is no $3)
Add package "i915-firmware" as a meta package to install all the i915
firmwares, it is a balance between simplicity and optimization.
* Installing all the available firmwares as a whole, can support all the
platforms, not only the current one but also the future ones. The
price to pay is the increased size.
* If we want to minimize the storage, we can customize to install the
necessary ones only, even for the target platform only (e.g. ADL) and
skip the others. The price to pay is the time to tune.
What I am going to do is:
* Let drm-i915 driver depend on i915-firmware-dmc, which is small and
can cover most of the old platforms
* Let the user select i915-firmware to install all the i915 firmwares as
a whole to cover the latest or future platforms
Signed-off-by: Joe Zheng <joe.zheng@intel.com>
Link: https://github.com/openwrt/openwrt/pull/16276
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit ca00bafd7e)
Link: https://github.com/openwrt/openwrt/pull/17097
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Both packages `ombnia-mcu-firmware` and `omnia-mcutool` would depend on
a specific device. The buildbots however build all devices and therefore
the package isn't build at all, due to unmet dependencies.
While this didn't cause issues with OPKG, APK fails actively due to the
missing packages. Drop the specific dependency, however wants to install
unrelated firmware on any device can do that anyway.
Signed-off-by: Paul Spooren <mail@aparcar.org>
(cherry picked from commit f35a29d63f)
Link: https://github.com/openwrt/openwrt/pull/17097
Signed-off-by: Petr Štetiar <ynezz@true.cz>
The version was a mix of strings, hex numbers and semantic numbers.
Switch the PKG_VERSION to something digestible by APK and introduce
PKG_SOURCE_VERSION to handle the actual filename.
While at it, drop the redundant PKG_B_NAME which was the same as
PKG_NAME anyway.
Signed-off-by: Paul Spooren <mail@aparcar.org>
This commit packages the newly merged firmware (v39.0) for Realtek RTL8192DU
802.11a/b/g/n USB wireless cards.
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/16721
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
After a long time QCA has pushed an updated release of 2.9.0.1 firmware
for IPQ8074 and QCN9074, so lets update to 2.9.0.1-02146.
Sadly, still nothing new for IPQ6018.
QCA has also moved the repository where they will be posting firmware to
their CodeLinaro instance, so we move to using that and it allows us to
remove the manual download of QCN9074 board-2.bin.
Link: https://github.com/openwrt/openwrt/pull/16720
Signed-off-by: Robert Marko <robimarko@gmail.com>
b66b9a1 wireless-regdb: update regulatory database based on preceding changes
5097b4a wireless-regdb: Update regulatory info for Tanzania (TZ) for 2024
29633a6 wireless-regdb: Update regulatory info for Pakistan (PK) for 2024
b44edb2 wireless-regdb: Update regulatory info for Serbia (RS) for 2024
dbfae47 Revert "wireless-regdb: Update regulatory info for Serbia (SR) for 2024"
8e3d27c wireless-regdb: Correct regulatory rules of 6GHz frequency for Türkiye (TR)
8760bc3 wireless-regdb: Update regulatory info for Honduras (HN) for 2023
3ba2c53 wireless-regdb: Update regulatory info for Israel (IL) for 2021
83c175c wireless-regdb: Update regulatory info for Kuwait (KW) for 2022
388c80c wireless-regdb: Update regulatory info for Serbia (SR) for 2024
bf55ed4 wireless-regdb: Add .b4-config
3afe172 wireless-regdb: Update .gitignore
3b34761 wireless-regdb: Correct regulatory rules for China (CN)
003c282 wireless-regdb: Update regulatory info for Philippines (PH) on 6GHz
21fcb86 wireless-regdb: Update regulatory info for Guatemala (GT) for 2020
158f105 wireless-regdb: Update regulatory info for Bahrain (BH) for 2024
218d146 wireless-regdb: Add regulatory info for Namibia (NA) for 2023
aad0c26 wireless-regdb: Update regulatory info for Togo (TG) for 2022
983f551 wireless-regdb: Update regulatory info for El Salvador (SV) on 6GHz
58575b4 wireless-regdb: Update regulatory info for Peru (PE) on 6GHz
bad3985 wireless-regdb: Update regulatory info for New Zealand (NZ) for 2022
c7d1083 wireless-regdb: Update regulatory info for Qatar (QA) on 6GHz
Signed-off-by: Itay Shoshani <itai.sho@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16678
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
dcbab62 ipq40xx: add BDFs for SKSpruce WIA3300-20
A new board file package "ipq-wifi-skspruce_wia3300-20" will be
added for the incoming device SKSpruce WIA3300-20.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Link: https://github.com/openwrt/openwrt/pull/16476
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use most recent version of the Intel AX101 and AX210 firmware provided
by linux-firmware and supported the driver used in OpenWrt.
Link: https://github.com/openwrt/openwrt/pull/16621
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Kick to version 92 - that already support station
MLO correctly.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16558
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
