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

08:48 <\x> hello there next WiFi 7 https://benchlife.info/gigabyte-z790-aorus-pro-x-with-mediatek-wifi-7-motherboard-preview/ MT7927 on this one

09:30 <rmilecki> philipp64: i was on holidays for a week

09:30 <rmilecki> philipp64: did you solve 02_network & logging?

13:26 <hauke> rmilecki: openwrt-22.03_bcm4908/generic is not building: https://buildbot.staging.openwrt.org/images/#/builders/206

14:11 <KanjiMonster> hauke: rmilecki: looks like it just needs a backport of https://github.com/openwrt/openwrt/commit/57a8ea6d749e5fe0e00673cc77b5f2c17b792650

15:49 <lynxis> Does someone knows whats the github account of apache14 at the forum? I'm looking for a rk3588 openwrt branch.

15:50 <lynxis> Or i'm looking for an openwrt with 6.4 or 6.5-rcX kernel support.

17:38 <schmars[m]> lynxis: not the account you're looking for, but Tianling Shen might be able to help you with rockchip

18:50 <hitech95> did someone ever tried to use DTS overlays in openwrt? and switching them at runtime to change the ETH phys?

18:51 <hitech95> Zyxel used a MUX to switch a SGMII interface between a SFP cage and a PHY.

21:30 <dangole> hitech95: switching at runtime got reject upstream, hence we also don't support dynamic dt overlays

21:30 <dangole> hitech95: but dt overlays are nicely supported with uImage.FIT in U-Boot

21:38 <hitech95> dangole: yep I've just seen that. The thing is or phylink need to be able to handle both a PHY and a SFP cage and switch between them at runtime (using a gpio) or I have to reboot the hardware. In any case before all of that #13143 must be merged to even think about the overlays.

21:39 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html

21:40 <dangole> hitech95: sure, but that way is still a workaround. having phylink switch between phy and sfp would be the best, obviously. we should discuss with netdev folks

21:40 <dangole> swalker: cheers, appreciated

21:41 <hitech95> dangole: yea for sure. I'll try to write an email to the mailing list but I had no luck with previous questions. I'm not that good :D

21:42 <hitech95> another idea was to create a fake phy driver that handle the switch and the calls to the sfp phy or the mxl phy but that its even worse.

21:46 <hitech95> BTW is there any chance that now that SLIC chips division has been sold to SKYWORKS we can have a proper SLIC API code to implement FXS VOIP?

22:25 <dangole> hitech95: that would be amazing. i feel uncomfortable with the fact that Linux has no proper support for SLICs, but it's not just that. There is no abstraction for PCM bus, it's all part of ALSA... That has lead to SLIC drivers always being SoC specific and mixing code which programs the SoC and code which programs the SLIC...

22:27 <hitech95> Having PCM alsa working would at least be a huge step. years ago I tried to work with the mt7628 the DMA was broken. But recently I've tried and I got I2S data correctly. So some steps are been done.

22:27 <dangole> hitech95: i start to play with that PiPBX hat a while ago but the software support is too messy. even with their gigabytes of sd card image audio would not work properly with asterisk...

22:28 <dangole> hitech95: and obviously all drivers are specific for basbpi/brokencom chips

22:28 <hitech95> A standard interface for configuring the phy of the SLIC would be awesome. but for the audio itself alsa is IMHO good.

22:28 <hitech95> about the proprietary driver, the issue is microsemi. they dont use SPI but a variant of it that require CS cycling for each byte.

22:28 <dangole> sure, for audio alsa is fine. just for all the additional signalling knobs ALSA doesn't seem to be suitable

22:29 <hitech95> dangole: yep using the widgets to configure the slic is not the right way.

22:29 <hitech95> PiPBX ? what is that?

22:30 <dangole> SwitchPi is the name sorry

22:30 <dangole> It's a Si3126 on a RasbPi hat

22:30 <dangole> *Si3216

22:32 <hitech95> oh i've not seen that, they build the driver with the dahdi interface?

22:33 <dangole> I thought it'd be a cool thing to have to try that SLIC on different hosts with 40-pin RasbPi header, but nope, it the drivers are super hacky and directly write to bcm27xx registers to setup PCM

22:33 <dangole> yes, it comes with dahdi driver

22:33 <dangole> but it's a mess

22:33 <dangole> the hardware seems pretty cool though

22:34 <dangole> i never got it working though, and their support is non-existent

22:35 <hitech95> LOL I've just seen, they used a DSP chip and in their chematic there is a big empty rectagle for it. DSP is one of those super locked down vendor.

22:38 <hitech95> dangole: dumb question before going to sleep wasnt the openwrt led naming convention like: "nanopi:green:wan"?

22:39 <dangole> hitech95: yep, that looks correct

22:39 <dangole> hitech95: so you found their github... this is the dahdi driver: https://github.com/lixinswitchpi/oakr2/blob/master/oslec_experience/dahdi-linux-oak-oslec-2.11.1/drivers/dahdi/oak/pidma.c

22:39 <hitech95> ok so I'll add the comments for my friend working on the zyzel

22:39 <dangole> for the simple oak2 board i got

22:41 <dangole> hitech95: i've considered that switchpi hardware a while ago for an arts project involving rotary dial analog phones. but turned out to be easier to just source used lantiq cpes on ebay for 10 bucks each...

22:41 <dangole> plus they can run openwrt and work fine

22:41 <dangole> but sure, lantiq telephony stack is also just a blob running on the 2nd CPU core, no real abstraction for PCM, SLIC, ...

22:41 <hitech95> dangole: never worked with lantiq tapi even if I had a w8970 for a long time. I then moved to pfsense for some years and now I'm back to opewrt

22:42 <dangole> hitech95: lantiq tapi works very well with asterisk, and the driver looks clean (but the real magic happens in the blob, of course)

22:43 <hitech95> dangole: yea I supposed that, but the sources are quite big so some special souce should be there too!

22:46 <hitech95> well its time to sleep. I'll try to contact mainline tomorrow lets hope to have a reply i'm not that good on kernel stuff. I might pay for a proper course one day.