#openwrt-devel on 2021-03-16 — irc logs at freenode.irclog.whitequark.org

00:28 <lipnitsk> rsalvaterra: looks good to me. thanks for doing more due diligence - hope it gets merged. are you planning to email it or submit a PR soon?

00:29 <rsalvaterra> lipnitsk: Sure, I'll email it tomorrow. Now I'm off to bed. :)

00:30 <lipnitsk> sound good

00:53 <mangix> lipnitsk: fewer patches is better

00:54 <mangix> I should probably ask upstream to merge the wrt3200acm patch...

00:54 <mangix> /s/merge/backport

00:54 <lipnitsk> mangix: agreed

01:01 <mangix> I am very curious what this patch is about... https://github.com/openwrt/openwrt/blob/master/target/linux/mvebu/patches-5.10/304-revert_i2c_delay.patch

01:02 <mangix> Couldn't find much in git history

01:12 <mangix> oh hell no

01:12 <mangix> https://github.com/openwrt/openwrt/commit/7379f8bd3e7ee0722faa6ec8b2969081fbdc1e07

01:12 <mangix> that kills debian 9 support AFAIK

01:23 <Grommish> mangix: explain it to me like the idiot I am.. Why would someone want to run an OS that is already EOL and slated for EOL on even the LTS in less than a year?

01:24 <Grommish> I mean, I get it that sometimes it isn't an option.. I worked for a large Fortune1000 company that used COBOL mainframes and flat files, but only on the backend

01:26 <Grommish> but doesn't expanding the base of "compatible" build systems lead to other issues of compatability across ALL bases?

01:27 <Grommish> I'm legit asking because I'm interested in the view.. When I installed Ubuntu, I went with 20.04LTS rather than 18.04, let alone 16.04 which that says is also going to be dropped

01:28 <mangix> Grommish: the large company aspect is the issue

01:29 <Grommish> mangix: Yes, but openwrt isn't being built by large companies, is it?

01:29 <mangix> I assume netgear is a large company

01:29 <mangix> not that I wish to imply they do, but there are multiple large companies that use OpenWrt as a base

01:29 <Grommish> From their firmware, I'd say not so much.. nor are they running a current version of OpenWrt

01:30 <Grommish> They use a base of it, but I don't know of one that uses an official release?

01:30 <mangix> Grommish: I mean, there's nothing newer than 19.07 yet

01:30 <mangix> seems a lot of the newer SDKs use that

01:31 <Grommish> *nod* Ok. Well, you'd think they'd update their build system to a supported version

01:31 <Grommish> I'm not disagreeing or agreeing with either position btw

01:31 <Grommish> I'm curious as to what line does it not become tenible to try and support everyone

01:32 <Grommish> even MS gave up on XP eventually :D

01:32 <mangix> Grommish: I assume just keep support for everything LTS

01:33 <Grommish> Fair enough.. Will Deb make a Python3.6 package if it's within their LTS timeline you think?

01:33 <Grommish> Which they just list as "2022"

01:33 <Grommish> https://wiki.debian.org/DebianReleases

01:39 <mangix> Grommish: nope

01:39 <Grommish> then that's on them I guess

01:40 <Grommish> if they can't be bothered, why jump through hoops on compat with it?

01:41 <Grommish> of course, that just require 3.6, so I guess if they had it locally they'd be fine regardless

01:41 <Grommish> no?

01:41 <Grommish> I KNOW there are reasons for everything, I just want to understand it :)

01:41 <Grommish> You and others don't complain just to complain

01:46 <mangix> Grommish: you would think you can build OpenWrt everywhere.

01:46 <mangix> Unfortunately, only GNU/Linux is really supported

01:47 <mangix> macOS kind of sort of.

01:47 <mangix> FreeBSD even less so

01:47 <mangix> Cygwin, forget it

01:47 <mangix> there's also clang

01:48 <mangix> in my branch, I have several build fixes for clang but I haven't sent since they'll just get rejected

01:50 <Grommish> Meh, I don't like it when people say that.. If you've got it, make them reject it and give you a reason.. If it is't a good reason, then complain

01:50 <Grommish> But just saying "Not sending it in because they might say no" *shrug* I dunno..

01:50 <mangix> Grommish: been there done that

01:50 <Grommish> If it works, send it.. make them justify not using it

01:51 <Grommish> *nod* Gotcha

01:51 <mangix> and it's not might

01:51 <mangix> it's will

01:51 <Grommish> Any idea why?

01:51 <mangix> Argument is that the bug is HOSTCC/HOSTCXX not being respected

01:52 <mangix> both are set to gcc and g++ respectively

01:52 <mangix> but even so, a one line patch still gets rejected

01:53 <mangix> there was a guy named Tom who no longer contributes that was complaining about his patches being rejected for no good reason

01:56 <mangix> He changed the submitter name and patches were applied instantly

01:58 <mangix> Grommish: https://github.com/neheb/openwrt/commit/29aa07407ee6e31ab88132d4999ac9b5151d863f and https://github.com/neheb/openwrt/commit/019ffd319b4021ecdc6f1c313da5f140c6f0141d if you're curious

01:59 <Grommish> Was it done by the same person who rejected it the first time?

02:00 <Grommish> if so, that's an issue that needs to be addressed

02:00 <mangix> in the case of Tom no

02:00 <Grommish> if not, the question is why was it rejected vs accepted by two separate poeple

02:01 <Grommish> I'm scanning gpio ports on the er10x and its at gpiochip448:470 and climbing

02:01 <Grommish> I[m guessing that's not normally

02:02 <mangix> Grommish: grepping irclogs shows https://news.ycombinator.com/item?id=22019903

02:02 <mangix> not what I was looking for but close

02:04 <Grommish> I'd like to have seen the original patch submitted

02:04 <Grommish> Which guy says was cludgy to begin with

02:05 <mangix> 12:43 < ynezz> this https://news.ycombinator.com/item?id=22019903 is probably FS#2423

02:06 <Grommish> My issue with people who push push push for patches is they have no real idea of the wide-reaching consequences across all devices that get used for. the scope of OpenWrt is beyond a single device or tree (as you are well familar with)

02:07 <Grommish> But, when I was doing active android rom dev, we told people if they wanted something we didnt offer, they could fork and do what they wanted with our base

02:07 <Grommish> Very very few wanted to get their hands dirty enough to actually do it

02:08 <mangix> OpenWrt is not android. I also do not want to carry out of tree patches for no good reason.

02:09 <Grommish> Right.. YOU know different :) Your active and respected (by me if no one else ;p)

02:09 <Grommish> Even if I don't understand or agree with everything

