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
wwilly has quit [Read error: Connection reset by peer]
wwilly has joined #armlinux
torez has quit [Remote host closed the connection]
Nact has quit [Quit: Konversation terminated!]
HdkR has quit [Changing host]
HdkR has joined #armlinux
Xogium_ has joined #armlinux
Xogium has quit [Ping timeout: 240 seconds]
Xogium_ is now known as Xogium
sakman has quit [Quit: Leaving]
audgirka has joined #armlinux
kristo has quit [Ping timeout: 250 seconds]
kristo has joined #armlinux
frieder has joined #armlinux
audgirka has quit [Remote host closed the connection]
audgirka has joined #armlinux
matthias_bgg has joined #armlinux
alpernebbi has joined #armlinux
sszy has joined #armlinux
Pali has joined #armlinux
<mort> Does anyone have suggestions for how to debug a qualcomm remoteproc crash...?
<mort> https://p.mort.coffee/PuW those kinds of messages
<mort> this might just be a firmvare version issue, let me try to upgrade it
Pali has quit [Ping timeout: 265 seconds]
<mort> hmm, no
<mort> seems to have been related to the unused onboard modem. Disabled that in the dts and remoteproc stopped crashing
eduardas has joined #armlinux
wwilly has quit [Ping timeout: 272 seconds]
wwilly has joined #armlinux
wwilly_ has joined #armlinux
wwilly has quit [Ping timeout: 272 seconds]
wwilly__ has joined #armlinux
cmarinas_ has joined #armlinux
cmarinas has quit [Ping timeout: 244 seconds]
wwilly_ has quit [Ping timeout: 265 seconds]
cmarinas_ has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
cmarinas has joined #armlinux
<mort> Is there a way to remap gpio chips, so that what's currently gpio390 becomes gpio0 and its gpio pins start counting from 0?
<mort> ik the software *shouldn't* care but... it does
<geertu> mort: no there isn't
<geertu> don't rely on GPIO numbers...
<geertu> GPIO chardev interfave rulez
<geertu> s/fave/face/
<mort> "don't rely on GPIO numbers" isn't very useful when there's software which relies on GPIO numbers which I want to run on a kernel with different GPIO numbers
<mort> everyone relies on GPIO numbers, literally every stackoverflow answer related to GPIO tells you to rely on GPIO numbers
<mort> how does Linux decide on the gpiochip bases? What's currently reliably gpiochip390 used to reliably be gpiochip0 in an older version
<geertu> mort: The issue is there is no reliable numbering
<geertu> it depends on probe order, kernel version, plug-in hardware, ...
<broonie> Probe ordering of the gpiochips is the main contributor, combined with the set of gpiochips in the system.
<mort> isn't it kinda weird that it starts counting from 382
<geertu> mort: Plus ARCH_NR_GPIOS
<broonie> Most likely if you boot identical software on an identical system it'll end up with the same result (but possibly not if there's some timing dependency or whatever) since the boot tends to be repeatable but that doesn't mean it's reliable over any substantial change in the environment.
alpernebbi has quit [Quit: alpernebbi]
<geertu> robher: broonie: Is there a way to describe in yaml that the value of regulator-name must be equal to $nodename? "properties: regulator-name: const: $nodename" doesn't work, as it seems to require the literal "$nodename"
<broonie> geertu: I have no idea about how the YAML stuff works.
<geertu> broonie: hehe ;-)
<geertu> robher: The closest I get is repeating the same pattern for both, which obviously doesn't protect against people shuffling the names
<mort> so there's no way, not even a hacky way, to just say "the gpio chip named 1000000.pinctrl should have a base of 0"
<mort> I feel like that *has to* be possible
<robher> geertu: no. Generally, each property's schema in json-schema is independent.
torez has joined #armlinux
<mort> I've looked through a couple GPIO libraries, every single one of them expect you to use GPIO numbers.
<mort> like it or not, GPIO numbers are part of the public API, and changing them in a kernel upgrade is an API break
<mort> so I would prefer to keep them stable
<geertu> mort: Yeah, people like to bitbang gpio from userspace, instead of writing proper kernel drivers for the devices attached to those gpios
<broonie> The GPIO API includes interfaces for enumerating the GPIOs in the system too; in general the feedback would be that having a userspace API at all was a bad idea.
<mort> geertu: yeah, and I would prefer the public API to not break
<mort> broonie: maybe you would have a point if GPIO libraries' documentation suggested that, or if stackoverflow examples suggested that, or if anything at all in the entire world of interacting with hardware from linux suggested that
<mort> but nope, everyone uses GPIO numbers, so that's the API which has to be kept stable
<mort> so I ask again, how can I upgrade my kernel without breaking that interface
<geertu> mort: Use the chardev interface
<mort> geertu: have you read anything of what I've written? Are you literally just here to troll
<geertu> Looks for presentations from LinusW, Bartosz, or me ;-)
<geertu> s/Looks/Look/
<mort> geertu: I'm not writing new software for this, I'm trying to upgrade a kernel and run old software on it
<mort> the new kernel breaks an API in a really stupid way
<mort> I'm trying to make the new kernel not break that API
<geertu> mort: The sysfs interface is deprecated
<mort> geertu: good for you
<mort> now how do I configure it
<jn> which gpio driver is this?
<mort> geertu: if your response is, "it's impossible to choose which base a gpio chip starts at", then that's one thing
<geertu> mort: You can still enable CONFIG_GPIO_SYSFS if CONFIG_EXPERT=y
<broonie> mort: The kernel docs explicitly say not to rely on the userspace interface for anything other than prototyping and recommends the use of libgpiod which doesn't appear to use gpio numbers.
<mort> but you're not saying that, you're saying "the other people who wrote the software many years ago should have used a different gpio interface"
<mort> and that's literally useful
<geertu> but you can't do anything about the unstable numbers
<mort> literally useless*
<mkl> mort: is there an alias for the SoC gpios like "gpio0 = &gpio0;"?
<mort> geertu: gpio is already enabled in sysfs by default
<mort> broonie: that's good for you
<mort> I'm already sold on, "we should eventually find every instance in every program which uses gpio numbers directly, and change that to be relative to the correct gpio chip's base"
<geertu> mort: Not anymore since 3b4feb21158f8732 ("gpio: sysfs: Enforce character device") in v5.11
<mort> (I'm not sold on "we should write drivers for everything which uses gpio" but that's a different matter)
<mort> geertu: well I'm not running a kernel with that commit then
<mort> maybe I will in a few years and we'll have moved onto the chardev thing by then
<geertu> mort: If you want to fix the bases, you'll have to add your own hack to the gpiolib core
<linusw> mort: it's not really me you havet to convince but the OF binding people. That said I am very much opposed to anything relying on the global GPIO numberspace.
<linusw> mort: however I see your problem and our migration plan is to make the character device tasty, while not breaking old sysfs clients. A bit like pipewire
<mort> linusw: how do you not break old sysfs clients when the sysfs api is removed
<linusw> mort: I think I need to tell people how dangerous the sysfs API really is so they stop using it.
<linusw> mort: it is not removed we cannot remove it until noone uses it.
<mort> linusw: but geertu said 3b4feb21158f8732 from 5.11 removes it?
<mort> also, what's actually so dangerous about the sysfs api? It's just something which you can write a 1 or a 0 to to enable or disable some pin on a board
<geertu> mort: I said CONFIG_GPIO_SYSFS depends on CONFIG_EXPERT=y
<linusw> mort: nah. It becomes an expert option and a non-standard feature. One has to consciously look for it.
<mort> geertu: so it's still enabled by default?
<broonie> No, it's only available at all if CONFIG_ExPERT is set.
<linusw> mort: it has never been enabled by default I think? Just a lot of distros enabled it.
<mort> linusw: /sys/class/gpio has never been enabled by default? I think that's incorrect?
<broonie> It might've been enabled by some defconfigs.
<mort> that's enabled by default then
<broonie> Yeah, it's in a lot of arch/arm configs.
<mort> why exactly is the sysfs interface dangerous?
<mwalle> mort: well I'd say the numbering depends on the probe order of the devices, thus it's kinda.. unusable :)
<mort> it's probably a good idea to move to the chardev interface, and to do the offset calculation based on the base of the desired gpio chip... But if that's a requirement for upgrading the kernel, I'll run on 4.9 for a while longer
<mort> man do I understand now why so many IoT devices end up running ancient Linux versions for a decade
<mort> upgrading linux is *hard* unless the entire team of developers working on the product are perfect, never make a mistake, and have a few decades of experience in kernel programming and following best practice
<mort> and even then shit just breaks or you have to backport or forward port patches
audgirka has quit [Remote host closed the connection]
bps has quit [Ping timeout: 258 seconds]
matthias_bgg has quit [Ping timeout: 265 seconds]
Pali has joined #armlinux
<linusw> mort: there is a way in which the sysfs can be really dangerous and that is if the user relies on IRQ events being properly delivered to userspace by doing a poll on a value file.
headless has joined #armlinux
<linusw> mort: this uses sysfs_notify_dirent() which is a notification to userspace that "something happened in this file"
<linusw> mort: if two or more IRQs arrive in quick succession, you will miss some of them because you will only get one notification.
<linusw> mort: if this is used in an application where you really need to see all edges on the signal, this is going to be really problematic.
<mort> linusw: ah, so sysfs + inotify is dangerous, but writing is safe and polling to get the current state is safe
<linusw> mort: yeah pretty much. Unless you plug in a device with GPIO in some USB port and it gets enumerated first during boot, and kick around the GPIO number order....
<linusw> mort: of course one can avoid doing that.
<linusw> mort: the thing is that sysfs wasn't designed with any pluggable GPIO in mind, it was designed for embedded systems with a few GPIOs on a chip.
<linusw> mort: I suppose I should do one of those writeups on the kernel.org blog at some point.
matthias_bgg has joined #armlinux
<linusw> mort: the conceptual problem with the GPIO numberspace is that all hardware description models (DT, ACPI) assume all resources of a type are equal, not assigned operating-system-specific numbers.
<linusw> mort: what is BSD and Windows supposed to do with the base GPIO number for example. The ambition with devicetree or ACPI is to provide resource abstraction also for those guys.
<linusw> mort: admittedly that is a soft requirement since we have linux,input event-codes for example. But someone would have to take the fight with the DT community on that and it's not me.
<linusw> mort: the sysfs is a bad idea for new code since we are improving and adding features only to the character device.
<linusw> mort: like we now support reading/setting several lines at the same time, open drain, drive strength, and proper events.
<linusw> mort: another danger with sysfs is that they have state and do not disappear if the program who set up the GPIOs (exporting) crashes. Often people have to script around this or reboot the system if this happens. sysfs will release the GPIO lines when the application stops and release the file handle, which happens if it crashes.
<linusw> mort: so it is more elegant in a number of ways.
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
<geertu> linusw: s/sysfs will release/chardev will release/
<geertu> linusw: And sometimes keeping the state is a wanted feature
eduardas has quit [Quit: Konversation terminated!]
bps has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 272 seconds]
matthias_bgg has joined #armlinux
<mort> linusw: fwiw, it sounds like our use case is precisely what the procfs interface was designed for; a static set of pins, on one gpio controller, which can be written to control basic hardware things and read from to get the current state of basic hardware things where neither performance nor detecting every edge is important
<mort> used to be that the SoC's GPIO112 was GPIO112 in Linux etc, that's also why we ended up relying on it because it looked like a direct mapping to what we wanted
frieder has quit [Remote host closed the connection]
<linusw> mort: this was the intent of the beginnings of the GPIO subsystem so the reasoning was right at the time.
<linusw> mort: it was designed under the assumption that the GPIO subsystem was for a few fixed GPIOs on a single system on a single piece of silicon, numbered from 0..n.
<linusw> mort: then people invented stuff like GPIO on I2C, SPI, USB etc expanders on pluggable buses.
<linusw> mort: even PCI.
<linusw> mort: so there we are: now GPIOs are not just something that exists on the main SoC and what do we do with all the other GPIOs.
<linusw> mort: there are hacks to make the main SoC GPIO start from 0. This can be done with e.g. auxdata supplied to the device tree.
<linusw> mort: but in the view of people working with hardware abstraction (DT, ACPI etc) this has no future, we are facing a set of abstract GPIO resources on vast numbers of systems.
<linusw> mort: for a while the SoCs have tried to keep all their GPIOs in a strict number order with macros in boardfiles (GPIO expanders etc) but it became a mess.
<linusw> mort: resisting the change away from a global GPIO numberspace essentially means resisting HW description languages such as DT and ACPI and wanting to get back to board files. Sadly.
<broonie> It was also designed for use on single, vertically integrated systems.
<broonie> Rather than general purpose systems running upstream software.
<javierm> mort: we don't enable it in Fedora for example
<linusw> broonie: exactly
<linusw> one could even say that this is a result of a strains between special-purpose computing and general-purpose computing
<javierm> broonie: it reminds the per SoC pinmux interfaces before the pinctrl subsys
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<mort> thing is, this is a single, vertically integrated symbol, with a few fixed gpio pins on a single piece of silicon, numbered from 0..n
<mort> just that after a linux update, they're numbered from 390..n+390 instead
<mort> so the initial reasoning and design, is, like, 100% perfectly ideal for our use case
<mort> a single PCB with a single SoC with only a few static GPIO pins from the SoC itself, writing a 1 or a 0 to a pin and reading a 1 or a 0 from another in a way where missing some edges doesn't matter at all
<mort> literally the only issue seems to be that the base was changed from 0 to 390 inexplicably
alpernebbi has joined #armlinux
headless has quit [Ping timeout: 268 seconds]
headless has joined #armlinux
matthias_bgg has quit [Ping timeout: 268 seconds]
matthias_bgg has joined #armlinux
Nact has joined #armlinux
rbutler1728 has joined #armlinux
matthias_bgg has quit [Quit: Leaving]
<linusw> mort: what you are addressing is the fact that Linux's ambition is to be a general purpose operating system while what you want is a special-purpose operating system, it seems.
rbutlerc1728 has joined #armlinux
rbutlerc1728 has quit [Client Quit]
rbutlerc1728 has joined #armlinux
headless has quit [Quit: Konversation terminated!]
alpernebbi has quit [Quit: alpernebbi]
wwilly__ has quit [Ping timeout: 265 seconds]
rbutler1728 has quit [Read error: Connection reset by peer]
rbutlerc1728 has quit [Read error: Connection reset by peer]
Crassus has joined #armlinux
wwilly has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 256 seconds]
torez has quit [Quit: torez]
CrashTestDummy2 has joined #armlinux
CrashTestDummy3 has quit [Ping timeout: 265 seconds]