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
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
Turingtoast has joined #armlinux
<mort>
Does anyone here know how Linux maps GPIO pins? I have a gpiochip called 1000000.pinctrl, before a kernel update its pins got mapped to 0..122, but after upgrading the kernel its pins get mapped to 390..512
<geertu>
mort: That's internal kernel business, and may depend on probe order
<geertu>
I.e. never use GPIO pin numbers directly.
<mort>
Right.
<mort>
Problem is, literally everything uses gpio numbers directly
<geertu>
mort: From userspace, I guess?
<mort>
yeah
<mort>
linux isn't too good at this "don't break userspace" thing tbh
<geertu>
The general advice is to stop using /sys/class/gpio, and switch to the GPIO chardev device
<mort>
because I can certainly patch the kernel for everything I have to do via gpio, but since no in-kernel interface is remotely stable, upgrading the kernel will be a huge pain
<mort>
I see /dev/gpiochip* is another one of those things which are "files" but that actually just means they support the open syscall and otherwise you have to use IOCTLs so they're not really files
<geertu>
mort: So you are already at bullet 3 or 4
<geertu>
3 has moved to Documentation/driver-api/gpio/drivers-on-gpio.rst
<mort>
so by "YOU DO NOT ACCESS GPIOS FROM USERSPACE" it just means "if the kernel happens to already have a driver for what you use, and it happens to just work with your hardware, use that driver instead"
<geertu>
mort: Yep. And perhaps write a driver if it doesn't exist yet.
<mort>
one gpio lets us turn off and on the backlight, one lets us read the value of a switch
<abelloni>
switch => gpio-keys
<abelloni>
backlight => gpio_backlight.c
<abelloni>
YOU DO NOT ACCESS GPIOS FROM USERSPACE :)
<mort>
generating key press events from a switch seems like something which would fuck up a lot
<mort>
backlight isn't mentioned by drivers-on-gpio.rst but if it exists, maybe it could be made to work
<abelloni>
using gpio-keys for a switch actually has many benefits
<mort>
such as?
<abelloni>
like free interrupt and wakeup handling
<geertu>
mort: KEY_BRIGHTNESS_TOGGLE from include/dt-bindings/input/linux-event-codes.h
<geertu>
so both can be handked by gpio-keys
<mort>
I absolutely don't want the kernel to forcibly set the state of the backlight based on the value of the switch, we have to be able to manage the backlight from userspace
<geertu>
although gpio_backlight might be better, depending on whether you want to have userspace ky handling or not
<geertu>
mort: so gpio-keys and KEY_BRIGHTNESS_TOGGLE
<mort>
I might be misunderstanding, but it sounds like you're suggesting letting the kernel handle backlight directly from the switch "key"
<geertu>
mort: with gpio-keys, userspace can read input events, and will receive a KEY_BRIGHTNESS_TOGGLE event when the backlight switch is pressed.
<mort>
can I read the current value of a key or is it just through events
<geertu>
mort: Good question. I only used the events for testing.
<mort>
I also feel like X would be annoying? Like, X will presumably send keydown/keyup events for it, and maybe even multiple key events for it if X handles key repeat which it probably does
<geertu>
mort: X will receive the events, not send them.
<mort>
but X sends events to connected clients when Linux sends X events
<geertu>
I have to admit I don't know who actually handles such keys (and the multimedia keys) on a typical laptop.
<mort>
X11 sends the events to clients as normal X11 key events.
<geertu>
mort: If I run a client on a remote machine, with the X server running on my laptop, and I press the brightness keys on my laptop, it changes the brightness on my laptop, i.e. where the X server runs.
<geertu>
(just tried it with xev local or remote)
<geertu>
xev receives FocusIn and FocusOut events, but not the actual brightness event
<mort>
ok, if X11 has nothing to do with it, you should be able to kill X11 and change the brightness
<mort>
or start *only* X11, with no DE or anything, and change brightness
<mort>
if you can do that, you might have some weird laptop which handles brightness buttons in the BIOS or something, idk
<geertu>
I can't change brightness on the text VCs
<geertu>
I can change keyboard backlight on text VC and X11
<geertu>
interestingly, I don't get any events in xev for the keyboard backlight key
<geertu>
s/for/when pressing/
<geertu>
Dell XPS13 from 2014
<mort>
wait you're talking about your *keyboard* backlight? I'm talking about the backlight for the screen
<geertu>
brightness = LCD backlight
<mort>
the keyboard light is indeed handled by firmware or something, you have a setting for the current backlight level in the BIOS settings
<mort>
and the keyboard backlight toggle button affects that BIOS setting
<mort>
at least if your XPS works similar to mine
<geertu>
mort: X is aware of keyboard backlight keypresses, as it displays a small overlay with a bar indicating the level
<mort>
weird
<geertu>
Same for backlight changes through the brightness key
<mort>
anyways, it doesn't really feel worth changing this stuff, because the current solution works as long as GPIO is mapped correctly, and I don't feel like having a key which is constantly pushed in when a switch is in one position
<mort>
the lack of a somewhat stable driver interface really makes upgrading Linux extremely difficult
<mort>
I think I might literally have to forward-port a wifi driver
<geertu>
mort: what about upstreaming the wifi driver, and elt the netdev folks handle future upporting?
<geertu>
s/elt/let/
<mort>
geertu: sure, feel free to ask the hardware manufacturer to upstream their driver
<mort>
or you can grab it and work on it, it's GPL I think
<geertu>
mort: That would be even better. But if you do plan to spend time on forward-porting the driver (ad infinitum?), it might be worthwhile to upstream it.
<mort>
there are three different drivers, one for USB, one for SDIO, one for PCIe
<mort>
geertu: I can certainly try to get the kernel to work for my purposes and then send it as a code dump on the mailing list, but I feel like that wouldn't be extremely appreciated?
<mort>
it would also kind of just be extra work, because it would presumably be a lot of work to port the driver from our version to 5.13, which we aren't going to be using for a while
<mort>
I feel like there's a huge disconnect between the kernel project's view of "just upstream everything" and "upgrading the kernel is as simple as checking out a different commit", and the reality that upstreaming something is actually a whole lot of otherwise-unnecessary work just for the potential benefit of an easier upgrade in many years, and the
<mort>
reality that upgrading the kernel actually breaks a whole bunch of stuff and it can actually take months to iron out all the issues
Crassus has joined #armlinux
geertu has quit [Quit: Changing server]
geertu has joined #armlinux
Crassus has quit [Ping timeout: 245 seconds]
<milkylainen_>
mort: That is the harsh reality of being a platform engineer at some random company.
<mort>
yeah
<milkylainen_>
There is a big disconnect between kernel developer and kernel user / implementer.
<mort>
it's fine that it is this way, this is my job after all, but I wish there was *any* acknowledgement *at all* from Greg & Co. that upgrading the kernel isn't as simple as `git checkout master && git pull`
<milkylainen_>
"The stop breaking everything" only applies to userspace. If you're doing an embedded project everything is going to break if you move more than a few minor steps.
<milkylainen_>
Which sort of makes it hard for someone who isn't in the loop of all the small changes all the time. Most changes are pretty mundane, but understanding they have changed, they are related to your problems etc can take some time.
<mort>
yeah I spent a long time figuring out why my MMC wasn't working with 5.4+, turned out that the reason was someone removed a leading zero from a devicetree device address in the upstream qualcomm dtsi my dts was including
<milkylainen_>
I have a pet peeve since 2008 when Kconfig removed complaints about unassigned symbols.
<geertu>
milkylainen_: mort: I agree that was a very useful warning
<milkylainen_>
This tells me. "We are kernel developers, we remove annoying nag about unassigned symbols". Ie, We do not care about some guys migrating from a oldconfig where half the symbols gone changed and missing now
<geertu>
and I do miss the warning myself
<milkylainen_>
geertu: I think I voiced that on some occasion. I also voiced symbol annotation for the configuration. So I can keep configurations comments close to the configuration during the read write cycle.
<mort>
I don't understand how removing warnings which tell you about config option renames/removals is consistent with the general idea that upgrading the kernel is easy
<mort>
unless there's a commitment to never renaming or removing config options?
<milkylainen_>
Also to help us lowly maintainers everywhere.
<milkylainen_>
:)
<mort>
it really doesn't surprise me at all that a lot of embedded linux stuff is still on 2.x
<milkylainen_>
mort: Not everything is the kernel developers fault. A lot of downstream companies really screwed up their Linux support..
<mort>
hardware manufacturers releasing driver source code without upstreaming it certainly doesn't help
<milkylainen_>
TI really messed things up with their video and media platforms during the early 201x...
<mort>
but it remains a fact nonetheless that upgrading linux is, actually, incredibly difficult in many circumstances
<milkylainen_>
mort: Yeah. I usually put some requirements when entering a new project. Preference goes something like "If I can't make it build and function with a vanilla something with a minimal set of patches, then I won't touch it with a 10 foot pole" :P
<milkylainen_>
That atleast is painful, but probably manageable.
<mort>
milkylainen_: that seems like a nice requirement for new development at least
<mort>
still doesn't protect you from breakages in the dtsi files you include :p
<milkylainen_>
Heh. Nope.
<milkylainen_>
mort: I think more companies are waking up to the security issues and that embedded software isn't "fire and forget". A lot of them have been traditional hardware manufacturers. "Nut & Bolt Inc." are all waking up to the consequences of modern software. They are getting pretty good at it, but doesn't mean it isn't painful.
<milkylainen_>
I see a lot of "we have this really, really old Linux kernel. Can we change it please?"
<mvaittin>
SOC vendors providing vendor BSPs based on kernels released more than 10 years ago does not help either. Then those who use SOCs for products are struggling with them. And component vendors who would like to upstream stuff and provide drivers are struggling with requests to backport the work to bunch of anxient foo.bar.baz versions...
* mvaittin
hides
<milkylainen_>
:)
<milkylainen_>
Userspace security becomes a bit of a problem with an old kernel aswell. For example. I think ARM had a glibc breakpoint at 3.x somewhere? I don't know if you can run a newer glibc on an old kernel?
<mort>
I think one of the issues is: hardware vendors (SoC vendors or otherwise) will develop drivers for the kernel versions they expect people to use (so the LTSes, 4.19 or 5.4 if they're bleeding edge)
<mort>
then they have drivers which can't be upstreamed because, well, they work for 4.19 or 5.4, not 5.13
<mort>
certainly, if I was a hardware component company, priority #1 would be to develop drivers for the kernel versions my customers are running, and none of them would be running 5.13
* mvaittin
knows a vendor who works for 5.13 and offers this to customers. Customrs either do backporting - or ask me to do that.
<mvaittin>
There actually is both kind of customers.
<mvaittin>
but now - enjoy the weekend peeps. I'm off :)
<mort>
fair, my description probably doesn't account for the whole of embedded linux hardware vendors
<mort>
bye, have a good week-end :)
<milkylainen_>
TGIF. :)
tagr has joined #armlinux
torez has joined #armlinux
torez has quit [Client Quit]
torez has joined #armlinux
theborger has joined #armlinux
CrashTestDummy2 has joined #armlinux
CrashTestDummy has quit [Ping timeout: 245 seconds]
Nact has joined #armlinux
guillaume_g has quit [Quit: Konversation terminated!]
mvaittin has quit [Quit: node-irc says goodbye]
mvaittin has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]