On Wed, Mar 26, 2025 at 12:16:53PM +0000, Jon Hunter wrote:
On 25/03/2025 17:05, Mark Brown wrote:
quoted
quoted
The way I imagine it, exporting would involve writing a chip-select to a
specific SPI controller's "export" sysfs attribute to have a SPI device
created for that particular chip-select and bind it to spidev.
quoted
My general feeling with those is that if you're building for them you're
probably either already modifiying your kernel or easily able to cope
with doing so.
That's definitely what we do today, modify the kernel directly to achieve
what we need. I am trying to avoid carrying too many out of tree patches for
stuff like this and have something in the kernel that works by default. This
is even more important for 3rd party Linux distros that will not accept
non-upstream code.
Overlays should work well for that case too!
Our devkits, very much like Raspberry PI, allow users to connect various
hardware for development and so having an easy way to connect a SPI device
is useful. For any production systems, users will definitely want a proper
device and device-tree bindings. So I am just trying to explore what would
be acceptable. If it is acceptable to have a sysfs interface for creating a
SPI device at runtime, then we can look into that.
The main issue I see with the sysfs thing is that you have to describe
the presence of the device somehow which currently needs a device of
some kind there, it's not like I2C where you can just use the address.