On Sat, 2018-02-03 at 08:31 +0000, Henry Gomersall wrote: > 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. > > > > 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 I'll need to send it again. > > > > 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? The new_device was presented as a patch recently, but was linked to spidev. I don't remember seeing a v2 that was not linked to spidev, which seemed straightforward, but I easily could have missed it. Most of the dynamic DT pieces are already in the kernel, for example ce79d54ae44 "spi/of: Add OF notifier handler". I think the configfs part is still unmerged, see https://patchwork.kernel.org/patch/5179621/ I don't know why it's not in already. This would solve the problem of dynamically adding and removing SPI (and I2C) devices.��.n��������+%������w��{.n�����{����)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