<eduardas>
a colleague got some cheap Chinese routers, don't really remember the brand
<eduardas>
said they have u-boot-2016 on them
<eduardas>
which is probably a fork of this
<eduardas>
not sure how we're gonna get an u-boot onto it, though
kab-el has joined #openwrt-devel
phong has joined #openwrt-devel
<eduardas>
if anyone knows any hacker-friendly Wi-fi 6 hardware one can buy, please let me know :)
<pkgadd>
mediatek should be easier (but still only very few devices - and not really interesting ones). ipq807x is much further ahead than ipq60xx or ipq50xx (by at least 2 years)
<pkgadd>
but you should consider if you really need to work on the u-boot side - or if just working on kernel+rootfs is enough
<eduardas>
pkgadd: is ipq807x Wi-fi 6 capable?
<pkgadd>
yes
<eduardas>
pkgadd: that is really useful to know, thanks... I have not really looked into mainline support much yet
<pkgadd>
things like xiaomi ax3600, redmi ax6, netgear rax120, asus rt-ax89x
<pkgadd>
neither of them is supported officially by OpenWrt yet, but there seems to be a lot of interest behind the ax3600 (and some initial efforts which appear to work to quite some extent)
<nitroshift>
nbd, mail sent, please let me know if it reached you
goliath has joined #openwrt-devel
valku has quit [Ping timeout: 260 seconds]
valku has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
quark_ has quit [Ping timeout: 260 seconds]
gnustomp has quit [Ping timeout: 260 seconds]
black_ant has quit [Ping timeout: 258 seconds]
<nbd>
nitroshift: yep, it arrived, thanks
gnustomp has joined #openwrt-devel
<nitroshift>
nbd, hope it's ok. wouldn't have made it without rsalvaterra's help
Ycarus has joined #openwrt-devel
quark_ has joined #openwrt-devel
ivanich has joined #openwrt-devel
Borromini has joined #openwrt-devel
kab-el has quit [Ping timeout: 240 seconds]
kab-el has joined #openwrt-devel
<russell-->
can someone help me convert this slightly complicated vlan config to current DSA language? https://pastebin.com/4j8UTyFX
rsalvaterra has joined #openwrt-devel
<rsalvaterra>
'morning!
feriman has joined #openwrt-devel
<rsalvaterra>
Today I woke up thinking… do you guys have some procedure as to how to rebase conflicting patch files, or is it as horrible as I imagine it to be? :P
<rsalvaterra>
(It hasn't happened to me… yet…)
* nitroshift
hands rsalvaterra a mug of hot coffee
<nitroshift>
morning
<rsalvaterra>
nitroshift: I'm actually having coffee as we speak. :P
<rsalvaterra>
Have you been able to configure git-email? :)
<nitroshift>
yep
<nitroshift>
this morning
<nitroshift>
yahoo changed their security mechanisms
<nitroshift>
but managed to do it eventually
* nitroshift
lets the cat in stintel's bedroom
<rsalvaterra>
Great! Now you can send patches by email. Like everything in life, it's easy when you know how. :)
<nitroshift>
and it's even easier when someone with more experience guides you
<nitroshift>
brb, cigarette time
<Borromini>
git send-email is pretty neat :)
<rsalvaterra>
Borromini: It's magic. But hard to grasp for a git beginner, for sure.
<Borromini>
well once you set your git config...
<Borromini>
sure, you need to read a bit
* Borromini
is looking at one of those realtek switches with PoE
<Borromini>
damex: yeah although that is apparently a list of possible targets
<Borromini>
looking at the zyxel gs1900-8hp
samantaz_ has quit [Ping timeout: 246 seconds]
<damex>
Borromini: are you sure it has the same switch inside? there is just GS1900-10HP
<Borromini>
damex: no, good point, that's not the 10 port i'm looking at...
<damex>
i really want to replace my ubnt edgeswitch 8 150w with one of that switches (as long as it runs openwrt)
kab-el has quit [Ping timeout: 240 seconds]
<damex>
but es8 is kinda LARGE
<Borromini>
:)
<Borromini>
i'm still debating what to do best since i'll need a few PoE ports for APs, but i'm doing the wiring in the new place (there's nothing when it comes to network cabling)
<rsalvaterra>
I just wanted a 16-port multigig layer-3 smart switch which didn't cost an arm and a leg…
<Borromini>
rsalvaterra: and you didn't find it? :P
<damex>
actually 2.5L is not that bad but pretty sure it could be smaller if we use more efficient soc and oversubscribe poe ports a bit
<damex>
Borromini: is poe is 24v - edgerouter x sfp might fit ;p
<damex>
just for power for APs
<Borromini>
=)
<Borromini>
i'm looking at the er4 as edge router
<damex>
s/is poe/if poe/
<damex>
oh you
<damex>
it is not merged yet and have no idea when it will be
<Borromini>
but the er-x has too few ports to do switching really, i'd rather have a beefier edge router and an l2 switch behind for the remainder
<Borromini>
damex: no but pr is pending i saw, thanks for the work :)
<rsalvaterra>
Borromini: you're actually waiting for damex to merge er4 support so you can buy one? :P
kab-el has joined #openwrt-devel
<damex>
> 61 comments
<damex>
yeah... pending
<Borromini>
rsalvaterra: the pr looks pretty solid from where i stand (no coding experience beyond scripting though) so that's good enough for me :P
<damex>
comment*
samantaz_ has joined #openwrt-devel
<Borromini>
damex: depending on whose cup of tea it is it might take a while, really depends.
samantaz_ is now known as samantaz
<Borromini>
what i am wondering though: how's octeon's path into the future looking?
<damex>
Borromini: if we don't give up half way - there might be er6p and er12 + er12p support too
<damex>
Borromini: well, only changes are accepted that <fix some crap> not the ones that improve <target state>
<damex>
so dunno for now
<Borromini>
i thought i saw someone say octeon as an architecture might be dropped by cavium or marvell (who seems to own them now)?
<Borromini>
damex: ok.
<damex>
they make arm octeons now
<Borromini>
is this one mips?
<damex>
mips64
<Borromini>
ok :)
<damex>
it is actually looks like a dead end. lots of octeon devices have poor vendor support and target is pretty known on how it behaves and what is needed to get it working
<damex>
so providing openwrt for them might be a good choice ;p
<Borromini>
:P :P
Redfoxmoon has quit [Changing host]
Redfoxmoon has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
kab-el has quit [Ping timeout: 272 seconds]
kab-el has joined #openwrt-devel
<slh64>
marvell obviously bought cavium for the name, all they did is rebranding their armada 4080 (ARMv8) as cavium and letting octeon die
f00b4r0 has quit [Quit: Leaving]
<Borromini>
was cavium that successful?
<rsalvaterra>
blocktrron: ping
<slh64>
good question, but they seem to embrace it
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<damex>
cavium3 is still in production under the marvell name
Nick_Lowe has joined #openwrt-devel
<damex>
s/cavium3/octeon3/
Nick_Lowe has quit [Client Quit]
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rsalvaterra>
damex: Does the octeon on er4 have SIMD?
Borromini has quit [Ping timeout: 256 seconds]
<svanheule[m]>
Borromini: bear in mind that PoE switches with more than 8 powered ports usually have a built-in PSU and fans. Loud fans.
Nick_Lowe has joined #openwrt-devel
<damex>
rsalvaterra: it is not reflected in cpuinfo but architecture support that
<damex>
it also has fpu but it is not enabled on octeon target yet
<rsalvaterra>
This is (informed) speculation, but can't imagine the er4 being faster than, say, an APU2D4.
<rsalvaterra>
Quad-channel RAM? Am I reading this right?
<damex>
rsalvaterra: depends on model i guess. er4 have two H5TQ4G63CFR-RDC
<damex>
so we're currently trying to add support for er4 to <generic octeon target>
<damex>
fpu and other stuff is planned as an improvement
kab-el has quit [Ping timeout: 265 seconds]
<rsalvaterra>
I guess we can forget about the Neuron accelerator… :P
<damex>
if it brings something to the tablet (routing?)
<damex>
rsalvaterra: it is actually very specific in patches and there a public patches that implement offloading and other features
<damex>
we might add that (or try to upstream it)
kab-el has joined #openwrt-devel
<blocktrron>
rsalvaterra: whats up
gnustomp has quit [Ping timeout: 240 seconds]
Redfoxmoon has quit [Read error: Connection reset by peer]
grift has quit [Ping timeout: 244 seconds]
<rsalvaterra>
blocktrron: If I correctly read your hostapd commits, now all -full variants are built with support for 802.11u, is that true? :)
Redfoxmoon has joined #openwrt-devel
gnustomp has joined #openwrt-devel
Redfoxmoon has quit [Changing host]
Redfoxmoon has joined #openwrt-devel
grift has joined #openwrt-devel
opal has quit [Ping timeout: 240 seconds]
<blocktrron>
yes
<rsalvaterra>
Hmm…
<rsalvaterra>
In that case, I really want to make a hostapd-basic-openssl (because I'm stuck with openssl for tor and stubby)…
<rsalvaterra>
Shouldn't 802.11u be part of the -hs20 variants only?
opal has joined #openwrt-devel
dangole has joined #openwrt-devel
<blocktrron>
HS2.0 uses a subset of 802.11u
<blocktrron>
No, the other way around
<blocktrron>
Anyways, I don't see a benefit in the hs20 variant at all. If we continue doing this we end up with a million build variants
<dangole>
blocktrron: i would love to see all this be part of hostapd-full, however, i didn't manage to build wpad-full with hs20 features enabled, and it also only worked with openssl...
<dangole>
blocktrron: if building wpad-full with hs20 and 11u works, we can safely drop hostapd-hs20
<blocktrron>
dangole: *sigh* let me check
<blocktrron>
someone queried me yesterday informing me that wpad fails to build with my first patch
<blocktrron>
however I've pushed a fix which fixed that for me. wpad-full-wolfssl is the troublemaker?
<dangole>
blocktrron: internal crypto failed as well and apparently some weird symbol overlap when building wpad multicall
grift has quit [Ping timeout: 260 seconds]
grift has joined #openwrt-devel
victhor has joined #openwrt-devel
<blocktrron>
dangole: gimme a sec, I'm building wpad-wolfssl rn
daregap has joined #openwrt-devel
<rsalvaterra>
Ouch. Sorry for opening the tin of worms. :P
<rsalvaterra>
But the WirelessAPD section is a horrible mess…
<dangole>
rsalvaterra: well, not just that WirelessAPD section, but also hostapd itself...
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rsalvaterra>
blocktrron: I know hs20 is a subset of 802.11u, what I meant is there should be a -80211u variant, not -hs20. Maybe this would make more sense. :)
<dangole>
rsalvaterra: 802.11u is much older than hs20, hs20 supersedes 802.11u
<dangole>
blocktrron: i'm assuming DPP is also needed in practice for hs20
<blocktrron>
dangole: i only came for the ESR flag, so i cannot say much about hs2.0
<blocktrron>
Okay, wpad-wolfssl builds fine. I assume wpad-full w/o/ crypto is where things went south
Nick_Lowe has joined #openwrt-devel
grift has quit [Ping timeout: 260 seconds]
<blocktrron>
dangole: hmm, wpad-wolfssl as well as wpad w/o ssl build fine on master
grift has joined #openwrt-devel
eduardas has joined #openwrt-devel
grift has quit [Ping timeout: 240 seconds]
grift_ has joined #openwrt-devel
<dangole>
blocktrron: nice. i saw some linker breakage when i was working on it some months ago
<dangole>
blocktrron: feel free to drop hostapd-hs20 then, but please also add CONFIG_DPP to the full variant
<rsalvaterra>
And speaking of wolfssl, it builds and runs just fine with MIPS16. I don't know why it was disabled, but I guess probably some bugged gcc version.
<blocktrron>
dangole: I'll look into that in the coming days
<dangole>
blocktrron: thanks for cleaning this up!
<dangole>
rsalvaterra: the state of MIPS toolchain is in a shockingly bad condition. the recent mips64 fallout opened my eyes on how bad it is...
<Nick_Lowe>
802.11w in LuCI seems bust - does not appear when I have wpad-wolfssl installed
<rsalvaterra>
Yeah, I can imagine…
<Nick_Lowe>
Have to do a:
<Nick_Lowe>
uci set wireless.default_radio0.ieee80211w="1"
<Nick_Lowe>
uci set wireless.default_radio1.ieee80211w="1"
<Nick_Lowe>
uci commit wireless
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Nick_Lowe has joined #openwrt-devel
grift_ has quit [Ping timeout: 260 seconds]
grift has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
<svanheule[m]>
damex: if you're in for a challenge, there's also Cisco Meraki switches that use a Vitesse SoC. We're nowhere near starting with another target after RTL83xx, but it seemed like an interesting next platform (with actual useful datasheets available)
<stintel>
and possibly upstream support, there are some vitesse switch chips supported in the kernel
<damex>
stintel: yeah, i have seen that. vitesse phy is used on er4/6p/12/12p
<damex>
it is actually microsemi now which is acquired by microchip
<damex>
so probably it is called microchip in kernel
<stintel>
still called vitesse afaik
<damex>
well, kernel driver/module is no longer a vitesse ;(
<svanheule[m]>
I've search for vsc74xx and vsc75xx (the switch SoCs), but couldn't really find much
grift has quit [Quit: Bye]
<svanheule[m]>
some vsc85xx phy parts are though, IIRC
<stintel>
drivers/net/dsa/vitesse-vsc73xx*
grift has joined #openwrt-devel
<stintel>
and drivers/net/dsa/ocelot/*
<svanheule[m]>
stintel: thanks, using codenames doesn't make stuff easier to find :-/
<stintel>
well I happen to have been messing around with devices with a vsc9953 chip ;)
<stintel>
those WatchGuard/PPC thingies
<damex>
svanheule[m]: i guess it is no go for me for now. no hardware and all i wanted originally is to downsize homelab. i thought about selling er4 but managed to make openwrt to run there. same goes for aircube ac ;p
<stintel>
downsize homelab o_O
<svanheule[m]>
stintel: not everyone wants a 19" rack in their house
* stintel
hides
<svanheule[m]>
:P
<svanheule[m]>
stintel: I found 802.3bt switches with Realtek hardware btw
<svanheule[m]>
but only gigabit ethernet
<stintel>
I'm still looking for 802.3bt PoE-PD 10GbE uplink and preferably a few more 10GbE ports
<stintel>
like 4x10GbE and 8x1GbE would be epic
<damex>
so i sold synology ds1819+ and currenly wait for ds620slim to arrive (6x5T drives). 2x low power Nuc with 16 and 32gb ram + 9x RPI/LibreComputer SBCs + 2x EdgeSwitch 8 150w + EdgeRouter 4 + EdgeRouter X + AirCube AC. EdgeSwitch is a huge Pita. takes lots of space and it is heavy
<stintel>
damex: my huawei does wirespeed 10GbE L3 ;)
<damex>
how many 10GbE ports you have there ?
nitroshift has quit [Quit: Gone that way --->]
Ivan_83 has quit [Quit: Miranda NG]
<damex>
svanheule[m]: actually it is not about <19' rack at home> - it is about changing jobs every 1 or 2 years and travel to other country (or change apartments in between). i prefer to keep all the hardware
<damex>
no way i am moving to another country with 19' rack
<damex>
but <20L homelab? doable
<damex>
even <10L maybe
kab-el has quit [Ping timeout: 260 seconds]
<stintel>
haha yeah if I need to move I'm going to have fun
<grift>
dangole: decided to replace the busybox ntpd functionality with chrony so that i can use its nts feature, also replaced dnsmasq with unbound so that i can use some of its advanced features like dot, router setup is pretty neat now
<stintel>
but not planning on doing that anytime soon. as long as they don't touch the 10% tax I'll be here
<damex>
grift: do not need other dnsmasq features? atleast tftp/dhcp?
<grift>
i let odhcpd also do ipv4 dhcp
<grift>
and i dont use tftp, so not sure yet if i am missing out there
<damex>
i boot that SBCs over network. pxe use tftp to pull kernel+initrams (or just kernel, depends)
<grift>
i bet one can make tftp work without dnsmasq
<damex>
yeah, sure
<karlp>
grift: what made you choose to use odhcpd for dhcp4?
<grift>
well i wanted to use unbound dot , and the how to said either disable dnsmasq dns or remove it althother and use odhcp for ip4 dhcp
<grift>
so i just removed it
kab-el has joined #openwrt-devel
<grift>
less is more
<grift>
so i now have pretty much the ultimate setup and the selinux policy supports it: https://termbin.com/jcj5
<grift>
added wireguard vpn, and tightened selinux:
<grift>
thus yanked out the ntpd support from busybox and went with chrony
<grift>
and thats what i like about openwrt
<damex>
grift: why not dnsdist (powerdns) for doh ? :)
<stintel>
too complex / requires boost and all
<grift>
unbound is superior
kab-el has quit [Ping timeout: 240 seconds]
<eduardas>
hello, anyone here involved with the Prpl Foundation that I could ask some questions about it?
<eduardas>
because as I understand it is supposed to make OpenWrt more usable by network equipment OEMs and such
dangole has quit [Remote host closed the connection]
kab-el has joined #openwrt-devel
<grift>
but otherwise i would like into knot-resolver, see what it can do
<grift>
i use knot as my dns server and very happy with it
<grift>
decisions decisions
<damex>
we have here powerdns+dnsdist - we're gonna split part of the company to its own infra and need to decide what to use. pdns+dnsdist will make things overly complicated in a current setup.
<damex>
been thinking about automating unbound+bind
<grift>
look into knot
<damex>
same people that made bird?
<grift>
yes i guess (same org at least cz.nic)
barhom_ has joined #openwrt-devel
<damex>
thanks, never heard about that one. would be happy to ditch powerdns + postgresql setups
<stintel>
cool. I have a "spare" 256GB mSATA somewhere
<svanheule[m]>
:-)
<svanheule[m]>
I've once used an APU to recover data from the mSATA SSD built into a Samsung T3 portable SSD :P
kab-el has quit [Ping timeout: 256 seconds]
black_ant has quit [Ping timeout: 260 seconds]
kab-el has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
<stintel>
what am I going to do with all this extra storage though :P if I replace 16GB with 256GB :P
<grift>
i already have that with 256mb flash on my router (currently 59MiB sitting there empty going to waste)
<stintel>
pi-hole container seems to use almost 5GB (including logs)
swex has joined #openwrt-devel
black_ant has quit [Ping timeout: 240 seconds]
<rsalvaterra>
stintel: 16 GB on an APU, for OpenWrt?
<stintel>
rsalvaterra: well that was the smallest SSD PCengines offered
<rsalvaterra>
I have a 16 GB SLC SSD in the APU at the office. It's complete overkill, let alone 256 GB. :)
<dangole>
grift: remember that this is NAND flash, so having some spare blocks for wear leveling and to replace bad blocks before shit hits the fan is a good idea...
<grift>
dangole o right
<stintel>
rsalvaterra: well with my pi-hole container some of it is not wasted
<grift>
especially for me , this router is less than a month old and must have reflashed it over a 1000 times already
<dangole>
i finally got procd-ujail + uxc ready to replace 'runc' or 'crun' well enough for podman to work :)
<grift>
heck i bricked in less than 15 minutes after it was delivered
<rsalvaterra>
stintel: Why a container with pi-hole? Have you tried banip?
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has quit [Remote host closed the connection]
<rsalvaterra>
dangole: Ah, forgot to ask you! Is ntpd supposed to run with uid 123 all the time, or only with jails?
<stintel>
rsalvaterra: never heard of banip
<stintel>
and a container because pihole is not properly packagable
<dangole>
rsalvaterra: it can do it only with ujail because that's needed to retain ambient capabilities. without that it'd need to run as root. hance the logic in the init script detecting /sbin/ujail
<stintel>
rsalvaterra: but does it come with fancy graphs :)
<rsalvaterra>
dangole: I see, thanks for the explanation. :)
<rsalvaterra>
stintel: Right, I forgot you like pretty GUIs. :P
<stintel>
rsalvaterra: for stats I do
kab-el has quit [Ping timeout: 258 seconds]
<stintel>
but I might cook something myself and build a grafana dashboard for it
<rsalvaterra>
I had rrdtool running on the APU at the office. It was cute. :)
<stintel>
if I ever find time :P
<rsalvaterra>
Ok, so I implemented ADC entropy collection for AR5008-AR9002 (ath9k) on Linux 5.10-rc1… now I just need to test this on the AR5008 I ordered yesterday…
<rsalvaterra>
… and find the courage/patience to send it upstream. :P
barhom_ has quit [Ping timeout: 258 seconds]
barhom_ has joined #openwrt-devel
<dangole>
rsalvaterra: nice work! does that entropy collection start right after probing the hardware or does the interface have to be up for that?
<rsalvaterra>
(While also addressing nbd's concerns, like having the AR_PHY_TST_ADC register all the time configured for I/Q sampling.)
<rsalvaterra>
dangole: It works just like on AR9003. It spawns a kthread which reads the sample register as needed, until the entropy pool reaches a certain threshold, then blocks until the entropy pool drops below another threshold.
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
kab-el has joined #openwrt-devel
<rsalvaterra>
But to answer your question, the radio must be up. It doesn't have to be associated.
<dangole>
rsalvaterra: was asking because was wondering if that helps key generation on firstboot... especially now that we might generate both, SSH and TLS keys....
<rsalvaterra>
I'm… sorry. :P
<dangole>
rsalvaterra: is having a monitor interface up enough?
<rsalvaterra>
dangole: Haven't tested that.
<rsalvaterra>
Do you want to give it a spin yourself? I can send you the patch. :)
<dangole>
because that wouldn't hurt much to just do as soon as the radio gets detected...
<dangole>
i don't have any ath9k hardware at hand
<dangole>
but i'd like to see the patch anyway :)
<rsalvaterra>
As crazy as it may sound, me neither… Well, apart from my AirGrid M2, which is running my patch perfectly.
<rsalvaterra>
dangole: Sure! I'll mail it to you. It's against Linux 5.10-rc1.
<rsalvaterra>
Oh, and AR9001 hardware (Buffalo WZR-HP-AG300H) has also been thoroughly tested by a friend of mine, a couple of months ago.
DonkeyHotei has joined #openwrt-devel
<rsalvaterra>
dangole: you've got mail.
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<adrianschmutzler>
Will it also work if you just alloc and drop rename?
<adrianschmutzler>
I assume you actually run into the strncmp with return 0 ...
<damex>
lets see if dropping rename possible
<adrianschmutzler>
looks like dev_alloc_name is just a more complex variant of the strlcpy(eth->netdev[id]->name, name, IFNAMSIZ); from mt7621
<adrianschmutzler>
I assume that
<adrianschmutzler>
ret = __dev_alloc_name(net, name, buf);
<adrianschmutzler>
if (ret >= 0)
<adrianschmutzler>
essentially does the same as the "if (name)" for mt7621?
<damex>
seems so
<damex>
adrianschmutzler: so just allocating device name is enough
<adrianschmutzler>
That's nice, I think this is a better solution and since mt7621 does the same, it should acceptable although it's essentially a hack.
<damex>
so it does initialization for 4 interface device per qsgmii without even checking for node state. i wonder if there is a way to tell it to not do that?
<adrianschmutzler>
Please add a header to the (kernel) patch, just something short like for the mt7621 one (you probably can just copy-paste the text)
<adrianschmutzler>
sorry, can't help you with that
black_ant has quit [Ping timeout: 264 seconds]
<damex>
sure, would having just that properly named lan* devices enough to get device in a tree? (without caring about the rest for now, they don't affect anything)
<adrianschmutzler>
I do not know much about ethernet drivers, I'm just reading code in this context
jas4711 has joined #openwrt-devel
<adrianschmutzler>
what do you mean by "get device in a tree"?
<damex>
adrianschmutzler: like get device support merged. or we definitely need to fix all the possible quirks? basically we need to patch kernel at this point
<adrianschmutzler>
I have no idea whether a patch like that would be acceptable upstream.
<damex>
well, yeah. but am more interested in this context to get device support into the openwrt.
<adrianschmutzler>
in the ER4 PR, just before the commit adding device support
<damex>
adrianschmutzler: sure.
<adrianschmutzler>
that separate commit would just add the kernel patch locally
<adrianschmutzler>
Then add the labels in the device support commit
<adrianschmutzler>
And I would consider that particular issue solved.
<adrianschmutzler>
The problem is that I personally cannot review the entire device support PR
<adrianschmutzler>
What I understand looks okay, but there is a lot that needs to be checked by somebody else.
<adrianschmutzler>
I will have another look during the rest of the week, though
<adrianschmutzler>
the biggest problem will obviously be the kernel config changes, as they might affect other devices which would need to be tested.
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Acinonyx has quit [Ping timeout: 260 seconds]
Acinonyx has joined #openwrt-devel
<damex>
well, i 'tested' it on edgerouter lite and edgerouter 4. there is just 4 devices in a tree. edgerouter lite, edgerouter and itus shield where 'edgerouter' does not even boot due to lack of needed kernel option to enable board specific hack
<damex>
4 including new edgerouter 4
<damex>
> 'edgerouter' does not even boot due
<damex>
that is with a current kernel openwrt have. enabling such option degrade performance heavily
<adrianschmutzler>
and you have the "generic" device, which at least was used with some device we don't know
zkrx has joined #openwrt-devel
<damex>
adrianschmutzler: it is irrelevant since they can not be #1 flashed, #2 they don't preserve configs #3 they are not listed in compatibility list of openwrt
<adrianschmutzler>
well, I cannot discuss too much about generic devices anyway, they are a concept from before my time here
<damex>
adrianschmutzler: how about that DTS_DIR, could i just use DEVICE_DTS_DIR in Device/Default like other targets do?
<damex>
or i better put DTS_DIR to <target>/Makefile?
<adrianschmutzler>
but it does not matter anyway; somebody will be needed to review your PR anyway, and that one will also review the kernel config changes eventually
<adrianschmutzler>
just keep the same line, and put it _before_ the Device/Default block
<adrianschmutzler>
DEVICE_DTS_DIR does something different than DTS_DIR
<adrianschmutzler>
this is actually considerably complex if you try to disentangle it
<adrianschmutzler>
but since we have a target-wide DTS directory, using DTS_DIR actually seems appropriate to me
<adrianschmutzler>
DEVICE_DTS_DIR is more meant for subfolders and stuff
<adrianschmutzler>
btw reviewers don't have to be people with commit access; if you find other developers that thoroughly review the code and are willing to provide a Reviewed-by: with their name, this will also help
<stintel>
same with Tested-by :)
<adrianschmutzler>
stintel: indeed. Although I would e.g. be willing to merge something I only partially understand with 2 Reviewed-by, but not with 2 Tested-by ...
<adrianschmutzler>
depending on what we are talking about, obviously
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
adrianschmutzler has joined #openwrt-devel
dangole has quit [Ping timeout: 240 seconds]
Night-Shade has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 240 seconds]
dangole has joined #openwrt-devel
<aparcar[m]>
adrianschmutzler: should we just move the metadata out of tree but keep schemas in openwrt.git?
<adrianschmutzler>
aparcar[m]: I lean towards having a separate meta repository, as this solve several problems at once. I don't see why we would keep the schemas in main repo then, though, and not "move" them as well.
<aparcar[m]>
fair
<aparcar[m]>
I just like to keep the scripts in openwrt.git instead of distributing them
<aparcar[m]>
I'd clone the devices.git folder into my openwrt.git repo
<aparcar[m]>
just like I do with openwrt-ci.git
<adrianschmutzler>
and why couldn't devices.git contain the schemas then?
<aparcar[m]>
sure it can, would just mean to run ./devices/scripts/validate rather than ./scripts/validate
<aparcar[m]>
also having it in tree results in more eyes
<adrianschmutzler>
very simple one, just adding a label property
<adrianschmutzler>
So, you can change the name of ethernet devices with DSA by just adding a label
<aparcar[m]>
Okay if we patch existing things and not just add additional stuff, we have to add it as kernel patches anyway
jg_ has quit [Ping timeout: 260 seconds]
<adrianschmutzler>
for ipq806x we had a case where we backported several patches changing property names and possible values one or two months ago
<adrianschmutzler>
don't remember how/whether we dealed with schema stuff there
<adrianschmutzler>
but obviously, this is already quite specific and probably not the first thing to deal with
<aparcar[m]>
I can just bump the mail thread from some time ago
<ynezz>
what speaks against target/linux/sunxi/device-info/friendlyarm_nanopi-r1.yaml?
<ynezz>
then you can have schemas/device-info schemas/dts in top tree
<aparcar[m]>
ynezz: I don't want multiple yaml files if a devices exists in multiple targets
<aparcar[m]>
don't you think?
<adrianschmutzler>
ynezz: we were discussing how much stuff we should include in the yaml files; I'm not sure whether it's really a good idea to essentially copy over all of the ToH properties from Wiki
<ynezz>
which device exists in multiple targets?
<aparcar[m]>
ar71xx?
<aparcar[m]>
some rasperry stuff I think
<ynezz>
rm -fr ar71xx; solved
<aparcar[m]>
ynezz: I tried that and it postponed my "membership" by more than a year
<ynezz>
:)
<ynezz>
adrianschmutzler: this needs to be decided, yes
<adrianschmutzler>
having all that stuff would probably cause a relevant amount of additional commits just _changing_ metadata
<aparcar[m]>
Thomas from the wiki wants to add e.g. power supply and much more, so that would "flood" PRs with only metadata information
<adrianschmutzler>
I'm not sure whether I want this in main repo and I could imagine others being generally opposed to that idea
<aparcar[m]>
The kernel figured out to handle quite a bit of documentation in tree
<adrianschmutzler>
As I see a clash between "firmware" and "router info database" here
<aparcar[m]>
but sure that's a differen cup
<ynezz>
so now it's commit message -> tmomas manual work -> wiki ToH (and would mean) -> parsing wiki ToH -> device.yaml
<aparcar[m]>
adrianschmutzler: if you use the workd "platform" all fits :)
<ynezz>
but it could be device.yaml -> automatic ToH
<aparcar[m]>
ynezz: yes
<aparcar[m]>
We could do an arrangement that e.g. Thomas and me prepare bi weekly metadata updates that are merged at once
<aparcar[m]>
kind of like the translation updates in LuCI
<aparcar[m]>
that way we wouldn't have daily metadata updates
<adrianschmutzler>
that's an interesting idea, but would that actually be _better_ than having a separate repo where he/others could just push when needed
<aparcar[m]>
but collaborate with Thomas (et al) in a sane way, rather than seeing it as two totally different platforms
<aparcar[m]>
adrianschmutzler: not sure. I would prefer that device adding requires whatever dev to provide a yaml file
opal has quit [Ping timeout: 240 seconds]
<adrianschmutzler>
and actually I just wanted to use the luci translation updates as a negative example
<aparcar[m]>
we can just say the dev must provide a commit hash of devices.git
<ynezz>
hm, whats wrong with luci translation updates?
<aparcar[m]>
adrianschmutzler: well people keep merging it there on a daily basis instead of giving it a few days to have bigger PRs. That's not an issue of the system but of people being excited to merge things
<adrianschmutzler>
The whole history consists of translation updates?
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ynezz>
or source code updates :)
<aparcar[m]>
actually the system might be an issue, I'll tell weblate to send translation updates only once a week
<adrianschmutzler>
I'm almost never looking at luci, so I cannot really discuss this substantially. But it left a first impression ...
<adrianschmutzler>
Anyway, of course, for merging device support just having the yaml as part of it would be nicer than adding a hash
<adrianschmutzler>
I just would not require too many things to be specified as mandatory.
opal has joined #openwrt-devel
<aparcar[m]>
adrianschmutzler: yea we'd need to come up with a sane default
<aparcar[m]>
afk for an hour
<adrianschmutzler>
but of course I admit it's total nonsense to store only a part of the ToH in metadata, and then having Wiki people to store the rest elsewhere
<ynezz>
it might be easier to just do ToH -> device.yaml for the start as this would be needed anyway
<adrianschmutzler>
probably yes. although that still would be somewhat semi-automatically ...
<ynezz>
then later switch direction (if it would make sense) and do dts -> device.yaml -> ToH