03:05 <Mangix> https://github.com/openwrt/openwrt/pull/14918 is interesting

08:04 <rmilecki> hint: we now have LED_FUNCTION_WLAN_2GHZ and LED_FUNCTION_WLAN_5GHZ defines for per-band LEDs

08:04 <rmilecki> please start using them in .dts files when applicable :)

08:04 <rmilecki> (and LED_FUNCTION_WLAN_6GHZ too)

10:41 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)

12:58 <rmilecki> nbd: is there a chance to get some focus on https://github.com/openwrt/mt76/issues/865 ("mt7603: unstable traffic (stalls/hangs) under load (MT7603EN, MT7628AN)") ?

13:45 <oliv3r> robimarko: Based on the discussions, I've done https://github.com/openwrt/openwrt/pull/14913 . Hopefully that'll address some raised concerns and metioned pitfalls.

13:56 <nbd> rmilecki: don't have time for it at the moment

13:56 <nbd> rmilecki: but one thing you could try is check if things improve if you drop the rx loopback skbs instead of buffering them

13:58 <nbd> rmilecki: at the beginning of mt7603_rx_loopback_skb, just do dev_kfree_skb(skb) and return

14:01 <robimarko> oliv3r: Nice

14:01 <oliv3r> robimarko: I hope it helps :)

14:01 <oliv3r> and avoids more dredging discussions :p

14:05 <rmilecki> nbd: ah, great, thank you

14:05 <rmilecki> i will give it a try

15:31 <f00b4r0> oliv3r: to avoid further drama you might want to ping m-l about this ;P

15:54 <oliv3r> Who?

15:59 <f00b4r0> just the m-l. Maybe just reply to the thread you've already replied to?

17:23 <schmars[m]> most of the ramips/* targets snapshots haven't been rebuilt since 12-Mar

17:31 <zorun> it seems they are all failing except mt7620

17:32 <zorun> example: https://buildbot.openwrt.org/images/#/builders/61

20:17 <mrkiko> robimarko: regarding the mvebu kernel bump - it would be very nice to remove some uneeded code from the kernel - the one I've seen as an example is the turris support - turris_mox_*

20:18 <mrkiko> robimarko: I guess the correct solution is to build it as a package and ship it with the devices that actually needed it, not to all devices

20:37 <robimarko> mrkiko: I am yet to look at that PR

20:38 <mrkiko> robimarko: fine, just wanted your opinion - and if you happen to remember, once you might look at it, let me know. I can try to do that

20:38 <mrkiko> not particularly happy to see these mesages in my dmesg

20:52 <mrkiko> robimarko: do you think it's appropriate for me to say this in PRs comments?

21:01 <robimarko> mrkiko: Well, that boils down to the question if it really matters for mvebu

21:01 <robimarko> As there shouldnt really be size constaints

21:01 <mrkiko> robimarko: I tend to agree but this is a slippery slope in my opinion

21:02 <mrkiko> robimarko: I see it as a matter of connerctness - that change wasn't implemented at it should have been

21:02 <mrkiko> I would have seen it differently if - for example - I see that turris_mox doesn't support being built as module

21:03 <robimarko> What is the kernel symbol for Mox MCU driver?

21:04 <robimarko> I see it as a improvement point, but wouldnt really tie it to the kernel bump

21:04 <robimarko> As it should be version agnostic

21:05 <robimarko> If its tristate then it should be easy to package as kmod instead

21:18 <mrkiko> robimarko: oh no, I don't mean to tie it to the version bump absolutely

21:19 <mrkiko> the symbol is target/linux/mvebu/cortexa53/config-6.1:CONFIG_TURRIS_MOX_RWTM=y

21:20 <robimarko> Yeah, that is tristate and unless there is explicit need for it to load extremely early it looks convertable to kmod