02:10 <Grommish> Don't get me wrong, I've dealt with my own ego and frustration with patches, but.. eh.. If it bothered me enough, I'd run my own

02:10 <mangix> oh perfect. this was flat out rejected: https://github.com/neheb/openwrt/commit/b3807a0022a8cd7e459f94ec5c823f921a185163

02:11 <mangix> That clang patch happens to be an upstream backpprt/

02:11 <mangix> The goal was to silently fix this on version update

02:11 <Grommish> Do you hev the PR I can look at as to why rejected?

02:11 <Grommish> I don't do the email list.. I get enough stuff inbound on a daily basis

02:11 <mangix> it was on patchwork. let me dig it up

02:12 <mangix> strange...no comments

02:13 <Grommish> Just closed?

02:13 <Grommish> is it possible they merged it under a different PR?

02:13 <Grommish> They did that last time I send something in.. Instead of merging it, it was closed and merged under a different PR with my name attache

02:13 <mangix> no he explained in an email

02:13 <Grommish> Ah

02:13 <Grommish> Which seems.. wrong

02:13 <Grommish> If there is an issue with a patch, it should be public

02:14 <Grommish> unless it represents a security issue

02:14 <mangix> i don't see it in email

02:15 <mangix> must have been on IR

02:15 <mangix> C

02:15 <Grommish> Which shouldn't be anything official

02:15 <Grommish> I dunno sir.. Just don't give up :)

02:16 <mangix> Grommish: the "fix" was http://lists.openwrt.org/pipermail/openwrt-devel/2020-December/032471.html

02:16 <Grommish> So it was merged?

02:16 <Grommish> Just with a bunch of hoops to deal with?

02:17 <mangix> That one yes. But that pointless math patch remains

02:17 <mangix> It fixes a bug in GCC version old as hell.

02:17 <Grommish> I'd send it.. request an answer as to why it is declined if it is

02:18 <Grommish> It isn't like you are lacking on documentation

02:18 <Grommish> I'll do it ;p

02:18 <Grommish> not that it'll matter since I don't know what it actualky does..

02:19 <Grommish> or can test it.. I don't use clang afaik

02:19 <Grommish> but if you are using it, someone else probably is too

02:20 <Grommish> If nothing else, I can see about getting you to help me setup a test environment for the outlier cases

02:20 <mangix> I use it locally. Building with clang helps with some non-openwrt related stuff

02:20 <mangix> I have CC and CXX set to clang(++)

02:21 <mangix> I still need to attach numbers to https://github.com/neheb/openwrt/commit/79e2c1b0a7e130d649760027578842f83ee72cf6

02:24 <Grommish> Is ld.gold a toolchain specific linker?

02:24 <Grommish> I don't have ld.gold on any of my toolchains or targets in staging_dir

02:24 <Grommish> Or is it something tha thas to be enabled first?

02:25 <mangix> https://github.com/neheb/openwrt/commit/ab61443eb86c32d93c9d899e6b7274bce1c65319

02:25 <mangix> :)

02:25 <Grommish> Ooo.. Ok.. I can help quantify if you want

02:26 <mangix> speed wise, LLVM linker > GOLD > LD

02:26 <mangix> but we don't have LLVM in tree

02:26 <mangix> gold is the next best thing

02:31 <Grommish> Gotcha.. few minutes :)

02:32 <mangix> I should probably get rid of https://github.com/neheb/openwrt/commit/3984b7ea495c438a1ec8460520d92f675cf2e650 . rsalvaterra handled this in his kernel 5.10 bump.

02:51 <Grommish> mangix: In order to test this, I should remove staging_dir and build_dir between builds?

02:51 <Grommish> or will make clean be enough?

02:52 <mangix> make clean should be enough

02:52 <mangix> ld.gold speeds up the linking stage, not necessarily compilation

02:54 <Grommish> Ok.. I'm running it now then

02:55 <Grommish> I'll have numbers in a few minutes

02:56 <Grommish> mangix: Errored out

02:57 <Grommish> mangix: let me make sure it in't omething I did stupid

02:58 <mangix> Grommish: these two patches require a toolchain rebuild btw

02:58 <Grommish> So make clean isn't enough? hehe

02:58 <Grommish> I'll just shitcan the entire build structure between runs. no biggie

02:59 <Grommish> but i want to make sure it isn't an issue on something I forget to bring over first

02:59 <mangix> Grommish: so you can apply the patches and compile the toolchain. if you want to compare before and after, just undo the changes in the last patch

02:59 <Grommish> I usuallt remove bin/ build_dir/ staging_dir/ tmp/

03:00 <mangix> the first patch actually builds gold. the second switches OpenWrt to actually use it

03:00 <Grommish> *nod*

03:02 <Grommish> I'll remove .ccache as well just for giggles

03:02 <Grommish> building out now :)

03:03 <Grommish> (I don't think I use ccache to build with anymore, but eh.. can't hurt)

03:03 <mangix> why not?

03:23 <Grommish> i had issues with ccache when I was buildig with CONFIG_ALL

03:24 <mangix> I would like to know which. I already fixed a bunch.

