06:17 <blocktrron> djfe: it is not a silicon bug

06:28 <djfe> 🤔

06:34 <djfe> I didn't want to introduce any false information, sorry. I quoted from the replies but don't know it better myself. Thanks for correcting me

07:26 <Christophe[m]1> Hey, I started enabling UBSAN in my builds a while ago. When it found a shift-out-of-bounds issue in drivers/clk/mediatek/clk-mux.c, I got in touch with Sergio Paracuellos an he submitted a fix: https://lkml.org/lkml/2023/2/6/165

07:28 <Christophe[m]1> There's a similar issue on mediatek and I fixed it in a similar fashion. https://paste.centos.org/view/2f8a787c

07:31 <Christophe[m]1> Should I get in touch with Owen Chen of Mediatek who contributed this code?

08:04 <KanjiMonster> Christophe[m]1: that fix looks wrong, AFAICT from the code the gate_shift is supposed to have a bit index, not a mask, especially seeing as it is a u8 (so the highest bit you could address would be bit 7 if it were a mask). Also look at the users of the MUX_GATE_* macros, they pass a value <= 31 as the 9th argument (the gate shift value)

08:09 <KanjiMonster> Christophe[m]1: the issue likely comes from mux clocks defined via the MUX_FLAGS() macro, which initialized gate_shift to -1 (aka 255 as u8)

08:10 <KanjiMonster> (as well as the MUX() macro)

08:16 <KanjiMonster> also the MUX_CLR_SET_UPD() macro passing a fixed 0 for gate_shift feels wrong, and might have intended to disable gating for that clock

08:26 <Christophe[m]1> Let me revert my patch and get all three ubsan warnings.

08:26 <Christophe[m]1> Thanks for having a look

08:29 <KanjiMonster> clk-mux.c already provides different ops for gateable and non-gatable mux clocks; so the core issue seems to be that non-gateable clocks use the gateable ops

08:42 <KanjiMonster> so yeah, the proper fix would be to figure out where the 255/-1 comes from, and why the wrong ops are used

08:45 <Christophe[m]1> Here are all three warnings: https://paste.centos.org/view/f73da55c

08:49 <KanjiMonster> Christophe[m]1: unfortunately these don't tell us which clock this is with the wrong gate_shift / ops

08:56 <KanjiMonster> Christophe[m]1: maybe put a printk in https://elixir.bootlin.com/linux/latest/source/drivers/clk/mediatek/clk-mux.c#L157 with a check for mux->gate_shift > 31 and print the clock name, that should make it easy to find

09:20 <Christophe[m]1> It's these: https://paste.centos.org/view/d5bc3bb2 https://elixir.bootlin.com/linux/v6.1.37/source/drivers/clk/mediatek/clk-mt7986-infracfg.c#L40

09:31 <bluecmd[m]> robimarko: Hi, got your comment in https://github.com/openwrt/openwrt/pull/13038#discussion_r1250528054 re. AutoLoad vs AutoProbe. I belive for our use case it is fine to do AutoProbe, I was merely cargo-culting the other sensors which uses a whole lot of AutoLoad. Do you know if this was a problem in the past or why it's so prevelent to use AutoLoad?

09:32 <bluecmd[m]> Seems like the load order should be handled by the kernel and device tree resolution

09:32 <robimarko> That is why AutoProbe is prefered, as it will get loaded only when needed

09:32 <robimarko> With AutoLoad you are loading the module regardless

09:32 <bluecmd[m]> Yes, that seems wrong indeed. Thanks for spotting that

09:32 <robimarko> Its usually used only for things that dont have a probing mechanism or are not DT aware

09:34 <Christophe[m]1> KanjiMonster: Should it be MUX_CLR_SET_UPD instead of MUX_GATE_CLR_SET_UPD?

09:39 <KanjiMonster> Christophe[m]1: that sounds like it should do the trick

09:41 <KanjiMonster> it also passes -1 for upd_shift, but upd_shift is s8, and there is a check for it, so that part should be fine

09:45 <Christophe[m]1> ubsan warnings are gone and no occurrences of gate_shift>31 :-D

