<philipp64>
lipnitsk: if you can fix the parallel build for a lot of these projects and upstream the fixes, then everyone wins...
<lipnitsk>
philipp64: yeah, maybe I'll peek at it (haven't looked at all yet). Chances are it's some hornet's nest otherwise maybe it wouldn't have been a problem in the first place..
<philipp64>
my recollection is that automake generates parallel-safe builds...
<lipnitsk>
what do you mean by a lot of these projects?
<philipp64>
but... not everyone uses autotools.
<lipnitsk>
which ones are misbehaving to your understanding?
<lipnitsk>
it's not just gettext?
<philipp64>
libtool, uci, libxml2, mdnsresponder... freeswitch... there are a few.
<philipp64>
might be more. just did a search but it wasn't exhaustive.
hbug__ has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
hbug_ has quit [Ping timeout: 268 seconds]
silverwhitefish has joined #openwrt-devel
<lipnitsk>
philipp64: what did you search for? PKG_BUILD_PARALLEL:=0 ?
<philipp64>
yes
<lipnitsk>
yeah, probably set to 0 for good reason ;) funnily enough gettext-full does have it set to 1
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<enyc>
Namidairo: hrrm... ok can you put that on the above ticket? Should there be an openwrt tracking bug to look into before release or otherwise?
<enyc>
Namidairo: in one case, 3* SSIDs on 5ghz (ath10k) and also 2* SSIDs on 2.4ghz (ath9k) .... but nothing too onerous!
<enyc>
Namidairo: will try to see if older logs/versions make apparent where it maybe used to work....
<enyc>
Namidairo: thinking about it i have identical router with similar slightly-older config and older master build, I can swap that in and fix its' update config..., get info on ath10k versions etc.
rmilecki has joined #openwrt-devel
opal has quit [Ping timeout: 268 seconds]
opal has joined #openwrt-devel
nitroshift has joined #openwrt-devel
opal has quit [Ping timeout: 268 seconds]
opal has joined #openwrt-devel
<aparcar[m]>
mangix: ping
Darkmatter66_ has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #openwrt-devel
mattsm has quit [Ping timeout: 246 seconds]
<guidosarducci>
aparcar[m]: in addition to the OWRT build automation, do we support any type of automated run-time testing? e.g. kernel self-tests or home-brewed
<mangix>
aparcar[m]: pong
dedeckeh has joined #openwrt-devel
<aparcar[m]>
mangix: I'm thinking how to detect best modified packages
mattsm has joined #openwrt-devel
<aparcar[m]>
currently it only detects changes in Makefiles/test.sh
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
<aparcar[m]>
but since we now have AUTORELEASE modifications to makefile are not always required.
<aparcar[m]>
it's not always package/<packagename>/<changes>
<aparcar[m]>
but sometimes package/<top folder>/<packagename>/<changes>
<aparcar[m]>
guidosarducci: not so far, we could run some qemu images I guess via an CI
<guidosarducci>
aparcar[m]: that's what I was thinking too. we have malta, armvirt and x86, that together cover *a lot* or archs, word sizes, and endianness space
<aparcar[m]>
guidosarducci: well do you have experience with those setups? maybe we can setup something
<lipnitsk>
aparcar: there is also the case where pkg name != folder name
<guidosarducci>
guidosarducci: not really, I've set up my own ad-hoc tests for packages I care about, but using upstream tests would be better
<aparcar[m]>
lipnitsk: treason! which package?
<lipnitsk>
one example is protobuf-c (pkg name is libprotobuf-c)
<guidosarducci>
aparcar[m]: I worry that (as usual) much of the testing infra doesn't play well with cross-compilation/embedded stuff. Would need to look at it carefully.
<aparcar[m]>
guidosarducci: it kinda works well at this point, qemu is kinda mounted and then the arch specific packages are run
<aparcar[m]>
what runtime tests are you thinking of?
<guidosarducci>
aparcar[m]: I meant the upstream's testing infra. Things like kernel self-tests on the networking side, BPF, etc.
<aparcar[m]>
lipnitsk: ugh awkward. what do you suggest
<guidosarducci>
aparcar[m]: even a basic runner based on QEMU would be a good start. There are some simple tests like "modprobe test_bpf" that already exist (and I've packaged the module)
<lipnitsk>
aparcar: one way could be to grep for "PKG_NAME.*:=" while walking directories up, until you hit one match
<guidosarducci>
aparcar[m]: I just don't understand enough of what exists for OWRT testing to gauge what's possible...
<aparcar[m]>
guidosarducci: kernel stuff seems difficult with the current setup as it's within a docker setup. but we can run the full redis upstream tests for example
<aparcar[m]>
anything not kernel related should work
<guidosarducci>
aparcar[m]: redis? For kernel stuff could we not simple parse for output as usual?
<lipnitsk>
aparcar: actually wait, you want the directory name, not PKG_NAME, since that's what make uses
Darkmatter66 has quit [Read error: Connection reset by peer]
<lipnitsk>
some clever way to find where the Makefile is then get the dirname where it's in?
<lipnitsk>
or find all Makefiles, then take off the Makefile part and match that path to what git said changed?
Darkmatter66 has joined #openwrt-devel
<aparcar[m]>
lipnitsk: you want to do the thinking?
<lipnitsk>
dunno. It's getting late here
<lipnitsk>
Let me try.
<aparcar[m]>
lipnitsk: I can also come up with something
<lipnitsk>
give me a few min
<aparcar[m]>
guidosarducci: do you have actual machines for testing?
<guidosarducci>
aparcar[m]: I do my local stuff on an ubuntu box and another VM box. Is that what you mean?
<aparcar[m]>
guidosarducci: I'll think of something
<aparcar[m]>
lipnitsk: ping me if you figured something out, thanks for the nightshift
<guidosarducci>
aparcar[m]: Thanks. BTW, some simple, concrete targets I was thinking of was: 1. self-contained test script, 2. iproute2 "make check", and 3. "modprobe test_bpf". Appreciate if you have some good pointers to how our current testing is set up.
<ynezz>
maybe we need to convert it to some kind of task list with [x] ticks or such
<ynezz>
this is a moment where I miss some usable issue system, where we could create ticket with all the tasks so the state tracking would be much easier
<rsalvaterra>
Heh… I had to use lipnitsk's big hammer, but at least I now have WireGuard on 5.10, on my Omnia. :)
<rsalvaterra>
zx2c4: How do I know which of the algorithms (scalar or NEON) are being used in WireGuard? I see them in /proc/crypto, but with refcnt at 1 (as WireGuard uses the libraries directly, not the crypto API, right?)…
<adrianschmutzler>
Just a few espressobins as it appears?
<rsalvaterra>
adrianschmutzler: Yeah, git made a bit of a mess, it's not obvious from the diffstat.
<rsalvaterra>
So, files/ is common to all kernel versions, files-5.4/ is specific to the 5.4 kernel version, correct?
<adrianschmutzler>
so, espressobin-emmc, -v7 and -v7-emmc are upstreamed?
<rsalvaterra>
Yes, those are upstreamed.
<adrianschmutzler>
rsalvaterra: yes, files/ is common, so your copying of files/ to files-5.10/ does not make much sense ;-)
<adrianschmutzler>
But I will probably just fix that myself
<rsalvaterra>
It does when you don't want to make big mistakes (and I did :P).
<rsalvaterra>
So, I first made sure I had files-5.4/ and files-5.10/. Only then I started factoring things into files/.
<rsalvaterra>
As files-5.10/ ended up empty, I removed it.
<adrianschmutzler>
then it's probably just not distributed well over the patches
<adrianschmutzler>
anyway, as we see files might need special treatment
<rsalvaterra>
You're the fan of small steps at a time… ;)
<rsalvaterra>
(And I am too.)
<adrianschmutzler>
btw, how did you do kernel_oldconfig now? (which commands/sequence?)
<rsalvaterra>
1) make kernel_oldconfig
<rsalvaterra>
2) make kernel_oldconfig CONFIG_TARGET=subtarget (for each subtarget)
<rsalvaterra>
I'm assuming the hierarchy is generic -> target -> subtarget.
<adrianschmutzler>
yes, I'm just never sure what exactly kernel_oldconfig does when subtargets are around
<rsalvaterra>
Yeah, it updates the main target. It's what we want. :)
<rmilecki>
adrianschmutzler: thanks for porting that backport patch from 5.4 to 5.10
<rmilecki>
adrianschmutzler: unfortunately nbd_ missed more patches, so one should compare both trees
<rmilecki>
adrianschmutzler: 402-v5.12-0001-dt-bindings-mtd-move-partition-binding-to-its-own-fi.patch and 402-v5.12-0002-dt-bindings-mtd-add-binding-for-BCM4908-partitions.patch are mssing too
<adrianschmutzler>
so, if something very old slipped, I wouldn't have it
<rmilecki>
not sure how easy to understand outptut will be
<adrianschmutzler>
well, diffing means you have to check for every removed patch manually
<rmilecki>
right
Net147_ has quit [Read error: Connection reset by peer]
<rmilecki>
may be a lot of work for 5.4 -> 5.10
<adrianschmutzler>
I tried that first, but then gave it up as it would require a substantial amount of time
<rmilecki>
ok
<rmilecki>
i understand
<adrianschmutzler>
essentially you would have to do the kernel bump _again_
Net147 has joined #openwrt-devel
<adrianschmutzler>
so, I thought checking the history would be a good compromise, assuming the general job done during migration is fine
<adrianschmutzler>
btw I also checked patches and hack dirs
<adrianschmutzler>
so, the main risk would be that nbd_ removed a patch during the process he wanted to work on later, and forgot to do that
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
opal has quit [Ping timeout: 268 seconds]
opal has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
<adrianschmutzler>
rsalvaterra: any reason why only one of the 6 functional patches in v5.11 was taken for turris omnia?
<rsalvaterra>
kab-el: I just noticed, is there any reason we're not exposing the atsha204a at i2c@5, on the Omnia device tree?
Acinonyx has quit [Ping timeout: 260 seconds]
<rsalvaterra>
adrianschmutzler: I told tmn505 I wanted to first get the exact same functionality we had with 5.4, so those patches will be added in the future (when I add support for the LEDs, for example).
<adrianschmutzler>
okay. I probably will leave out the turris omnia patches for now, though, anyway
<rsalvaterra>
adrianschmutzler: In other words, we're at 5.10 plus bug fixes only, minus LEDs.
<rsalvaterra>
Uhh… no, we need those.
<adrianschmutzler>
reads like enabling a feature?
<rsalvaterra>
They fix the hardware buffer management and the IRQ storm.
<rsalvaterra>
Wait, are we on the same page? Which patches?
<adrianschmutzler>
mvebu: fix the Turris Omnia device tree
<adrianschmutzler>
There, it says "enable and fix". This means that without the patch, it's disabled and thus won't hurt :-)
<rsalvaterra>
These are the patches I'm talking about: 002-ARM-dts-turris-omnia-enable-HW-buffer-management.patch, 100-ARM-dts-turris-omnia-fix-hardware-buffer-management.patch, 101-ARM-dts-turris-omnia-configure-LED-2--INTn-pin-as-interrupt-pin.patch.
<rsalvaterra>
002 and 101 enable/fix hbm, it's been working for a long time already on Linksys hardware with the same SoC.
<rsalvaterra>
(I already sent a patch to enable/fix hbm on 21.02 too.)
<rsalvaterra>
101 fixes the GPIO IRQ storm.
<adrianschmutzler>
I mainly just don't want to have to review these.
<rsalvaterra>
adrianschmutzler: It hurts network performance, especially at small packet sizes. :P
<nitroshift>
rsalvaterra, o/
<rsalvaterra>
Hey, nitroshift! o/
<adrianschmutzler>
but it will still boot and not explode without them?
<nitroshift>
what hardware buffer manager on mvebu are you talking about?
<nitroshift>
so far there is only software buffer manager
<rsalvaterra>
adrianschmutzler: If that makes you more comfortable, those patches were approved upstream.
<adrianschmutzler>
well, give me two links and I might be fine :-)
<rsalvaterra>
nitroshift: I'll get to you, let me just "unstress" adrianschmutzler. :)
<nitroshift>
:)) ok
<adrianschmutzler>
doesn't look like they made it in the 5.12 set
<adrianschmutzler>
okay, and "just" reviewed means we do not know when and whether they will land in kernel
<adrianschmutzler>
but that should be good enough for us at the moment
<rsalvaterra>
Let's make a bet…? ;)
<adrianschmutzler>
It's all fine
<rsalvaterra>
It's not a matter of "if", just a matter of "when" (for the IRQ storm patch) and "how" (for the hbm fix, as it's being discussed the possibility of including in the generic SoC .dtsi).
<adrianschmutzler>
but stuff like the "how" would normally be something you would wait for
<rsalvaterra>
nitroshift: About hbm, you're talking about the WRT1900AC v1, right?
<rsalvaterra>
nitroshift: Check for something like this on your dmesg: [ 1.536185] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled
<adrianschmutzler>
hmm, that CONFIG_POWER_RESET_LINKSTATION is set up strangely
<rsalvaterra>
Oh…? I wasn't prompted for that.
<adrianschmutzler>
not your fault, just generally
<nitroshift>
rsalvaterra, got confused, you're right
<adrianschmutzler>
it's =m in modules, but disabled in the subtargets, and not set in the target ...
<rsalvaterra>
adrianschmutzler: ack for your nitpicks, thanks. :)
Tapper has joined #openwrt-devel
<rsalvaterra>
I have a question which has been bugging me for a while… Let's say I have a system for which the Wi-Fi driver is basically in maintenance mode. Is there any easy way to build an image without the compat stuff?
<rsalvaterra>
For mvebu? Not at all, I don't have that in my tree.
<rsalvaterra>
Well, wait. You have WireGuard?
<rsalvaterra>
In that case, you need a patch, yes.
<adrianschmutzler>
I will just do a test with buildbot settings
<adrianschmutzler>
which would want to build at least kmod-wireguard ...
<rsalvaterra>
I shamelessly stole this one: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=commit;h=39fe90daccb410ab0bbc82227bc3f875c97fe4f0
<rsalvaterra>
This won't build the module, but WireGuard will work if you select it (built-in) in the kernel configuration.
<rsalvaterra>
In either case, the build won't fail.
* rsalvaterra
eagerly waits for the big-ass WireGuard pull to land…
<adrianschmutzler>
I'm still curious how this will end
<rsalvaterra>
What do you mean? :)
<rsalvaterra>
The migration from compat to patches in 5.4?
<rmilecki>
adrianschmutzler: i think / hope your comments were addressed
<adrianschmutzler>
rmilecki: yes.
<rmilecki>
adrianschmutzler: thank you for looking at that MR
<adrianschmutzler>
I just wonder whether stuff like ucidef_set_led_default is really needed. But probably patching a default-on into DTS is not worth it ...
<adrianschmutzler>
btw, since this LED is selected in diag.sh:
<adrianschmutzler>
will it stay on or off after boot?
<adrianschmutzler>
done) status_led_on ...
<adrianschmutzler>
hmm, looks like the ucidef_set_led_default "logo" "Power" "bcm53xx:white:power" "1" can be just removed
<adrianschmutzler>
but if you don't want to touch the code again, I'm also fine with the current state
<rmilecki>
adrianschmutzler: bcm53xx uses 99% of upsteam DTS code and we don't have some code that is commonly used in OpenWrt, like those aliases
<rmilecki>
i'm not well aware how it looks like
<rmilecki>
I'll have to clean it up somehow
<rmilecki>
that bcm53xx:white:power should be default-on in DTS, weird
<rmilecki>
or should be set by some .sh code
<rmilecki>
i'll check that
<adrianschmutzler>
as I understand it, it's picked up by the code in base-files/etc/diag.sh
<rmilecki>
it should be, i believe
<adrianschmutzler>
so, default-on will only be relevant during first 3 seconds
<rmilecki>
right
<adrianschmutzler>
then diag.sh will blink and after boot is finished, it should make the LED solid-on
<adrianschmutzler>
those ucidef_set_led_default lines are typically put by people so they can only change a value, but don't have to add the full uci block themselves (if they don't use luci)
<adrianschmutzler>
personally, I think that's not really necessary, and particularly not for a LED which is used in diag.sh
<adrianschmutzler>
for the general subject, one could of course just add local patches that insert led-* aliases into the DTS files and then use generic diag.sh
<adrianschmutzler>
but I don't really think that's worth the effort
<adrianschmutzler>
particularly since we still do not know how to use this feature with the new color/function properties, where we cannot determine the LED name from DT anymore
<rsalvaterra>
I guess now I can start working on the Omnia LEDs… mangix will be happy. :)
* rsalvaterra
runs
Rene__ has joined #openwrt-devel
<lipnitsk>
adrianschmutzler: any advice on how to move forward with that WireGuard PR? It seems pretty quiet now on the mailing list and in the PR comments. Is it a matter of following up? If so then with who?
<hurricos>
I thought all of the stuff got dropped there.
<rsalvaterra>
No, ath79 is device tree based, like God intended. :P
<hurricos>
Other than that, how big would a PR for ath79 actually *be* though?
<hurricos>
or sorry. Github terminology bastardization. A patchset?
<hurricos>
... wait
<hurricos>
Never mind. I see. This is about bmips
<hurricos>
I was beginnig to sweat. "ath79 ... not mainline? What about code rot???"
<Borromini>
lol
<rsalvaterra>
hurricos: It would probably be big, but nothing unmanageable, I think.
<hurricos>
rsalvaterra: So it's not mainline, but also not far. At this point I just have to ask, what even *is* MIPS
<hurricos>
What is RAM. What are computers. Sigh
MichaelOF has quit [Quit: Konversation terminated!]
<hurricos>
I like how neat device trees are but they totally conceal a lot of quirks from the bootloader
<rsalvaterra>
MIPS is actually well maintained upstream, even for really exotic stuff (N64 support was just added, for example).
<hurricos>
like, it's not what's actually on the board
<hurricos>
or not just that, but also the variations shimmed in by U-boot. SATA on APM82181 only works if properly initialized by U-boot it seems
<hurricos>
(as an example)
<hurricos>
I should stop counting my blessings and be thankful as much works as it does
<rsalvaterra>
adrianschmutzler: I totally missed the fact that the Omnia's .dts LED node was added in disabled state. No LEDs for 5.10, I guess mangix is safe, for now… :P
gromero_ has joined #openwrt-devel
<adrianschmutzler>
rsalvaterra: I already wondered, but was not sure whether I missed something
<adrianschmutzler>
mvebu builds fine, so let's throw it in
gromero has quit [Ping timeout: 256 seconds]
<rsalvaterra>
\o/
<PaulFertser>
rsalvaterra: that last lkml link of yours, hm, that's not what happened eventually, right? The "crazy tables" just migrated to dts, but still maintained along with the kernel, as an inherent part.
<rsalvaterra>
Yes, of course. The point is .dts became the standard way to describe ("platformless") hardware.
<guidosarducci>
FYI, for those using mips/malta for development, kernel 5.10 support comes with PR https://github.com/openwrt/openwrt/pull/3881. Hopefully that gets reviewed/merged.
KGB-2 has quit [Ping timeout: 240 seconds]
Borromini has joined #openwrt-devel
bookworm has quit [Read error: Connection reset by peer]
<rsalvaterra>
adrianschmutzler: The ESPRESSObin is Cortex-A53… ;)
<rsalvaterra>
So it's run-tested too. :)
<adrianschmutzler>
looks like I copied that from v3 series ...
<rsalvaterra>
No worries, it works, that's what matters. :)
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #openwrt-devel
shibboleth has joined #openwrt-devel
joaohcca has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
joaohcca has quit [Quit: Connection closed]
Tost has quit [Ping timeout: 256 seconds]
kubrickdave has joined #openwrt-devel
dansan_ has quit [Ping timeout: 240 seconds]
dansan_ has joined #openwrt-devel
<pkgadd>
rsalvaterra: I'd guess the biggest hurdle for getting the rest of ath79 mainlined would be ag71xx, mainline has a stripped down version of it which won't work on most ath79 devices - that's slowly getting expanded, but it's a hell of a maze to get all the necessary bits and pieces refactored and done properly - beyond that big hurdle, it's probably mostly 'just' a huge amount of devices to take care
<pkgadd>
of
Tapper has joined #openwrt-devel
dansan_ has quit [Remote host closed the connection]
dansan_ has joined #openwrt-devel
dansan_ has quit [Remote host closed the connection]
<rsalvaterra>
Yes, I was looking at it already. ;)
<hurricos>
pkgadd: That's good to know, with any luck whatever makes it into mainline won't require any extreme tweaks to dts' pll_data or anything whacky like that
<Hauke>
rsalvaterra: in the upstream kernel MBUS_ID is not modified
<rsalvaterra>
Hauke: Oh, you missed the discussion. ;) Wait, don't merge that yet, I was just about to mark it as superseded, exactly to make it more clear.
<Hauke>
ok
Borromini has quit [Quit: leaving]
<rsalvaterra>
Actually, I already did.
<Grommish>
Someone was asking about Octeon and TZ settings. Ping that person ;p
<rsalvaterra>
Hauke: I'll send a new patch which will include everything, three patches in logical sequence, enabling/fixing hardware buffer management and the IRQ storm I've been seeing for years on the Omnia.
<Grommish>
Something is settng UTC to be UTC-3. I had to go back to -8 to read the correct time for EST
<pkgadd>
Grommish: youre looking for Borromini
<Grommish>
Thanks pkgadd.. Ping Borromini then :)
<Grommish>
Or I'll remember later since he's not on
foxtrot has quit [*.net *.split]
jow has quit [*.net *.split]
user890104 has quit [*.net *.split]
wigyori has quit [*.net *.split]
dangole has quit [Ping timeout: 272 seconds]
<zx2c4>
lipnitsk: yea, it'll be in there this week after the net.git sync
<lipnitsk>
okay, I figured it was some process like that - thanks
<lipnitsk>
zx2c4: I just did a minor push to add a note to the backport patch before my sign-off.
<zx2c4>
For now just stick with the commits i put in there originally
<zx2c4>
Ah cool
<lipnitsk>
just for posterity
wigyori has joined #openwrt-devel
user890104 has joined #openwrt-devel
jow has joined #openwrt-devel
foxtrot has joined #openwrt-devel
<Hauke>
rsalvaterra: thanks
<Hauke>
as they have a Fixes tag they will probably added to 5.4 later anyway
<rsalvaterra>
Hauke: That's my hope, but we'll still need the hardware buffer management backport for 21.x. The other two patches will probably become obsolete with a future stable kernel update.
<Hauke>
rsalvaterra: ok
<Hauke>
does anyone know why CONFIG_HAVE_ARM_ARCH_TIMER is not unset in generic 5.10 any more, but was in 5.4?
<zx2c4>
lipnitsk: are we ready to have Hauke or blocktrron merge?
<lipnitsk>
blocktrron said he will by this weekend
<lipnitsk>
or by next week :)
<zx2c4>
Bah, so much waiting
<zx2c4>
Hauke: maybe you want to do it now so we can get it over with? :)
<rsalvaterra>
Hauke: I saw that too. CONFIG_HAVE_ARM_ARCH_TIMER makes no sense on Cortex-A9, only A7 and A15, if I'm not mistaken.
<lipnitsk>
zx2c4: yes, we are ready. I polish things as they come to mind, but it all works, so just a matter of any feedback from core folks at this point
<rsalvaterra>
zx2c4: Oh, the WireGuard merge? Let me get the popcorn… :D
m4t has quit [K-Lined]
<Hauke>
zx2c4: I didn't look closely into the wiregurad changes
m4t has joined #openwrt-devel
ivanich has quit [Read error: Connection reset by peer]
<zx2c4>
Hauke: all the more reason to press the green merge button!
<zx2c4>
Big improvements, anyway. Finally using the upstream code
<Hauke>
rsalvaterra: why does the CONFIG_HAVE_ARM_ARCH_TIMER make no sense on cortex A9? is this not needed for the arm global timer?
<rsalvaterra>
Hauke: Different things. The global timer is shared by all cores, the architected timer is introduced with A7/A15 and is a per-core timer.
fblaese has quit [Quit: irc_error]
<lipnitsk>
zx2c4: I don't know if you want to push for cherry-picking the backport into 21.02, but 5.4 will eventually be deleted from master with no planned 5.4 release off master anymore, AFAIK
<lipnitsk>
zx2c4: Otherwise, 21.02 will use wireguard-linux-compat
<Hauke>
rsalvaterra: thanks for the clarification
<rsalvaterra>
FWIW, I'd *really* love to see 21.02 dropping compat for WireGuard.
<lipnitsk>
I can just open a 21.02 PR and see where it goes from there
<lipnitsk>
:)
* rsalvaterra
would also like OpenWrt to drop compat entirely. And a unicorn. :P
<zx2c4>
Hauke: I'd prefer the backport in 21.02 rather than compat. Let's get this in master first and then we can do 21.02
<zx2c4>
So hoping that PR gets merged soon (today? now?) so that we can move onto next steps
<zx2c4>
lipnitsk: oh great
<lipnitsk>
yeah I can wait for now..
<Hauke>
I do not have time before the weekend
<enyc>
Hauke: did you see the fun with -ct firmware? uerr .... been busy on other task myself.