03:24 <mangix> In other news, AliExpress refunded my purchase of the totolink :(

03:24 <mangix> no ax for me

03:25 <Grommish> was with the luci packages if I remember right

03:27 <mangix> Maybe I should look into the linksys e8450 instead...

03:28 <mangix> :(. more expensive

03:29 <Grommish> Why did they cancel the order?

03:30 <mangix> No idea

03:30 <mangix> Just says closed

03:31 <Grommish> Huh. AE doesn't usually stop and order. sell worthless fakes, yes, but not cancel

03:31 <Grommish> maybe the shop got shut down

03:31 <Grommish> and you got saved from being scammed

03:35 <pkgadd> I've been really interested in the e8450/ rt3200 for the last couple of days - but shipping- and import/ customs fees for post-Brexit Britain have gotten quite uncomfortable

03:36 <pkgadd> the price over all is still reasonable, but ~25 EUR shipping/ customs for a device that already sells with 21% VAT included just feels wrong

03:37 <mangix> pkgadd: more expensive than the totolink :(

03:38 <Grommish> oof.. yeah.. They've still got teh 25% tarrifs on damn near all silicon parts here.. it's nuts

03:38 <pkgadd> I might still bite, as I have a need for a device faster (or at least as fast as-) ipq8065 (especially considering wired performance), but so far I haven't gotten through with it

03:40 <pkgadd> I've skipped looking at the totolink because of its mt7621 SOC, independent of the price (and I'm not toooo keen on importing from outside the EU either) - mt7622b is just so much more interesting

03:42 <mangix> hmmm so the Linksys E8450 from what I see sells for around ~200

03:42 <mangix> the belkin rt3200 sells for around ~100

03:42 <mangix> seems to be the same hardware though

03:42 <pkgadd> yep, https://www.amazon.co.uk/Belkin-Wireless-Dual-Band-Streaming-Parental/dp/B08L4PJKKB ~= 92 EUR, plus shipping and customs fees

03:43 <mangix> oh I see. it's for the european market

03:44 <mangix> found the reason order was canceled

03:44 <mangix> Seller failed to ship your order in time. A full refund will be issued automatically to your original payment method within 3 to 20 business days.

03:44 <Grommish> Ah, see.. probably a scam store

03:44 <pkgadd> but I've often noticed low promotional prices on amazon.co.uk not seen on e.g. amazon.de, the Linksys ea6350v3 sold for ~35 GBP there as well

03:44 <mangix> Grommish: No it's the official one

03:44 <Grommish> mangix: Interesting then

03:45 <mangix> maybe they ran out

03:46 <mangix> Now I have to convince myself to get the rt3200

03:48 <pkgadd> I'd be fine with the price (~92 EUR), but not the shipping/ import duties on top

03:51 <pkgadd> the xiaomi ax3600 could be a nice alternative (ipq8071a), but sadly there seem to be quite some roadblocks to get ethernet/ wireless going with ipq807x

03:53 <mangix> right. I assume there are more mediatek devices that can be added

03:53 <mangix> I don't see anything on the mailing list

03:53 <pkgadd> btw. there seems to be one difference between e8450 and rt3200, the number of LEDs (the rt3200 only seems to have two, the e8450 also activity LEDs for the LAN ports on the bottom front)

03:54 <pkgadd> hard to tell from the vendor pictures though

03:55 <mangix> meh I hate LEDs

03:55 <mangix> nbd seems to have a patch for the D-Link DIR-X1860

03:56 <pkgadd> furthermore the e8450 advertizes 2500 sqft coverage, the rt3200 2000 sqft - which doesn't need to mean anything

03:56 <pkgadd> (or could refer to FCC vs ETSI power levels)

03:56 <mangix> yeah...no. DIR-X1860 costs too much here

03:56 <mangix> and it's mt7621

03:58 <pkgadd> btw. has anyone seen encrypted/ signed firmwares for mt7621 so far? or is it 'safe' to assume that mt7621 based devices can be ported/ flashed 'easily'? (I know that the TP-Link mt7622b+mt7915 devices seem to make it difficult that way)

04:05 <pkgadd> mangix: https://www.aliexpress.com/item/1005002132960438.html would be a cheaper option, but according to błogıc with secure boot (locked via arm trusted firmware); https://wikidevi.wi-cat.ru/TP-LINK_TL-XDR3230

04:07 <mangix> which means a bootloader exploit would be needed

04:07 <mangix> ugh

04:10 <mangix> pkgadd: btw MIPS has no such thing as TrustZone

04:11 <pkgadd> thanks, that's what I thought - but wasn't 100% sure about (no experience with mt7621 for far)

04:28 <Grommish> anyone have RTL8367rb experience?

04:30 <Grommish> Or, just switch/swconfig knowledge? <_<

04:32 <pkgadd> I have devices using it (ath79/ tl-wr1043nd v1 and lantiq/ Arcadyan/Astoria Easybox 904xDSL (VGV952CJW33-E-IR)), but not really any developer side experience

04:33 <mangix> ugh

04:33 <mangix> how did these openssl failures creep in

04:33 <Grommish> I've got the switch working, but only 4 of the 5 ports ;/ port0 on the switch refuses to work

04:34 <owrt-snap-builds> Build [#2](https://buildbot.openwrt.org/master/images/#builders/23/builds/2) of `mpc85xx/p2020` completed successfully.

04:34 <Grommish> port1-4 work normally.. eth0-eth4 on the mt7621 work as well

04:34 <Grommish> Buggin the hell outta me as to why it refuses to work

04:35 <pkgadd> Grommish: (boring, almost default) network config of the tl-wr1043nd v1, http://paste.debian.net/hidden/6e5e1b82/

04:36 <Grommish> pkgadd: This is what I've got so far.. https://gist.github.com/Grommish/c9ac775fc9041e676e092a3f5750ccf9

04:37 <Grommish> Port 6 is the DSA CPU port for the switch

04:38 <Grommish> but I have no experience with switch configs under Openwrt.. Not used them before

04:39 <pkgadd> swconfig configuration is quite nice with luci

04:40 <Grommish> VLAN 1: info: VLAN 1: Ports: '06', members=0041, untag=0041, fid=0 ports: 0 6

04:40 <Grommish> Wonder if that's why

04:42 <Grommish> Well.. that broke it good

04:42 <pkgadd> Grommish: this would be a slightly more complex swconfig configuration, http://paste.debian.net/1189560/

04:43 <Grommish> It's wierd because eth5 (port0 on the switch) is competely dead.. doesn't even recognize a cable plugged in.. but the rest of the switch is afine

04:46 <pkgadd> just to visualize the config above in luci, https://imgur.com/a/U4G6HN3

04:53 <Grommish> pkgadd: *nod* I was going to try luci to see what it showed, but the port being dead just annoys me to no end hehe

04:55 <Grommish> I need to figure out the dead port, then try to figure out the leds

05:00 <damex> Grommish: you can disable ports by corresponding status definition in device tree node

05:00 <damex> if it is actually considered dead

05:00 <Grommish> damex: It works under EdgeOS

05:00 <Grommish> It flashes alive on boot

05:00 <damex> edgeos this. edgeos that

05:01 <Grommish> The physical port is fine, whatever in openwrt is not bring it up while the rest of the switch ports are fine

05:02 <Grommish> this is that wierd ass er10x with the external phy swith

05:02 <Grommish> So you'd think it would ALL work, or not work at all ;/

05:06 <Grommish> damex: ;p and I"m trying to get away from EdgeOS

05:07 <damex> Grommish: the constellation is so special or ubiquiti guys dodn't know any better

05:08 <damex> so 5 port mtk switch connected via rgmii link to mt7621 mac ?

05:09 <Grommish> 5 port rtl8367rb connects via rgmii2(?) to the mt7621

05:10 <damex> Grommish: does rtl8367rb even have driver with DSA support?

05:10 <Grommish> damex: Nope.. swconfig

05:10 <Grommish> At least, not that I can find

05:11 <Grommish> but like I said, rtl8367rb port 1-4 are fine.. port 0 just refuses to acknowledge it's even there

05:11 <damex> eww, whole mt7621 is (mostly/or fully by now) a dsa target

05:11 <Grommish> dsa is setup on port 6 for the mt7621

05:11 <Grommish> but it all funnels thru eth5 it seems

05:12 <damex> i don't think you want have dsa+swconfig on single system

05:13 <Grommish> mangix: Holy sh!t.. I just ran the ld vs ld.gold

05:15 <Grommish> mangix: https://gist.github.com/Grommish/c3e4645a9d81045d3b381321a9c37fb3 Both builds from a rm -rf bin/ build_dir/ staging_dir tmp/ .ccache/

05:15 <Grommish> damex: I don't think I have to choice unless I want to lose half the ports on the device

05:15 <mangix> Grommish: that is...impressive

05:16 <Grommish> I run make -j5 to build

05:16 <damex> Grommish: https://forum.openwrt.org/t/ubiquiti-edgerouter-10x-er-10x/42980/41 so just 5th port does not work?

05:16 <Grommish> damex: Right.. eth5 should be port0 on switch0. port1-port4 work

05:18 <lipnitsk> Grommish: do you have dmesg?

05:18 <Grommish> lipnitsk: if not, I can opkg install it.. I'm using defconfig, but adding the rtl8367rb drivers in the 5.10 kernel

05:19 <lipnitsk> Grommish: pastebin your dts and dmesg output

05:21 <Grommish> lipnitsk: One sec.. I've got to rebuild from testing

05:21 <Grommish> lipnitsk: dts https://gist.github.com/Grommish/e595092b4702ff581045fb85eb6d4a8e

05:23 <mangix> Grommish: how did you get those numbers. Was it just a difference between the second commit?

05:24 <Grommish> mangix: Right.. I have my standard kernel-5.10 branch.. that's the without.. the only different between the two are your two patches

05:24 <Grommish> with the removal of the directories before each build

05:25 <Grommish> and just a time make -j5 for each *shrug* seemed like the easiest way to A/B test

05:26 <mangix> Those numbers make no sense to me. Can you try just by applying both patches and reverting/keeping the last one?

05:28 <Grommish> What do you mean? I rebased from master, removed bin/ build_dir/ staging_dir/ tmp/ .ccache/, built with time make -j5 Switched branches from master, cherry-picked your 2 commits, removed the same dirs and built again

05:28 <Grommish> So the only difference is your 2 commits *shrug*

05:30 <Grommish> but, I'll run it again later for ya if you'd like

05:30 <Grommish> I need to get the toolchain for the er10x rebuilt (I built for the Itus device) so it's doing that at the moment

05:32 <Grommish> I can only report the output of the time command *shrug*

05:33 <mangix> Grommish: time command is good enough

05:34 <Grommish> but yeah, I

05:34 <Grommish> err I'll rerun it later

05:34 <KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 98.1% packages reproducible in our current test framework.)

05:34 <Grommish> if I cherry pick and revert, the toolchain will be set to build with gold

05:34 <Grommish> so I'd have to remove it anyway

05:35 <mangix> hmm funny

05:35 <mangix> -mips64r2 -mtune=mips64r2 -mabi=64 does not support PAUSE but -mips32r2 -mtune=mips32r2 -mabi=32 does

05:35 <mangix> figure that one out

05:36 <Grommish> We dealt with that before

05:36 <Grommish> Something with MIPS16 being defaulted to on

05:36 <Grommish> which predated PAUSE opcode

05:36 <Grommish> might start there

05:37 <mangix> nope. has nothing to do with mips16

05:37 <Grommish> gotcha.. that' the only time I've seen an issue with PAUSE

05:37 <mangix> those three parameters are the only difference

05:37 <mangix> gotta love it

05:37 <Grommish> If you can search the irc logs, it was.. a month ago? maybe?

05:38 <mangix> I remember the discussion. I assumed it was just an octeon problem. looks like no :)

05:38 <lipnitsk> Grommish: rtl8367b only has port5, right? the other 5 ports (eth0-eth4) come up ok?

05:38 <Grommish> lipnitsk: eth0-4 are fine.. eth6-9 (switch0:1-4) are fine.. eth5 which should be switch0:0 is dead

05:39 <Grommish> eth0-4 are on th mt7621

05:39 <Grommish> 5-9 on the rtl

05:39 <lipnitsk> Grommish: okay, i see.

05:39 <lipnitsk> Grommish: 6-9 come up but not 5?

05:39 <Grommish> Right

05:40 <Grommish> eth5 doesn't even acknowledge a cable plugged in

05:40 <lipnitsk> how come eth5 is so special? And where does eth0 map if eth5 is switch0:0?

05:40 <lipnitsk> mangix: :help cmd

05:40 <Grommish> eth5 is the external phy

05:41 <mangix> lipnitsk: I know it at a basic level, but that's not good enough

05:41 <Grommish> lipnitsk: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/dsa/mt7530.txt#L43 and https://forum.openwrt.org/t/ubiquiti-edgerouter-10x-er-10x/42980/47 if you're interested

05:41 <mangix> I recently figured out that dd is not delete but cut...

05:43 <mangix> lipnitsk: didn't know there was such a thing as 1.2gb ethernet...

05:43 <lipnitsk> internally

05:43 <lipnitsk> just for the CPU port

05:46 <lipnitsk> mangix: https://lore.kernel.org/netdev/20190616182010.18778-1-opensource@vdorst.com/

05:52 <lipnitsk> mangix: yeah but, effectively dd is delete. unless you care about what's in your default register or whatever

05:52 <mangix> interesting to say the least

05:52 <mangix> lipnitsk: dd + p = cut + paste

05:52 <lipnitsk> ya

05:52 <mangix> i was googling how to paste in vim

05:53 <lipnitsk> p - paste after cursor, P - paste before cursor

05:53 <lipnitsk> you can also paste with mouse in insert mode ;)

