04:23 <owrt-snap-builds> Build [#837](https://buildbot.openwrt.org/master/images/#builders/4/builds/837) of `x86/generic` completed successfully.

09:36 <karlp> Mangix: last message is more concerning: https://lore.kernel.org/all/20230314103316.313e5f61@kernel.org/

09:42 <aiyion> I'd like to take a look at googles mesh-set from 2017 and have considered backporting it to 22.03.

09:42 <jow> karlp: I defer that one to the original author of theu pdate

09:42 <aiyion> ist that worthwhile? Or is 23.xx nearer, than I think?

09:42 <jow> karlp: I did enough autoconf in the past ten years to know that the only viable change to anything autotools related is removing it

09:42 <aiyion> :D

09:43 <aiyion> / voice in the off: "and wiser words were not spoken that day"

09:43 <karlp> jow: soundsd good to me :) sorry for tagging you

09:44 <jow> anyone here a bit experienced with kernel flow offloading?

09:44 <jow> there's an ongoing bug report about broken offloading with pppoe in 22.03

09:45 <jow> the issue has been identified and is solvable by ensuring that only the pppoe device and not its underlying ethernet device are added to the flowtable, so instead of { wan, pppoe-wan, lan1, ... } it should only contain { pppoe-wan, lan1, ... }

09:45 <jow> this leads me to two thoughts...

09:46 <jow> 1) the above makes it conceptually impossible to use pppoe in conjunction with some other protocol directly on the same ethernet device (e.g. a static alias interface to reach the modem status page)

09:46 <jow> 2) shouldn't it be up to the kernel to simply not flow-offload `wan` if it has upper devices on top also doing flow offloading?

09:49 <jow> maybe defunct pppoe offloading on top of offloaded ethernet is simply a bug

09:50 <jow> I did not read into the offloading architecture but maybe it is possible to exempt pppoe frames from flow offloading?

13:20 <shifttymike> Hi! Not entirely sure whether this should be in devel or not, but I have a device where the NAND layout differs to what is in the dtb. I'm appending mtdparts=... to the cmdline, but it seems to be getting ignored. Is there a way for the cmdline to take precedence over the dtb or adjust this without rebuilding the dtb? I want to avoid doing this everytime I do a sysupgrade, it should work with vanilla images

13:59 <tmn505> what is Your target? You could add CMDLINE to device recipe in image builder, but I don't know if that still works or if it won't need kernel rebuild (which implies full rebuild).

14:32 <oliv3r[m]> So I have a node in my devicetree (I2C regmap mux driver) that is responsible for muxing the I2C pinout pins. (Our I2C controller can select (mux) one of 8 SDA pins, to each SCL pin). My issue is with pinctrl setup. Each mux channel gets a pinctrl, to map the SDA pin. A mux can also select a 'disconnected state'. Very easy in pinctrl terms, define a "default" and a "disconnect" state. easy so far. But now, I need to at runtime toggle

