Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
On Thu, Jan 5, 2023 at 7:12 PM Stefan Lippers-Hollmann wrote: > On 2023-01-06, Christian Marangi wrote: > > On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote: > > > On Thu, Jan 5, 2023 at 11:59 AM Brian Norris > [...] > > > Do I need to create some intermediate/stub package just to express the > > > dependency, or is there some better way? > > > > > > > In theory there is [1] coreutils-base64 as a separate package but I > > think we have to move that to core packages as it's part of the feeds > > package. coreutils definitely works. (busybox would too, except I just can't get the dependency mechanics right.) > There would be another alternative for base64 functionality, openssl... > While not the lightest package, it's already available in main and > with DEVICE_PACKAGES a relatively low-maintenance alternative. > > openssl enc -base64 -in foo -out foo.base64 > openssl enc -d -base64 -in foo.base64 -out foo I have to throw "-A" in there apparently, since openssl is apparently too strict on (lack of) line wrapping in the data source, but that works too. > With root/ overlay on eMMC, this shouldn't be too heavy for this > kind of hardware. Yeah, should be no big deal on space. These devices have ~4GB storage [1]. Does anybody care on non-disk-space grounds? Like "lack of choice"? (I guess one can install multiple SSL libraries.) So what do you all think? Pick my favorite? I suppose I kinda like the 'base64' (either coreutils or busybox) option, since it's a bit of a simpler tool, and has multiple options (in case somebody is trying to slim things for some reason). But openssl is easiest from a friction point of view, since it's just a DEVICE_PACKAGES dependency away, instead of porting over something from feeds. Brian [1] Although the default partitioning sets CONFIG_TARGET_ROOTFS_PARTSIZE=200, which limits the default build unnecessarily to ~128MiB. I still need to figure out the best way to fix that: https://openwrt.org/toh/google/wifi#expanding_storage_optional ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
Hi On 2023-01-06, Christian Marangi wrote: > On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote: > > On Thu, Jan 5, 2023 at 11:59 AM Brian Norris [...] > > Do I need to create some intermediate/stub package just to express the > > dependency, or is there some better way? > > > > In theory there is [1] coreutils-base64 as a separate package but I > think we have to move that to core packages as it's part of the feeds > package. There would be another alternative for base64 functionality, openssl... While not the lightest package, it's already available in main and with DEVICE_PACKAGES a relatively low-maintenance alternative. openssl enc -base64 -in foo -out foo.base64 openssl enc -d -base64 -in foo.base64 -out foo With root/ overlay on eMMC, this shouldn't be too heavy for this kind of hardware. Disclaimer: I did not check wolfssl/ mbedtls for potential alternatives. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote: > In case you are open to giving more helpful tips to a relative > newcomer to openwrt development: > > On Thu, Jan 5, 2023 at 11:59 AM Brian Norris > wrote: > > I'll just need to > > force a 'base64' utility into these images > > This is turning out to be nontrivial. The only in-tree base64 tool is > a busybox tool, and it's not enabled in the default busybox > configuration. I don't see an easy way for a target to change this > default. I *do* see package dependencies that do this (like > DEPENDS:=+@BUSYBOX_CONFIG_), but I don't think that works in > a target (e.g., adding to DEVICE_PACKAGES). > > Do I need to create some intermediate/stub package just to express the > dependency, or is there some better way? > In theory there is [1] coreutils-base64 as a separate package but I think we have to move that to core packages as it's part of the feeds package. Just for testing can you test if that package suits your need for a userspace solution? [1] https://openwrt.org/packages/pkgdata/coreutils-base64 -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
In case you are open to giving more helpful tips to a relative newcomer to openwrt development: On Thu, Jan 5, 2023 at 11:59 AM Brian Norris wrote: > I'll just need to > force a 'base64' utility into these images This is turning out to be nontrivial. The only in-tree base64 tool is a busybox tool, and it's not enabled in the default busybox configuration. I don't see an easy way for a target to change this default. I *do* see package dependencies that do this (like DEPENDS:=+@BUSYBOX_CONFIG_), but I don't think that works in a target (e.g., adding to DEVICE_PACKAGES). Do I need to create some intermediate/stub package just to express the dependency, or is there some better way? Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] realtek: don't relocate kernel on HPE 1920 series
This is no longer needed now that the kernel is built with a load
address that matches the one hard-coded in the bootloader.
Signed-off-by: Jan Hoffmann
---
target/linux/realtek/image/Makefile | 14 --
target/linux/realtek/image/common.mk | 2 --
2 files changed, 16 deletions(-)
diff --git a/target/linux/realtek/image/Makefile
b/target/linux/realtek/image/Makefile
index 82390212e62d..3dfbcf67c166 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -71,20 +71,6 @@ define Build/h3c-vfs
mv $@.new $@
endef
-define Build/relocate-kernel
- rm -rf $@.relocate
- $(CP) ../../generic/image/relocate $@.relocate
- $(MAKE) -j1 -C $@.relocate KERNEL_ADDR=$(KERNEL_LOADADDR)
LZMA_TEXT_START=0x8200 \
- CROSS_COMPILE=$(TARGET_CROSS)
- ( \
- dd if=$@.relocate/loader.bin bs=32 conv=sync && \
- perl -e '@s = stat("$@"); print pack("N", @s[7])' && \
- cat "$@" \
- ) > "$@.new"
- mv "$@.new" "$@"
- rm -rf $@.relocate
-endef
-
define Device/Default
PROFILES = Default
KERNEL := \
diff --git a/target/linux/realtek/image/common.mk
b/target/linux/realtek/image/common.mk
index 8f536bf15f58..214683f8e959 100644
--- a/target/linux/realtek/image/common.mk
+++ b/target/linux/realtek/image/common.mk
@@ -34,14 +34,12 @@ define Device/hpe_1920
KERNEL := \
kernel-bin | \
append-dtb | \
- relocate-kernel | \
7z | \
h3c-image | \
h3c-vfs
KERNEL_INITRAMFS := \
kernel-bin | \
append-dtb | \
- relocate-kernel | \
7z | \
h3c-image
IMAGE/sysupgrade.bin := \
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
On Thu, Jan 5, 2023 at 11:02 AM Robert Marko wrote: > On Thu, 5 Jan 2023 at 19:47, Brian Norris wrote: > > On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote: > > > Also on top of that the besto solution for these special case is to > > > parse the base64 data in userspace a produce a calibration bin to pass > > > with sysfs. A patch and some code to decode base64 seems overkill to me. > > > > I'd love something that's more pleasant than in-kernel base64. Is there > > some sysfs method for this that I'm not aware of? The closest I find is: > > > > /sys/kernel/debug/ieee80211/*/ath10k/cal_data > > > > But that's read-only, not read-write. And it's not completely obvious to > > me that this data can be (re)written to the target radio arbitrarily, so > > I suppose the API would be a bit fiddly -- that one has to know to write > > this file before ever bringing up the interface (but after loading the > > driver/module). > > > > Without a user space API, this is the best I came up with. > > You can extract and provide the caldata from userspace by acting on the > hotplug > event that kernel files after request_firmware() fails, look at what > Fritzbox devices are doing in: > https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata Awesome, I had an inkling that other devices would probably have some similar problems, but I didn't find exactly how they're handling it. And wow, I didn't realize there was a uevent/sysfs method for filling in the gaps on missing /lib/firmware files. TIL. > Basically, you trigger on the requested file and device and then you > can just use a userspace > script or binary to actually provide that file. Yep, this totally looks like it'll work for me. I'll just need to force a 'base64' utility into these images, but otherwise, looks pretty easy. > That would probably work best here as I dont know if upstream will > accept adding a base64 > method just for one or 2 devices. Yeah, I figured this is arcane enough (and not really a typical job for DT bindings) that we'd need to patch up something ourselves. I'm glad to not have to approach the "convince upstream" question on this ugly patch, and even more glad to find a way do this without modifying the kernel/driver. Thanks a lot, Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: two mt7915e cards and irq 149: nobody cared dump
czw., 5 sty 2023 o 16:41 Janusz Dziedzic napisał(a): > > Hello, > > Have two mt7915e cards in my banana PI R64 (latest master). > After do ifconfig wlan1 up - dump. > While ifconfig wlan2 up works correctly. > > [7.093206] mt7915e :01:00.0: assign IRQ: got 148 > [7.098405] mt7915e :01:00.0: enabling device ( -> 0002) > [7.104537] mt7915e :01:00.0: enabling bus mastering > [7.181837] mt7622-wmac 1800.wmac: N9 Firmware Version: > _reserved_, Build Time: 20220630094834 > [7.193914] Bluetooth: hci0: Device setup in 243529 usecs > [7.233531] mtk-pcie 1a143000.pcie: msi#0 address_hi 0x0 address_lo > 0x44e050c0 > [7.291849] mt7915e :01:00.0: HW/SW Version: 0x8a108a10, Build > Time: 20220929104113a > [7.291849] > [7.435118] mt7915e :01:00.0: WM Firmware Version: 00, > Build Time: 20220929104145 > [7.492309] mt7915e :01:00.0: WA Firmware Version: DEV_00, > Build Time: 20220929104205 > [7.655412] mt7915e 0001:01:00.0: assign IRQ: got 149 > [7.660552] mt7915e 0001:01:00.0: enabling device ( -> 0002) > [7.666722] mt7915e 0001:01:00.0: enabling bus mastering > [7.783768] mtk-pcie 1a145000.pcie: msi#0 address_hi 0x0 address_lo > 0x44e150c0 > [7.803991] mt7915e 0001:01:00.0: HW/SW Version: 0x8a108a10, Build > Time: 20220929104113a > [7.803991] > [7.822350] mt7915e 0001:01:00.0: WM Firmware Version: 00, > Build Time: 20220929104145 > [7.846429] mt7915e 0001:01:00.0: WA Firmware Version: DEV_00, > Build Time: 20220929104205 > > > > # ifconfig wlan1 up > > Creating netns for phy2 on port 2302 > [ 379.207067] irq 149: nobody cared (try booting with the "irqpoll" option) > [ 379.213884] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S > 5.15.86 #0 > [ 379.221291] Hardware name: Bananapi BPI-R64 (DT) > [ 379.225909] Call trace: > [ 379.228352] dump_backtrace+0x0/0x15c > [ 379.232035] show_stack+0x14/0x30 > [ 379.235359] dump_stack_lvl+0x64/0x7c > [ 379.239030] dump_stack+0x14/0x2c > [ 379.242351] __report_bad_irq+0x48/0x128 > [ 379.246280] note_interrupt+0x2e4/0x340 > [ 379.250124] handle_irq_event+0xb8/0xe0 > [ 379.253965] handle_simple_irq+0xb0/0x10c > [ 379.257980] generic_handle_domain_irq+0x28/0x3c > [ 379.262610] mtk_pcie_intr_handler+0x144/0x19c > [ 379.267064] handle_domain_irq+0x5c/0x8c > [ 379.270999] gic_handle_irq+0x64/0x8c > [ 379.274668] do_interrupt_handler+0x30/0x54 > [ 379.278859] el1_interrupt+0x2c/0x4c > [ 379.282446] el1h_64_irq_handler+0x14/0x20 > [ 379.286547] el1h_64_irq+0x74/0x78 > [ 379.289953] _stext+0xa0/0x294 > [ 379.293012] __irq_exit_rcu+0xdc/0xfc > [ 379.296680] irq_exit+0xc/0x1c > [ 379.299738] handle_domain_irq+0x60/0x8c > [ 379.303673] gic_handle_irq+0x64/0x8c > [ 379.307340] call_on_irq_stack+0x28/0x44 > [ 379.311269] do_interrupt_handler+0x4c/0x54 > [ 379.315460] el1_interrupt+0x2c/0x4c > [ 379.319045] el1h_64_irq_handler+0x14/0x20 > [ 379.323145] el1h_64_irq+0x74/0x78 > [ 379.326550] arch_cpu_idle+0x14/0x20 > [ 379.330131] do_idle+0xc0/0x140 > [ 379.333284] cpu_startup_entry+0x24/0x50 > [ 379.337218] rest_init+0xc4/0xd0 > [ 379.340451] arch_call_rest_init+0xc/0x14 > [ 379.344471] start_kernel+0x5b4/0x5d4 > [ 379.348144] __primary_switched+0xa0/0xa8 > [ 379.352163] handlers: > [ 379.354433] [] pcie_pme_irq > [ 379.358808] Disabling IRQ #149 > And lspci: root@OpenWrt:~# lspci :00:00.0 PCI bridge: MEDIATEK Corp. Device 3258 :01:00.0 Unclassified device [0002]: MEDIATEK Corp. MT7915E 802.11ax PCI Express Wireless Network Adapter 0001:00:01.0 PCI bridge: MEDIATEK Corp. Device 3258 0001:01:00.0 Unclassified device [0002]: MEDIATEK Corp. MT7915E 802.11ax PCI Express Wireless Network Adapter root@OpenWrt:~# root@OpenWrt:~# root@OpenWrt:~# lspci -tv -+-[:00]---00.0-[01]00.0 MEDIATEK Corp. MT7915E 802.11ax PCI Express Wireless Network Adapter \-[0001:00]---01.0-[01]00.0 MEDIATEK Corp. MT7915E 802.11ax PCI Express Wireless Network Adapter root@OpenWrt:~# root@OpenWrt:~# root@OpenWrt:~# lspci -v :00:00.0 PCI bridge: MEDIATEK Corp. Device 3258 (prog-if 00 [Normal decode]) Device tree node: /sys/firmware/devicetree/base/pcie@1a143000/pcie@0,0 Flags: bus master, fast devsel, latency 0, IRQ 148 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: 2000-201f [size=2M] [32-bit] Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Power Management version 3 Capabilities: [80] Express Root Port (Slot+), MSI 00 Capabilities: [100] Virtual Channel Capabilities: [400] L1 PM Substates Capabilities: [600] Latency Tolerance Reporting Kernel driver in use: pcieport lspci: Unable to load libkmod resources: error -12 :01:00.0 Unclassified device [0002]: MEDIATEK Corp. MT7915E 802.11ax PCI Express Wireless Network Adapter (prog-if 80) Subsystem: MEDIATEK Corp. MT7915E 802.11ax PCI Express Wireless Network
Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
On Thu, 5 Jan 2023 at 19:47, Brian Norris wrote: > > Hi Christian, > > On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote: > > On Mon, Jan 02, 2023 at 03:25:33PM -0800, Brian Norris wrote: > > > See the patch notes about the stock firmware for TP-Link Onhub and > > > https://chromium-review.googlesource.com/243115. > > > > > > As noted there, the production firmware for Google OnHub devices only > > > provide the *-base64 Device Tree property, and so either the kernel or > > > some user space mechanism needs to know how to parse/convert this > > > property. > ... > > > > Aside from this, I notice this is actually NOT used in the 2 device you > > are proposing. I'm totally missing something or this is not needed at > > all? > > It's provided by the production firmware, which patches it into the > device tree on its own. So you're not going to find it in the kernel or > DTS sources. > > If you want to look at its source though, it's here: > https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/firmware-storm-6315.B/src/board/storm/wifi_calibration.c > > And unfortunately, systems I'm looking at were only programmed with the > base64 VPD: > > # ls -1 /sys/firmware/vpd/ro/wifi* > /sys/firmware/vpd/ro/wifi_base64_calibration0 > /sys/firmware/vpd/ro/wifi_base64_calibration1 > /sys/firmware/vpd/ro/wifi_base64_calibration2 > > > Also on top of that the besto solution for these special case is to > > parse the base64 data in userspace a produce a calibration bin to pass > > with sysfs. A patch and some code to decode base64 seems overkill to me. > > I'd love something that's more pleasant than in-kernel base64. Is there > some sysfs method for this that I'm not aware of? The closest I find is: > > /sys/kernel/debug/ieee80211/*/ath10k/cal_data > > But that's read-only, not read-write. And it's not completely obvious to > me that this data can be (re)written to the target radio arbitrarily, so > I suppose the API would be a bit fiddly -- that one has to know to write > this file before ever bringing up the interface (but after loading the > driver/module). > > Without a user space API, this is the best I came up with. You can extract and provide the caldata from userspace by acting on the hotplug event that kernel files after request_firmware() fails, look at what Fritzbox devices are doing in: https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata Basically, you trigger on the requested file and device and then you can just use a userspace script or binary to actually provide that file. That would probably work best here as I dont know if upstream will accept adding a base64 method just for one or 2 devices. Regards, Robert > > Brian > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
two mt7915e cards and irq 149: nobody cared dump
Hello, Have two mt7915e cards in my banana PI R64 (latest master). After do ifconfig wlan1 up - dump. While ifconfig wlan2 up works correctly. [7.093206] mt7915e :01:00.0: assign IRQ: got 148 [7.098405] mt7915e :01:00.0: enabling device ( -> 0002) [7.104537] mt7915e :01:00.0: enabling bus mastering [7.181837] mt7622-wmac 1800.wmac: N9 Firmware Version: _reserved_, Build Time: 20220630094834 [7.193914] Bluetooth: hci0: Device setup in 243529 usecs [7.233531] mtk-pcie 1a143000.pcie: msi#0 address_hi 0x0 address_lo 0x44e050c0 [7.291849] mt7915e :01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20220929104113a [7.291849] [7.435118] mt7915e :01:00.0: WM Firmware Version: 00, Build Time: 20220929104145 [7.492309] mt7915e :01:00.0: WA Firmware Version: DEV_00, Build Time: 20220929104205 [7.655412] mt7915e 0001:01:00.0: assign IRQ: got 149 [7.660552] mt7915e 0001:01:00.0: enabling device ( -> 0002) [7.666722] mt7915e 0001:01:00.0: enabling bus mastering [7.783768] mtk-pcie 1a145000.pcie: msi#0 address_hi 0x0 address_lo 0x44e150c0 [7.803991] mt7915e 0001:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20220929104113a [7.803991] [7.822350] mt7915e 0001:01:00.0: WM Firmware Version: 00, Build Time: 20220929104145 [7.846429] mt7915e 0001:01:00.0: WA Firmware Version: DEV_00, Build Time: 20220929104205 # ifconfig wlan1 up Creating netns for phy2 on port 2302 [ 379.207067] irq 149: nobody cared (try booting with the "irqpoll" option) [ 379.213884] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S 5.15.86 #0 [ 379.221291] Hardware name: Bananapi BPI-R64 (DT) [ 379.225909] Call trace: [ 379.228352] dump_backtrace+0x0/0x15c [ 379.232035] show_stack+0x14/0x30 [ 379.235359] dump_stack_lvl+0x64/0x7c [ 379.239030] dump_stack+0x14/0x2c [ 379.242351] __report_bad_irq+0x48/0x128 [ 379.246280] note_interrupt+0x2e4/0x340 [ 379.250124] handle_irq_event+0xb8/0xe0 [ 379.253965] handle_simple_irq+0xb0/0x10c [ 379.257980] generic_handle_domain_irq+0x28/0x3c [ 379.262610] mtk_pcie_intr_handler+0x144/0x19c [ 379.267064] handle_domain_irq+0x5c/0x8c [ 379.270999] gic_handle_irq+0x64/0x8c [ 379.274668] do_interrupt_handler+0x30/0x54 [ 379.278859] el1_interrupt+0x2c/0x4c [ 379.282446] el1h_64_irq_handler+0x14/0x20 [ 379.286547] el1h_64_irq+0x74/0x78 [ 379.289953] _stext+0xa0/0x294 [ 379.293012] __irq_exit_rcu+0xdc/0xfc [ 379.296680] irq_exit+0xc/0x1c [ 379.299738] handle_domain_irq+0x60/0x8c [ 379.303673] gic_handle_irq+0x64/0x8c [ 379.307340] call_on_irq_stack+0x28/0x44 [ 379.311269] do_interrupt_handler+0x4c/0x54 [ 379.315460] el1_interrupt+0x2c/0x4c [ 379.319045] el1h_64_irq_handler+0x14/0x20 [ 379.323145] el1h_64_irq+0x74/0x78 [ 379.326550] arch_cpu_idle+0x14/0x20 [ 379.330131] do_idle+0xc0/0x140 [ 379.333284] cpu_startup_entry+0x24/0x50 [ 379.337218] rest_init+0xc4/0xd0 [ 379.340451] arch_call_rest_init+0xc/0x14 [ 379.344471] start_kernel+0x5b4/0x5d4 [ 379.348144] __primary_switched+0xa0/0xa8 [ 379.352163] handlers: [ 379.354433] [] pcie_pme_irq [ 379.358808] Disabling IRQ #149 BR Janusz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: fix bugs added with mac-address-ascii support
From: Rafał Miłecki
1. Check for -EPROBE_DEFER
If it occurs we have to return immediately. Trying other properties
could result in another error and ignoring -EPROBE_DEFER which has a
special meaning.
2. Check for read result
Assuming property->read() success can result in NULL pointer
dereference. It happens e.g. for "mac-address" with NVMEM cell
containing invalid MAC.
3. Simplify code
Don't move cell reading & nvmem_cell_put() into a loop. Simplify loop
code.
Fixes: ecd81de7a5ab ("ath79: add nvmem cell mac-address-ascii support")
Cc: Yousong Zhou
Signed-off-by: Rafał Miłecki
---
...of_net-add-mac-address-ascii-support.patch | 39 +--
...of_net-add-mac-address-ascii-support.patch | 39 +--
2 files changed, 38 insertions(+), 40 deletions(-)
diff --git
a/target/linux/generic/hack-5.10/601-of_net-add-mac-address-ascii-support.patch
b/target/linux/generic/hack-5.10/601-of_net-add-mac-address-ascii-support.patch
index 5dd70f5f71..cf2a26c9d6 100644
---
a/target/linux/generic/hack-5.10/601-of_net-add-mac-address-ascii-support.patch
+++
b/target/linux/generic/hack-5.10/601-of_net-add-mac-address-ascii-support.patch
@@ -75,36 +75,35 @@ Submitted-by: Yousong Zhou
/**
* Obtain the MAC address from an nvmem cell named 'mac-address' associated
* with given device.
-@@ -552,19 +609,23 @@ int nvmem_get_mac_address(struct device
+@@ -550,21 +607,28 @@ EXPORT_SYMBOL(eth_platform_get_mac_addre
+ */
+ int nvmem_get_mac_address(struct device *dev, void *addrbuf)
{
++ struct nvmem_cell_mac_address_property *property;
struct nvmem_cell *cell;
const void *mac;
- size_t len;
-+ struct nvmem_cell_mac_address_property *property;
+ int i;
-
-- cell = nvmem_cell_get(dev, "mac-address");
-- if (IS_ERR(cell))
-- return PTR_ERR(cell);
--
-- mac = nvmem_cell_read(cell, );
-- nvmem_cell_put(cell);
--
-- if (IS_ERR(mac))
-- return PTR_ERR(mac);
++
+ for (i = 0; i < ARRAY_SIZE(nvmem_cell_mac_address_properties); i++) {
+ property = _cell_mac_address_properties[i];
+ cell = nvmem_cell_get(dev, property->name);
-+ if (IS_ERR(cell)) {
-+ if (i == ARRAY_SIZE(nvmem_cell_mac_address_properties)
- 1)
-+ return PTR_ERR(cell);
-+ continue;
-+ }
-+ mac = property->read(cell);
-+ nvmem_cell_put(cell);
-+ break;
++ /* For -EPROBE_DEFER don't try other properties. We'll get back
to this one. */
++ if (!IS_ERR(cell) || PTR_ERR(cell) == -EPROBE_DEFER)
++ break;
+ }
+- cell = nvmem_cell_get(dev, "mac-address");
+ if (IS_ERR(cell))
+ return PTR_ERR(cell);
+
+- mac = nvmem_cell_read(cell, );
++ mac = property->read(cell);
+ nvmem_cell_put(cell);
+-
+ if (IS_ERR(mac))
+ return PTR_ERR(mac);
+
- if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
+ if (!is_valid_ether_addr(mac)) {
kfree(mac);
diff --git
a/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
b/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
index 4ab05b4ea6..eb390961d7 100644
---
a/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
+++
b/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
@@ -75,36 +75,35 @@ Submitted-by: Yousong Zhou
/**
* nvmem_get_mac_address - Obtain the MAC address from an nvmem cell named
* 'mac-address' associated with given device.
-@@ -551,19 +608,23 @@ int nvmem_get_mac_address(struct device
+@@ -549,21 +606,28 @@ EXPORT_SYMBOL(eth_platform_get_mac_addre
+ */
+ int nvmem_get_mac_address(struct device *dev, void *addrbuf)
{
++ struct nvmem_cell_mac_address_property *property;
struct nvmem_cell *cell;
const void *mac;
- size_t len;
-+ struct nvmem_cell_mac_address_property *property;
+ int i;
-
-- cell = nvmem_cell_get(dev, "mac-address");
-- if (IS_ERR(cell))
-- return PTR_ERR(cell);
--
-- mac = nvmem_cell_read(cell, );
-- nvmem_cell_put(cell);
--
-- if (IS_ERR(mac))
-- return PTR_ERR(mac);
++
+ for (i = 0; i < ARRAY_SIZE(nvmem_cell_mac_address_properties); i++) {
+ property = _cell_mac_address_properties[i];
+ cell = nvmem_cell_get(dev, property->name);
-+ if (IS_ERR(cell)) {
-+ if (i == ARRAY_SIZE(nvmem_cell_mac_address_properties)
- 1)
-+ return PTR_ERR(cell);
-+ continue;
-+ }
-+ mac = property->read(cell);
-+ nvmem_cell_put(cell);
-+ break;
++ /* For -EPROBE_DEFER don't try other properties. We'll get back
to
[PATCH-22.03] lantiq-xrx200: fix wan LED on o2 box 6431
From: Florian Maurer The WIFI LED already worked for me with the latest openwrt 22.03 version. Wifi LED did not with an older 22.x version (in gluon - there phy0radio did nothing but phy0tpt did show activity the WAN interface has the name "wan" and not "pppoe-wan" on this device fixes #7757 (and FS#2987) Signed-off-by: Florian Maurer (cherry picked from commit 0820d620123a03b6db6642acb6e950d22ffb030f) Signed-off-by: Jan-Niklas Burfeind --- target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds b/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds index bac3ed2b53..8f59538b83 100644 --- a/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds +++ b/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds @@ -28,7 +28,10 @@ arcadyan,arv7519rw22) ucidef_set_led_netdev "lan" "lan" "green:lan" "eth0.1" ;; arcadyan,vgv7510kw22-nor|\ -arcadyan,vgv7510kw22-brn|\ +arcadyan,vgv7510kw22-brn) + ucidef_set_led_netdev "internet" "internet" "$led_internet" "wan" + ucidef_set_led_wlan "wifi" "wifi" "green:wlan" "phy0radio" + ;; zyxel,p-2812hnu-f1|\ zyxel,p-2812hnu-f3) ucidef_set_led_wlan "wifi" "wifi" "green:wlan" "phy0radio" -- 2.39.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[ubus PATCH] libubus: remove global variables
Remove the use of global blob_buf and blob_attr variables to allow
for better thread safety with a ctx per thread on client invoke
and sends.
Add the same variables to within each calling function's scope,
encapsulating the memory usage there.
Fixes a multithreaded use case and has been verified 10,000
threads multiple times running invokes and send events.
Signed-off-by: Simon Tate
---
cli.c | 38 --
libubus-internal.h | 2 +-
libubus-io.c | 10 ---
libubus-obj.c | 63 ++-
libubus-req.c | 44 +-
libubus-sub.c | 13 ++---
libubus.c | 67 ++
7 files changed, 161 insertions(+), 76 deletions(-)
diff --git a/cli.c b/cli.c
index 81591ec..e6d7a1b 100644
--- a/cli.c
+++ b/cli.c
@@ -16,7 +16,6 @@
#include
#include "libubus.h"
-static struct blob_buf b;
static int listen_timeout;
static int timeout = 30;
static bool simple_output = false;
@@ -140,18 +139,29 @@ static int ubus_cli_call(struct ubus_context *ctx, int
argc, char **argv)
if (argc < 2 || argc > 3)
return -2;
+ struct blob_buf b = { 0 };
blob_buf_init(, 0);
if (argc == 3 && !blobmsg_add_json_from_string(, argv[2])) {
if (!simple_output)
fprintf(stderr, "Failed to parse message data\n");
- return -1;
+ ret = -1;
+ goto error;
}
ret = ubus_lookup_id(ctx, argv[0], );
- if (ret)
- return ret;
+ if (ret) {
+ goto error;
+ }
+
+ ret = ubus_invoke(ctx, id, argv[1], b.head, receive_call_result_data,
NULL, timeout * 1000);
+ if (ret) {
+ goto error;
+ }
- return ubus_invoke(ctx, id, argv[1], b.head, receive_call_result_data,
NULL, timeout * 1000);
+error:
+ blob_buf_free();
+
+ return ret;
}
struct cli_listen_data {
@@ -265,15 +275,23 @@ static int ubus_cli_send(struct ubus_context *ctx, int
argc, char **argv)
if (argc < 1 || argc > 2)
return -2;
+ int ret = UBUS_STATUS_OK;
+
+ struct blob_buf b = { 0 };
blob_buf_init(, 0);
if (argc == 2 && !blobmsg_add_json_from_string(, argv[1])) {
if (!simple_output)
fprintf(stderr, "Failed to parse message data\n");
- return -1;
+ ret = -1;
+ goto error;
}
- return ubus_send_event(ctx, argv[0], b.head);
+ ret = ubus_send_event(ctx, argv[0], b.head);
+
+error:
+ blob_buf_free();
+ return ret;
}
struct cli_wait_data {
@@ -428,6 +446,7 @@ ubus_cli_get_monitor_data(struct blob_attr *data)
struct blob_attr *tb[UBUS_ATTR_MAX];
int i;
+ struct blob_buf b = { 0 };
blob_buf_init(, 0);
blob_parse(data, tb, policy, UBUS_ATTR_MAX);
@@ -454,7 +473,10 @@ ubus_cli_get_monitor_data(struct blob_attr *data)
}
}
- return blobmsg_format_json(b.head, true);
+ char* ret = blobmsg_format_json(b.head, true);
+
+ blob_buf_free();
+ return ret;
}
static void
diff --git a/libubus-internal.h b/libubus-internal.h
index 24477a0..5b23668 100644
--- a/libubus-internal.h
+++ b/libubus-internal.h
@@ -17,7 +17,7 @@
extern struct blob_buf b;
extern const struct ubus_method watch_method;
-struct blob_attr **ubus_parse_msg(struct blob_attr *msg, size_t len);
+void ubus_parse_msg(struct blob_attr *msg, size_t len, struct blob_attr
**attrbuf, size_t attrbuf_len);
bool ubus_validate_hdr(struct ubus_msghdr *hdr);
void ubus_handle_data(struct uloop_fd *u, unsigned int events);
int ubus_send_msg(struct ubus_context *ctx, uint32_t seq,
diff --git a/libubus-io.c b/libubus-io.c
index 3561ac4..143d3be 100644
--- a/libubus-io.c
+++ b/libubus-io.c
@@ -41,12 +41,10 @@ static const struct blob_attr_info
ubus_policy[UBUS_ATTR_MAX] = {
[UBUS_ATTR_SUBSCRIBERS] = { .type = BLOB_ATTR_NESTED },
};
-static struct blob_attr *attrbuf[UBUS_ATTR_MAX];
-__hidden struct blob_attr **ubus_parse_msg(struct blob_attr *msg, size_t len)
+__hidden void ubus_parse_msg(struct blob_attr *msg, size_t len, struct
blob_attr **attrbuf, size_t attrbuf_len)
{
- blob_parse_untrusted(msg, len, attrbuf, ubus_policy, UBUS_ATTR_MAX);
- return attrbuf;
+ blob_parse_untrusted(msg, len, attrbuf, ubus_policy, attrbuf_len);
}
static void wait_data(int fd, bool write)
@@ -137,6 +135,8 @@ int __hidden ubus_send_msg(struct ubus_context *ctx,
uint32_t seq,
hdr.seq = cpu_to_be16(seq);
hdr.peer = cpu_to_be32(peer);
+ struct blob_buf b = {0};
+
if (!msg) {
blob_buf_init(, 0);
msg = b.head;
@@ -152,6 +152,8 @@ int __hidden ubus_send_msg(struct ubus_context *ctx,
uint32_t seq,
if (fd >= 0)
Re: [PATCH 5/8] ipq8064: ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
On Thu, 5 Jan 2023 at 04:02, Brian Norris wrote: > > Hi Christian, Robert, > > On Wed, Jan 04, 2023 at 02:30:23PM +0100, Robert Marko wrote: > > On Wed, 4 Jan 2023 at 14:04, Christian Marangi wrote: > > > > > > On Mon, Jan 02, 2023 at 03:25:31PM -0800, Brian Norris wrote: > > > > This fixes device tree registration for 'qcom,lpass-cpu' as used by > > > > qcom-ipq8064 SoCs, and allows speaker audio to function. > > > > > > > > This patch has been submitted (and merged, for -next) upstream. > > > > > > Considering it's tagged for stable and assuming it will be part of 6.2 > > > wonder if it's a good idea to add the kernel tag to better track this? > > I first wrote this when I had just posted the patch; didn't expect it to > land so quickly! > > But what do you mean: just tweak the commit title to 'kernel: ...'? Or > move this to the generic kernel patches > (target/linux/generic/backport-5.15/)? No need for generic as its cleary QCA related, he means to add the kernel version it will be available in after number, so lets say 024-v6.2-whatever.patch > > > Also, the 900 prefix isn't really meant for backports. > > Ack. I only just noticed target/linux/generic/PATCHES. So I guess that's > one of these? > > 0xx - upstream backports > 1xx - code awaiting upstream merge > > Thanks, > Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 5/8] ipq8064: ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
Hi Christian, Robert, On Wed, Jan 04, 2023 at 02:30:23PM +0100, Robert Marko wrote: > On Wed, 4 Jan 2023 at 14:04, Christian Marangi wrote: > > > > On Mon, Jan 02, 2023 at 03:25:31PM -0800, Brian Norris wrote: > > > This fixes device tree registration for 'qcom,lpass-cpu' as used by > > > qcom-ipq8064 SoCs, and allows speaker audio to function. > > > > > > This patch has been submitted (and merged, for -next) upstream. > > > > Considering it's tagged for stable and assuming it will be part of 6.2 > > wonder if it's a good idea to add the kernel tag to better track this? I first wrote this when I had just posted the patch; didn't expect it to land so quickly! But what do you mean: just tweak the commit title to 'kernel: ...'? Or move this to the generic kernel patches (target/linux/generic/backport-5.15/)? > Also, the 900 prefix isn't really meant for backports. Ack. I only just noticed target/linux/generic/PATCHES. So I guess that's one of these? 0xx - upstream backports 1xx - code awaiting upstream merge Thanks, Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
Hi Christian, On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote: > On Mon, Jan 02, 2023 at 03:25:33PM -0800, Brian Norris wrote: > > See the patch notes about the stock firmware for TP-Link Onhub and > > https://chromium-review.googlesource.com/243115. > > > > As noted there, the production firmware for Google OnHub devices only > > provide the *-base64 Device Tree property, and so either the kernel or > > some user space mechanism needs to know how to parse/convert this > > property. ... > > Aside from this, I notice this is actually NOT used in the 2 device you > are proposing. I'm totally missing something or this is not needed at > all? It's provided by the production firmware, which patches it into the device tree on its own. So you're not going to find it in the kernel or DTS sources. If you want to look at its source though, it's here: https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/firmware-storm-6315.B/src/board/storm/wifi_calibration.c And unfortunately, systems I'm looking at were only programmed with the base64 VPD: # ls -1 /sys/firmware/vpd/ro/wifi* /sys/firmware/vpd/ro/wifi_base64_calibration0 /sys/firmware/vpd/ro/wifi_base64_calibration1 /sys/firmware/vpd/ro/wifi_base64_calibration2 > Also on top of that the besto solution for these special case is to > parse the base64 data in userspace a produce a calibration bin to pass > with sysfs. A patch and some code to decode base64 seems overkill to me. I'd love something that's more pleasant than in-kernel base64. Is there some sysfs method for this that I'm not aware of? The closest I find is: /sys/kernel/debug/ieee80211/*/ath10k/cal_data But that's read-only, not read-write. And it's not completely obvious to me that this data can be (re)written to the target radio arbitrarily, so I suppose the API would be a bit fiddly -- that one has to know to write this file before ever bringing up the interface (but after loading the driver/module). Without a user space API, this is the best I came up with. Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/8] ipq806x: Point to externally compiled dtbs in recipes
On Wed, Jan 04, 2023 at 01:50:17PM +0100, Christian Marangi wrote: > On Mon, Jan 02, 2023 at 03:25:28PM -0800, Brian Norris wrote: > > See also: > > > > commit 4d8b42d8a7774070ac0439915f8de1430db9a8e3 > > Author: Tomasz Maciej Nowak > > Date: Thu Aug 25 20:26:11 2022 +0200 > > > > ipq40xx: point to externally compiled dtbs in recipes > > > > Adjusting dts will cause a rebuild of whole kernel as the buildroot > > considers this a part of kernel source. It's a royal PITA when trying to > > prepare support for new device, since this takes a lot of time on slower > > systems. As it stands, buildroot itself, with own rule, also compiles > > dtbs and the results are $(KDIR)/image-$(DEVICE_DTS).dtb. With setting > > DEVICE_DTS_DIR to directory holding the device dts (similarly to some > > other targets), buildroot doesn't consider changed dts as part of kernel > > source and rebuilds only dtb. This really speeds up development. And > > since the kernel built dts are no longer used, drop the paches adding > > dtses to its build. > > > > In a similar fashion, we can drop the DTS patch. > > Can we improve the commit description without appending the commit > description of another commit? Seems wrong to me. Sure. I suppose I can liberally borrow (and reference) the description instead of quoting. > If you already found a similar commit description feel free to link as I > could be totally wrong about this. Eh, my quick search didn't really find any. The closest was something like this: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=0dc58214896aacf67a3759495d70e2b4e9c160d8 where at least some of the larger metadata (author, commiter, dates) were pasted. Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/8] base-files: Remove nand.sh dependency from emmc upgrade
Hi Christian,
On Wed, Jan 04, 2023 at 01:40:57PM +0100, Christian Marangi wrote:
> On Mon, Jan 02, 2023 at 03:25:27PM -0800, Brian Norris wrote:
> > --- a/package/base-files/files/lib/upgrade/common.sh
> > +++ b/package/base-files/files/lib/upgrade/common.sh
> > @@ -127,6 +127,33 @@ get_magic_fat32() {
> > (get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
> > }
> >
> > +identify_magic_long() {
...
> > diff --git a/package/base-files/files/lib/upgrade/nand.sh
> > b/package/base-files/files/lib/upgrade/nand.sh
> > index a8e3cab0b8b1..a1dbd6e2663d 100644
> > --- a/package/base-files/files/lib/upgrade/nand.sh
> > +++ b/package/base-files/files/lib/upgrade/nand.sh
> > @@ -65,40 +65,12 @@ get_magic_long_tar() {
> > identify() {
> > - identify_magic $(nand_get_magic_long "$@")
> > + identify_magic_long $(nand_get_magic_long "$@")
>
> Should we really change the name from identify_magic to
> identify_magic_long?
I was trying to match the conventions of common.sh, where I moved the
helper to. common.sh has get_magic_word() and get_magic_long() (and
other suffixed helpers for specific purposes), and it's important the
caller uses the correct ones. While this identify function could
partially work (it can identify "combined" and "gzip") with just a
'word' of data, it would be misleading.
Is there a reason *not* to change the name?
Thanks,
Brian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/2] toolchain: build all user space with sanitizer on glibc
On 1/4/23 18:39, Christian Marangi wrote: On Sun, Jan 17, 2021 at 06:10:34PM +0100, Hauke Mehrtens wrote: This patch allows to build most the OpenWrt user space with address and undefined behavior sanitizer activated by default. This only works with glibc and gcc 10 and I only tested this on x86 64 so far. It is not intended to activate this by default ever, but this is helpful to detect (security) bugs in our applications. The first patch adds a work around for a problem with our Kconfig system, I did not fully understand the problems and only provided a workaround for it, if someone has any idea what is going wrong there this would be helpful. I already found some problems like memory leaks and a use after free problem, will send separate mails for the later. When these sanitizers are activated the OpenWrt userspace needs significant more memory, use at least 256MB for a basic system. TODOs: * Fix the Kconfig recursive dependency problem * Test this on more than x86 / 64 * Make it depend on GCC 10 or wait till GCC 10 is the default. This is a bit of necroposting... But any news with this? Considering we are switching to gcc12 by default i think these feature are now mature enough to be finally introduced. Hi, I was trying it again some days ago with gcc 12. I am still running into a bug with the script which generates the Kconfig. It has some problems with the iw Makefile which has two build variants. I will update my branch in the next days. I do not know if I find the time to look into the Kconfig problem. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
