Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #linux-msm
srinik has quit [synthon.oftc.net weber.oftc.net]
irungentoo has quit [synthon.oftc.net weber.oftc.net]
jessica_24 has quit [synthon.oftc.net weber.oftc.net]
bamse has quit [synthon.oftc.net weber.oftc.net]
qyousef has quit [synthon.oftc.net weber.oftc.net]
mka has quit [synthon.oftc.net weber.oftc.net]
ldts__ has quit [synthon.oftc.net weber.oftc.net]
jhugo___ has quit [synthon.oftc.net weber.oftc.net]
elder_ has quit [synthon.oftc.net weber.oftc.net]
CosmicPenguin has quit [synthon.oftc.net weber.oftc.net]
sboyd has quit [synthon.oftc.net weber.oftc.net]
pundir has quit [synthon.oftc.net weber.oftc.net]
jstultz has quit [synthon.oftc.net weber.oftc.net]
ndec has quit [synthon.oftc.net weber.oftc.net]
steev has quit [synthon.oftc.net weber.oftc.net]
arnd has quit [synthon.oftc.net weber.oftc.net]
dianders has quit [synthon.oftc.net weber.oftc.net]
srinik has joined #linux-msm
jessica_24 has joined #linux-msm
bamse has joined #linux-msm
irungentoo has joined #linux-msm
qyousef has joined #linux-msm
jhugo___ has joined #linux-msm
pundir has joined #linux-msm
steev has joined #linux-msm
CosmicPenguin has joined #linux-msm
ndec has joined #linux-msm
mka has joined #linux-msm
sboyd has joined #linux-msm
elder_ has joined #linux-msm
jstultz has joined #linux-msm
arnd has joined #linux-msm
dianders has joined #linux-msm
ldts__ has joined #linux-msm
<mort_>
did they finally remove the ability to have a devicetree node with compatible = "spidev" and talk to it from userspace? I no longer have /dev/spidev* devices after upgrading to 1.15
<mort_>
apparently not, there was something else weird in my devicetree.
<mort_>
nvm disregard that last message
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
<krzk>
mort_: in devicetree you cannot have it such compatible, but driver still exists and is used
<mort_>
krzk: what do I put in the devicetree then?
<krzk>
mort_: Specific device. Look at the of_device_id table.
<mort_>
krzk: there is no specific device
<mort_>
it's simply a microcontroller which speaks SPI, and we want to talk to that microcontroller from userspace
<mort_>
I hate that that's not a supported use-case, that Linux is incompatible with ad-hoc uses of SPI
<krzk>
mort_: Linux is. Devicetree is not. Devicetree (source) describes hardware and there is no hardware in your case.
<mort_>
krzk: but there is????
<krzk>
mort_: if there is, then there is specific device.
<mort_>
my hardware has a SPI controller
<krzk>
but you said there is no....
<mort_>
no?
<krzk>
aren't you now mistakin master and slave?
<mort_>
there is no "specific device" as in an existing product which the kernel already knows about
<mort_>
there is an SPI controller connected to an MCU
<krzk>
you wrote "there is no specific device", so this means line is not connected.
<mort_>
I don't think I'm mistaking master and slave, the Linux system is the master and the MCU is the slave
<mort_>
okay disregard what I said. What do I put in the devicetree
<mort_>
I need to tell the kernel that there's a SPI controller connected to an MCU
<krzk>
I answered at beginning. Did you check the table?
<mort_>
what am I supposed to be looking for
<krzk>
the table of spidriver. This binds, right?
<krzk>
So this is where the compatibles are - always, for every device/driver.
<mort_>
but there is no device the kernel knows about
<krzk>
s/spidriver/spidev driver/
<mort_>
it's a completely generic MCU which speaks SPI
<krzk>
and I am not talking about device. Look at my two responses above - I talk about driver.
<mort_>
I just need linux to expose it as an SPI device which I can talk to from userspace
<mort_>
there is no driver other than that
<krzk>
If there is no driver, then nothing binds, so you cannot use it and Linux does not support spidev. Which is of course not true, but if you come with such approach - that's the answer you will get.
<krzk>
Anyway, I know what you need - this is fairly common use case
<mort_>
so what is the generic SPI device driver
<mort_>
the equivalent of what the old compatible = "spidev" thing did
<krzk>
I don't know what is "generic"...
<krzk>
I did not mention it.
<mort_>
I did
<mort_>
it's not a difficult question
<krzk>
So I don't know what do you mean by that.
<mort_>
what compatible string do I put there to make the kernel do what it used to do with compatible = "spidev"
<aka_[m]>
he just want to be able to expose device in ioctl-style to userspace
<mort_>
yes
<mort_>
the MCU speaks a custom protocol on top of SPI and I want to talk to the MCU
<krzk>
aka_[m]: I know. I don't get why do you explain basics.
<mort_>
krzk: because you seem confused
<aka_[m]>
>_>
<aka_[m]>
he have point tho
<aka_[m]>
DT supposed to show real hardware
<krzk>
mort_: I am not. You asked weird questions like "what is generic SPI device driver" - I have no clue. What is generic I2C driver? Also no clue.
<aka_[m]>
and not imaginary abstraction
<mort_>
aka_[m]: there is real hardware, there's the SPI controller and there's the MCU
<mort_>
krzk: I just need a driver which exposes a device in /dev/ which I can throw bytes at and read bytes from
<aka_[m]>
then in theory you should write driver to talk to MCU
<mort_>
aka_[m]: yeah I'm not doing that
<krzk>
mort_: I told you what to put into DT - specific compatible matching device (the slave). I also told you where to look for specific explanation of it - spidev driver table.
<mort_>
krzk: AND WHAT IS THAT
<mort_>
what is the specific compatible matching the device
<krzk>
mort_: I know, if you are going to explain basics, then let's finish it. I know what you need, to rephrasing it won't change it.
<aka_[m]>
if this MCU is lets say stm32 based you are supposed to define it as stm32
<mort_>
krzk: the MCU is some STM32, is that what I put? But why would the kernel care that it's an STM32?
<aka_[m]>
how that works idk
<krzk>
mort_: what is that? You mean spidev driver? it is a driver. You can use git grep to find it.
<mort_>
krzk: but what am I looking for???
<krzk>
mort_: are you joking now? I wrote for what do you look for.
<krzk>
exactly, and you located the driver. Now go to my first reply. What is not understandable there?
<mort_>
krzk: but I need a compatible string, not a driver!
<krzk>
to recall - I wrote: "ook at the of_device_id table.
<mort_>
yes
<aka_[m]>
you are supposed to add new one to table
<mort_>
that's useless
<mort_>
none of the entries in spidev_dt_ids matches my hardware
<krzk>
so again, you are playing with me or what?
<mort_>
krzk: no? Why would you believe that
<aka_[m]>
spidev is generic so you can add your own compatible with name matching your hardware
<mort_>
krzk: which one of those entries do I pick for my random MCU speaking a custom protocol on top of SPI
<aka_[m]>
you add new one
<mort_>
krzk is saying I don't need to patch the kernel though
<krzk>
You do not pick these ones. you add new matching your specific device (product)/
<krzk>
mort_: I never said this.
<mort_>
wait so now I do need to patch the kernel?
<krzk>
Of course
<krzk>
because you need specific compatible for specific device - your product
<mort_>
so what is one supposed to do
<mort_>
when one doesn't want kernel patches
<mort_>
this used to be possible
<aka_[m]>
carry it oot
<krzk>
Fork the kernel... If we talk about upstream, you need patches.
<krzk>
Anyway lore and git log on that driver will give you also answers how people did it.
<mort_>
the upstream kernel already has all the functionality I need though, it *has* a generic SPI device driver which just exposes a device you can use from userspace
<mort_>
why the hell did they make that inaccessible without kernel patches when it used to be available
<krzk>
mort_: you were explained this at beginning - kernel accepts it. Devicetree does not, because you want to add something fake to DTS.
<mort_>
krzk: I don't want to add anything fake!
<aka_[m]>
DT says you are supposed to describe real hardware, this is abstraction
<mort_>
I want to tell the kernel that there's a device there which speaks SPI
<krzk>
Fake meaning, non-existing, non-specific, wildcard device. Wildcards and non-specific devices are not allowed.
<mort_>
that's not fake
<mort_>
krzk: it's not non-existing
<mort_>
it's right there
<krzk>
spidev is abstraction, it's fake, it is not a device
<aka_[m]>
but spidev is not real hardware per se
<mort_>
it is real hardware
<aka_[m]>
no
<krzk>
no, spidev is not
<aka_[m]>
there is MCU exposing SPI interface
<mort_>
this is literally as if you had to hard-code the name of the wifi access point model you intend to connect to
<krzk>
Right. Because we describe WiFi clients in DT...
<krzk>
This is like with all the buses - I2C, SPI, 1wire whatever
<mort_>
krzk: no we don't, but we have to describe SPI connections in the DT
<krzk>
You don't have to
<mort_>
it *does not matter to anyone* what's on the other side
<mort_>
it's some black box which speaks SPI
<krzk>
You can load the driver anyway you wish, don't mess DT into it. If you want to use DT, then follow DT rules.
<mort_>
why would you remove this completely harmless, incredibly useful, widely used feature
<mort_>
this is a major regression
<krzk>
mort_: anyway, if you do not like spidev or something about DT, feel free to share this on LKML, although I do not think you will get much of support in this matter :)
<mort_>
this is directly working against the apparent goal of making people stop carrying custom kernel patches
<Tooniis[m]>
cant you like just enable the bus without defining any device nodes in it?
<krzk>
"this is" like is when? You mean "this was"?
<mort_>
krzk: this as in removing support for SPI?
<krzk>
SPI is dev, nothing got regressed. You can use spidev with anything you wish.
<krzk>
You did not loose anything.
<mort_>
SPI doesn't work anymore
<mort_>
you can't connect SPI devices to your hardware anymore without patching the kernel
<krzk>
What we do not allow is non-real (non-specific, wildcards) devices in DTS.
<mort_>
Linux removed support for connecting SPI devices to the kernel
<mort_>
err, to the system
<krzk>
You can. Why do you mess DTS into it?
<mort_>
I need the SPI node to make /dev/spi* show up
<mort_>
people have been connecting SPI devices to their systems and telling the kernel through dt for as long as SBCs have been a thing, probably longer
<mort_>
removing support for that is an incredible regression
<mort_>
why encourage people to carry kernel patches?
<mort_>
so anyways, it seems like the practical solution here is to give up any hope of running mainline linux since linux doesn't support SPI devices
<aka_[m]>
>_>
<krzk>
yep, no SPI devices are supported.
<mort_>
aka_[m]: what do you mean by that
<krzk>
let's ask broonie to 'rm -fr drivers/spi/'
<aka_[m]>
fact, nothing has changed at all
<aka_[m]>
its just spidev compatible going out
<mort_>
aka_[m]: you used to be able to say compatible = "spidev"
<aka_[m]>
now you need add shit in dt_itds and instead of spidev use new compatible you add pointing to same .data
<krzk>
you used to add many incorrect things in the kernel or Devicetree, so let's keep doing that
<krzk>
Why using other means? Let's do incorrect way...
<mort_>
aka_[m]: exactly!
<mort_>
aka_[m]: Linux doesn't support it anymore, you have to patch the kernel
<mort_>
aka_[m]: which means there is no hope of running mainline linux anymore
<krzk>
of course it supports...
<mort_>
krzk: so what do I put in the compatible string
<aka_[m]>
there is but it takes way too much effort and patches to achieve same outcome
<aka_[m]>
if you have time.....
<Tooniis[m]>
mort_: whats so difficult about sending a one-liner patch adding a new compatible?
<krzk>
whatever you wish... like spidev
<mort_>
aka_[m]: wait what are you disagreeing with? You just agreed with me that you need to patch the source code
<krzk>
binding DT nodes works also by driver name
<aka_[m]>
on the other hand its beneficial to have very specific dts because other OSes can write their drivers to utilize "descriptions" for them so they don't have to deal with custom dt
<mort_>
aka_[m]: I do not care, Linux removed support for connecting SPI devices
<aka_[m]>
it didn't
<mort_>
aka_[m]: oh, what do I put in the compatible string then?
<aka_[m]>
whatever what explain chip
<mort_>
so what explains the chip
<aka_[m]>
can you read MCU name on board?
<krzk>
srsly, you are trolling now... "removed support for connecting SPI devices" - that's a joke
<mort_>
it's some STM32, I don't have the full name. f4 something?
<mort_>
krzk: ok so what do I put in the compatible string
<krzk>
I answered to you.
<mort_>
krzk: you said whatever I wish, like spidev
<krzk>
yep
<mort_>
krzk: but if I put spidev in the compatible string, the device doesn't show up
<mort_>
because you guys broke that
<krzk>
and what about other spi devices? You wrote there is no support.
<krzk>
My devices show up.
<krzk>
And they talk over SPI...
<mort_>
krzk: what do I put in the compatible string to make my device show up
<mort_>
aka_[m]: did it help you that it's some stm32f4
<mort_>
or shall I find the exact model name
<aka_[m]>
you add compatible like:
<aka_[m]>
prefix_vendor,device_model
<mort_>
would that help you suggest a compatible string
<aka_[m]>
stm,stm32f104
<aka_[m]>
or so/
<aka_[m]>
not sure what is stmicroelectronic prefix
<mort_>
aka_[m]: and that will just work? Linux has a list of every single stm mcu?
<aka_[m]>
unless someone adds it there isn't any list
<mort_>
aka_[m]: oh, so why did you suggest it then
<aka_[m]>
ok i feel a bit too dumb now >_>
<mort_>
you are, don't worry
<mort_>
you're trying to argue that Linux didn't remove support for generic SPI devices, while at the same time trying to argue that I should add a kernel patch to add support for generic SPI devices
<krzk>
aka_[m]: it's just trolling, I am not sure what's the point to keep discussing.
<mort_>
those two are incompatible
<aka_[m]>
it removed compatible
<mort_>
yeah, Linux removed support for generic SPI devices
<aka_[m]>
not driver
<mort_>
I didn't say it removed the driver
<mort_>
software does not support a given feature if you need to go in and modify the source code to add support for the feature
<mort_>
Linux used to support generic SPI devices, that support was removed, you two are trying to argue against that while at the same time arguing that it was a good thing that support for generic SPI devices was removed
<krzk>
Linux supports generic SPI devices. They work perfectly fine.
<mort_>
krzk: oh, so what do I put in the compatible stirng
<krzk>
BTW, why do we discuss something which was done 7 years ago?
<krzk>
Or actually 8?
pespin has joined #linux-msm
<krzk>
mort_: you repeat the same question but it is not the argument towards my statement. There are generic devices which are supported. This is enough to make your statement "Linux used to support generic SPI devices," not true.
<krzk>
This statement is simply not true.
<mort_>
krzk: I repeat the same question because you keep claiming that Linux supports generic SPI devices
<krzk>
Yes, there are some generic SPI devices which are supported.
<mort_>
if Linux supports generic SPI devices, there is something I can put in my compatible string
<krzk>
Therefore from logic point of view, that statement is correct.
<mort_>
"Linux supports these specific SPI devices" does not support the idea that Linux support generic SPI devices
<krzk>
First, you can put there many stuff and we told you what - you keep ignoring it. Second, now you refer to DT, and how does it matter? You can support generic devices with other ways, not only DT.
<mort_>
krzk: what am I ignoring?
<krzk>
Waht compatible to put there.
<mort_>
I know I have to patch the kernel to make Linux support my SPI device
<mort_>
you keep saying I don't have to while at the same time arguing that I should
<krzk>
But focus on the second item - why do you mess here with DT? Linux suppports all this.
<mort_>
I need a SPI device to throw ioctls at.
<krzk>
It is not related to DT.
<mort_>
it is
<krzk>
No, my system does not have DT and generic SPI devices are supported.
<krzk>
Thus statement they are not supported, is not true.
<krzk>
BTW, you are aware we talk about change done 8 years ago?
<krzk>
8 years.
<mort_>
krzk: incorrect
<mort_>
Linux supported compatible = "spidev" as recently as 5.10
<mort_>
I mean it did warn on it, but it worked
<krzk>
mort_: 8 years ago there was big deprecation message done telling you - YOU CANNOT do this
<mort_>
yeah, which was a terrible decision, but it still worked
<krzk>
yep, it gave you 8 years to fix old, broken stuff
<mort_>
there is no old, broken stuff
<krzk>
So decision was made 8 years ago or even earlier...
<mort_>
there is no migration path, other than to carry a kernel patch
<krzk>
Nothing stops you to bind any generic SPI device with any other way you wish (not DT-compatible way)
<mort_>
there isn't even anything inappropriate about having it in the dt though
<krzk>
So the feature is exactly still there, except for DT case where we told 8 years ago - it's going bye-bye.
<mort_>
the DT is there to describe my hardware
<krzk>
Now you discuss abuot something 8 years ago... no point.
<mort_>
the fact that there is an MCU connected to these particular SPI pins is part of the hardware
<mort_>
I'm discussing a recent breaking change in Linux.
<krzk>
8 years ago we did not allow something. This is the moment decision was made.
<mort_>
you know, this didn't have to be a long discussion
<mort_>
if you simply agreed, "yeah, Linux removed support for that, you now need to carry a kernel patch or bind it manually" this discussion would have been over an hour ago
<krzk>
There was no such question..
<mort_>
what question
<krzk>
Feature is there - you can put any compatible we gave you (which for some reason you keep ignoring and asking "which?" even though we pointed specific ones), you can use other wys to bind your devices. Everything is there.
<krzk>
The question "what piece was removed from linux"...
<mort_>
krzk: point me at a compatible string I can put in my devicetree without kernel patches again, I must have missed it.
<krzk>
So only yours, only yours system cannot work with generic SPI devices (spidev). And you claim something is lost... but all other people can. Weird,.
<krzk>
I told you - whatever you wish (for your testing)
<mort_>
oh or maybe I choose to pretend it's a silicon labs
<mort_>
this isn't for testing
<krzk>
Wait, so you want to put it to real device and you keep arguing that "it is not specific device"?
<mort_>
of course it's a real device, it's a proper stm32 with some firmware which speaks a protocol built on top of SPI
<krzk>
Is it hotplug? Like connector?
<mort_>
I told you this
<krzk>
Then it is a specific device, not a generic.
<mort_>
it's not hotplug, it's BGA mounted to the PCB
<krzk>
So it is fairly specific. Don't see a problem there.
<z3ntu>
mort_: add `yourcompany,your-stm-product` to the driver, send it upstream and carry it in your tree in the meantime
<mort_>
z3ntu: what does that help anyone at all
<krzk>
Just like with all other cases - all other people and their products. Srsly, why your case is different?
<z3ntu>
if you don't want to send it upstream, don't
<krzk>
You said that some feature is lost, but you are the only person affected, so I don't believe that. All other people have that feature - spidev via DT - only you do not have it... weird.
<mort_>
anyways, I'm done with this discussion. I'm disappointed that Linux removed support for this use case, I'm disappointed that none of you are even capable of acknowledging the breakage, and I will just carry a patch forever to add back support for what Linux removed support for.
<mort_>
krzk: the raspbian people are also carrying a similar patch because they were also hit by this breaking change
<mort_>
I'm not alone here
<mort_>
anyways bye
<AffeNull[m]>
Is there an alternative way to bind spidev to an otherwise unused SPI bus, e.g. via sysfs?
<krzk>
AffeNull[m]: hm, maybe through udevadm trigger? But it does not matter because for testing you can use any compatible from spidev you wish. For real DTS then *since 8 years DTS* with "spidev" is *not allowed*. It was forbidden 8 or more years ago. So even if kernel allowed spidev to bind to such spidev-compatible devices, the DTS could not be upstreamed.
<krzk>
and this is nothing new... many years passed since then.
Danct12 has quit [Quit: WeeChat 3.8]
Daanct12 has quit [Remote host closed the connection]