00:35 <owrt-2203-builds> Build [#110](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/63/builds/110) of `at91/sama7` failed.

02:25 <\x> jayk: well what i meant was you see you normally use 80MHz on 5GHz right? with that much devices you can do 20MHz and still cover the whole spectrum :p

03:10 <mrnuke> hurricos: broadcom! lovely!

05:29 <owrt-snap-builds> Build [#632](https://buildbot.openwrt.org/master/images/#builders/54/builds/632) of `ramips/mt7620` failed.

06:11 <KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (100.0% images and 99.9% packages reproducible in our current test framework.)

07:25 <dwfreed> russell--: it does

07:25 <dwfreed> dunno how it looks on 21.02+, because I'm lazy and still on 19.07

07:27 <stintel> I only use LuCI for the realtime graphs and other fancy stats :P

08:02 <russell--> i have a user would would prefer a gui to help them do with complex vlan'ing, and i sort of assumed that there would be something like that for dsa switch land, and am not finding it

08:03 <russell--> deal* with

08:06 <dwfreed> as I understand it, DSA-land is a far bit more complex on the luci side of things

08:06 <dwfreed> s/far/fair/

08:10 <russell--> showing the ports and their tagging status associated with a bridge-vlan was what i was looking for. what i see instead is a bewildering bunch of devices with no indication of which bridge-vlan they are associated with.

08:11 <russell--> the CLI is much more coherent and understandabe

08:11 <russell--> so, i guess i'm questioning the effort i'm putting into getting luci on these devices, if it doesn't actually help.

08:55 <f00b4r0> russell--: https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa#swconfig_dsa_vlan_configuration_comparison

11:52 <arnd> noltari, mkresin, hauke: I'm looking at converting the last four upstream clk drivers to common-clk. I already have patches for superh and coldfire, so now I'm looking at lantiq and bcm63xx. Not sure I can do the lantiq one blindly, but bcm63xx seems doable.

11:54 <arnd> any suggestions for either one? I see that there is already drivers/clk/bcm/clk-bcm63xx-gate.c for bcm63xx in the bmips-generic variant, which seems to duplicate the one in arch/mips/bcm63xx/clk.c, so I'm not sure if doing another port of the old driver makes sense or if I should just make it use the new driver

12:03 <russell--> f00b4r0: wholy crap, that was what i needed to find the interface, thank you!

12:15 <oliv3r[m][m]> Hi, I'm trying to build a kernel with DEVMEM enabled for debugging; I went into `make kernelmenuconfig` and enabled the option. The option IS visible in my `target/linux/realtek/rtl9302/config-5.10` as it should; but no matter what i try and what i wipe, it never actually gets enabled (which is evident from the multitude of .config files under build_dir/target/ ..../.config.*;

12:15 <oliv3r[m][m]> How can I coerce openwrt build to actually honor my CONFIG_ option?

12:15 <robimarko> For devmem you have to enable it through menuconfig under kernel options as well

12:16 <robimarko> As that will override whatever is set in the kconfig

12:17 <oliv3r[m][m]> ohh, ok that's not confusing :D

12:18 <robimarko> Yeah, its a bit confusing

12:19 <robimarko> But that is one of the generic things that is exposed in openwrt menuconfig so you dont have to change kernel config itself

12:20 <oliv3r[m][m]> so how do I do that, because 'kernel' is just a `---` with an an arrow and nothing I can select there. Kernel modules however is optional

12:20 <oliv3r[m][m]> nvm; I just did a / on DEVMEM that found the right place

12:21 <oliv3r[m][m]> (global build settings -> kernel options -> devmem)

12:26 <oliv3r[m][m]> that seems to have done the trick :) thank you robimarko

12:52 <hauke> arnd: I think xdarklight started with a clk driver for lantiq

12:53 <arnd> ah, nice. That would definitely help

13:06 <arnd> I found https://github.com/xdarklight/linux/commits/lantiq-clk-20160620 now, but it's six years old now, so probably nontrivial to port

13:24 <hauke> arnd: it depends on how this port is done, the current clk driver is not really matching all the HW, it only provides some bits we have to change from Linux

13:25 <hauke> the driver does not build up the none trivial clock tree

14:32 <KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 99.9% packages reproducible in our current test framework.)

17:24 <nick[m]1234> hauke: found a way to fix the sdk, however I am not very happy with it https://github.com/openwrt/openwrt/pull/10458

17:27 <hauke> nick[m]1234: do you know which change breaks it?

17:34 <nick[m]1234> hauke: it is the parsing of the parameters that fail. I used the docker container to reproduce the issue however it is horrible slow on my machine. So I did have the time to try everything. Also Corona hit me. :/ Just wanted to fix the master. I will have a look again when I'm healthy again.

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

21:34 <Tapper1> nick[m]1234 get well soon mate.

23:44 <owrt-snap-builds> Build [#633](https://buildbot.openwrt.org/master/images/#builders/54/builds/633) of `ramips/mt7620` completed successfully.