05:54 <mangix> one cool thing I found out is that this vim setup (well nvim actually) automatically wraps commit messages to 72 characters per line

05:54 <lipnitsk> can't say I'm a super expert, but been using it for a number of years and what I know is enough for me..

05:55 <mangix> quite convenient for OpenWrt commits

05:55 <lipnitsk> yeah, there are some cool plugins that do all sorts of stuff too

05:55 <mangix> I saw this guy's nvim config and replicated to force myself to use nvim. didn't last long.

05:55 <mangix> but now I need to since nano doesn't work right on this terminal

05:58 <mangix> fascinating. just saw an ebay listing for a broadcome router. wonder what that is.

06:13 <lipnitsk> Grommish: maybe eth5 is an internal port similar to 'dsa' and there is a conflict. have you tried using a different label for port@5?

06:14 <lipnitsk> Grommish: ie both mt7530 and rtl8367 drivers are trying to bring it up?

06:14 <Grommish> lipnitsk: Not yet.. this compile is about finished and I can change things quick and easy then. i'm flashing from TFTP to sdram so its quick

06:15 <lipnitsk> Grommish: I'm going to bed now, sorry. but it seems you are close. probably need to make it work with DSA though anyway.. but it's a start.

06:15 <Grommish> I can't find a dsa driver for it .. meh

