ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
djrscally has quit [Ping timeout: 268 seconds]
cdaudt has joined #armlinux
cdaudt has quit [Client Quit]
linusw_ has joined #armlinux
Nact has quit [Ping timeout: 240 seconds]
Nact has joined #armlinux
Nact has quit [Client Quit]
apritzel_ has quit [Ping timeout: 256 seconds]
russ has quit [Ping timeout: 250 seconds]
alpernebbi has quit [Ping timeout: 264 seconds]
alpernebbi has joined #armlinux
russ has joined #armlinux
shailangsa has quit [Remote host closed the connection]
mcfrdy has quit [*.net *.split]
j`ey has quit [*.net *.split]
Stary has quit [*.net *.split]
kbingham has quit [*.net *.split]
j`ey has joined #armlinux
mcfrdy has joined #armlinux
Stary has joined #armlinux
Fridtjof has quit [*.net *.split]
jtf has quit [*.net *.split]
scott-ph has quit [*.net *.split]
javierm has quit [*.net *.split]
Amanieu has quit [*.net *.split]
nullheroes has quit [*.net *.split]
rperier has quit [*.net *.split]
mmind00 has quit [*.net *.split]
hauke has quit [*.net *.split]
tagr has quit [*.net *.split]
scott-ph has joined #armlinux
mmind00 has joined #armlinux
rperier has joined #armlinux
tagr has joined #armlinux
javierm has joined #armlinux
hauke has joined #armlinux
Amanieu has joined #armlinux
nullheroes has joined #armlinux
jtf has joined #armlinux
Fridtjof has joined #armlinux
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #armlinux
damxsa has joined #armlinux
damxsa has quit [Remote host closed the connection]
damxsa has joined #armlinux
cdaudt has joined #armlinux
guillaume_g has joined #armlinux
milkylainen21 has joined #armlinux
milkylainen21 is now known as milkylainen_
tre has joined #armlinux
damxsa has quit [Remote host closed the connection]
damxsa has joined #armlinux
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
System_Error has quit [Ping timeout: 276 seconds]
djrscally has joined #armlinux
apritzel_ has joined #armlinux
System_Error has joined #armlinux
Turingtoast has joined #armlinux
NishanthMenon has quit [Ping timeout: 246 seconds]
NishanthMenon has joined #armlinux
apritzel_ has quit [Ping timeout: 245 seconds]
damxsa has quit [Quit: Leaving]
iivanov has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
System_Error has quit [Ping timeout: 276 seconds]
Pali has joined #armlinux
sszy has joined #armlinux
tudorel has quit [Remote host closed the connection]
shailangsa has joined #armlinux
nsaenz has quit [Remote host closed the connection]
ndesaulniers has quit [Ping timeout: 264 seconds]
Crofton has quit [Ping timeout: 268 seconds]
sboyd has quit [Ping timeout: 246 seconds]
pjw has quit [Ping timeout: 246 seconds]
cengiz_io has quit [Ping timeout: 250 seconds]
olofj_ has quit [Ping timeout: 250 seconds]
arnd has quit [Ping timeout: 265 seconds]
tfiga has quit [Ping timeout: 265 seconds]
netonaut_ has quit [Ping timeout: 264 seconds]
robher has quit [Ping timeout: 268 seconds]
broonie has quit [Ping timeout: 268 seconds]
ccaione_ has joined #armlinux
linusw_ has quit [Ping timeout: 260 seconds]
sjg1_ has joined #armlinux
dianders has quit [Ping timeout: 246 seconds]
mturquette has quit [Ping timeout: 246 seconds]
jamestperk has quit [Ping timeout: 265 seconds]
unixsmurf has quit [Ping timeout: 265 seconds]
ccaione has quit [Ping timeout: 260 seconds]
ccaione_ is now known as ccaione
khilman has quit [Ping timeout: 264 seconds]
sjg1 has quit [Ping timeout: 264 seconds]
sjg1_ is now known as sjg1
NishanthMenon has quit [Ping timeout: 250 seconds]
dianders has joined #armlinux
nathanchance has quit [Ping timeout: 268 seconds]
nohit has quit [Ping timeout: 268 seconds]
robclark has quit [Ping timeout: 268 seconds]
jamestperk has joined #armlinux
steev has quit [Ping timeout: 265 seconds]
zx2c4 has quit [Ping timeout: 265 seconds]
maennich has quit [Ping timeout: 264 seconds]
nsaenz has joined #armlinux
roxell has quit [Ping timeout: 268 seconds]
dtor has quit [Ping timeout: 268 seconds]
narmstrong has quit [Ping timeout: 268 seconds]
robclark has joined #armlinux
nohit has joined #armlinux
NishanthMenon has joined #armlinux
zx2c4 has joined #armlinux
steev has joined #armlinux
maennich has joined #armlinux
dtor has joined #armlinux
mturquette has joined #armlinux
cengiz_io has joined #armlinux
arnd has joined #armlinux
unixsmurf has joined #armlinux
nathanchance has joined #armlinux
Crofton has joined #armlinux
roxell has joined #armlinux
robher has joined #armlinux
broonie has joined #armlinux
narmstrong has joined #armlinux
linusw_ has joined #armlinux
olofj_ has joined #armlinux
dtor has quit [Ping timeout: 240 seconds]
zx2c4 has quit [Ping timeout: 240 seconds]
khilman has joined #armlinux
zx2c4 has joined #armlinux
tfiga has joined #armlinux
dtor has joined #armlinux
ndesaulniers has joined #armlinux
netonaut_ has joined #armlinux
sboyd has joined #armlinux
pjw has joined #armlinux
kbingham has joined #armlinux
alexels has joined #armlinux
apritzel has joined #armlinux
tudorel has joined #armlinux
tudorel has quit [Client Quit]
tudorel has joined #armlinux
Amit_T has joined #armlinux
<mort>
I wish the entire embedded linux ecosystem wasn't built entirely around custom vendor patches with non-upstream patches
<mort>
complicates stuff
<jn>
there are spots of light, a few platforms where upstreamed code actually works well
<jn>
but yea, vendor code is a pain
<Xogium>
jn: heh I agree. Working with st's stm32mp1 is all in all a very peasant experience
<Xogium>
since they actually make an effort to mainline the stuff
<mort>
not all of us can make the choice to use a significantly more expensive soc than what's necessary just to have a nicer development experience
<mort>
sadly
<Xogium>
*pleasant, I meant
<Xogium>
I didn't say you could
<mort>
yeah, I know
<Xogium>
just saying that there are some very nice SoC out there, if you can get your hands on them
<milkylainen_>
I don't think vendor patches are a big issue. It's a lazy ass vendor that's the big problem.
<milkylainen_>
Not everything and the kitchen sink _needs_ to be in the kernel.
<Xogium>
yep
<mort>
so, I half-agree half-disagree
<milkylainen_>
If vendors would actually maintain their shit, it wouldn't be much of an issue.
<mort>
I think the kernel should be structured with a stable driver API so that vendors could make drivers for their shit and it would just work with the upstream kernel
<milkylainen_>
But they don't. They throw half-baked stuff out the door. "Look we have something that has a console prompt. Yay!"
<jn>
oh, if the vendor patches are forward-ported by the vendor, onto every new upstream version, that's just as convenient for the user as having them upstream, but it is an unlikely proposition
<Xogium>
that, or when they act dumb and decide to take say… a rc, not even an actual release, port their 3000 patches over it -- yes I'm not exagerating much is some case there are really that many, they don't get their code reviewed at all, and they never update the kernel again
<mort>
but since that's not the case, everything *has* to be in the kernel, otherwise we're all stuck on ancient kernels
<milkylainen_>
"Maintenance you say? Not our problem.."
<mort>
vendors aren't gonna work their asses off to rewrite all the drivers for all their 400 SoCs going back to 2002
<mort>
every few months
<mort>
maybe they *should*, maybe that's part of their job
<mort>
but they're not gonna do it
<mort>
they're gonna say, "this soc supports linux 4.3 blurry fish butt" and that's that
<jn>
this downstream-only attitudes leads to comical results sometimes: i have a chip with *three distinct* linux ports, and a fourth of my own (which is upstream-oriented by very very incomplete)
<jn>
s/by/but/
<mort>
"need a newer kernel? Buy our new SoC, it supports Linux 5.4 Kleptomaniac Octopus"
<mort>
it makes for a great sales pitch to drive upgrades
<Xogium>
hehehe
<jn>
i see the logic, but i do not approve
<Xogium>
neither do I
<mort>
not saying I like it, I'm saying it's the logical consequence of not having a stable driver API
<mvaittin>
better than approving the logic without seeing it :]
<jn>
i want linux 5.999 on my scraps from the recycler :)
<Xogium>
:D
<mort>
my ideal linux would have a stable driver API that's broken at every major release (in fact, major release === breaks driver API) and where the licensing situation is such that anything which uses the driver API has to also be under a GPL-compatible license (because closed source drivers is possibly the only world that's worse than today's)
<mort>
that way, vendors would just release a bunch of drivers, I could take an upstream kernel and their drivers and their dts and end up with a working linux system and I could be fairly confident that I could be able to use any kernel release in the current major version series
<mort>
I feel like upstream currently pretends like out-of-tree drivers don' t exist, yet almost every linux device runs out-of-tree drivers
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Turingtoast has joined #armlinux
cdaudt has joined #armlinux
apritzel_ has joined #armlinux
damxsa has quit [Ping timeout: 245 seconds]
damxsa has joined #armlinux
<CounterPillow>
mort: precisely one of my devices runs out-of-tree drivers and they're in the process of being upstreamed. Upstream should not care about out-of-tree drivers because out-of-tree drivers don't care about being upstream.
<CounterPillow>
Literally anyone can work on upstreaming them. For example, I did that with the Rockchip I2S/TDM controller, having no prior experience with Linux kernel development.
<mort>
CounterPillow: I'm sure you're very representative
<CounterPillow>
I'm equally representative as your claim.
<mort>
I really don't think so
<mort>
upstream should care about out-of-tree drivers, because most users of linux are using out-of-tree drivers
CrashTestDummy has joined #armlinux
<CounterPillow>
no, most users of Linux (android users) are using complete forks
<mort>
...with out-of-tree drivers
<CounterPillow>
with core kernel changes as well
<mort>
maybe they wouldn't have to be complete forks if those out-of-tree drivers could be used with an upstream kernel
<CounterPillow>
They would have to be because vendors want to keep them proprietary anyway, which would mandate support for not just an API but an ABI, which is impossibly disruptive for something that only benefits GPL violators.
abelvesa has quit [*.net *.split]
<mort>
what are you talking about
abelvesa has joined #armlinux
<mort>
vendors currently GPL their out-of-tree drivers because the license mandates it
CrashTestDummy2 has quit [Ping timeout: 260 seconds]
<mort>
what makes you think anything would change with a more stable API
<CounterPillow>
lol I wish they did
<mort>
well, qualcomm and rockchip seem to?
<mort>
I don't have much experience with others
<mort>
well, I know certain wifi chip manufacturers also GPL their out-of-tree drivers
<CounterPillow>
rockchip is an exception, and the "tainted kernel" flag and GPL symbols exists for a reason. Give these fucks a single finger and they'll take the whole hand.
<mort>
is qualcomm an exception too
<mort>
how many exceptions do you need before it becomes the rule
prabhakarlad has quit [Quit: Client closed]
<CounterPillow>
according to you, 2 apparently
<mort>
I know the mali drivers are closed, but that's from arm themselves not soc vendors (and they probably have some bs GPL condom?)
<HdkR>
kbase is open source
<amstan>
sorry, what's the rule?
<mort>
I'm talking about qualcomm and rockchip because those are the ones I have experience with, I guess they are somewhat representative because they don't exactly seem great and they don't have a reputation of being flawless here
<mort>
if rockchip and qualcomm are truly exemplary, please do tell, because then the embedded linux ecosystem is much worse than I had thought
<CounterPillow>
yes, rockchip for example is one of the few vendors who will let you boot without any blobs.
<CounterPillow>
realtek just code dumps because they don't care about writing drivers or upstreaming anything, and a kernel driver API 1. already exists as dkms in this case, 2. would not solve the issue of these drivers being complete garbage, 3. all realtek stuff finds its way into staging anyway
<mort>
interesting
<mort>
rockchip's newest kernel for the px30 is a blurry fish butt kernel, they don't exactly strike me as being completely on top of things
<amstan>
i can provide an explanation for both rockchip and qcom, they worked on a particular project around the time they became so nice in terms of upstreaming ;)
<CounterPillow>
chromebooks?
<amstan>
yes
<amstan>
though i hear rockchip has been keeping that upstreaming momentum going for other chips in their lineup too
<mort>
apparently not
<amstan>
well, i'm sure there's a little bit of slowing down, heh
<CounterPillow>
Correct, though they currently are quite busy so others have been helping ot
<Xogium>
they sure can't be as bad as broadcom
<mort>
rockchip's official kernel for their socs is 4.4 with 4.19 under development
<mort>
from what I can tell
<CounterPillow>
They have in fact said that they've been extremely busy on the mailing list, in the recent vop2 discussion
<mort>
that doesn't translate into actually supporting kernels it seems
<amstan>
mort: it always was, yeah
<CounterPillow>
yes, bsp linux will still be horrible, but the point of upstreaming is that you can then use upstream linux
<mort>
welp
<amstan>
rk3399 chromebooks launched with 4.4, and there was a recent uprev of rk3288 chromebooks to 4.19
<mort>
I won't ever be able to use the upstream kernel because there are other kernel patches because of the lack of a fucking driver API
<steev>
wat
<amstan>
so i can see why rockchip would use those version numbers for their "vendor" kernel
<mort>
forward-porting hundreds of kloc from 4.4 to 5.15 can't be very easy
<steev>
px30 is already in 5.15
<CounterPillow>
mort: I've done it with no prior kernel development experience
<amstan>
mort: it's much easier when most of your stuff is upstream, that's the magic that we've been trying to teach
<amstan>
it'll just lead to various drivers being out of tree and never merging
<steev>
correct
<mort>
CounterPillow: is that an actual driver API or is it just "these are the headers which are probably gonna prove useful when making a driver"
<CounterPillow>
Is there a difference?
<mort>
amstan: I'm not talking about an ABI
<mort>
CounterPillow: yes
<mort>
one is a well-defined interface
<mort>
the other is, well, whatever Linux does
<CounterPillow>
It is well-defined.
<steev>
not sure this conversation is even worth continuing at this point, seems mort just wants to bitch to bitch
<amstan>
the pressure of upstreaming is because you'll be left behind on your own if you keep it out of tree, if there was a stable api (or worse: abi) that would work across kernel versions all that pressure would be gone
<CounterPillow>
If Linux changes the APIs drivers are using, it's usually for a pretty good reason as it requires tree-wide fixups.
<mort>
maybe I'm wrong, maybe there is a very clear separation between the driver API and all the other parts of the kernel
<mort>
the most important thing is that there's no stable driver API
<mort>
amstan: there is already no pressure of upstreaming, approximately all drivers are already out of tree
<mort>
amstan: if there was a stable driver API, it would be so much easier for some rando to take a driver and upstream it
<CounterPillow>
Correct, because that would arbitrarily restrict kernel improvements for the benefit of unmaintained code that people should be fixing up anyways.
<steev>
what is "approximately all"
<amstan>
mort: yes, but that leads you to only offer 4.4 kernels for even new stuff and you get laughed at
<mort>
as it is, you're sitting on a 4.4 driver and can't upstream it because it would take you half a year to port it to 5.15, by which time Linux has moved on and you have to port it to 6.6
<CounterPillow>
mort: do you have any commits in linux?
<steev>
probably not
<mort>
CounterPillow: I sent in a patch which has been sitting ignored for ages, I have no code in linux
<steev>
if it takes > 6 months to port a driver, then the driver was written wrong in the first place
<amstan>
CounterPillow, steev : come on, we can be nice to him
<mort>
steev: sounds like all drivers written by hardware vendors
<CounterPillow>
amstan: I'm asking because he's making claims about the ease of upstreaming something
<steev>
amstan: why? he's making wild ass claims with no basis in reality
<CounterPillow>
porting the i2s/tdm controller from 4.19 or whatever to 5.14 took exactly one afternoon
<CounterPillow>
the rest of the time was spent on fixing all the bad code.
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<CounterPillow>
which there was a lot of, and upstream code reviews caught it
<mort>
CounterPillow: I'm not talking about the ease of upstreaming existing working code, I have no comment about that. I'm talking about how difficult it is to get something to a point where it is even compatible with current Linux
<CounterPillow>
?
<mort>
I have tried porting a wifi driver from 4.9 to 5.4, it was hell and I gave up
<CounterPillow>
how is that different from me porting a driver from 4.19?
<amstan>
4.20 kernel that hasn't been touched in years, doesn't even have patches that make it compile with a recent gcc
<amstan>
if i had a choice of reevaluating the hardware i was using, this would be a show stopper for me
<mort>
CounterPillow: maybe it's a driver that's using more unstable parts? Maybe the part of the kernel that's relevant to i2s/tdm controllers hadn't changed very much from 4.19 to 5.14?
<mort>
maybe you're already experienced in the world of I2S/TDM, while I'm not experienced in the world of wifi? Maybe wifi drivers are more complicated than I2S/TDM drivers?
<mort>
maybe you're more experienced with Linux kernel hacking than me?
<mort>
probably some combination of all of the above
<CounterPillow>
I'm sure they're more complicated, but I had no prior experience.
<CounterPillow>
amstan: but the C language is a stable API, how dare it not work with newer compilers :^)
<mort>
anyways, where does rockchip document that px30 is supported in linux 5.15
<mort>
I've been unable to find anything about it from them
<amstan>
CounterPillow: -Werror for one, a lot of people love for some reason on things that are supposed to be portable
<CounterPillow>
they probably don't document it themselves because their opensource pages are usually either down or outdated, but the kernel code itself documents this by the fact that there is px30 devicetrees and drivers in there
<CounterPillow>
amstan: -Werror is the worst :(
<mort>
so they don't actually support it
<amstan>
leming likes it :D
<CounterPillow>
upstream linux supports it
<mort>
I agree that -Werror is completely inappropriate other than possibly for some CI system
olofj_ is now known as olofj
<mort>
if there was a stable driver API I would've tried to use Linux 5.15 with our px30 board
<CounterPillow>
I'm sure you would've
<mort>
yes
prabhakarlad has joined #armlinux
<CounterPillow>
If there was a stable driver API, world hunger would no longer exist
<mort>
I'm not sure what you're insinuating
<Xogium>
that its an utopia, I think
<mort>
are you trying to say that if there was a stable driver API, that wouldn't have made it any easier to take old drivers and use them on newer kernels
<amstan>
mort: don't mind us, we're just jarred by everyone suggesting stable apis/abis
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mort>
does linux even want drivers for every single piece of hardware in history in the upstream kernel? Doesn't that make changing things *harder*, not easier?
<ukleinek>
mort: having to maintain a stable api is quite some effort
<mort>
it's been done
<mort>
supporting every single piece of hardware in history in one code base in one git repository without any stable interfaces for the drivers... sounds harder, and hasn't been attempted before Linux to my knowledge
<ukleinek>
mort: and if the driver authors from 4.9 would have done their homework (i.e. provided patches and responded to feedback) then the driver would be in mainline today
<mort>
ukleinek: driver authors don't do that
<ukleinek>
mort: that's their problem then :-)
<mort>
no, it's my problem
<mort>
and it's the Linux user community's problem
<steev>
nah, linux users tend to learn the crappy drivers and start avoiding that vendor
<mort>
definitely not
<steev>
sorry, i didn't realize your experience speaks for everyone
<ukleinek>
mort: with stable APIs each single driver might be easier to handle, but the frameworks get quite complicated and less common code means less tested code paths.
<mort>
I'm not talking about end-users of laptops here, I'm talking about people who use linux in embedded systems and the like
<steev>
well you keep saying linux users as if it's all inclusive, and you're talking about a fraction of the users
<ukleinek>
mort: I work in that area and we convince our customers that mainlining has a net benefit
<Xogium>
better mainline right from the start…
<mort>
ukleinek: well I don't disagree with you
<steev>
so which wifi driver are we talking about?
<mort>
Xogium: I don't understand why you're telling me this
<mort>
Xogium: but I'll keep it in mind for whenever I become CTO of some hardware vendor which writes linux drivers
<ukleinek>
mort: having said this, porting a half-way sane driver fom 4.9 to 5.4 shouldn't be hard.
<mort>
I had serious trouble porting the H&D Wireless driver
<mort>
obviously it might just be because I'm not an experienced kernel hacker, maybe CounterPillow would've had it done in an evening
<CounterPillow>
what's your obsession with stables anyway, are you a horse or something
<mort>
but I had to go through some very very fundamental parts of how it deals with time, and there were no 1:1 replacements for the APIs it was using, I would've had to actually fundamentally understand what it was trying to do
<amstan>
almost to the point of it being a meme
<amstan>
there's been whole presentation at linux conferences about this, with equally incredulous audiences
<amstan>
i don't like it personally because it means there's less upstreaming going to happen
<amstan>
sorry guys, I can't partake anymore in this discussion, my matrix bridge is being really slow
<mort>
I seriously suspect it could lead to more upstreaming when the driver you started developing for 5.15 will just work once it's done and 6.9 is in development but the 5.15 driver you've made just works on 6.9
<mort>
but I'm not familiar enough with the industry to say that for sure obviously
<ukleinek>
mort: if you mainlined the driver for 5.15 it will (most probably) work in 6.9
<mort>
not at all my experience, but maybe my experience isn't representative
<mort>
oh wait
<mort>
I read "if you maintained the driver for 5.15", you said mainlined
* ukleinek
nods
<mort>
if you start developing your driver on a 5.15 kernel, you work on it for a while, and then when you've gotten it to a good state where it's actually ready to mainlined the current development version of Linux is 6.9
<mort>
can you just try to upstream your driver against 5.15 and let someone else do the porting work to 6.9?
<steev>
no
<mort>
so how would you mainline your driver for 5.15 when it's not ready to be mainlined until 6.9
<steev>
i mean, technically, sure
<steev>
that's no different than say, a vendor writing one for 4.9 and expecting someone else to mainline it to 6.9
<steev>
just an extra middleman
<mort>
yeah aka ain't gonna happen
<steev>
well, if you aren't willing to do the work *shrug*
<steev>
complain to the vendor, and don't use their hardware in the future
<mort>
but I'm curious how ukleinek thinks time works if they think you can take your driver back in time from the 6.9 time frame, mainline it against 5.15, and let someone else keep it working
<steev>
that is called backport, actually, and there is a project that does that. backports newer drivers to older kernels
<mort>
but in the 6.9 time frame, you have a completed driver which works for linux 5.15
<mort>
how can you mainline that driver against 5.15 as they suggest
<steev>
5.15 is already released, it is not accepting new drivers
<mort>
yes
<mort>
so how can you upstream that driver against 5.15
<mort>
re: 21:29 <ukleinek> mort: if you mainlined the driver for 5.15 it will (most probably) work in 6.9
<steev>
you don't. if you were to upstream now, it would be for 5.17
<steev>
he was using the version numbers you gave, as an example
<steev>
not as gospel
<mort>
but he's making it sound like you "just" upstream your driver and then don't have to think about it anymore, ignoring my entire point which was that developing a driver takes time and linux is a moving target which has progressed when you complete the driver
<steev>
it doesn't change *that* much, with a few exceptions, of course, but if you're upstreaming, you're working on something much closer instead of something like 4.9
<mort>
if I was a hardware vendor, I would target the latest LTS, develop my driver against that, and then when the driver is done, time has moved and the driver is incompatible with current linux
<marex>
wow, it's lively here today, what're we discussing, spidev ?
Turingtoast has joined #armlinux
<steev>
we're discussing how it's impossible to make a driver be compatible with more than 1 kernel marex :(
<marex>
steev: sounds awfully hard indeed
<marex>
steev: I gave up, better just upstream it and let upstream take care of it
<steev>
better to let marex do the upstreaming work
<Xogium>
ulo marex :)
<Xogium>
poor marex
<steev>
still waiting on my efikamx support
<marex>
steev: it was upstream, wasnt it ?
<marex>
at least partly
<steev>
it was pre-dtb
<steev>
no, it wasn't
<mort>
problem is, to upstream something you need a driver that's compatible with current linux
<steev>
it was blocked from entering upstream because of the lack of dtb stuff
<marex>
mort: git cherry-pick the driver ?
<mort>
marex: but the driver API is incredibly unstable
<marex>
mort: then just upgrade to latest linux-next ?
<mort>
that's what we're discussing
<mort>
upgrade what? The driver?
<marex>
your machine of course
<marex>
just run linux-next on your system and no problem
<mort>
sorry, I was thinking the other way around
<steev>
marex: ah, actually it was blocked because of switching from board files to dtb, and by the time that switch happened... the two of us who could do the work had moved on from genesi
<mort>
if you have an existing kernel, but it's for 4.4, you ain't gonna have an easy time upstreaming that to 5.15
<mort>
an existing driver*
<marex>
mort: that's why you should always upstream everything and then run the latest
<mort>
latest linux breaks stuff
<marex>
only if you dont upstream it properly and dont maintain it upstream properly
<steev>
no, we need stable kernels with stable api and drivers should only work with at most 1 kernel
<marex>
if you do, then its no problem
<mort>
just from a devicetree/userspace perspective, upgrading the kernel has caused huge breakages for me in the past
<marex>
DT is stable ABI, it cannot break, that's impossible
<mort>
let me go find a commit which broke my devicetree, sec
<mort>
actually why do I bother
<mort>
you're gonna say "oh, well you should've used labels", I'm gonna say "there were no labels", you're gonna say "well there should have been labels", I'm gonna say "well what does that help" and we're just gonna argue
<mort>
I've been through this before
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<steev>
have you considered forking the linux kernel and making it the way you want?
<steev>
i'd suggest bsd, but well, we're talking wifi and bsd's wifi support isn't exactly good
<mort>
linux is a fine kernel
<mort>
probably the best kernel on earth, for certain common definitions of "best"
<marex>
except for the stable driver ABI :-/
<mort>
it's something I think could be improved, yes
<j`ey>
mort: so a leading 0 had an effect?
<marex>
mort: did you submit any patches to that effect to help out ?
<mort>
I also acknowledge that I could be wrong about that, I have laid out my reasoning for why I think it would make upstreaming easier, but I have admitted that I don't know enough about the industry to know what exactly the current drivers and blockers for upstreaming is
<mort>
marex: for the driver thing or the dts thing?
<marex>
the driver thing
<mort>
j`ey: yes, we had a dts which modifies sdhci@07824000, and apparently stuff is matched based on strings and not the numeric address or something
<mort>
j`ey: all I know is, when I removed my leading 0 to match the .dtsi's removal of the leading 0, the kernel found the emmc again
<marex>
that DT node should be mmc@address too , you really should fix your DT
<j`ey>
mort: oh, so it wasnt actually a kernel issue?
<j`ey>
I mean, the kernel didnt fail to find the device
<mort>
j`ey: no, the kernel did as it should, I obviously initially suspected that the mmc driver somehow broke but luckily that wasn't the case
<j`ey>
the DT contents might not be the stable, but their ABI is
<mort>
I'm guessing we just had something like `sdhci@07824000 { status = "ok" }` to override the default `status = "disabled"`
<mort>
so when it changed from sdhci@07824000 to sdhci@7824000 that broke
<Xogium>
that's why phandle exist, afaik
<Xogium>
you know these &spi0 {
<Xogium>
or some such
<mort>
I know it should've used sdhci_1 not sdhci@07824000, but our dts was copied from the SoM vendor's dts and that didn't use labels
<Xogium>
I can be wrong though
<mort>
I might be using the word label where I should've used the word phandle idk
<marex>
mort: but then you must complain to your SoM vendor for shipping you ancient broken software, no ?
scosu has quit [Quit: No Ping reply in 180 seconds.]
scosu has joined #armlinux
<mort>
I don't really feel like I can fault variscite for modelling their SoM's DTS after a very similar upstream SBC's DTS?
<mort>
and variscite probably updated their DTS to reflect the kernel change, but we had copied variscite's DTS again and made our own changes to support the board which the SoM was used with
<mort>
the msm8916 sdhc_1 defaults to off, so the dts for a sbc or som which has an sdhc_1 has to override the status, upstream does that by using sdhci@07824000 (or now sdhci@7824000) rather than through the sdhc_1 label
<j`ey>
(upstream of that time, not current mainline)
<mort>
fair
<mort>
anyways, the other topic: marex: how would you suggest I open a PR for the driver thing? There's not exactly much code, it's more of a policy thing, before any code can be written the linux project has to be on board that "ok, a stable driver API is something we want"
<mort>
I can send an e-mail describing my reasons for wanting a stable driver API, but I feel like they have most likely already heard those arguments? Would anything new be contributed?
System_Error has quit [Ping timeout: 276 seconds]
iivanov__ has joined #armlinux
ardb has quit [Quit: Leaving.]
damxsa has quit [Ping timeout: 245 seconds]
iivanov_ has joined #armlinux
iivanov_ has quit [Remote host closed the connection]
iivanov_ has joined #armlinux
<marex>
mort: I cannot tell, you seem to have a lot of arguments, so check for previous discussions, summarize them and open it on LKML
iivano___ has joined #armlinux
iivanov has quit [Ping timeout: 268 seconds]
iivanov__ has quit [Ping timeout: 260 seconds]
iivano___ has quit [Remote host closed the connection]
iivanov has joined #armlinux
System_Error has joined #armlinux
iivanov_ has quit [Ping timeout: 245 seconds]
cdaudt has joined #armlinux
<ukleinek>
mort: sorry, my ISP sucks
<ukleinek>
DT is only stable in theory
<ukleinek>
if you develop a driver today, better be quicker than 2 years or update the base regularily such that you are on a recent release when you submit the driver
<ukleinek>
steev: v4.9 has a stable API :-)
<ukleinek>
steev: it's just incompatible with the stable API of 4.10 :-P