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
prabhakarlad has joined #armlinux
Pali has quit [Ping timeout: 264 seconds]
torez has quit [Quit: torez]
apritzel_ has quit [Ping timeout: 265 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
nsaenz has quit [Ping timeout: 265 seconds]
tudorel has joined #armlinux
audgirka has joined #armlinux
guillaume_g has joined #armlinux
apritzel_ has joined #armlinux
iivanov has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 250 seconds]
CrashTestDummy has joined #armlinux
apritzel_ has quit [Ping timeout: 250 seconds]
monstr has joined #armlinux
djrscally has joined #armlinux
sszy has joined #armlinux
alexels has joined #armlinux
iivanov__ has joined #armlinux
iivanov_ has joined #armlinux
iivanov_ has quit [Client Quit]
iivanov has quit [Ping timeout: 250 seconds]
iivanov__ has quit [Ping timeout: 265 seconds]
iivanov has joined #armlinux
iivanov has quit [Remote host closed the connection]
gdd has quit [Ping timeout: 250 seconds]
iivanov has joined #armlinux
nsaenz has joined #armlinux
gdd has joined #armlinux
iivanov__ has joined #armlinux
iivanov__ has quit [Read error: Connection reset by peer]
iivanov has quit [Ping timeout: 256 seconds]
iivanov has joined #armlinux
apritzel has joined #armlinux
iivanov__ has joined #armlinux
iivanov_ has joined #armlinux
iivanov has quit [Ping timeout: 250 seconds]
iivanov__ has quit [Ping timeout: 256 seconds]
iivanov has joined #armlinux
iivanov_ has quit [Ping timeout: 265 seconds]
bps has joined #armlinux
bps has joined #armlinux
Pali has joined #armlinux
matthias_bgg has joined #armlinux
elastic_dog has quit [Ping timeout: 250 seconds]
audgirka has quit [Remote host closed the connection]
elastic_dog has joined #armlinux
Turingtoast has joined #armlinux
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #armlinux
iivanov__ has joined #armlinux
iivanov_ has joined #armlinux
iivanov has quit [Ping timeout: 256 seconds]
iivanov__ has quit [Ping timeout: 264 seconds]
iivanov_ has quit [Read error: Connection reset by peer]
iivanov has joined #armlinux
audgirka has joined #armlinux
iivanov__ has joined #armlinux
iivanov has quit [Ping timeout: 250 seconds]
iivanov__ has quit [Read error: Connection reset by peer]
iivanov has joined #armlinux
leming has quit [Ping timeout: 256 seconds]
iivanov has quit [Ping timeout: 268 seconds]
leming has joined #armlinux
<Xogium>
I've asked in kernelnewbies on oftc already but didn't get any answer yet… so I also ask here in case people would know what to do
<Xogium>
I have stm32f769 discovery kit board, where I must set sdram base address to 0xc0000000
<Xogium>
problem is menuconfig won't let me do it and says invalid entry
<Xogium>
how do I go about this ?
torez has joined #armlinux
<arnd>
Xogium: do you have CONFIG_SET_MEM_PARAM enabled?
<arnd>
without these, CONFIG_DRAM_BASE is hidden
<Xogium>
arnd: yeah… I found the trick. I think
<Xogium>
I needed to set it typing c0000000
<Xogium>
which converted to 0xc0… for some reason typing 0xc0 did not work
<Xogium>
time to put this show on the road
Nact has joined #armlinux
<Xogium>
what the ?
<Xogium>
I set it to 0xc0 in the config, I mean even my defconfig has it
<Xogium>
I start a rebuild of the kernel, and ram base address is back to 0x00000000
<Xogium>
I definitely have that mem_param option enabled
<Xogium>
I mean… I'm very confused now
macromorgan has quit [Quit: Leaving]
audgirka has quit [Remote host closed the connection]
<Xogium>
is linux trolling me ? ;0
<Xogium>
;) even
<Xogium>
or, maybe its buildroot ? Hmph… don't think it tweaks the ram address…
<Xogium>
yeah I think its buildroot making fun
<Xogium>
ah yes used the wrong config fragment
<Xogium>
I swear sometimes I feel like a newb
<Xogium>
:p
<mort>
Hey, so I have a gpio-keys node. I'd love to figure out which gpio it corresponds to. What's the best way to do that?
<mort>
I did find the OF node, it's in /sys/firmware/devicetree/base/gpio-keys/user-button
<mort>
there's a file there called gpios, it seems to contain 'j'
<mort>
ah most of the bytes in gpios are non-printable, it contains 0000 006a 0000 0015 0000 0001
<geertu>
mort: It's a 3-cell GPIO specifier: phandle, index, and flags
<mort>
so three u16s I assume
<mort>
big endian? weird
apritzel_ has joined #armlinux
<geertu>
mort: each cell is 32-bit
<mort>
ohh I was misreading xxd's output then
<mort>
apparently busybox xxd shows you two bytes without spaces inbetween followed by a space and then two more bytes
<geertu>
So it's GPIO 21 on the controller with phandle 0x6a
<mort>
from the dts I know it's the controller with the name gpio3, which happens to be gpiochip96; but how would I otherwise find a gpio from its phandle?
<geertu>
mort: find the virtual file phandle under /sys/firmware/devicetree/base that contains (binary) 0x6a
<geertu>
once you get to gpiochip96, you know the gpio is 96 + 21
apritzel_ has quit [Ping timeout: 260 seconds]
<mort>
which works very well in theory but writing 117 to gpio/export gives a device or resource busy error, curious
<mort>
I'll verify that it's actually gpiochip96 by looking at the phandle files
<geertu>
mort: Of course it's busy, it's in uswe by gpio-keys ;-)
<mort>
ah, derp. I assumed there could be multiple readers like how you can read the iio device backing an adc-keys while the adc-keys is doing its thing
<geertu>
You can unbind it: "echo gpio-keys > /sys/bus/platform/drivers/gpio-keys/unbind"
<geertu>
(the first gpio-keys comes from /sys/firmware/devicetree/base/gpio-keys, the second from the driver's name)
<mort>
ah, awesome
<geertu>
After that export shpuld work
<mort>
I'll build a kernel without the gpio-keys in the dts anyways, but this is useful
<geertu>
When you're done, repeat with s/unbind/bind/
monstr has quit [Remote host closed the connection]
Amit_T has joined #armlinux
torez has quit [Ping timeout: 250 seconds]
torez has joined #armlinux
shoragan[m] has quit [K-Lined]
psydroid has quit [K-Lined]
a3f has quit [K-Lined]
mvaittin has quit [K-Lined]
amstan has quit [K-Lined]
psydroid has joined #armlinux
cengiz_io has quit [Ping timeout: 264 seconds]
NishanthMenon has quit [Ping timeout: 264 seconds]
ndesaulniers has quit [Ping timeout: 264 seconds]
mturquette has quit [Ping timeout: 264 seconds]
broonie has quit [Ping timeout: 264 seconds]
pjw has quit [Ping timeout: 264 seconds]
ccaione has quit [Ping timeout: 240 seconds]
roxell has quit [Ping timeout: 240 seconds]
narmstrong has quit [Ping timeout: 264 seconds]
linusw_ has quit [Read error: Connection reset by peer]
sboyd has quit [Read error: Connection reset by peer]
robclark has quit [Read error: Connection reset by peer]
unixsmurf has quit [Read error: Connection reset by peer]
dtor has quit [Read error: Connection reset by peer]
Crofton has quit [Ping timeout: 268 seconds]
zx2c4 has quit [Ping timeout: 250 seconds]
maennich has quit [Read error: Connection reset by peer]
dianders has quit [Read error: Connection reset by peer]
nohit has quit [Ping timeout: 265 seconds]
nathanchance has quit [Read error: Connection reset by peer]
robher has quit [Write error: Connection reset by peer]
khilman has quit [Read error: Connection reset by peer]
olofj_ has quit [Read error: Connection reset by peer]
netonaut_ has quit [Read error: Connection reset by peer]
jamestperk has quit [Read error: Connection reset by peer]
arnd has quit [Ping timeout: 250 seconds]
sjg1 has quit [Read error: Connection reset by peer]
tfiga has quit [Read error: Connection reset by peer]
roxell has joined #armlinux
sboyd has joined #armlinux
robclark has joined #armlinux
dianders has joined #armlinux
nathanchance has joined #armlinux
arnd has joined #armlinux
netonaut_ has joined #armlinux
Crofton has joined #armlinux
linusw_ has joined #armlinux
khilman has joined #armlinux
dtor has joined #armlinux
olofj_ has joined #armlinux
sjg1 has joined #armlinux
pjw has joined #armlinux
ndesaulniers has joined #armlinux
maennich has joined #armlinux
ccaione has joined #armlinux
narmstrong has joined #armlinux
cengiz_io has joined #armlinux
NishanthMenon has joined #armlinux
mturquette has joined #armlinux
jamestperk has joined #armlinux
nohit has joined #armlinux
zx2c4 has joined #armlinux
mvaittin has joined #armlinux
a3f has joined #armlinux
shoragan[m] has joined #armlinux
amstan has joined #armlinux
unixsmurf has joined #armlinux
broonie has joined #armlinux
robher has joined #armlinux
tfiga has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
psydroid has quit [Quit: Client limit exceeded: 20000]
shoragan[m] has quit [Quit: Client limit exceeded: 20000]
Xogium has quit [Quit: Leaving.]
Xogium has joined #armlinux
mvaittin has quit [Quit: Client limit exceeded: 20000]
headless has joined #armlinux
sudeepholla has quit [Ping timeout: 240 seconds]
sudeepholla has joined #armlinux
tudorel has quit [Quit: tudorel]
<javierm>
broonie: do you have any thoughts on "[PATCH] spidev: Make probe to fail early if a spidev compatible is used" ?
psydroid has joined #armlinux
mvaittin has joined #armlinux
shoragan[m] has joined #armlinux
<javierm>
ukleinek is correct that users could still make it match / probe with the driver_override sysfs entry
<broonie>
javierm: Didn't ukleinek already point out issues there?
<javierm>
broonie: he did yes, but wondered if you had any opinions. For example, was expected to make it work with driver_override or that's just another oversight ?
<javierm>
in other words, do we want to support compatible = "spidev" at all ?
<javierm>
broonie: because I think with the current status quou is hard to know whether that's supposed to work on or
<broonie>
Well, we don't want people to use it.
alexels has quit [Quit: WeeChat 3.3]
<broonie>
But binding at runtime is a valid thing.
<broonie>
As he said.
<javierm>
broonie: got it. Thanks for the clarification
prabhakarlad has quit [Quit: Client closed]
<geertu>
ukleinek: javierm: broonie: Seems like I'm missing something. How does that patch prevent option c) (unless $chipname == spidev, of course)?
<javierm>
geertu: right, I assumed that $chipname == spidev since that's what people are using in the DTB that we don't want to break
<broonie>
Hrm, right - I'd not actually checked that bit but yeah, I don't immediately see how driver_override impacts of_device_is_compatible().
<javierm>
broonie: but /sys/bus/spi/devices/spiX.Y will have a spi->dev.of_node with compatible = "spidev" so it will prevent the probe
<broonie>
Where will it get that from?
<broonie>
I'm thinking of the case where it has some valid compatible that's not supported by anything and the user uses driver_override to bind to spidev.
<javierm>
broonie: ah, that will work. I (mis?)understood that ukleinek meant that we want to keep supporting a DTB with compatible = "spidev"
<javierm>
that won't match (after commit 6840615f85f6) but you could force the binding with driver_override
<geertu>
broonie: that's the expected use case, AFAIK
<broonie>
Yeh.
<broonie>
Yeah.
<javierm>
broonie: my opinion is that anyone using compatible = "spidev" was abusing the SPI device model and we shouldn't attempt to keep supporting that
<geertu>
So true
<broonie>
Yes, I'm not so worried about that but if it does for some reason break the case I mentioned above that's a serious problem.
<geertu>
DT schould describe the actual hardware, driver_override helps to make the spidev driver work with it (and handle the rest in userspace)
<broonie>
ukleinek: What's the issue you see with driver_override.
<javierm>
broonie: I don't see how it would as geertu also said. This will only prevent compatible = "spidev" but you could have compatible = "foobar" and still bind from user-space
<javierm>
even if there isn't a spi_device_id or of_device_id entry that matches
<broonie>
Yeah, me either - I'd not actually double checked since you both seemed to agree it was an issue.
<javierm>
broonie: I did not completely agree if you read the last paragraph in my email :) that's why I asked what was your take on this
<broonie>
You said you'd just give up on the broken driver_override, I'm not seeing anything in there which says that driver_override still works.
<javierm>
sorry if I wasn't clear, I meant that I would just give up on the broken compatible = "spidev"
<javierm>
that's the abuse I was talking about there
<broonie>
So just addressing a and not c.
<javierm>
broonie: yes, b and c should continue to work. Option a would not but in my opinion that's not an issue
<javierm>
it was working before should out of sheer luck
<javierm>
s/should/just
<javierm>
broonie, geertu: just to make it clear, what we will be breaking with that patch is:
<javierm>
$ echo $chipname > /sys/bus/spi/devices/spiX.Y/driver_override should continue to work
<broonie>
So it does break binding spidev to a device then? How does it get broken - AFAICT that only happens if it causes of_device_is_compatible() to match and I can't see how that happens?
<javierm>
err, sorry I got confused again. The former should continue to work unless compatible = "spidev"
<broonie>
driver_override should be... right.
<javierm>
broonie: yeah, it should continue to work even after that patch. Sorry for the noise in the last messages
<geertu>
javierm: "echo $chipname > /sys/bus/spi/devices/spiX.Y/driver_override" is actually wrong, as what you write to driver_override should be the driver's name
<geertu>
i.e. spidev in this caswe
<javierm>
geertu: yeah, misread as device_override. It's getting late here :)
<javierm>
broonie, geertu: I'll answer to in the list and stop spamming this channel
<broonie>
Oh, I just did that - snap .
Amit_T has quit [Quit: Leaving]
<javierm>
broonie: thanks
prabhakarlad has joined #armlinux
<rfs613>
IMHO... the normal use case for spidev is to let userspace issue SPI commands, typically for devices that do not have a kernel driver. There are tons of these, typically not performance critical, but often necessary for proper device functioning.
<rfs613>
All the changes to try and banish compatible=spidev does not help convert these to proper drivers. It just creates friction and users trying to find a fast way around whatever new restriction.
<geertu>
rfs613: Just use a proper compatible value in DT. That's all we ask for ;-)
apritzel has quit [Ping timeout: 250 seconds]
<rfs613>
I see it kind of like UIO for handing register mapped hardware and/or an interrupt. It's a valid use case for plenty of situations. Breaking it just adds more reasons for users to keep using older kernels, to avoid the hassle.
<geertu>
rfs613: spidev still works.
<rfs613>
geertu: if you can. But I bet you will end up with users just doing s/spidev/spidev01/ in their compat string.
<geertu>
rfs613: After which they still have to update spidev.c, or use driver_override.
<rfs613>
or even "sPiDeVruLes"
<broonie>
rfs613: The point here isn't to convert those drivers to in kernel drivers, the point is to make sure the DT actually describes the hardware.
<geertu>
Exactly, "DT describes hardware. not software policy"
<rfs613>
broonie: yes, I'm aware, but i've been on both sides of this... and UIO drivers are another perfect example where the DT doesn't describe the actual hardware.
<geertu>
90% of the DT questions can be answered by following that mantra.
<broonie>
UIO should be similarly fixed then.
<javierm>
rfs613: that's a fair argument but commit 956b200a846e ("spi: spidev: Warn loudly if instantiated from DT as "spidev"") and later 6840615f85f6 ("spi: spidev: Add SPI ID table") drop that support
<rfs613>
broonie: expect much more pushback then, as I suspect UIO is used a lot more than spidev.
<javierm>
rfs613: so since the kernel doesn't support that case (never really did by design) it should just fail the probe
<broonie>
I mean, even if you're using spidev userspace still needs to know which userspace driver to start!
<geertu>
UIO is very similar: MODULE_PARM_DESC(of_id, "Openfirmware id of the device to be handled by uio");
<geertu>
It should also work with driver override BTW
<geertu>
Actually UIO took the lead: they do _not_ have "uio" in uio_of_genirq_match[0].compatible
<broonie>
nor does spidev, it only worked due to the fallback to spi_device_id which was there since the DT bindings were added to the core.
<javierm>
broonie: yeah, the fact that compatible = "spidev" matched was due the SPI core leaking a linux kernel implementation detail
<broonie>
Well, the fact that we had that spidev thing in there was a bit hacky even for board files TBH.
<javierm>
right
<rfs613>
hmm, but for a UIO device, the DTS entry has compatible = "generic-uio" (or at least it did the last time I checked)
<broonie>
It shouldn't, that just happens to work probably because of the same fallback to matching DT IDs with board file ones.
<geertu>
rfs613: There's one in-kernel DTS with that compatible value. And no driver matches against it.
<rfs613>
right, so you either had to patch the driver to match it, or set a kernel commandline parameter to add to the match table
<geertu>
"git grep -w compatible -- drivers/uio/" shows better use (although I dislike the "-uio" suffix, as that's policy. What if a kernel driver is written?)
<broonie>
At this point we should probably go through buses and make any use of fallbacks warn, DT is widespread enough that it's probably worth the costs.
<rfs613>
javierm: to most users though, this is just voodoo, which they probably found on a stackoverflow post (or some vendor forum)
<javierm>
rfs613: well, it's voodoo even when being familiar with the linux driver model :)
<rfs613>
they are busy trying to build something, not figure out the "lastest kernel fashion trend". So if we want people to really switch, there needs to be a good document of what is the problem, what needs to be done by user to fix it. And ideally the warning should point them directly to such a document.
<javierm>
it's for sure a very creative way to use the matching
<javierm>
rfs613: agreed
<rfs613>
maybe something under Documentation directory, the warning could link to kernel.org copy of it. I'd be happy to review such a document... not sure if I could write it, think I am probably too biased ;-)
<rfs613>
by the way, in response to "option c)" described by Uwe... that approach is messy for many users, as they need to get those echo statements into their boot sequence, before userspace code that needs to access spidev starts. Sounds simple but often is more covoluted and complicated than you'd expect. So at least using a cmdline override is "simpler" in that regard.
<broonie>
TBH if you're using this stuff you're typically also patching your kernel so just adding something to the ID table in the relevant kernel driver is usually not a huge barrier.
<rfs613>
broonie: I know of a lot of kernel repos carrying a patch to remove the existing WARN()...
<broonie>
I'm not sure such users are going to be swayed by documentation.
<javierm>
rfs613: strange they are doing that instead of just adding an entry for their device...
<rfs613>
it comes down to time... they have to learn how to fix it "properly".. but they don't invest the time, because $(reasons)
<javierm>
rfs613: fair
<broonie>
the diffstat is literally smaller.
<rfs613>
instead they google, or just hack out the WARN(). It stops the kernel maintainer guy being asked about it by successive "verification" team members...
<javierm>
yeah, probably git blame + git revert is faster to come with
<rfs613>
then said kernel tree gets handed to me, along with 50 other out-of-tree patches, so fixing spidev is not high on my priority scale
<geertu>
rfs613: So we need a comment next to the WARN: do not remove, add your compatible value to the array instead
<rfs613>
esp if I have to convince them to add echo's to startup (are you using systemd or sysv.... "what?")
<geertu>
"next" to make sure it causes a conflict when they forward-port their code to a newer kernel (hahaha, who cares to upgrade to a newer kernel anyway? ;-)
<rfs613>
we basically have to give really explicit instructions. eg 1) in your device tree, change "spidev" to a more specific string such as..., and then 2) add this ID to the table (be clear which table we mean, line number/name, etc)
<broonie>
rfs613: If you add the compatible to the driver you don't need to do anything in startup.
<broonie>
and like I say I struggle to see people who are going around just finding the commit adding the warning and reverting it doing much more than that.
<javierm>
rfs613: Documentation/spi/spidev.rst already mentions that... it's kind of outdated because uses board files terminology but still
<javierm>
rfs613: I can propose a patch to update that doc but honestly I don't think such users will read it anyways
<rfs613>
javierm: hmm, quick scan of spidev.rst as of 5.15, it does not mention "compatible" or devicetree. It does say "list it in the spi_board_info ..." but I doubt this would help users who encounter the WARN() to understand what they should do.
<geertu>
perhaps we should also remove all "spidev" nodes from upstream DTS files?
<geertu>
and add a rule to checkpatch to complain about spidev?
<rfs613>
kinda comes across as the kid that won't let anyone else play with their toys ;-)
apritzel_ has joined #armlinux
<geertu>
rfs613: You can play with my toys, if you don't use a fake name ;-)
<rfs613>
ah, but my name really is Princess Naomi Suruga and I have a special Bank transfer for you! :P
apritzel_ has quit [Ping timeout: 264 seconds]
<javierm>
rfs613: yep, that's why I said that it uses board files terminology and could propose a patch to update it
<javierm>
geertu: that's a good idea if the kernel does not support that case anymore. Otherwise the upstream DTS are misleading
<javierm>
never thought that asking about this patch would lead into such a long discussion