Hi Trent, On 02/02/18 18:58, Trent Piepho wrote: >> 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. > Thanks for that. What's the status of the patch currently? I can't see it on patchwork... Looking back at your earlier email you point out doing this through udev rules, which is IMO a good way to solve the problem > > 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. Is this an aspiration, a WIP, or just a thought? Thanks, Henry
Attachment:
signature.asc
Description: OpenPGP digital signature
