wifi-scripts: ucode: fix airtime_mode with hostapd-mini
Currently wifi-scripts ucode appends airtime_mode to hostapd config file unconditionally. However this breaks bringing up interface with hostapd-mini because the mini variant doesn't support airtime policy.
Fix this by changing the script to append airtime_mode only when airtime_mode is set to greater than zero value in /etc/config/wireless.
Fixes: #20136 Fixes: #20314
Signed-off-by: Zhi-Jun You <hujy652@protonmail.com> (commit: 6a68c2f)
scripts/feeds: implement support for --root option
Some feeds might need to set the source for their packages in a different directory than the cloned one.
For example a feed "test" might be an entire repository and the relevant packages that wants to be included are in the directory "foo".
In such scenario the source info in the package will result in something like "feeds/test/foo/network/dnsmasq" instead of an expected entry like "feeds/test/network/dnsmasq".
To give a more real-world example, this problem is currently present with OpenWrt SDK where the SDK clone the entire OpenWrt core repository as "base" feeds but the package are present in the "package" directory.
This cause every package to have the source entry set to "feeds/base/package/..." conflicting with what a non-SDK build do with setting the source entry to "feeds/base/..."
To solve this, actually enable support for "flags" in the feeds script and implement a new option "--root" to set the root directory for the defined feed to an inner directory.
The "flags" in the feed script are no more than argument option that can be defined right after the "src-" type in the feed.conf file.
This feature was partially implemented but never actually used for anything keeping it dormant with all the core piece there (the pattern regex always accounted for these extra option but they were never passed to the relevant functions)
An example of the "--root" flag is the following:
src-git --root=package base https://git.openwrt.org/openwrt/openwrt.git;main
With "--root" defined, the script will append "_root" to the feed name clone directory and will create a symbolic link named with the feed name and pointing to the feed name clone directory + the value in root.
From the previous example:
feed name: base -> clone directory: base_root symbolic link: base -> base_root/package
The script internally reference the "_root" directory for every update operation and OpenWrt build system transparently use the feed name directory to reference feed packages producing consistent source info entry.
Link: https://github.com/openwrt/openwrt/pull/20396 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: e112fd8)
sdk: set package as the root directory for base feed
To produce consistent source entry for package compiled from non-SDK and SDK build, set the "--root=package" flag for the base feed.
This will set the root directory for the base feed to the OpenWrt core repository "package" directory.
This fix the reproducible problem of package build from SDK that have the source entry set to "feeds/base/package/..." for every package coming from the base feed.
Link: https://github.com/openwrt/openwrt/pull/20396 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: 297057f)
This is a preparation for introducing the 6.12 kernel support. All configs are automatically refreshed. In theory, they will generate the same .config files in the kernel build directory as before.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Link: https://github.com/openwrt/openwrt/pull/18989 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: da57f9b)
- Replace "strlcpy()" with "strscpy()". - Convert platform driver .remove() to .remove_new().
This patch fixes the following compile errors:
drivers/of/fdt.c:1064:17: error: implicit declaration of function 'strlcpy'; did you mean 'strncpy'? [-Wimplicit-function-declaration] 1064 | strlcpy(cmdline, p, min((int)l, COMMAND_LINE_SIZE)); | ^~~~~~~ | strncpy
drivers/devfreq/krait-cache-devfreq.c:171:27: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Wincompatible-pointer-types] 171 | .remove = krait_cache_remove, | ^~~~~~~~~~~~~~~~~~
drivers/devfreq/ipq806x-fab-devfreq.c:145:27: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Wincompatible-pointer-types] 145 | .remove = ipq806x_fab_remove, | ^~~~~~~~~~~~~~~~~~
Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Link: https://github.com/openwrt/openwrt/pull/18989 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: 1125d07)
ipq806x: dts: rework PCIe nodes for Chromium OnHub
- Reuse the bridges node defined on "qcom-ipq8064.dtsi". - Rename PCIe device nodes to unified "wifi@0,0". - Add the missing "qcom,ath10k" compatibles. - Remove unseless property "interrupt-controller". There are no consumers use these PCIe devices as interrupt controllers. - Change bus number from 0 to 1, just like other ipq806x devices. The valid PCIe bus range on this platform is 1 - 255.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Link: https://github.com/openwrt/openwrt/pull/18989 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: a4c654b)
These devices' reg cell[0] is equal to 0x10000, hence the correct node unitname should be "0,0". This patch fixes the following dtc warnings on 6.12 kernel:
qcom-ipq8065-tr4400-v2.dts:482.11-487.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8065-tr4400-v2.dts:499.11-504.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8065-rt4230w-rev6.dts:584.11-589.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8065-rt4230w-rev6.dts:601.11-606.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-g10.dts:291.11-295.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-g10.dts:303.11-307.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-wxr-2533dhp.dts:525.11-530.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-wxr-2533dhp.dts:539.11-544.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8068-ecw5410.dts:235.11-239.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8068-ecw5410.dts:251.11-255.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8068-ap3935.dts:261.11-264.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8068-ap3935.dts:275.11-278.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-fap-421e.dts:347.11-352.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-fap-421e.dts:362.11-367.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8068-cryptid-common.dtsi:78.18-81.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8068-cryptid-common.dtsi:89.18-92.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8068-cryptid-common.dtsi:100.18-103.4: Warning (pci_device_reg): /soc/pcie@1b900000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-wg2600hp.dts:464.11-469.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-wg2600hp.dts:478.11-483.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8062-wg2600hp3.dts:404.11-410.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8062-wg2600hp3.dts:419.11-426.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-d7800.dts:210.11-215.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-d7800.dts:227.11-232.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-r7500v2.dts:213.11-218.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-r7500v2.dts:230.11-235.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8065-nighthawk.dtsi:546.18-549.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8065-nighthawk.dtsi:559.18-562.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8065-ac400i.dts:202.11-206.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8065-ac400i.dts:218.11-222.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-ad7200-c2600.dtsi:319.11-324.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-ad7200-c2600.dtsi:333.11-338.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-vr2600v.dts:347.11-352.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0" qcom-ipq8064-vr2600v.dts:361.11-366.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Link: https://github.com/openwrt/openwrt/pull/18989 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: 41fe3aa)
ipq806x: migrate wifi configuration device paths for 6.12 kernel
The device tree PCIe host node names have been changed in the new 6.12 kernel[1]. Hence we have to update the wifi device path to make sure it can work properly.
This script is based on: target/linux/qualcommax/ipq807x/base-files/etc/hotplug.d/ieee80211/05-wifi-migrate
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.12.y&id=07299ba2e7d98045e6b522f7c5b97f402b15bc82 Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Link: https://github.com/openwrt/openwrt/pull/18989 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: ae70dbc)
Add pending patch to address PCI sysfs creation entry race observed on ipq806x. This is to handle a kernel warning on creating the same sysfs entry multiple times.
All affected patch automatically refreshed.
Link: https://github.com/openwrt/openwrt/pull/18989 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: 902f739)
Fixes: https://github.com/openwrt/openwrt/commit/726bb8e0e2fca96a160b3abbbf8e18227749cc27 ("mediatek: filogic: add support for SNR-CPE-AX2")
Signed-off-by: air jinkela <air_jinkela@163.com> Link: https://github.com/openwrt/openwrt/pull/20404 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 296f1cf)
qualcommax: ipq50xx: fix XO board clock rate for Yuncore AX850
Commit 468975a985ab changed the XO board clock definition from a fixed clock to a fixed rate clock in the dtsi.
As such, boards must use clock dividers and multipliers to calculate the clock rate based on the referenced parent clock.
Fixes: 5d2994a73e20 ("qualcommax: ipq50xx: Add support for Yuncore AX850") Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://github.com/openwrt/openwrt/pull/20405 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: c035447)
tools/meson: add pending patch to improve binary reproducibility
Add 3 pending patch that improve binary reproducibility. The first address a problem with RPATH string not getting cleared on removal of RPATH entry from ELF section. The other 2 skip including external shared library in RPATH in meson build phase.
This follows the logic that on cross-compiling we can't run the binary anyway as it does target a different arch hence it doesn't make sense to include those extra path in RPATH causing reproducibility problems (as path for those external library will depend on the build system path)
Link: https://github.com/openwrt/openwrt/pull/20389 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: 0b116e9)
apk-tools: fix compilation warning from downstream full print patch
Fix trivial compilation warning caused by downstream full print patch.
../src/app_list.c: In function 'print_full': ../src/app_list.c:85:35: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'uint64_t' {aka 'long long unsigned int'} [-Wformat=] 85 | printf("Installed-Size: %zu\n", pkg->installed_size); | ~~^ ~~~~~~~~~~~~~~~~~~~ | | | | | uint64_t {aka long long unsigned int} | unsigned int | %llu ../src/app_list.c:86:25: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'uint64_t' {aka 'long long unsigned int'} [-Wformat=] 86 | printf("Size: %zu\n", pkg->size); | ~~^ ~~~~~~~~~ | | | | | uint64_t {aka long long unsigned int} | unsigned int | %llu ../src/app_list.c:58:31: warning: unused variable 'd' [-Wunused-variable] 58 | struct apk_dependency d;
Remove unused variable and use PRIu64 to handle uint64_t type.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: e408030)
Add IPQ Wifi entry for ath79 TP-Link Archer C59 v1.
Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20401 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 8ea1396)
This patch resolves the LAN port not initializing on the FriendlyElec NanoPI R4S, especially during warm reboots.
Upstream commit patch is based on: https://github.com/torvalds/linux/commit/c3fe7071e196e25789ecf90dbc9e8491a98884d7
I've experienced the LAN port failing to initialize from a cold boot and after a reboot. Other users have reported this issue on https://forum.openwrt.org/t/nanopi-r4s-rk3399-is-a-great-new-openwrt-device/79143. The NanoPI R4S has its LAN port connected to the RK3399 via PCIE. Since the PCIE lanes don't initialize correctly after reboot, the LAN port doesn't initialize.
ksmbd.mount will give each interfaces list and bind_interfaces_only flags to ksmbd server. Previously, the interfaces list was sent only when bind_interfaces_only was enabled. ksmbd server browse only interfaces list given from ksmbd.conf on FSCTL_QUERY_INTERFACE_INFO IOCTL.