06:15 <Grommish> but yeah, it'll get fixed eventually :) Gnight!

06:38 <lxy> Hello, I want to add a procd trigger to watch some files, but not the uci files. How to?

06:39 <lxy> It seems that "procd_add_reload_trigger" does not take effect.

06:40 <lxy> https://openwrt.org/docs/guide-developer/procd-init-scripts#specifying_triggers

07:34 <Grommish> lipnitsk: For tomorrow - https://gist.github.com/Grommish/8fef54a79f6dc6e07d8dff3bd495ec20

07:43 <owrt-snap-builds> Build [#3](https://buildbot.openwrt.org/master/images/#builders/10/builds/3) of `bcm63xx/smp` failed.

08:13 <rsalvaterra1> 'mornin!

08:14 <Grommish> rsalvaterra1: Hey hey :)

08:15 <rsalvaterra1> mangix: Don't drop those. I only added patches to fix things, not to backport the latest device tree changes, although I have them in my tree. :)

08:16 <rsalvaterra1> mangix: https://github.com/rsalvaterra/openwrt/commit/fb214850fba0c9cefbe1840ab5b8b16bb2d37b21

08:19 <rsalvaterra> Grommish: Hey, mate! Looks like you're making progress, heh? :)

08:20 <Grommish> port0 on the switch still is dead for whatever reason :) It's super odd :) Any idea how I can set kernel CONFIG flags for just the er10x without changing config-5.10?

08:23 <rsalvaterra> Grommish: You can't, as far as I know… :/

08:23 <Grommish> Hmm.. I've got 5 changes to the kernel I need to set that won't be used in any other ramips device i wouldn't think

08:24 <rsalvaterra> Grommish: Which additional symbols do you need?

08:25 <Grommish> CONFIG_MDIO_DEVRES, CONFIG_RTL8366_SMI, CONFIG_SWCONFIG, CONFIG_RTL8367B_PHY, CONFIG_RTL8367_PHY

08:25 <rsalvaterra> Ouch… a swconfig driver.

08:25 <Grommish> no dsa that I can find for the rtl8367rb

08:26 <Grommish> But yeah, the entire rtl8367 is piped thru eth5, which is why its odd only one port on that switch doesn't work, but the other 4 do *shrug*

08:27 <rsalvaterra> Probably we'll just have to bite the bullet and enable the rtl8367rb on ramips/mt7621, for the time being…

08:28 <Grommish> I already have to hacky out target/linux/generic/files/drivers/net/phy.. this is getting ugly hehe

08:29 <Grommish> rsalvaterra: https://github.com/Itus-Shield/openwrt/commit/789faf443404d89d211ebcab5a2da2459d6526cc

08:30 <Grommish> That gives me 9 of the 10 ports *shrug*

08:32 <Grommish> wonder if I should change 0:lan to 1:lan and shift everything down

08:32 <Grommish> on the switch define

08:32 <rsalvaterra> Grommish: Could be… port numbering is weird.

08:33 <pkgadd> Grommish: perhaps read a bit into the easybox 904 xDSL porting, which also uses two switches (lantiq and rtl8367b), with weird internal VLAN connections

08:33 <Grommish> pkgadd: I'll take a look.. the switch works, but just the one port refuses to work

08:34 <Grommish> it's like it disabled, doesn't even recognize a cable plugged into it

08:37 <Grommish> rsalvaterra: Nope.. No change.. meh

08:38 <guidosarducci> Grommish: FYI, I just added the module for CONFIG_MDIO_DEVRES, kmod-mdio-devres

08:38 <Grommish> guidosarducci: Oo.. Thanks! :)

08:40 <nitroshift> rsalvaterra, 0/

08:41 <rsalvaterra> nitroshift: Hey, mate! How's it going? :)

08:42 <nitroshift> rsalvaterra, did you forget about HAVE_ARM_ARCH_TIMER in 5.10 config?

08:42 <nitroshift> it doesn't seem to be enabled

08:42 <nitroshift> *enabled --> defined

08:42 <pkgadd> Grommish: yeah, I would normally expect the switch not to work (respectively not allowing access to the SOCs sshd without proper VLAN setups)

08:43 <rsalvaterra> nitroshift: Nope. The Armada 385 is Cortex-A9, doesn't implement the ARM architectural (per-CPU) timer.

08:43 <rsalvaterra> Only the ARM global timer.

08:43 <nitroshift> ah i see

08:44 <nitroshift> it should be defined as not set nonetheless, shouldn't it?

08:44 <rsalvaterra> The architectural timer is implemented starting in Cortex-A15.

08:45 <nitroshift> rsalvaterra, i'm doing a build from master right now and it stopped asking about that

08:45 <rsalvaterra> nitroshift: I think that's already defined in the generic config, isn't it?

08:47 <rsalvaterra> Oh, wait, it probably doesn't even need to be specified, if it's one of the filtered symbols.

08:49 <rsalvaterra> nitroshift: Right, it's a CONFIG_HAVE_*, it doesn't have to be specified. https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/config-filter;h=719487be5fc73a448a734bca0eb9f8a8fc3a0b70;hb=HEAD

08:50 <nitroshift> rsalvaterra, strange

08:51 <nitroshift> must be my local clone....

08:55 <rsalvaterra> git log

08:55 <rsalvaterra> Ouch. Wrong terminal, sorry.

08:56 <EqUaTe> rsalvaterra: you say that like not everyone does it :)

08:57 <rsalvaterra> :P

10:03 <rsalvaterra> OMG, I just noticed my jffs2 zstd implementation has two perfectly avoidable *backwards* goto. The perils of copy-paste…

10:04 <Borromini> zx2c4: congrats on the FreeBSD port. sucks to get that kind of flak from netgate for actually helping *them* out >_>

10:06 <rsalvaterra> Borromini: Come on, it's not like Netgate is making money out of it… *rolls eyes*

10:07 <Borromini> :P

10:08 <Borromini> seems they kind of stonewalled him and now they're complaining about fallout and bad press for them

10:08 <Borromini> https://lists.zx2c4.com/pipermail/wireguard/2021-March/006499.html

