<mangix>
aparcar[m]: all meson capable packages in the packages feed already use meson. The one exception is dtc. I have a patch for it but might as well wait for a new version.
<rsalvaterra>
mangix: I see, struct ag71xx_ring reordering is done already.
<mangix>
yeah
<mangix>
I told the guy who upstreamed the ag71xx driver
<mangix>
The rest of the stuff I did after it was upstreamed.
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<rsalvaterra>
mangix: Do we need iperf numbers to merge this?
<rsalvaterra>
russell--: I forgot to alert you yesterday, my trees get rebased all the time.
<mangix>
rsalvaterra: I wouldn't bother
<mangix>
David Miller wants numbers if you're looking into that.
<rsalvaterra>
Upstream is a whole other battle. :)
<rsalvaterra>
Hmm… someone asking about Q-in-Q VLANs with DSA…
danitool has joined #openwrt-devel
<mangix>
basic googling reveals that it needs driver support
<rsalvaterra>
mangix: Indeed. Seems ocelot supports it.
<russell-->
rsalvaterra: gotcha
robin_ has joined #openwrt-devel
<mangix>
rsalvaterra: no idea if you saw Ansuel's LEDs patch
<rsalvaterra>
russell--: Also, you get new toys to play with, but note that I don't use LuCI, so there may be incoherence between UCI and the web interface. ;)
<rsalvaterra>
mangix: The LED patch?
<mangix>
yeah.
<mangix>
requires DTS changes
<rsalvaterra>
Oh. More cherry-picking is in order. :P
<rsalvaterra>
Do you have a link?
<rsalvaterra>
I need to go now, be back later.
<wvdakker>
Where can I find a good description of DTS files? I have a non-working WiFi in 21.02 because PCI did not detect it.
<wvdakker>
19.07 was ok, 21.02 did not work anymore (see also FS 3829)
valku has quit [Remote host closed the connection]
valku has joined #openwrt-devel
valku1 has joined #openwrt-devel
valku1 has quit [Quit: valku1]
valku has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
minimal has joined #openwrt-devel
danitool has joined #openwrt-devel
robin_ has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<rsalvaterra>
mangix: Then how in the world…? If I read the patch correctly, the LEDs are connected directly to the switch. How are they supposed to be supported, then?
dedeckeh has joined #openwrt-devel
fda has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
<mangix>
rsalvaterra: specify them in DTS and the driver exposes them to linux.
robin_ has quit [Ping timeout: 480 seconds]
exactxmpl has quit [Quit: Page closed]
<mrkiko>
will ah79 5.10 kernel fit in 4MB ?
<mrkiko>
Did you guys face the need to elnlarge some kernel partitions in this sense?
goliath has quit [Quit: SIGSEGV]
<mangix>
mrkiko: probably not
minimal has quit []
<slh>
mrkiko: I haven't actually flashed it, but you can do it with a stripped down config: -rw-r--r-- 1 3604768 17. Sep 02:12 r17525-a46fa5c3a7/ath79-tiny/targets/ath79/tiny/openwrt-ath79-tiny-tplink_tl-wr941-v2-squashfs-sysupgrade.bin
goliath has joined #openwrt-devel
<slh>
that is with kernel v5.10.66, no luci, no opkg and otherwise rather minimal
Tapper has joined #openwrt-devel
pmelange1 has joined #openwrt-devel
pmelange has quit [Read error: Connection reset by peer]
dedeckeh has quit [Remote host closed the connection]
<blocktrron>
mrkiko: you can do it with optimizations, but i don't get your question
<blocktrron>
Kernel partition is always enlarged when the kernel grows on boards using an mtdsplit driver for kernel / rootfs
<rsalvaterra>
mangix: So it should be an independent driver for the LEDs?
<olmari>
I hate to be repetitive... but I'll rephrase my question an bit other way... does current master with kernel 5.10 boot on tp-link wdr4900? :) as I have one device way remote, I would hate it being bricked again needing phsycal serial-console for reviving
<stintel[m]>
SamiOlmari: you should have a local test device identical to a remote device far away like that
<olmari>
stintel: I'd need locations to have better devices, but neither is really an option in one off home-sized enviroments where anything can cost exactly nothign
<stintel[m]>
is that ppc ?
<olmari>
stintel: yes, it is MPC8500 or whatever it was.. but yeah PPC
<stintel>
then don't do it
<stintel>
we've had multiple reports of ppc not booting since gcc10 default
<olmari>
it's not PPC issue (per se), but exactly some tplink or other partition/boot size limits
<stintel>
well as long as you can't test it on a local device (or someone can confirm that it works), don't update the remote device
<stintel>
alternatively, since you don't have a local testing device, I'd suggest not to run master at all
<stintel>
you're just making things hard for yourself
<grid>
i wonder if it's just gcc-10.3
<olmari>
..that's why I am asking here if any insight, instead blindly doing stuff ;)
<olmari>
to recap: I know the wdr4900 issue was originally resolved by that "simpleimage" stuff.. but I don't know why with 5.10 such won't work, that problem can be anywhere :)
<olmari>
or allegedly wont work
<olmari>
even more so, I know I can at times test new images when I can be locally at premises, but that does no good if there isn't anything to test, and this is quite literally something I can't do, not really my territory of doing that kind of programming :)
<olmari>
ofcourse for now I can keep using whatever older version, it is not the issue for now, but eventuallywuld be nice :)
<olmari>
but indeed best I can do for resolving is to do hardware testing at times, should that be of any help
<olmari>
ofcourse I also realise answer can be "version XYZ" (of owrt or kernel) is last version supported for WDR4900, then it'll be that and tough luck for that location that device ;D