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
balrog has joined #armlinux
Pali has quit [Ping timeout: 245 seconds]
scosu_ has joined #armlinux
scosu has quit [Ping timeout: 255 seconds]
CrashTestDummy2 has joined #armlinux
CrashTestDummy has quit [Ping timeout: 272 seconds]
amitk has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 255 seconds]
CrashTestDummy2 has joined #armlinux
CrashTestDummy3 has quit [Ping timeout: 255 seconds]
iivanov has joined #armlinux
frieder has joined #armlinux
<ukleinek>
milkylainen_: Yeah, I assume this is a compiler problem, I hit a similar problem in another driver, too.
<mkl_>
ukleinek: 40 bits must be enough for everyone?
elastic_dog has quit [Ping timeout: 255 seconds]
Pali has joined #armlinux
elastic_dog has joined #armlinux
<geertu>
ukleinek: bummer, I made it to the CC list of v4. thx to zorro ;-)
elastic_dog has quit [Ping timeout: 255 seconds]
<ukleinek>
geertu: :-)
elastic_dog has joined #armlinux
* ukleinek
marks a big Z on geertu's chest with his épée sword
* ukleinek
is irritated by spi tracing. Sending 0x1000 (i.e. .bits_per_word = 16) is shown in the trace as tx=[00-10]
<geertu>
ukleinek: fix it and send a patch?
* ukleinek
looks up who actually made the buffer contents appear in the traces and wails to the author of 8d245475c3f6e82d4685d5d9fd7b95ea118a7e25 instead :-)
<geertu>
ukleinek: Ah, the less-experienced you ;-)
<geertu>
ukleinek: How may "Too many recipients to the message" can I expect to receive?
* geertu
had never heard of industrypack-devel before
<ukleinek>
geertu: already archived these, just ~2 hands full of "your post is placed in the moderator's queue" replies
<ukleinek>
ah here, 12 such mails, but you probably only get 6 as there are two mails in my series with so many recipees
<geertu>
ukleinek: thx, got all of them, so everything is working fine
Pali has quit [Ping timeout: 268 seconds]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
elastic_dog has quit [Ping timeout: 245 seconds]
robinp has quit [Read error: Connection reset by peer]
elastic_dog has joined #armlinux
macromorgan has quit [Read error: Connection reset by peer]
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #armlinux
elastic_dog has quit [Ping timeout: 255 seconds]
elastic_dog has joined #armlinux
<mort>
what do y'all think about making embedded systems with linux 4.4 and 200kloc of custom kernel patches
<jn>
i'd prefer if people prioritized upstreaming a whole lot more, but i realize it's not the fastest path towards a shipping product, so i guess i can't convince managers that upstremaing is a good idea
<ukleinek>
mainlining is the fastest path to shipping a product with a sustainable maintainance burden. (Unless you fire-and-forget your products)
<jn>
yep indeed
<mort>
yeah I'm gonna try to get this to go down a different path
<jn>
that distinction is probably a very central one
<jn>
long-term vs. fire-and-forget
<mort>
well, no internet-connected product can ever be fire-and-forget
<jn>
i hope your higher-ups see it like that, too :)
<mort>
they do
elastic_dog has quit [Ping timeout: 245 seconds]
elastic_dog has joined #armlinux
<ukleinek>
mort: you'd be surprised how many internet-connected products are fire-and-forget.
<mort>
yea.. I know
<ukleinek>
product management usually agrees to use an LTS kernel, but running an LTS kernel doesn't help if you don't update to the releases on that branch.
<mort>
but, like, internet-connected products can't be fire-and-forget in the same way that a car can't have brakes which randomly disconnect; it's technically possible to make products like that, but it's insanely dangerous
<mort>
but I get why people don't ever upgrade their kernels
<mort>
kernel upgrades break a whooooole lot of shit
<mort>
linux is insanely unstable
torez has joined #armlinux
<milkylainen_>
mort: Depends on what that 200kloc contains.
<mort>
does it? What sort of 200kloc of patches are easy to forward port?
<mort>
I suppose arguably if all of those lines were backports and could be deleted
<milkylainen_>
mort: Mainline != make someone else maintain stuff no one else need but you.
<mort>
?
<mort>
what does that have to do with anything
<milkylainen_>
Personally I think the current process of putting everything and the kitchen sink in vanilla is a bit excessive.
<mort>
I mean you can give linus a call I suppose
<mort>
don't complain to me
<mort>
but what does this have to do with anything
<jn>
it is arguably an answer to your original question
<milkylainen_>
mort: You asked what the channel thought about 200kloc of custom patches. My answer is that it would depend what those 200kloc contains.
<milkylainen_>
If it's fixes to existing code then yes, that would need to be sent back for review upstream.
<mort>
milkylainen_: and I asked what kinds of 200kloc kernel patches are easy to forward port, and you responded by going on a tirade about your opinions about the kernel development process, and I didn't understand the relevance of that
<marex>
ukleinek: do you still remember how to hand-over linux-foo channel ownership to an actual owner ?
<milkylainen_>
mort: Sorry about the lag. But it was intended as an answer to your original question.
<mort>
how?
<marex>
mort: re obsolete kernel with 200kLoC of patches, I would say it is pretty nice compared to some other kernel forks ;-)
<mort>
it can all be hardware drivers for custom hardware which has no place in mainline and it would still be a maintenance nightmare, right?
<milkylainen_>
mort: ? 200kloc is not a valid measurement of anything. It highly depends on what it contains.
<milkylainen_>
And yes. It can be a nightmare, as you suggest.
<mort>
hence the "What sort of 200kloc of patches are easy to forward port?"
<mort>
milkylainen_: but I still don't understand what relevance your kernel development process opinions has
<mort>
anyways, it's not important, I'm just confused
<mort>
marex: if you're using the imx fork of the kernel you're relying on other people though, you're not responsible for bringing those 1m changes forwards
<marex>
mort: I am definitelly not using it, no way
<mort>
but I do wish Linux would just... do its job and support hardware
<mort>
well
<mort>
linux should either support hardware or have a stable driver API
<marex>
I use it as an implementation reference, but whatever I roll out is either LTS + patches (for production) or patches for upstream (and that is not XOR)
<mort>
the current model of, "every piece of hardware needs a few hundred kloc of custom kernel patches which have to be rewritten with every kernel release", isn't really workable at all
<marex>
and that LTS in production is set up to be the latest from linux-stable, patches on top are few and applied in the context of layer-specific OE bbappend, so the builds are actually up-to-date with latest fixes
audgirka has quit [Ping timeout: 255 seconds]
<marex>
ukleinek: ^
<marex>
this 1MLoC vendor kernel obsolete stuff is just ... forget it
<mort>
which SoC vendor is competitive on price and has all their SoCs fully supported by mainline and LTS releases of upstream linux
<marex>
mort: if you do the upstreaming right, then you have to maintain only a few extra patches for each product, and with every LTS kernel release, that number drops
<mort>
I don't do any upstreaming
<mort>
I don't write kernel patches (other than tiny very not-upstreamable ones), and I won't upstream SoC vendors' kernel patches because I absolutely don't understand them and wouldn't be able to go through the upstreaming process
<mort>
plus I don't have the time, upstreaming takes years of active work from what I've seen
<marex>
not really
<mort>
I depend on a driver which is currently on patch series v9 where the upstreaming process began in 2016 and the mailing list discussions are still active as of 2021
<marex>
the benefit still outweights the investment, although it is not immediatelly visible
<mort>
well tell that to SoC vendors
<marex>
mort: which driver ?
<mort>
a pm8916 PWM driver
<marex>
mort: so, take it, fix it up, submit it again, what;s the problem ?
audgirka has joined #armlinux
<mort>
how?
<marex>
mort: do it once, properly, and be done with it
<mort>
it has been done properly for 5 years through 9 revisions
<marex>
mort: well, git am the patch on top of next, build, test, git send-email
<marex>
mort: why was it so slow ?
<mort>
idk
<marex>
mort: time to invest that time to reap the benefits in the long run :)
<mort>
nah
<marex>
remember, the kernel development is a collaborative effort
<mort>
I can invest a few months into getting it into 5.18 which will maybe potentially let me remove a patch from my kernel in 2040
<geertu>
marex: These days it takes more revisions. I used to be very nervous when having to send out a v3.
<mort>
besides, I think the whole driver is gonna have to be entirely reimplemented as two different drivers
<mort>
it's a LED driver which happens to include a PWM driver, and the mailing list discussions are talking about how, ideally, it should be one PWM driver and one LED driver which builds on top of the PWM driver
<marex>
mort: why do you think it is so slow anyway ?
<mort>
I'm 100% not qualified to do that
<mort>
I don't know
<marex>
mort: so, why not give it a try and see what happens ?
<marex>
mort: I recall turris omnia also had such a LED/PWM chip
<mort>
I have enough other stuff to do, thanks
<marex>
mort: maybe talk to Pali here on IRC ?
<mort>
I don't need to dedicate months to learning everything required to write a PWM driver for some hardware chip I don't know how works
<marex>
mort: I think he works for cznic and might be able to direct you in the right direction to get this solved
<mort>
the only reason I mentioned this pm8916 driver is as an example about how slow the upstreaming process can be
<mort>
it's not actually a practical issue for me
<milkylainen_>
mort: Doesn't sound like an overly complex driver?
<marex>
mort: one example does not make it a rule though
<mort>
maybe
<mort>
anyways, go call SoC vendors and argue with them about why they should upstream their patches
<mort>
I don't control them and I'm not qualified to take their patches and upstream them
<marex>
geertu: you should upstream patches
shoragan has quit [Ping timeout: 272 seconds]
<mort>
clearly Linux isn't very interested in supporting SoCs anyways, those patches are all GPL and any kernel developer could presumably just grab them
* geertu
wonders what else he is doing
<mort>
I just want A) Linux to support hardware or B) linux to have a stable driver API so that patches don't have to be rewritten every release
<mort>
but again, which SoC vendors actually ask you to use mainline instead of some fork
<mort>
it's a genuine question
<mort>
since y'all are talking about it as if using mainline is a realistic possibility
<milkylainen_>
x86 ones? :D
<mort>
I mean if there are price competitive, low-power x86 chips, then sure
<mort>
doesn't raspberry have its own giant kernel fork
<marex>
you can run mainline on it just fine
<marex>
stm32mp1 same thing
<marex>
renesas probably same thing
<marex>
just to name a few
<marex>
prabhakarlad: ^
<mort>
I'm looking for SoCs where the vendor recommends mainline though, not one where certain versions of mainline may possibly happen to work in an unsupported fashion
<mort>
maybe raspberry has mainline as one of its supported kernels
neg has joined #armlinux
<mort>
stm32mp1 ships their own kernel fork which you need to accept ST's software license agreement to even download, lol
<marex>
git://github.com/STMicroelectronics/linux.git this fork ?
<marex>
just use mainline on the mp1
<mort>
I'm looking at the tarball they link to
<mort>
but then you're using an unsupported kernel, right?
<geertu>
mort: Who's supporting you best, the vendor, or the upstream people at #armlinux?
<mort>
I don't even know
<mort>
using mainline with the mp1 would probably work fine
<marex>
yeah, it does
<mort>
I kind of wish arm was as nice as x86
<milkylainen_>
The only case I've had where moving supported hardware to newer kernel was "Just too much" was the venerable ti816x... 2.6.37, sgx530(?) the whole video pipeline and accelerators, encoders etc, DSP integration and various other bits and bobs.
<milkylainen_>
The core a8 and soc was no problemo though.
<mort>
I wish there were vendors who didn't have kernel forks, other than private development forks, and whose official way to run Linux was to use mainline
<mort>
where you could go to their official documentation and see "use mainline linux, versions 5.4 and 5.10 are verified to work with the SoC"
<milkylainen_>
mort: That would be nice yes.
<prabhakarlad>
marex: at renesas we do have kernel fork but we keep it very much close to linux-cip kernels
<marex>
mort: I think what you are looking for is not embedded arm box, but rather arm64 server machine, with UEFI and all that
<mort>
nah
<mort>
I just wish the embedded arm world wasn't terrible
<milkylainen_>
marex: How is aarch64 uefi/acpi nowdays? How much can you do without devicetree descriptions today?
<marex>
mort: well, in that case, remember, linux is a collaborative effort, it depends on just that
<marex>
mort: time to get to work on making it so
<mort>
marex: yeah, but I play no part in that collaboration
<mort>
I don't have the time or expertise to make upstream linux work with socs
<marex>
milkylainen_: u-boot has efi services support, acpi I dunno
<j`ey>
edk2 works well
<maz>
milkylainen_: ACPI on arm64 works perfectly as long as you abstract your device in a way that makes sense for ACPI.
<mort>
one viable path forward would be for Linux to just specify a stable driver API already
<mort>
that way SoC vendors could just have their own kernel modules and I could still upgrade the kernel
<maz>
and end-up like the maintainance nightmare that windows has? no, thank you.
<mort>
maybe have some hard breaks now and then
<mort>
linux could even use semver, kernel modules written for 5.x works for any 5.y | y >= x but not for 6
shoragan has joined #armlinux
<maz>
that's a distro business. RH, and even Android will give you that kernel ABI.
<milkylainen_>
maz: Mkay.
<mort>
maz: then you're using vendor kernel forks again
<mort>
is that what you want
audgirka has quit [Remote host closed the connection]
<maz>
I certainly don't want the kernel to be limited in what we can change.
<mort>
well, it is
<maz>
if you want your code to be ealily moved across releases, upstream it.
<mort>
what if it's code which I rely on but not my code
<mort>
like, I don't know, all the SoC support code out there
<mripard>
mort: I mean, if you dislike it so much and find it really unpractical, you still have the option to not use it at all?
<mripard>
you know how it's developped, it's not going to change any time soon
<mort>
maz: you're completely ignoring the fact that most people who depend on out-of-tree patches didn't write those out-of-tree patches and can't upstream those patches
<mripard>
you don't want / can't participate to help improve it
<mort>
mripard: oh, which kernel do you think would be better?
<mripard>
then you may just have done a choice that isn't suited for you, and we can't help with that?
<mort>
do you have any suggestions
<mort>
mripard: almost every user of Linux in the embedded space has made the "choice" to use hardware from a vendor with their own kernel fork
<mripard>
any of the BSD kernels, Zephyr, a proprietary own, your own, I don't really care to be honest
<mort>
mripard: are you claiming that Linux isn't suited for embedded
<mripard>
but coming here saying constantly how we suck at our job and how we should make it better for you isn't great to be honest
<mort>
mripard: are you claiming that Linux isn't suited for embedded
<mort>
I'm not saying you suck at your job, I'm saying there are very serious problems here and, while some people in this channel seem to agree, most of you are just ignoring it tbh
<mripard>
no, I'm saying it looks like you made a poor choice (either for the kernel or SoC), and now you're blaming us for it.
<mort>
almost every SoC is gonna have a vendor fork
<mort>
quite possibly every single SoC
<mort>
so I suppose Linux is a bad choice for SoCs
<mripard>
some are better than the other, but you still have the option to participate in the community, either directly or by funding someone to do so
<mort>
but I don't think you want to think that
<mripard>
yet, you don't want to do that either
<mort>
I don't have money, I don't have time, and I don't have the required decades of kernel hacking experience
<mort>
how can I help
<mort>
I can diff a vendor kernel tree against a mainline kernel tree and send an e-mail with the diff. Does that help
<mripard>
buy SoCs where mainline is an option, test patches you're interested in, write some doc
<javierm>
mort: the linux upstream community can't force the vendors to upstream their code, they just need to comply with the GPL license
<mort>
mripard: I don't have SoCs where mainline is an option
<mort>
javierm: I know
<javierm>
mort: yet you are claiming that Linux is not suitable due companies not wanting to upstream their code...
<mort>
javierm: well, yeah
<jn>
(no, sending a vendor patchset upstream verbatim is not an option; upstreaming is a dialog)
<mort>
javierm: it's not Linux's fault that vendors aren't upstreaming their code. But it is a problem that 1) Linux has no stable kernel APIs and 2) vendors don't upstream their code. The result is that Linux is not very suitable.
<javierm>
mort: I disagree with you actually. The fact that the kernel doesn't have a stable internal ABI/API is an incentive for companies to upstream their code
<mort>
javierm: well it isn't fucking working now is it
<javierm>
besides the fact that helps doing kernel wide refactoring as others mentioned
<mort>
the fact that the kernel doesn't have a stable internal API is an incentive for companies to ship 4.4 forever
<javierm>
mort: I honestly think that it is. A decade ago you needed to build a kernel tailored to a board or SoC due having hardware description in C code
<mort>
and that's about the same these days except that the kernel is described in a DSL instead of C
<mort>
s/kernel/hardware/
<javierm>
mort: not really, the Device Trees work not only allowed to boot the same kernel image on different platforms but also lead to a lot of standarization
<javierm>
the common clock framework, pinctrl, etc were a by-product of this work
<mort>
right
<maz>
at the end of the day, Linux is what people what it to be. if a majority of people wanted a stable ABI, it would have happened. the fact is, we found that it was far more beneficial to Linux *not* to have this stable ABI. for example, tjhe whole spectre mitigation would have been impossible to do if we had an internal ABI.
<mort>
that's nice, but vendors are still shipping forked 4.4 kernels
<milkylainen_>
mort: well. You can always try to put some leverage into the buying process if you have such influence. You can always tell vendors to sod of if they won't provide you with a recent enough / small delta vanilla set?
<mort>
milkylainen_: where did I ever say I have influence
<milkylainen_>
mort: Merly a suggestion. Buying process has leverage. Or whomever has that influence in your company?
<milkylainen_>
merely even
<mort>
well, I will do what I can, but most vendors want you to use their kernel fork right
<javierm>
mort: I'm unsure having a stable API would even help tbh. Companies would still only test their drivers with old kernels, using deprecated APIs, etc
<mort>
javierm: removing deprecated APIs would happen in major releases, right?
<javierm>
mort: there's no such a concept in linux really, unless you take every release as a major release
<mort>
most projects have a stable API of some kind, with some process for breaking API when necessary, it's not like this is unexplored territory
<javierm>
but even in that case, you wouldn't be able to forwared port which is what you want
<mort>
drivers could be "forward ported" at least
<mort>
I don't see the big incentive for vendors to spend hundreds of extra person-months just to not have kernel forks
<javierm>
mort: you should complain your silicon vendor really, not the upstream linux community
<mort>
and you clearly see how much most customers care about security, it's not like there's any incentive for embedded devices to not be on 2.7 still
<mort>
anyways, the current state is clearly terrible and it's clearly not going to get better
kbingham_ has joined #armlinux
<ukleinek>
marex: I'd ask in #linux-ops
<mort>
I wonder if somewhat-stable kernel APIs could potentially have made vendors more happy to upstream stuff? I wonder if one of the problems currently is that people spend, say, a year, on a new hardware product and associated drivers, and when they're done, a ton of extra work is required to make the drivers work with the newer version of linux
<ukleinek>
stable kernel APIs don't work well with progress
<mort>
when I say "stable" I don't mean "stable forever", just that there's a few years instead of a few days between each major breaking change
abelvesa_ has quit [Ping timeout: 268 seconds]
abelvesa has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 268 seconds]
macromorgan has joined #armlinux
<macromorgan>
are there any guidelines about setting a "dev_emerg" message for the kernel? I want to set a potential value for wrong Lion battery voltage as the highest priority I can, since it could lead to catastrophic failure...
<geertu>
macromorgan: dev_emerg sounds fine to me. The rest is to be handled by userspace.
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #armlinux
<macromorgan>
k. for invalid values or failure to set the charge voltage of a lion battery I'm going to use dev_emerg, since wrong values could basically start a fire
<macromorgan>
I'm also going to set a dev_warn if you go different than default, everything else is info or lower.
CrashTestDummy2 has joined #armlinux
CrashTestDummy3 has quit [Ping timeout: 272 seconds]
<broonie>
macromorgan: You might want to have a look at stuff around dfa19b11385d4cf8f0242fd93e2073e25183c331 (reboot: Add hardware protection power-off) for super critical failures, though this probably isn't quite that from the sounds of it.
<macromorgan>
thank you, I will
<macromorgan>
do you know of any mailing list I can send an RFC for for my driver? I'm brand new to fuel gauge drivers, and this is only my second driver (after the audio driver for the same PMIC).
<broonie>
IIRC that stuff just gets copied to lkml but MAINTAINERS should tell you.
XV8 has joined #armlinux
<macromorgan>
for regmap_update_bits, is something like (0x07 << 4) a valid way to designate a bitmask? my regmap_update_bits calls aren't working and that's the only thing I can think of...
<robher>
arnd, olofj: Can you comment on '[GIT PULL] memory: tegra for v5.14, late fixes'?
<broonie>
macromorgan: regmap doesn't care how you generate the constant you're passing in.
<macromorgan>
hmm... wonder why my bits aren't setting then, have to look into it more
XV8 has quit [Ping timeout: 255 seconds]
XV8 has joined #armlinux
Pali has joined #armlinux
matthias_bgg has quit [Quit: Leaving]
headless has joined #armlinux
XV8 has quit [Ping timeout: 255 seconds]
XV8 has joined #armlinux
frieder has quit [Remote host closed the connection]
sakman__ is now known as sakman
<macromorgan>
Figured it out... novice programmer gonna novice. Needed to shift the value to write. Was using regmap_write_bits(regmap, register, bitmask, unshifted_value). Using regmap_write_bits(regmap, register, bitmask, shifted_value) works.
CrashTestDummy2 has quit [Ping timeout: 255 seconds]
<olofj>
robher: I should have my maintainer machine up again tomorrow, and will do merges then. I'll pick it up in our fixes branch
<olofj>
Hm. we've started seeing more and more platform patches get cc:d to soc@kernel.org. Has some tooling changed to start suggesting it from get_maintainer.pl or similar? It makes our list noisy, and runs the risk of us missing patches that are truly intended for us to be picked up.
<broonie>
olofj: Once some people start to do something like that it tends to get cut'n'pasted by others regardless of get_maintainer (but get_maintainer can pick up Ccs from changelogs and there are some in eg the bus code).
<geertu>
olofj: MAINTAINERS has a match entry for arch/arm{,64}/boot/dts/Makefile
<olofj>
Ugh, ok. I'll get a filter added.
headless has quit [Read error: Connection reset by peer]
headless has joined #armlinux
amitk_ has joined #armlinux
amitk has quit [Ping timeout: 255 seconds]
headless has quit [Quit: Konversation terminated!]
iivanov has quit [Remote host closed the connection]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #armlinux
Crassus has joined #armlinux
torez has quit [Remote host closed the connection]