10:14 <jow> nbd: I've started looking at luci/dsa again to get it in shape for the release

10:15 <jow> nbd: I encountered two issues I consider blockers

10:15 <jow> nbd: 1) when we have conflicting settings (config interface lan + option type bridge and config device; option type bridge; option name br-lan) - which one is preferred? Currently it seems that the behaviour is undefined

10:17 <jow> nbd: 2) what is the proper way to attach wifi-iface specific wireless netdevs as "config device; option type bridge" ports? It seems ucrrently the only ways are either a) "list ifname wlanX" in "config device" which is highly discourages due to the dynamic nature of wireless netdev naming

10:17 <grift> karlp: thanks for updating libwebsockets, turns out that did not fix my ttyd ssl issues but still appreciated

10:17 <jow> or b) utilizing "option network" in "config wifi-iface", but that requires an intermediate "config interface" referencing the target bridge

10:19 <jow> you proposed an "option network_vlan" a while back (http://lists.openwrt.org/pipermail/openwrt-devel/2020-July/030397.html) but it seems it didn't materialize in netifd yet?

10:20 <karlp> grift: no problems, it was well overdue, and it's much bigger than it used to be, but hey, "latest is greatest"

10:20 <karlp> and at least this version works on both ttyd and mosquitto.

10:21 <jow> I can work around 1) in LuCI by forcing a migration from "config interface lan; option type bridge; option ifname ..." to "config interface lan; option ifname br-lan" plus "config device; option name br-lan; option type bridge; option ifname ..."

11:59 <karlp> and.... what a surprrise, wolfssl + libwebsockets doesn't actually work....

12:53 <nbd> jow: with dsa, we'd have a switch0 bridge with two vlans. we should name the vlan devs something like sw0-lan, sw0-wan and use them as ifname in the config interface lan/wan section

12:53 <nbd> lan/wan interfaces will then no longer be bridges, but you can still use option network lan in wifi-iface sections

12:53 <nbd> there is no need to create device sections for wifi ifaces

12:53 <nbd> netifd will figure out that the vlan device sits on top of a vlan-filtering bridge

12:54 <nbd> and add the ports dynamically

12:54 <jow> I know, currently writign a summary mail with the problems I see

12:54 <jow> a lot can be solved by shipping a different default config that makes the switch0 bridge declaration explicit

12:54 <jow> we should phase out implicit bridging entirely

12:54 <nbd> i agree

12:55 <nbd> we should keep support for it in netifd, but once configs have been migrated, we can phase out simple ui support for it

12:56 <jow> one piece of the puzzle I miss is the ability to attach wifi-ifaces to config device bridges without requiring a dummy config interface

12:57 <jow> right now the netdefs are bridged into (wireless.wifi-iface.network -> network.interface.ifname -> network.device.name)

12:57 <jow> *wireless netdevs

12:57 <nbd> for normal configurations you have a interface set up on each relevant vlan, right?

12:59 <jow> Not necessarily

12:59 <jow> I mean sure, if with "normal" you mean lan + wan

12:59 <jow> and nothing else

12:59 <nbd> if you don't, you could still set up a proto=none interface for the relevant vlan

12:59 <nbd> and use that in option network in wifi-iface

13:00 <jow> I know, and I don't like it

13:00 <nbd> so you wouldn't refer to dummy interfaces from bridge port listings

13:01 <jow> requiring dummy config interfaces w/ proto none made a little bit more sense when we did implicit bridging at the same time, so that these actually declared the target bridge

13:01 <jow> now with bridge devices declared as config device, they're just redundant config churn

13:02 <jow> I'd rather wish for an wireless.wifi-iface.bridge which simply refers to a netdev (e.g. br-lan)

13:03 <jow> no implicit behaviour choices based on type of target interface (and type of device referenced by target interface)

13:04 <nbd> so you'd prefer to specify bridge and vlan settings explicitly as two options?

13:05 <jow> you mean bridge membership or layer 3 settings? VLAN settings are separate in either case

13:05 <nbd> bridge port vlan membership

13:05 <jow> either option network + option network_vlan to select vlan within target bridge

13:05 <nbd> brb

13:06 <jow> yes, I'd prefer bridge port membership to be explicit

13:06 <jow> option network is too overloaded with different configuration semantics

13:09 <jow> if the target config interface is unbridged (option type bridge removed or ifname changed to something not being a bridge), I'd rather see the wireless netdevs become orphaned than suddenly inheriting layer 3 protcol settings in an undefined manner

13:09 <jow> so that you end up with two interfaces running a dhcp client, or worse having the same static ip settings or just one of the former members

13:09 <jow> ... having them

13:22 <nbd> jow: from a ui consistency point of view, i actually strongly prefer the option network variant

13:22 <nbd> because it means that wifi interface network settings can be assigned with one single drop down

13:22 <jow> from being the one implementing the ui I can assure you that there is no consistency at all

13:22 <jow> the code has grown extremely complex

13:23 <nbd> why not just allow selecting any interface as network for the wifi iface?

13:23 <jow> because in my tests it results in undefined behaviour

13:24 <nbd> which tests?

13:24 <jow> multiple interfaces inheriting the same layer 3 settings for example

13:24 <jow> also keep in mind that option network is actually a list

13:24 <jow> you can attach a wifi-iface to multiple networks

13:25 <jow> got knows what happens if one is a bridge or happens to reference a bridge and the other is not

13:25 <nbd> what was the use case for supporting network as a list?

13:27 <nbd> maybe the first step in reducing complexity would be to get rid of that

13:28 <jow> wireless wan

13:28 <jow> having both wan and wan6

13:30 <nbd> one way to deal with that would be to add a way to assign wan6 to wan without making it depend on wan being up

13:30 <nbd> then network could go back to being a single option

13:31 <nbd> and we'd get rid of some corner cases that way

13:31 <nbd> and we'd get rid of some duplication of ifnames in /etc/config/network while we're at it

13:31 <nbd> specify the wan device only in the wan section

13:32 <jow> there is no duplication of ifnames

13:32 <jow> typically in the non-bridge case, the target interface has no option ifname

13:32 <nbd> i mean for the non-wireless wan case

13:32 <nbd> where we typically throw the same ifname in both wan and wan6

13:33 <jow> usually we throw @wan in wan6

13:33 <nbd> i think we got rid of that

13:33 <nbd> because that would mean with dhcp, ipv6 connectivity depends on ipv4 connectivity

13:34 <nbd> if wan6 would use @wan, there would be no need to specify both wan and wan6 as wifi-iface network

13:34 <jow> correct

