<znullptr[m]>
I've had luck with lifting the vcc pin only and using a clip before
<kabel>
blogic: do you know what is the status of mtk_eth_soc driver on mt7621 board in upstream kernel in comparison to openwrt's version? I see that openwrt still overwrites that driver entirely
<mangix>
kabel: is this in relation to 21.02?
<kabel>
no
<kabel>
I am comparing upstream Linux kernel and openwrt master
<mangix>
oh I see what you mean
<mangix>
the driver in target/linux/ramips is for mt7620 and below
<kabel>
I am trying to run upstream kernel on WiTiBoard, to test some patches for russell king
<mangix>
the upstream driver is used for mt7621. not sure about mt7628
<kabel>
mangix: oh! you are right, it's in another directory
<kabel>
so it isn't being overwritten at all
<kabel>
well, seems that I have broken confiugration or device tree
<kabel>
ok, thanks!
<mangix>
stintel: i think your perl 5.34 update needs to be revived.
<kabel>
jesus christ
<kabel>
so I had to add fw_devlink=permissive to kernel command line, because apparently in newer kernels the default is fw_devlink=permissive, which can block reset controllers entirely, because of the way they can link to OF nodes
<kabel>
aaaaRRRRGHH!
<dwfreed>
kabel: you said the same thing twice, just fyi
<mangix>
ynezz: kernel 5.18's RNG improvements make it seem like there's no point for urng anymore.
tchebb_ has joined #openwrt-devel
ecloud has quit [Ping timeout: 480 seconds]
tchebb has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
gladiac has quit [Quit: k thx bye]
gladiac has joined #openwrt-devel
gladiac has quit []
gladiac has joined #openwrt-devel
gladiac has quit []
gladiac has joined #openwrt-devel
arifre has quit [Remote host closed the connection]
GNUmoon has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
guidosarducci has quit []
guidosarducci has joined #openwrt-devel
<rsalvaterra>
mangix: Heh. It's been brought to my attention that my preliminary dnsmasq nftsets UCI support needs to be reworked, since the syntax differs a bit from ipsets. Oh, well.
<rsalvaterra>
jow: I don't know how fw4 implements nftsets, but they should probably have their own section (config nftset).
<rsalvaterra>
Especially as (as crazy as it may sound), both iptables and nftables can coexist. In theory, someone could have both fw3 and fw4 in the same system.
<rsalvaterra>
s/as/since
<rsalvaterra>
I see why the separator is #, the nftsets are still comma separated, so they needed a different separator.
<rsalvaterra>
mangix: It's possible, but it needs testing. We've been bitter before by horribly long boot times due to "entropy famine". :)
<rsalvaterra>
s/bitter/bitten
slh has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
ekathva has joined #openwrt-devel
<jow>
rsalvaterra: uhm ipsets also do a per-family distinction?
<rsalvaterra>
From what I understood, nftsets *can* do per-family distinction, but they don't *have* to, at least as far as being populated by dnsmasq is concerned.
<rsalvaterra>
How that translates to nftables rules, however, is beyond me. :)
<jow>
ah you're talking about dnsmasq specifics
<rsalvaterra>
Right.
<jow>
it's better to look at the actual implemetnation code
<jow>
hard to deduce actual working logic from the config file samples
<karlp>
I'm tyring to use the sdk I saved to do remote gdb on a device, so I've done a feeds update, and feeds install and then make package/blah/compile so I can get the binary to feed to scripts/remote-gdb right?
<karlp>
that sounds like it's the right method, but trying to build the package is crashing on failing to compile cryptodev-linux?
<jow>
karlp: yeah, the old bug
<karlp>
which certainly didnt' fail when I built the images at the time,
<karlp>
oh, is this an sdk bug that I've managed to successfully "archive" as a present to my current self?
<jow>
no I guess its still unfixed, just worked around on our buildbots
<karlp>
well, might be fixed, this is a 19.07 based build.
<karlp>
what's the buildbot workaround?
<jow>
ensure that libelf-dev is present when building the SDK
<jow>
TLDR; if SDK is built on a host without eligible libelf, it is built without working objtool
<karlp>
ok, so this sdk was built a year ago as part of the release process at the time, so it's ~unfixably flawed now then?
<jow>
if that SDK is then executed on a host *with* a suitable libelf, kernel stack protection stuff is getting enabled, requiring not present objtool, failing all kmod builds