Hi Martin, Yes, this is definitely a problem that needs to be solved, and it isn't restricted to SPI devices. I2C, GPIO, etc all have the same problem. Using a device driver with kernel parameters isn't a very good interface though. There is already some conversations going on about allowing device tree fragments to be loaded into the kernel at runtime to augment the device tree data with additional devices, but as I think you're trying to point out, that isn't always a good solution particularly when experimenting.
I think it would be valuable to have some bus-level attributes in sysfs (or maybe configfs) for instantiating new spi/i2c devices, and then make sure the driver model probe/remove manipulation from sysfs is also working correctly. The driver model does support that, but it will require some SPI/I2C subsystem work to get it going. Also need to be concerned about security here. Adding a user interface for adding devices may provide an attack vector from userspace for taking control of devices that userspace should not be able to touch (ie. an EEPROM). Will need a way of filtering the devices allowed to be created by userspace. g. On 28 Oct 2013 09:50, "Martin Sperl" <[email protected]> wrote: > > Any feedback? > > Thanks, > Martin > > > On 07.10.2013, at 13:47, Martin Sperl wrote: > > > Hi! > > > > A lot of people have been trying to get their preferred SPI devices working > > on a Raspberry Pi (and probably some other development boards as well). > > Most (newbies) of them have failed because it requires a recompile of the > > kernel to change the default config from SPIDEV to any other device of your > > choice - at least for non-device tree devices. > > > > This is quite "burdensome" for people new to Linux, who just want to access > > their device - most of the time just changing modinfo, max_speed_hz and > > maybe assigning an irq-line for the driver. > > > > As far as my experience goes, the ability to change the SPI device > > registration on the fly on development board (beagle-board, openwrt > > routers,...) would be of great advantage to the users. > > > > Device tree would provide the "config" part, but would not allow to change > > settings on the fly. Also Device-tree requires a lot of "knowledge" > > (especially to newbies, that just want to add an ADC, or access a CAN bus > > board they just bought) to get it right and then a reboot hoping for the > > device-tree to work... > > > > So here a proposal for a "simple" module that does only register SPI > > devices based on arguments passed to it when loading the module (and > > releasing the devices when removing the module). > > > > You can find it in the form of an out of tree module at: > > https://github.com/msperl/spi-config > > > > I agree, that this module provides some means to shoot yourself into the > > foot resulting in a crashed kernel. > > But at least after a reboot we are back to "normal" again without any > > additional recovery procedures to boot the kernel. > > So it is not an optimal solution, but at least it fills the niche for quick > > modifications to a system when the parts in question are not needed to get > > the system up and running in the first place. > > > > The other benefit is that it also reduces support overhead for people who > > create and sell extension modules/capes/..., who then have to provide a > > separately patched kernel to make the extension work. With the above > > approach they just need to provide the command "modprobe spi-config > > device=..." and then load the relevant SPI driver module to get the people > > started with the default kernel that comes with the OS/board (assuming the > > OS has the module compiled). > > > > Please review this out-of-tree-module and give some feedback. > > Maybe you find it valuable enough to get it included with the kernel itself? > > > > Thanks, > > Martin > > > > P.s: the module has an option to replace an existing SPI board-registration > > that comes with the default kernel. But - for now - such an action will > > taint the kernel, as this action might produce unexpected results... > > (besides memory that does not get freed) > > > ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
