Re: [PATCH 1/2] devices: Add Atheros AR9381
On Wed, Jan 19, 2022 at 2:31 AM Hauke Mehrtens wrote:
> On 1/18/22 23:38, Sergey Ryazanov wrote:
>> On Mon, Jan 17, 2022 at 12:35 AM Hauke Mehrtens wrote:
>>> This adds the Atheros AR9381 to the devices list. This card was found in
>>> the TP-LINK TD-W8970.
>>>
>>> Signed-off-by: Hauke Mehrtens
>>> ---
>>> devices.txt | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/devices.txt b/devices.txt
>>> index e6c18e6..3cec45a 100644
>>> --- a/devices.txt
>>> +++ b/devices.txt
>>> @@ -172,6 +172,7 @@
>>> 0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984"
>>> 0x168c 0x0050 0x 0x0 0 "Qualcomm Atheros" "QCA9887"
>>> 0x168c 0x0056 0x 0x0 0 "Qualcomm Atheros" "QCA9886"
>>> +0x168c 0xabcd 0x 0x0 0 "Atheros" "AR9381"
>>
>> I am just curious, is this a normal device ID for AR9381 chips or is
>> this some kind of wrongly programmed EEPROM of TD-W8970?
>>
>> ath9k driver knows nothing about the 0xABCD device. And according to
>> wikidevi [1], the normal DevID for AR9381 based devices is 0x0030.
>>
>> 1. https://wikidevi.wi-cat.ru/Alpha_Networks_WMC-N02
>>
>
> Hi,
>
> Thanks for pointing this out.
> It could be that I broke something in the EEPROM on this device
> accidentally, I use it for testing since some time. It could also be
> that the PCIe controller driver is broken, it is not upstream and not
> looking nice.
>
> Hauke
>
>
> Here is the output:
> ---
> root@OpenWrt:/# lspci -v -n
> 00:00.0 0604: 1bef:0011 (rev 01) (prog-if 00 [Normal decode])
> Device tree node:
> /sys/firmware/devicetree/base/fpi@1000/pcie@d90/pcie@0
> Flags: bus master, fast devsel, latency 0, IRQ 144
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: [disabled]
> Memory behind bridge: 1c00-1c0f [size=1M]
> Prefetchable memory behind bridge: 1c10-1c1f [size=1M]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
> Capabilities: [70] Express Root Port (Slot-), MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Power Budgeting
> Kernel driver in use: pcieport
> lspci: Unable to load libkmod resources: error -12
>
> 01:00.0 0200: 168c:abcd (rev 01)
> Device tree node:
> /sys/firmware/devicetree/base/fpi@1000/pcie@d90/pcie@0/wifi@168c,002e
> Flags: bus master, fast devsel, latency 0, IRQ 144
> Memory at 1c00 (64-bit, non-prefetchable) [size=128K]
> Expansion ROM at 1c10 [virtual] [disabled] [size=64K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
> Capabilities: [70] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [300] Device Serial Number 00-00-00-00-00-00-00-00
> Kernel driver in use: ath9k
> ---
>
> This is the kernel log:
>
> [ 23.735405] ifx_pcie_bios_map_irq port 0 dev :01:00.0 slot 0 pin 1
> [ 23.740723] ifx_pcie_bios_map_irq dev :01:00.0 irq 144 assigned
> [ 23.746963] ath9k :01:00.0: enabling device ( -> 0002)
> [ 23.753378] ath9k :01:00.0: Direct firmware load for
> ath9k-eeprom-pci-:01:00.0.bin failed with error -2
> [ 23.762891] ath9k :01:00.0: Falling back to sysfs fallback for:
> ath9k-eeprom-pci-:01:00.0.bin
> [ 24.599413] ieee80211 phy0: Atheros AR9300 Rev:3 mem=0xbc00, irq=144
>
Most probably the chip calibration data is Ok, the chip just has no
access to it and utilizes the default DevID value.
Upstream ath9k knows nothing about the 0xABCD device, but our mac80211
package has a special patch for this case:
mac80211 $ grep -rni abcd *
patches/ath9k/513-ath9k_add_pci_ids.patch:17:+#define
AR9300_DEVID_INVALID 0xabcd
patches/ath9k/513-ath9k_add_pci_ids.patch:27:+ { PCI_VDEVICE(ATHEROS,
0xabcd) }, /* PCI-E internal chip default ID */
Commit that introduced the patch has no additional evidences:
mac80211 $ git log -n1 3251cddf31e
commit 3251cddf31efc23089da6f25f97655beaa1f5950
Author: John Crispin
Date: Thu Jul 25 20:28:45 2013 +
mac8021: add ath9k pcie id for AR9381
So I am in doubt. On one hand, 0xABCD is a real ID that is returned by
the AR9381 chip when it has no attached EEPROM or the OTP data. On the
other hand, this is an ID of an invalid state. And I do not know how
many other Atheros chip models return it. Most probably your patch is
the best solution which we can implement at the moment. Since it is
better to have an almost accurate description than "Unknown device" :)
Could you just add some notes to the commit message to clarify that
0xABCD is the unusual Device ID that
Re: [PATCH 1/2] devices: Add Atheros AR9381
On 1/18/22 23:38, Sergey Ryazanov wrote: Hello Hauke, On Mon, Jan 17, 2022 at 12:35 AM Hauke Mehrtens wrote: This adds the Atheros AR9381 to the devices list. This card was found in the TP-LINK TD-W8970. Signed-off-by: Hauke Mehrtens --- devices.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/devices.txt b/devices.txt index e6c18e6..3cec45a 100644 --- a/devices.txt +++ b/devices.txt @@ -172,6 +172,7 @@ 0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984" 0x168c 0x0050 0x 0x0 0 "Qualcomm Atheros" "QCA9887" 0x168c 0x0056 0x 0x0 0 "Qualcomm Atheros" "QCA9886" +0x168c 0xabcd 0x 0x0 0 "Atheros" "AR9381" I am just curious, is this a normal device ID for AR9381 chips or is this some kind of wrongly programmed EEPROM of TD-W8970? ath9k driver knows nothing about the 0xABCD device. And according to wikidevi [1], the normal DevID for AR9381 based devices is 0x0030. 1. https://wikidevi.wi-cat.ru/Alpha_Networks_WMC-N02 Hi, Thanks for pointing this out. It could be that I broke something in the EEPROM on this device accidentally, I use it for testing since some time. It could also be that the PCIe controller driver is broken, it is not upstream and not looking nice. Hauke Here is the output: --- root@OpenWrt:/# lspci -v -n 00:00.0 0604: 1bef:0011 (rev 01) (prog-if 00 [Normal decode]) Device tree node: /sys/firmware/devicetree/base/fpi@1000/pcie@d90/pcie@0 Flags: bus master, fast devsel, latency 0, IRQ 144 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: 1c00-1c0f [size=1M] Prefetchable memory behind bridge: 1c10-1c1f [size=1M] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [70] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Power Budgeting Kernel driver in use: pcieport lspci: Unable to load libkmod resources: error -12 01:00.0 0200: 168c:abcd (rev 01) Device tree node: /sys/firmware/devicetree/base/fpi@1000/pcie@d90/pcie@0/wifi@168c,002e Flags: bus master, fast devsel, latency 0, IRQ 144 Memory at 1c00 (64-bit, non-prefetchable) [size=128K] Expansion ROM at 1c10 [virtual] [disabled] [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [300] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: ath9k --- This is the kernel log: [ 23.735405] ifx_pcie_bios_map_irq port 0 dev :01:00.0 slot 0 pin 1 [ 23.740723] ifx_pcie_bios_map_irq dev :01:00.0 irq 144 assigned [ 23.746963] ath9k :01:00.0: enabling device ( -> 0002) [ 23.753378] ath9k :01:00.0: Direct firmware load for ath9k-eeprom-pci-:01:00.0.bin failed with error -2 [ 23.762891] ath9k :01:00.0: Falling back to sysfs fallback for: ath9k-eeprom-pci-:01:00.0.bin [ 24.599413] ieee80211 phy0: Atheros AR9300 Rev:3 mem=0xbc00, irq=144 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] devices: Add Atheros AR9381
Hello Hauke, On Mon, Jan 17, 2022 at 12:35 AM Hauke Mehrtens wrote: > This adds the Atheros AR9381 to the devices list. This card was found in > the TP-LINK TD-W8970. > > Signed-off-by: Hauke Mehrtens > --- > devices.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/devices.txt b/devices.txt > index e6c18e6..3cec45a 100644 > --- a/devices.txt > +++ b/devices.txt > @@ -172,6 +172,7 @@ > 0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984" > 0x168c 0x0050 0x 0x0 0 "Qualcomm Atheros" "QCA9887" > 0x168c 0x0056 0x 0x0 0 "Qualcomm Atheros" "QCA9886" > +0x168c 0xabcd 0x 0x0 0 "Atheros" "AR9381" I am just curious, is this a normal device ID for AR9381 chips or is this some kind of wrongly programmed EEPROM of TD-W8970? ath9k driver knows nothing about the 0xABCD device. And according to wikidevi [1], the normal DevID for AR9381 based devices is 0x0030. 1. https://wikidevi.wi-cat.ru/Alpha_Networks_WMC-N02 -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD
On Mon, Jan 17, 2022 at 11:52 AM Denis K wrote: >> I'm seeing this in the bootlogs when using this patch: >> >> [5.183305] gpio-latch gpio_latch: failed to get gpio 7: -517 >> [5.235889] rb91x-nand nand_gpio: failed to get gpios: -517 > > It's okay. The gpio-latch probe function seems to be called before the > rb91x-key probe, but it also returns EPROBE_DEFER (-517), so it will > be called later. Nice catch! Will it be a good idea to avoid printing the error messages from the gpio-latch/rb91x-nand drivers in case of EPROBE_DEFER? Looks like this will help to avoid noise in the dmesg and users confusion. I do not mean doing this immediately in this series, but maybe somedays this will be a welcome change? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Proposed reviewers to include in patches
Hello Mauri, On Mon, Jan 17, 2022 at 5:11 PM Mauri Sandberg wrote: > I sent a patch set for review two months back but I am yet to receive > any comments, ack/nack. Maybe nobody took action since I did not Cc: > anyone specifically. > > Are there ppl who normally carry out reviews or should I just resend the > patch set? Generally, this is a good idea to include people who are involved in a particular component development to the CC list. You could check the committer field of git log --pretty=full to grab a list of involved devs. And even with filled CC, a patch can be overlooked. A month ago I tried to raise a discussion on IRC about a good practice on how to draw some attention to submitted patches. After that discussion I started thinking that most devs are Ok if a submitter "pings" them once a week. So just reply to your initial submission with a "gentle ping" to bump your patch in the list. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath10k_ct firmware crashes
On 1/18/22 4:29 AM, Koen Vandeputte wrote: Hi Ben, After stress testing some wave 1 2x2 radios on multiple boards using openwrt master I noticed this crash on 2 of them. Any idea? 01:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter Thanks, Koen [ 16.441327] ath10k 5.15 driver, optimized for CT firmware, probing pci device: 0x3c. [ 16.468523] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0 [ 17.719409] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043222ff sub 19b6:d042 [ 17.728819] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 tracing 0 dfs 1 testmode 0 [ 17.740820] ath10k_pci :01:00.0: firmware ver 10.1-ct-8x-__fH-022-ecad3248 api 2 features wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,txrate-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 1b2a161c [ 18.063728] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 18.993270] ath10k_pci :01:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [ 19.011087] ath10k_pci :01:00.0: wmi print 'P 128 V 8 T 410' [ 19.017226] ath10k_pci :01:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0' [ 19.025374] ath10k_pci :01:00.0: wmi print 'alloc rem: 25000 iram: 38944' [ 19.082086] ath10k_pci :01:00.0: htt-ver 2.2 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1 [ 19.097374] ath10k_pci :01:00.0: NOTE: Firmware DBGLOG output disabled in debug_mask: 0x1000 [ 19.228812] ath: EEPROM regdomain sanitized [ 19.228825] ath: EEPROM regdomain: 0x64 [ 19.228830] ath: EEPROM indicates we should expect a direct regpair map [ 19.228849] ath: Country alpha2 being used: 00 [ 19.228854] ath: Regpair used: 0x64 [ 19.282229] usbcore: registered new interface driver option [ 19.288009] usbserial: USB Serial support registered for GSM modem (1-port) [ 19.318937] usbcore: registered new interface driver qcserial [ 19.324852] usbserial: USB Serial support registered for Qualcomm USB modem [ 19.342601] qcserial 2-1:1.0: Qualcomm USB modem converter detected [ 19.349298] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB0 [ 19.359080] qcserial 2-1:1.2: Qualcomm USB modem converter detected [ 19.365777] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB1 [ 19.389826] qcserial 2-1:1.3: Qualcomm USB modem converter detected [ 19.396484] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB2 [ 19.429616] kmodloader: done loading kernel modules from /etc/modules.d/* [ 26.341428] eth0: link up (1000Mbps/Full duplex) [ 26.346711] br-wan: port 1(eth0) entered blocking state [ 26.352077] br-wan: port 1(eth0) entered disabled state [ 26.357631] device eth0 entered promiscuous mode [ 26.375076] br-wan: port 1(eth0) entered blocking state [ 26.380431] br-wan: port 1(eth0) entered forwarding state [ 32.696768] ag71xx: max retries for SGMII fixup exceeded [ 32.702172] eth1: link up (1000Mbps/Full duplex) [ 32.727999] br-wan: port 2(eth1) entered blocking state [ 32.733310] br-wan: port 2(eth1) entered disabled state [ 32.738882] device eth1 entered promiscuous mode [ 32.808555] br-wan: port 2(eth1) entered blocking state [ 32.813867] br-wan: port 2(eth1) entered forwarding state [ 37.660591] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 85.293759] ath10k_pci :01:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [ 85.311655] ath10k_pci :01:00.0: wmi print 'P 128 V 8 T 410' [ 85.317869] ath10k_pci :01:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0' [ 85.326004] ath10k_pci :01:00.0: wmi print 'alloc rem: 25000 iram: 38944' [ 85.398523] ath10k_pci :01:00.0: pdev param 0 not supported by firmware [ 85.413584] ath10k_pci :01:00.0: rts threshold -1 [ 85.428114] device wlan0 entered promiscuous mode [ 85.435115] device wlan0 left promiscuous mode [ 5578.497296] ath10k_pci :01:00.0: Failed to synchronize setup for vdev 0 restart 0: -145, will restart firmware [ 5578.507831] ath10k_pci :01:00.0: failed to start vdev 0 addr 00:00:00:00:00:00 on freq 5320: -145 [ 5578.518005] ath10k_pci :01:00.0: firmware crashed! (guid b696878d-15a0-434c-9d17-81052d629e31) Firmware/hardware hung, so we faked a crash to restart it. I doubt I can do anything to fix/improve this. I assume the radio's came back up OK after they crashed? In general, wave-2 ath10k-ct seems more stable if you have a choice. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mvebu: cortexa9: Fix board.d/01_leds
Fix syntax error in the case statement
Fixes: 9149ed4f05f8 ("mvebu: cortexa9: Add support for Ctera C200-V2")
Signed-off-by: Klaus Kudielka
---
target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
b/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
index 161d111ea..2b045d094 100644
--- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
+++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
@@ -11,7 +11,7 @@ board=$(board_name)
boardname="${board##*,}"
case "$board" in
-ctera,c200-v2
+ctera,c200-v2)
ucidef_set_led_usbport "usb2" "USB2" "green:usb-2" "usb1-port1"
"usb2-port1"
ucidef_set_led_usbport "usb3" "USB3" "green:usb-1" "usb1-port2"
"usb2-port2"
;;
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH,opkg-lede] opkg_remove: avoid remove pkg repeatly with option --force-removal-of-dependent-packages
Hello OpenWrt devs, Here an example of CI failure this patch fixes: https://github.com/openwrt/packages/runs/4427963136?check_suite_focus=true Anything I can do to have this patch included ? Best, Etienne Le dim. 12 sept. 2021 à 18:31, Etienne Champetier a écrit : > > + @Jo-Philipp Wich > > Tested using mvebu target removing librt > > Le mar. 7 sept. 2021 à 18:42, Etienne Champetier > a écrit : > > > > From: Hongxu Jia > > > > While remove pkg with '--force-removal-of-dependent-packages', > > pkg may be added to pkgs remove list multiple times, add status > > check to make sure pkg only be removed once. > > > > Signed-off-by: Hongxu Jia > > Signed-off-by: Paul Barker > > (Cherry picked from > > https://git.yoctoproject.org/cgit/cgit.cgi/opkg/commit/?id=e8996180833aa35d101fbeadec3d787ce0bbda5c) > > (Fixes https://dev.archive.openwrt.org/ticket/18320 and openwrt/packages CI) > > --- > > libopkg/opkg_remove.c | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/libopkg/opkg_remove.c b/libopkg/opkg_remove.c > > index 96ca558..c2abf81 100644 > > --- a/libopkg/opkg_remove.c > > +++ b/libopkg/opkg_remove.c > > @@ -249,6 +249,14 @@ int opkg_remove_pkg(pkg_t * pkg, int from_upgrade) > > if ((parent_pkg = pkg->parent) == NULL) > > return 0; > > > > + /* While remove pkg with '--force-removal-of-dependent-packages', > > + pkg may be added to remove list multiple times, add status > > + check to make sure pkg only be removed once. */ > > + if (conf->force_removal_of_dependent_packages && > > + pkg->state_flag & SF_FILELIST_CHANGED && > > + pkg->state_status == SS_NOT_INSTALLED) > > + return 0; > > + > > /* only attempt to remove dependent installed packages if > > * force_depends is not specified or the package is being > > * replaced. > > -- > > 2.31.1 > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Hi all, Thanks for the active discussion. My thoughts on the three topics bug tracker, CI and Git _root_. ## Bug Tracker I looked today into migrating issues from bugs.openwrt.org over to GitHub.com, codeberg.org (GiTea) and todo.sr.ht (Sourcehut). The migration path is somewhat easy extending the fly-build-csv[1] to export tickets and comments from a Flyspray SQL dump. The resulting tasks.csv and comments.csv can be exported to the bug tracker of choice. While sr.ht allows to import the large collection of issues, each message is limited to about 16.000 characters which would require us to truncate existing tasks and comments (and instead have them on some paste service). This limit is likely tied to the first class email support, users without an account can write to a special email address and create tickets without registering at all. Try it by sending something to ~aparcar/openwrt-bugs-import-tes...@todo.sr.ht Apart from that there (might be) are minor bugs which is totally understandable since sr.ht is still considered Alpha[2]. I’d prefer to give it more time before considering moving over there. If we decide to move there, tools like gh2srht[3] would allow a quick migration. To get a feel what the bug tracker over at sr.ht would look like I migrated as much as possible, feel free to have a look[4]. Migrating existing issues to GitHub seems unfeasible, while it’s technically possible[5] their rate limits prevent me (or a bot account) to effectively transport open issues and comments. In case we choose GitHub, a static version of bugs.openwrt.org should stay online. Lastly I looked at codeberg.org which runs Gitea(.com) under the hood. From my understanding it’s a German _registered association_ (eingetragener Verein) with the goal to provide code hosting - great. Their API is well documented[5] and in no time at all I migrated some 4000 issues including comments[6]. It looks and feels like GitHub with some extra buttons, like you can assign issues to specific branches! A quick bug tracker conclusion, I’d be happy to use codeberg.org for issue tracking. Both sr.ht and codeberg.org are FOSS, GitHub not so much. It's possible to migrate all existing issues to codeberg and turn off bugs.openwrt.org entirely, no need to host a static copy. They also allow to login via GitLab.com and GitHub.com accounts lowering the bar for user to participate. If this seems a feasible option I’d rework the migration script and create them with a bot account, including username and time/date in the issues. As an immediate action, we might as well close down bugs.openwrt.org and open issues on GitHub.com without any migration of existing issues. Both users and developers already know the workflows over there and issues have a higher visibility. A migration away from GitHub over to coderberg or sr.ht is possible with much less effort than migrating away from flyspray. ## CI Codeberg does not offer any CI at all except an integration for a self hosted Drone CI setup[7]. That setup would keep the burden of server maintenance on our side, which makes it unfeasible. On the other hand sr.ht offers excellent CI in many flavors[8] (except macOS) which even allows to login on runners to manually debug failed runs. On all machines it’s possible to install Docker and run our own containers or trust in the package stability of Debian et al. I tested it in the past and it works great[9]. GitHub offers free CI which is already heavily used from our side. The package.git repository ran about 11.000 times since I added it in September 2020. They offer up to 40 parallel running jobs which could even take over snapshot building (about 2 hours per target). A quick CI conclusion, I’d start using GitHub CI for openwrt.git since we’re burning plenty of CPU and I don’t want to annoy sr.ht users and maintainers by flooding their infrastructure. In practice that would mean we have a folder called .github/ in our repository. However, we could also use some of the donated money and donate it ourselves to sr.ht hoping they invest in more CI runners. ## Git _root_ We’re currently maintaining multiple servers to host our many Git repositories (GitHub is just a mirror). Instead we could move to one of the three services and use them as our Git _root_. From what I know sr.ht does not offer any organization accounts for now, we’d have to use a shared one until it’s implemented. Codeberg and GitHub do support organizations. Sourcehut devs are the only ones thinking about supporting pre-commit hooks to allow "Signed-of-by” checks and more, something we have on git.openwrt.org. A workaround for Codeberg and Github is to disable direct pushes and only ever allow merging of PRs, which is a bit of a sad workflow downgrade. All three of them support 2FA, Codeberg support U2F and soon FIDO2[10], GitHub support FIDO2. All three play fine with in issue references in commit messages,
ath10k_ct firmware crashes
Hi Ben, After stress testing some wave 1 2x2 radios on multiple boards using openwrt master I noticed this crash on 2 of them. Any idea? 01:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter Thanks, Koen [ 16.441327] ath10k 5.15 driver, optimized for CT firmware, probing pci device: 0x3c. [ 16.468523] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0 [ 17.719409] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043222ff sub 19b6:d042 [ 17.728819] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 tracing 0 dfs 1 testmode 0 [ 17.740820] ath10k_pci :01:00.0: firmware ver 10.1-ct-8x-__fH-022-ecad3248 api 2 features wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,txrate-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 1b2a161c [ 18.063728] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 18.993270] ath10k_pci :01:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [ 19.011087] ath10k_pci :01:00.0: wmi print 'P 128 V 8 T 410' [ 19.017226] ath10k_pci :01:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0' [ 19.025374] ath10k_pci :01:00.0: wmi print 'alloc rem: 25000 iram: 38944' [ 19.082086] ath10k_pci :01:00.0: htt-ver 2.2 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1 [ 19.097374] ath10k_pci :01:00.0: NOTE: Firmware DBGLOG output disabled in debug_mask: 0x1000 [ 19.228812] ath: EEPROM regdomain sanitized [ 19.228825] ath: EEPROM regdomain: 0x64 [ 19.228830] ath: EEPROM indicates we should expect a direct regpair map [ 19.228849] ath: Country alpha2 being used: 00 [ 19.228854] ath: Regpair used: 0x64 [ 19.282229] usbcore: registered new interface driver option [ 19.288009] usbserial: USB Serial support registered for GSM modem (1-port) [ 19.318937] usbcore: registered new interface driver qcserial [ 19.324852] usbserial: USB Serial support registered for Qualcomm USB modem [ 19.342601] qcserial 2-1:1.0: Qualcomm USB modem converter detected [ 19.349298] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB0 [ 19.359080] qcserial 2-1:1.2: Qualcomm USB modem converter detected [ 19.365777] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB1 [ 19.389826] qcserial 2-1:1.3: Qualcomm USB modem converter detected [ 19.396484] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB2 [ 19.429616] kmodloader: done loading kernel modules from /etc/modules.d/* [ 26.341428] eth0: link up (1000Mbps/Full duplex) [ 26.346711] br-wan: port 1(eth0) entered blocking state [ 26.352077] br-wan: port 1(eth0) entered disabled state [ 26.357631] device eth0 entered promiscuous mode [ 26.375076] br-wan: port 1(eth0) entered blocking state [ 26.380431] br-wan: port 1(eth0) entered forwarding state [ 32.696768] ag71xx: max retries for SGMII fixup exceeded [ 32.702172] eth1: link up (1000Mbps/Full duplex) [ 32.727999] br-wan: port 2(eth1) entered blocking state [ 32.733310] br-wan: port 2(eth1) entered disabled state [ 32.738882] device eth1 entered promiscuous mode [ 32.808555] br-wan: port 2(eth1) entered blocking state [ 32.813867] br-wan: port 2(eth1) entered forwarding state [ 37.660591] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 85.293759] ath10k_pci :01:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [ 85.311655] ath10k_pci :01:00.0: wmi print 'P 128 V 8 T 410' [ 85.317869] ath10k_pci :01:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0' [ 85.326004] ath10k_pci :01:00.0: wmi print 'alloc rem: 25000 iram: 38944' [ 85.398523] ath10k_pci :01:00.0: pdev param 0 not supported by firmware [ 85.413584] ath10k_pci :01:00.0: rts threshold -1 [ 85.428114] device wlan0 entered promiscuous mode [ 85.435115] device wlan0 left promiscuous mode [ 5578.497296] ath10k_pci :01:00.0: Failed to synchronize setup for vdev 0 restart 0: -145, will restart firmware [ 5578.507831] ath10k_pci :01:00.0: failed to start vdev 0 addr 00:00:00:00:00:00 on freq 5320: -145 [ 5578.518005] ath10k_pci :01:00.0: firmware crashed! (guid b696878d-15a0-434c-9d17-81052d629e31) [ 5578.527126] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043222ff sub 19b6:d042 [ 5578.536571] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 tracing 0 dfs 1 testmode 0 [ 5578.548738] ath10k_pci :01:00.0: firmware ver 10.1-ct-8x-__fH-022-ecad3248 api 2 features wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 1b2a161c [ 5578.578143] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 5578.585563] ath10k_pci :01:00.0: htt-ver
Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD
On 17.01.22 09:51, Denis K wrote: I'm seeing this in the bootlogs when using this patch: [5.183305] gpio-latch gpio_latch: failed to get gpio 7: -517 [5.235889] rb91x-nand nand_gpio: failed to get gpios: -517 I still think this should be avoided somehow. It's okay. The gpio-latch probe function seems to be called before the rb91x-key probe, but it also returns EPROBE_DEFER (-517), so it will be called later. I've tested master with reset key patch and Koen's patch that sets ref clock freq to 2500. All is working: nand, leds, key and Gigabit Ethernet (setting 100 -- pings okay, setting back 1000 -- pings still okay). Should I delete from my rb91x-key patch support for kernel 5.4 and submit v2? Please do :-) Thanks, Denis Thanks! Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
