<alyssa>
I wish vendors had a 100%-mainline-first approach ..
<ndufresne>
it's a bit complicated subject for the kevin
<ndufresne>
the upstreaming has been running for years
<ndufresne>
A lot of new kernel uAPI had to be created
<ndufresne>
(that being said, wifi stuff probably has nothing to do with that)
<alyssa>
ndufresne: I don't mean just Kevin, I mean all of the Arm ecosystem... the fact that there are Android kernels and ChromeOS kernels and whatever is just.. annoying
<ndufresne>
there is a lot of movement happening as we speak
<alyssa>
I understand why it's this way (the Chrome team is doing good work on fixing it for the devices I'm interested in! <3), but hey
<ndufresne>
but you'll get better support on cheap SBC then on locked chromebook
<ndufresne>
chromebook are a pain to hack really for externals
<vagrantc>
sadly, until you find a vendor who can come up with a business model where they make more money by upstreaming first...
<alyssa>
vagrantc: Is that a challenge? :-)
<ndufresne>
haha, no, I'm not expecting that any time soon
<ndufresne>
anyway, kernel upstreaming is much slower then producing new HW
<ndufresne>
(and it's not always the vendor's fault)
<ndufresne>
adding new uAPI for new type of HW takes years really
* alyssa
wonders if there are ways to reduce friction to mainline
<ndufresne>
I guess things have started with a CoC
<alyssa>
Maybe I'm just spoiled by userspace ;)
<ndufresne>
well, you work a lot underneath standard APIs if I recall right
<ndufresne>
and that's what vendor adding drivers would dream of, but e.g. CODEC uAPI started being added in 2011, and is still heavily being worked on today
<ndufresne>
a lot of vendor need to confirm their HW spin works, so they implement the most minimal driver (like a mailbox), but then time is too short, they ended up shipping that to their customers
<alyssa>
It almost makes sense when you put it that way :)
<ndufresne>
and they call it a "reference implementation"
<ndufresne>
now, if only they took they habit of always open sourcing these, that could be a start
<ndufresne>
I really like right now the linux-rockchip/ repo on github, brings a lot of info
<ndufresne>
an other ting they could do, is properly identify to who they bought the IP, so they could make driver properly named (think of the stmmac, which is not STM in the end but Design Ware (dwmac) a design pretty much all sbc uses
<ndufresne>
today I found that rk3388 has a Hantro G1 and H1 VPU, but the driver isn't name as such
<alyssa>
I'm tempted to diagnose the issue as a race condition between the wifi driver loading and the root filesystem mounting, bearing in mind I have the wifi compiled in (not a module). Is that possible...?
<alyssa>
My ChromeOS kernel wouldn't have that since it's built as a module there
<alyssa>
Let's try as a module
stdint has quit [Read error: Connection reset by peer]
stdint has joined #linux-rockchip
<alyssa>
That was it. Guacomole.
<alyssa>
*Guacamole
<wens>
alyssa: if you have the wifi driver built-in, and it probes before rootfs is available, the kernel will not find the firmware on rootfs
<wens>
alyssa: best is to bundle the firmware into the kernel blob, or build the driver as a module
<ndufresne>
some drivers defer the loading, some don't
<wens>
I do the former for most of my stuff
<wens>
ndufresne: IIRC brcmfmac / rtl* don't
<ndufresne>
I'll keep a mental note
<alyssa>
wens: As far as I'm concerned, if it doesn't defer and it allows building without being a module, that's a bug ...
<ndufresne>
I guess most don't
<ndufresne>
agreed
<alyssa>
Similarly, with the audio driver bailing at runtime without DMA being enabled (but nothing to prevent having audio without DMA), I consider that a bug..
<alyssa>
Nothing personal about it -- my code is extremely buggy by my own standards and I'll be the first to admit that -- but a bug's bug to me, yeah?
<wens>
does the mounting of rootfs kick all the deferred drivers?
<alyssa>
I do userspace. *blinks*
<wens>
plus how would the kernel differentiate initfs vs the real rootfs?
<alyssa>
I don't have an initrd
<wens>
yeah, I'm just thinking about possible issues :)
<wens>
audio without DMA is a bug, though it is still possible for it to fail _with_ DMA enabled, such as when all DMA channels have been occupied
<alyssa>
True! To me, having a conflict int he build system (such that it's a compile-time fail) is a satisfying resolution, but I dunno.
<alyssa>
Anyway, I now actually have an mlan0 interface. Progress.
<alyssa>
On one rootfs, it gets as far as scannig networks. On the other, no, but still
<alyssa>
I will say, loving the 3s boot time :P
<vagrantc>
gru-kevin .dts is present in mainline u-boot, but not referenced by anything...
<alyssa>
State `unabvailable`
xming has joined #linux-rockchip
stdint has quit [Read error: Connection reset by peer]
<xming>
but wlan-platdata doesn't exist in the kernel
<xming>
so no driver will be loaded?
<xming>
it's rk's kernel specific
<wens>
alyssa: you mean with the DMA engine API not being enabled? that's not the only failure scenario though. you could have the API / core enabled, but forgot to enable any of the engine drivers
kaspter has quit [Remote host closed the connection]