Re: spidev: Instantiating from DT as "spidev"

[Trent Piepho <tpiepho-cgc2CodaaHDQT0dZR+AlfA@public.gmane.org>]

On Wed, 2017-11-29 at 17:32 +0100, Geert Uytterhoeven wrote:
> On Wed, Nov 29, 2017 at 4:04 PM, Kyle Roeschley <kyle.roeschley@ni.com> wrote:
> > Since commit 956b200a846e ("spi: spidev: Warn loudly if instantiated from DT as
> > "spidev""), listing "spidev" directly in a device tree is not recommended.
> > Instead, what I see in the (many) past discussions is that I should change my
> > device tree to describe the actual hardware and add whatever new ID I create to
> > spidev_dt_ids. That seems perfectly reasonable.
> > 
> > 
> > Is there a "correct" solution to this problem? Both the Raspberry Pi [2] and
> > Beaglebone [3] kernels have just added "spidev" back to the match table, but I
> > would rather not carry a patch around just for some printk spam.
> 
> Implement something in sysfs like "new_device" for i2c, or "slave" for SPI.
> Then people can add a new device (e.g. "spidev") by writing to that
> virtual file.

I had a product that used a number of devices controlled via spidev,
and patching the kernel to add them to the spidev_dt_ids list is,
IMNSHO, a crap solution.  So I came up with something different.

Some other Linux bus subsystems, like PCI and platform, have a
"driver_override" sysfs attribute for each device.  Writing the name of
a driver to this attribute will bind the device to the named driver, 
even if the driver does not explicitly list the device in the bind
table.  This can be used to bind spidev to a device, without adding the
device type to a dt id list in spidev nor giving the device a type of
"spidev" rather than the real type.

So I added driver_override to to the spi bus.  There are some other
uses too, as platform and pci have the attribute and there is no spidev
driver for those buses.  For instance, you can bind spidev to a device
with a real kernel driver to debug something, at runtime, without
needing to modify device tree entries or patch the kernel.

Rather than manual write to driver_override files, one can use udev
rules to do it automatically.  Example:

SUBSYSTEM=="spi", ENV{MODALIAS}=="spi:adrf6820", ATTR{driver_override}+="spidev"

One can now use a "proper" compatible entry in the device tree,
compatible = "adi,adrf6820".

Creating new spi device is, IMHO, a separate problem from binding a spi
device to spidev.  One could try to solve that with the "new_device"
system used in i2c.  However, i2c added that over eight years ago when
device tree support was a lot less common and device tree fragments
didn't exist.  Now that we have dynamic dt fragment loading, maybe that
is a better system?

One can create a dt fragment that adds a new spi device, and this gives
you the ability to add all the properties the device might need (spi
mode, speed, device specific parameters, etc.).  It could bind to an 
normal spi-slave kernel driver or to spidev.

If adding a dt fragment is "too hard", just wrap it in a script.  It
should be trivial to write a script that takes a spi bus and chip
select and produces a generic dt fragment with those fields plugged in
and sends it to the appropriate place in sysfs.