13:34 <nbd> so all we need is a way to make wan6 inherit the l2 device of wan

13:35 <jow> I just tried just setting "option network wan" in a wifi-iface btw, didn't work

13:35 <nbd> with @wan in wan6 ifname?

13:35 <nbd> or what kind ofconfig?

13:35 <jow> wan kept its ip settings, wlan0-1 ended up being unconfigured (which is fine, better than both inheriting settings or even worse, randomly either wlan or ethernet getting them)

13:35 <nbd> ah

13:36 <jow> but it also means that it is not consistent from an ui perspective

13:36 <jow> you still need to evaluate the target network, not offer interfaces which already have an ifname set (or if they have an ifname set, check if its a bridge or not, and only offer it if it is a bridge etc.)

13:37 <nbd> or let the user configure it, but report an error when attempting to set it up

13:37 <nbd> an error which clearly indicates what's wrong

13:37 <jow> so in short, the same magic wrt. option network that happens in netifd, needs to be replicated in the ui, only with less state available

13:37 <nbd> we could make netifd report an error for a wifi-iface that couldn't be assigned to a network

13:37 <nbd> and then the ui could easily tell the user what's wrong

13:38 <jow> yes, would be an improvement

13:39 <jow> next problem is config interface xxx + option type bridge vs. config device + option type bridge + option name br-xxx clashes

13:39 <jow> also something the ui needs to handle atm

13:39 <jow> which becomes a non-issue once I remove support for implicit bridging

13:40 <jow> but right now it is an issue, not sure how netifd handles it

13:40 <jow> ideally the config device should take precedence since it offers more bridge specific settings afair

13:45 <nbd> i think it merges the device settings currently

13:45 <jow> let me check

13:46 <nbd> no, wait. it overwrites the config blob

13:46 <nbd> since device gets parsed first, and the interface can overwrite it

13:46 <nbd> i guess i could change the code to simply pick the device instead

13:46 <rsalvaterra1> nbd: If possible, when you have time, would you please take a look at why mt76 breaks with mangix's musl 1.2.2 patch series? It builds, loads and runs, but something in broken in the EEPROM reading. I find it extremely odd, since musl is userspace and these are kernel modules… :/

13:47 <nbd> rsalvaterra1: what device?

13:47 <rsalvaterra1> nbd: All of mt76. In my specific case, MT7603 and MT7615.

13:48 <nbd> and what do you mean by "something in broken in the EEPROM reading"?

13:49 <rsalvaterra1> nbd: Simple: on my Redmi AC2100, when I build OpenWrt with musl 1.2.2, mt76 fails to read the correct MAC addresses and caldata.

13:50 <rsalvaterra1> The system works, but the signal strength is extremely low and the Wi-Fi MAC addresses are random.

13:52 <nbd> wow, that's really odd

13:52 <rsalvaterra1> It's particularly musl causing this… :P

13:53 <rsalvaterra1> But mangix has more details. Something related to stddef and endianness.

13:53 <zorun> possibly an issue with the caldata scripts? maybe something goes wrong in printf or other base tools

13:54 <rsalvaterra1> zorun: No scripts involved. The driver reads the data directly.

13:54 <rsalvaterra1> zorun: It's not the same as ath9k or ath10k.

13:54 <zorun> ah ok, it's different then

13:55 <Borromini> zorun: eeprom location is set in the dts for mt7621

13:55 <Borromini> unless i'm speaking out of turn

13:57 <rsalvaterra1> Borromini: You're not, it's exactly like that.

13:58 <Borromini> rsalvaterra: is this a nand device?

13:58 <rsalvaterra> Borromini: Yes, it is. 128 MiB.

13:59 <Borromini> but it works when you roll back the musl bump right

14:00 <rsalvaterra> Borromini: Yes, it works with the current musl. Weird as hell.

14:00 <rsalvaterra> Borromini: Here's the relevant device tree: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/dts/mt7621_xiaomi_router-ac2100.dtsi;h=7e6b3afcdf008dc6506bd09b207ec64770a59bbf;hb=HEAD

14:02 <Borromini> this might be silly, but hexdumping the factory partition returns the same contents before and after? you probably already checked that

14:02 <jow> nbd: last question; for wifi-iface netdevs, the bridge vlan membership is inherited from the target interface's ifname, right? So if there's a config interface vlan200; option ifname switch0.200 and a wifi-iface with option network vlan200, It'll end up as port in the bridge vlan with vid 200?

14:03 <rsalvaterra> Borromini: Yes, I hexedumped to compare. It's untouched by OpenWrt (and it better be :P).

14:04 <rsalvaterra> *hexdumped

14:05 <karlp> grift: are you https://github.com/openwrt/packages/issues/14577#issuecomment-800265515 ? (doverride on github?)

14:05 <karlp> sounds like your ttyd ssl issue should be fixed?

14:05 <grift> yes thats me

14:06 <grift> took the time to dig a little deeper after it became clear that libwebsockets had nothing to do with it

14:10 <nbd> jow: yes

14:10 <grift> karlp: and yes ttyd finally now works with acme/letsencrypt

14:20 <mangix> rsalvaterra: nbd: kernel modules need -most since passed with musl 1.2.0

14:20 <mangix> otherwise endianness issues occur

14:20 <mangix> *-nostdinc

14:21 <rsalvaterra> mangix: Thanks for explaining it better than me. :)

14:22 <mangix> This big was always there but musl 1.2 exposed it

14:22 <mangix> *bug

