Re: spidev: That spidev in the DT issue again...

[Trent Piepho <tpiepho@xxxxxxxxxx>]

On Fri, 2018-02-02 at 15:47 +0000, Henry Gomersall wrote:
> 
> Before I dig deeper into understanding it, is there a reason why we
> can't have an "spi-generic" device as a catch-all for a DT defined
> userspace SPI bus?
> 
> The clear use case for more flexibility in the system is around FPGA
> based SoCs (in my case a Zynq). In such a scenario the use of userspace
> is a natural complement to runtime configurable hardware blocks. It
> would really ease access to (at least somewhat) correct use of the
> driver if it could be recognised that the kernel might not actually need
> to know what's on the end of an SPI bus.

I've got a patch that adds "driver_override" to the SPI bus.  This
already exists on the PCI bus, platform bus, and AMBA bus.

One can name the SPI device's type in the DT correctly to anything you
want.  Call it "smartacoustics,fpga-codec-block-1.0" or whatever.  It
doesn't have to have to be "generic" or "name-of-linux-driver".  Names
like that are what aren't supposed to be in the DT.

Then driver_override allows this specific device to be bound to spidev.
 It works for all other spi drivers too.  Suppose the device you have
created in an FPGA is or can be compatible with a standard SPI eeprom. 
Bind the eeprom driver to it.  Reconfigure the FPGA logic and now it
works like a SPI controlled DAC and switch to the DAI driver.

I think this solves the problems of SPI slaves that are:
* Of an unknown type at the time the DT is given to the kernel.
* Unique devices that don't make sense to put into a kernel driver
framework and should be controlled from userspace as SPI devices.
* Implemented in re-configurable logic and how the kernel should view
them can change.

It does not solve the problem of creating and destroying SPI slaves
dynamically at run time.  This can be solved (and it way that isn't
specific to spidev), via:
* Copying the I2C new_device system, which allows this with limitations
and in a SPI (and I2C) specific way.
* Incorporation of the dynamic DT fragment loading system, which solves
this with far less limitation and it manner that is not bus specific.��.n��������+%������w��{.n�����{����)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