14:32 <oliv3r[m]> the pinmux. However, the mux is a child node of the mux, and as such doesn't have a compatible and doesn't have a `struct device` associated with it, which means, i can't do 'devm_pintrl_get(dev);`, unless i can do it of the parent node (e.g. the mux itself) which doens't have a pinctrl of course defined.

14:35 <oliv3r[m]> unless of course, 'dev' is only needed to find the actual pinctrl, and not the pinhandle? :)

14:42 <shifttymike> @tmn505 Linksys EA4500 (kirkwood). cmdline can be manipulated in u-boot, but it seems to be overridden by the dtb

14:43 <shifttymike> I could patch the dtb with imagebuilder, but then I'd need to do that every time I want to sysupgrade

14:47 <tmn505> afaics required options are enabled in kernel configuration, maybe there's something wrong with the srting You try to pass

14:48 <tmn505> *string

14:48 <soxrok2212> im aware theres no 6e support in openwrt yet, but is QCN9024 driver at least expected to work? asking in regard to https://forum.openwrt.org/t/adding-support-for-verizon-cr1000a

14:48 <soxrok2212> robimarko: i think you may know the answer to that one

14:51 <shifttymike> @tmn505 yeah that's what I saw too... I'll fiddle with the string a bit and see

14:56 <hurricos> time to port openwrt to a copier https://copiersonsale.com/wp-content/uploads/brochures/Kyocera-TASKalfa-406ci-Brochure.pdf

14:57 <hurricos> (this is a joke. I do appreciate they have 2GB of RAM dangling off of a P1022 though)

15:02 <svanheule> oliv3r[m]: you may need to provide a DTS (snippet) to clarify how you're defining your pinctrl and i2c mux nodes

15:03 <svanheule> oliv3r[m]: IIRC the SDA pins on rtl93xx can be either GPIO or SDA, so if they are used for I2C a static selection of the SDA should be OK, no?

15:05 <oliv3r[m]> svanheule: https://paste.debian.net/1274397/

15:06 <oliv3r[m]> svanheule: some more context, i'm writing an i2c-mux-regmap driver, https://gitlab.com/olliver/linux/-/blob/openwrt-22.03/5.15-realtek-22389-gd9c88cea5b-dirty/drivers/i2c/muxes/i2c-mux-regmap.c which will try to handle these 'exotic' (or actually any) simple mux based on syscon/regmaps.

15:08 <oliv3r[m]> the thing I'm a) not sure of, is that the pins are being pinctrled at all; b) I want/need to also support the 'mux disconnected' state. This does relate tot he rtl93xx nicely, as we can select a mux; but we can not 'unselect' it. Making the pinmux gpio solves that nicely

15:40 <robimarko> soxrok2212: QCN9024 works, I have it on AX9000

15:59 <soxrok2212> robimarko: 6ghz working do you know?

16:01 <slh> soxrok2212: the ax9000 doesn't has QCN9024, but physically no 6 GHz (not allowed in China so far) - so you'll probably the first to try

16:02 <slh> err, the ax9000 has QCN9024, ...

16:02 <slh> also be aware that netifs/ iwinfo might not be totally on top of 6 GHz, yet

16:05 <robimarko> soxrok2212: No idea about 6GHz, but it should be working

16:30 <soxrok2212> ok, i have a friend that is interested in sponsoring a device so i may look at it

16:33 <mrnuke> How do I fix "bash: line 1: staging_dir/host/bin/python3: No such file or directory" ?

16:35 <jakllsch> what's the first line of that file read?

16:36 <mrnuke> The file does not exist

16:47 <mrnuke> I did " rm staging_dir/host/.prereq-build " and now it seems to have re-generated that symlink

16:51 <oliv3r[m]> svanheule: I moved the pinctrl node one level up; and put 'all' pins up there. Slightly less nice; but not horribly ugly afaik

17:45 <johnf> I'm preparing a PR for packages, is there a way I can test this cleanly end to end

17:45 <johnf> so actually have scripts/feeds pull from my github based mirror, instead of the real feeds?

17:46 <johnf> it would be pretty sweet if this was covered here: https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md

17:46 <johnf> though, uh, if it is, please be gentle :)

17:51 <stintel> johnf: cp feeds.conf.default feeds.conf

17:51 <stintel> then edit feeds.conf in your favorite editor

17:52 <stintel> https://openwrt.org/docs/guide-developer/feeds

17:52 <stintel> you could also point it to your local clone even with src-link

17:57 <johnf> excellent, thank you stintel

17:58 <johnf> oddly enough I don't have a local clone because of how I'm doing this, but that will work quite well for me

18:09 <stintel> johnf: you're welcome!

18:40 <johnf> stintel: I was able to complete testing and submit my PR https://github.com/openwrt/packages/pull/20683

18:40 <johnf> looking forward to having sscep in tree

18:42 <stintel> I've approved the CI. you should probably squash those 2 commits into 1

18:57 <johnf> I thought that would happen through the PR merge process

18:57 <johnf> I can squash them on my side though

19:04 <johnf> done

19:04 <johnf> stintel: it looks like another approval is required after the force push

19:31 <Mangix> karlp: pointless drama

19:34 <Mangix> wonder if that patchset should be merged by openwrt. Up to ipq maintainers I guess.

21:56 <slh> Mangix: probably not, unless there would be a sudden (surprising) expectation that it's going to be applied soon - stmmac is quite active in terms of drive-by contributions from various sides to make their hardware work, a large and invasive patchset that has no chance of being merged might create more problems than gains, even if it were (technically-) pure gold