14:27 <owrt-snap-builds> Build [#3](https://buildbot.openwrt.org/master/images/#builders/14/builds/3) of `bcm63xx/generic` failed.

14:32 <nbd> mangix: shouldn't that be up to the kernel build system to pass that flag?

14:32 <nbd> is there an upstream commit that fixes it?

16:06 <Neighbor11111112> Hi all, if I build the kernel using make target/linux/install does that automatically update the firmware image as well? Or do I have to run another command to build the firmware image?

16:09 <owrt-2102-builds> Build [#4](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/61/builds/4) of `ramips/mt7621` completed successfully.

16:52 <rsalvaterra> Something's fishy with pinmux on ubnt XM hardware…

17:50 <lipnitsk> blocktrron: do you think https://github.com/openwrt/openwrt/pull/3960 aged enough to merge it into 21.02?

17:52 <Borromini> works fine here :)

18:45 <hurricos> Grommish: RE: https://github.com/openwrt/openwrt/commit/7379f8bd: what we really need is to teach people how to use a subset of buildbot.

18:46 <hurricos> I spend like ... no time actually articulating builds these days. It's just commit/push, add diffconfig + files, then `make output-${remote}_${revision}` and wait

19:29 <hurricos> Grommish: I updated https://git.laboratoryb.org/hurricos/docker-builder.git with much better documentatoin

19:34 <grift> i am toying with an idea to hold recurring test day's, i shamelessly copied that idea from fedora test day. it would look something like this (rough sketch) http://sprunge.us/s1NYlF

19:36 <grift> now sure i dont expect much participation in the first 3 or 4 test day's but it might pick up as people get used to the announcements posted in forums, mailing lists and other mediums

19:43 <grift> ill refine the idea but i can sense the excitement for the prospect, thats a good sign and inspirational

19:44 <grift> inspiring*

20:14 <Grommish> hurricos: Half the time a build fails it's a PITA to figure out why the build-bot died :p I honestly find it's easier to build locally for anything I need, but maybe it's because I never learned to use Git actions to build it for me..

20:16 <Grommish> I just do a make -j5 || make -j1 V=sc and come back in 15 minutes to see what happened

20:16 <lipnitsk> Grommish: isn't it usually searching the build log for "Error" or similar?

20:17 <Grommish> lipnitsk: or "***", but "error" can occur in many places that arent fatal

20:27 <mangix> nbd: the Makefile overrides all NOSTDINC_FLAGS

20:28 <mangix> It should be adding to them

20:37 <karlp> Grommish: turn onbuild logs and just do "grep -r '\*\*\*' logs" instead ?

20:57 <Grommish> karlp: Probably, but the original conversation revovled about ImageBuilder and making it too easy for people who don't want to get hands dirty making silly demands

20:58 <Grommish> karlp: It's why I just OR-gate the -j1 V=sc if it fails, it'll tell me why pretty easily

21:01 <aparcar[m]> mangix: https://patchwork.ozlabs.org/project/openwrt/patch/20210308231452.1585178-1-mail@aparcar.org/

21:01 <aparcar[m]> can you please test that?

21:38 <hurricos> Grommish: fair shake. My strat was to strip out the base imgae of the buildbot and script / layer away the process of cloning down everything from scratch ...

21:39 <hurricos> so it gives me a really really clean environment with exactly whatever crappy tree I want

21:39 <hurricos> and you can use the debug- rather than output- target from my docker-builder to persist the docker image after it dies to see what messed up

21:39 <hurricos> or rather it drops you to a shell.

23:09 <karlp> Grommish: yeah, but it takes way longer?

23:16 <mangix> aparcar[m]: bookmarked

23:18 <aparcar[m]> mangix: gracias

23:23 <rsalvaterra> Is it normal to see a one-armed router's switch configured with a single untagged VLAN during boot? My laptop is connected to an TL-WDR3600 and is receiving the IP address from the DHCP server upstream of the WDR3600(!!).

23:26 <rsalvaterra> I mean, it's not completely surprising, but still…

23:31 <mangix> rsalvaterra: did you try getting musl 1.2 to work with mt76?

23:34 <rsalvaterra> mangix: I did, but no cigar… that's why I asked for nbd's help, I was hoping it would be obvious to him, but he was as surprised as I was.

23:37 <lipnitsk> rsalvaterra: so why do we need GENERIC_CLOCKEVENTS_BROADCAST if we are not using cpuidle?

23:41 <rsalvaterra> lipnitsk: We don't strictly need it, but it's a form of documentation. It means we have a global timer (GIC) capable of waking up the cores if they go to sleep. Of course, we have no cpuidle driver for the 1004Kc, and I don't even know if it makes sense to write one (haven't dived in the datasheet), but at least we have that information.

23:42 <rsalvaterra> At least this is what I understood from reading the code and the documentation I found about GENERIC_CLOCKEVENTS_BROADCAST. If I'm lying through my teeth, someone please yell.

23:43 <lipnitsk> rsalvaterra: then should it be a weak dependency, 'imply'? Or better yet, an actual documentation entry? :) How much extra code are we talking?

23:43 <lipnitsk> rsalvaterra: just seems weird to compile in code that is unused

23:44 <lipnitsk> rsalvaterra: the patch does need to be split up regardless though, so I hope your change gets merged. we can optimize the code size as a future activity

23:44 <rsalvaterra> lipnitsk: It's not that much code: https://elixir.bootlin.com/linux/v5.10.23/A/ident/CONFIG_GENERIC_CLOCKEVENTS_BROADCAST

23:46 <rsalvaterra> Actually, I think I found something…

23:46 <rsalvaterra> The 1004Kc is a CPS (Coherent Processor System) arch.

23:52 <lipnitsk> so can we use https://github.com/torvalds/linux/blob/fcadab740480e0e0e9fa9bd272acd409884d431a/drivers/cpuidle/cpuidle-cps.c ?

23:54 <lipnitsk> in other news, mt7621 NAND driver is something that should be upstreamed... And there have been attempts, but not too successful so far.

23:54 <lipnitsk> 1. https://patchwork.ozlabs.org/project/linux-mtd/patch/1585678079-5999-1-git-send-email-weijie.gao@mediatek.com/ - OpenWrt uses this one

23:54 <lipnitsk> 2. https://lore.kernel.org/lkml/20191107073521.11413-1-gerg@kernel.org/

23:54 <rsalvaterra> lipnitsk: For some reason I wasn't able to select any MIPS cpuidle driver… I need to see what's missing.

23:54 <lipnitsk> 3. https://github.com/torvalds/linux/blob/master/drivers/mtd/nand/raw/mtk_nand.c - similar, but not quite the same driver?

23:55 <mangix> rsalvaterra: add --nostdinc to NOSTDINC_FLAGS

23:55 <mangix> sorry -nostdinc

23:56 <mangix> lipnitsk: it never will

23:56 <mangix> the issue is the driver is too similar to the already existing one

23:57 <rsalvaterra> mangix: Ok, I'll try a new build with -nostdinc tomorrow. You mean here, right? https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/mt76/Makefile;h=b60afb355d2ac7ed221a7603e1ca6fc2205a3bcf;hb=HEAD#l321

23:57 <lipnitsk> mangix: well right, maybe extending the existing won't be that hard?

23:57 <mangix> rsalvaterra: no 2 lines down

23:57 <mangix> lipnitsk: close to impossible without breaking the hardware already using it

23:58 <lipnitsk> mangix: has someone tried?

23:58 <mangix> let me find some logs for you

23:58 <rsalvaterra> mangix: After modules?

23:59 <rsalvaterra> lipnitsk: Ok, I was able to enable the driver!

23:59 <lipnitsk> rsalvaterra: yay. and it selects GENERIC_CLOCKEVENTS_BROADCAST when needed, too, btw