10:57 <Christophe[m]1> KanjiMonster: Thanks for stepping in. Iearned new things today (:

10:57 <KanjiMonster> you're welcome :)

13:34 <RoganDawes> Hi folks. Can anyone help me work through configuring a build for the Wink Hub v1?

13:36 <RoganDawes> I have managed to add an entry in the menuconfig, (https://hastebin.com/share/irihurazon.go), but I'm trying to figure out how to add target-specific kernel options, as well as end up with a ubifs root

13:38 <RoganDawes> I have also built a basic device tree which has the NAND partitions, serial console, and a couple of other peripherals. Once I can get a build going, I will then flesh out the DTS with the SDIO wifi device, etc

13:42 <PaulFertser> RoganDawes: the kernel is common for the whole target (or subtarget).

13:43 <PaulFertser> RoganDawes: usually OpenWrt is meant to be used with squashfs root, to have some solid state which can always be returned to (with generic reset or generic failsafe), and ubifs (or jffs2) is used as a r/w overlay.

13:44 <PaulFertser> RoganDawes: often times the easiest way to start with the port is to build initramfs images (where all the system is included in the kernel image, so no rootfs is needed at all) and load them directly with a bootloader.

13:49 <RoganDawes> PaulFertser: ok, thanks for this info. So, if I want to add SDIO wifi to the imx28 target, I would change target/linux/mxs/config-5.15 ?

13:51 <RoganDawes> The good news is that my partition layout is quite generous - I have 8MB for my "kernel", so I should be able to include a ramdisk there quite easily, I think. One complication is that I *think* my U-Boot build may be missing support for FIT images

13:53 <RoganDawes> does it make sense to have the root filesystem as an initramfs, with mutable content in the ubifs? Or is that an unnecessary waste of RAM (I do have 64MB, but not really enough to be wasteful with)

13:55 <PaulFertser> RoganDawes: OpenWrt uses wireless kernel backports for all wireless drivers, so you'd need to add another kmod to package/kernel/mac80211

13:55 <PaulFertser> RoganDawes: (initramfs + overlay) that's too uncommon so I would suggest you first stick to the way OpenWrt works on most devices currently.

13:56 <RoganDawes> makes sense

13:57 <RoganDawes> PaulFertser: so how would I enable the BRCMFMAC driver?

14:00 <RoganDawes> DEVICE_PACKAGES := kmod-ubifs kmod-brcmfmac ?

14:05 <tmn505> yes, but don't forget the proper firmware, I assume it's cypress-firmware-43430-sdio. Also nvram file is usually necessary, You can copy it from vendor image and place it in appropriate directory structure in target/mxs/base-files.

15:32 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (95.9% images and 99.9% packages reproducible in our current test framework.)

17:54 <RoganDawes> tmn505: Cool, I now have DEVICE_PACKAGES := kmod-brcmfmac cypress-firmware-43430-sdio cypress-firmware-43430-sdio cypress-firmware-43455-sdio cypress-firmware-43430-sdio cypress-firmware-43455-sdio cypress-firmware-43455-sdio :-)

17:55 <RoganDawes> sigh, just noticed that there was a lot of repetition. Only two actual firmwares

17:57 <RoganDawes> and actually a lot more, just none that appeared to be in use. Let's see how that works.

18:15 <RoganDawes> ok, so I was able to build the image, but the load address seems to be a bit off.

18:15 <RoganDawes> file bin/targets/mxs/generic/openwrt-mxs-generic-wink_hub_v1-initramfs-kernel.bin

18:15 <RoganDawes> bin/targets/mxs/generic/openwrt-mxs-generic-wink_hub_v1-initramfs-kernel.bin: u-boot legacy uImage, ARM OpenWrt Linux-5.15.117, Linux/ARM, OS Kernel Image (lzma), 4599133 bytes, Thu Jun 22 22:21:48 2023, Load Address: 0xFFFFFFF2, Entry Point: 0xFFFFFFF2, Header CRC: 0xC8EB39E5, Data CRC: 0xF134EB79

18:16 <RoganDawes> the vendor image loads at around 0x40008000 or thereabouts

18:43 <PaulFertser> RoganDawes: when you boot you'll see in the kernel outputs what firmware it really needs.

18:53 <csharper2005> Has anyone else experienced wireguard performance degradation with 23.05? https://github.com/openwrt/openwrt/issues/13045

21:41 <RoganDawes> PaulFertser: how do I get openwrt to build an initramfs, and append it to the kernel? And should it be before or after the DTB?

23:17 <rotanid> we just noticed that 4b5bd1509195bc8f19999ebe481b59356b5c3512 unfortunately was not part of the 22.03.2 release notes or changelog, but it should have been. there is at least one device (Rocket M) in that commit which shouldn't have been moved to tiny at that time, because it has 64m memory in contrast to the 32m devices of that target.

23:31 <djfe> I'm preparing a PR rn for the rocket-m and powerbridge-m

23:31 <djfe> is PolynomialDivision/Nick Hainke available via IRC? (I don't know his nickname)

23:32 <djfe> I have a question regarding https://github.com/openwrt/openwrt/commit/a14170b6e9c8bab493c5e0e7689405a8a0675e8a

23:48 <djfe> Feedback is welcome https://github.com/openwrt/openwrt/pull/13047

23:51 <rotanid> thank you