spi: mraa does not support dynamic SPI bus enumeration (Linux Kernel 3.19)

[xbolshe]

There is no static SPI bus in Kernel 3.19. MRAA does not support a dynamic SPI bus enumeration.
Boards: Galileo Gen1 & Gen2

[alext-mkrs]

My first question would be - where did you get a 3.19-based image for Galileos (or even Edison)? 😃, I haven't seen any official release with that one.

[xbolshe]

Actually I have own release :)
https://github.com/xbolshe/galileo-custom-images/tree/master/iot_1.1.0_dirty_kernel_3.19.2

[arfoll]

So essentially your spidev device is turning up on /dev/spidev169.0 instead of spidev0.0. I'm curious though why does yours turn up there?

I guess the solution would be to check /sys for where the device node is and enumerate them dynamically. I'd be happy to take a patch to do this.

[xbolshe]

spidev0.0 / spidev168.0 is used for ADC on Galileo board. spidev1.0 / spidev169.0 is used for an external SPI connection.

Last kernel versions like 3.19 have a feature:
https://www.kernel.org/doc/Documentation/spi/spi-summary

---

NON-STATIC CONFIGURATIONS

Developer boards often play by different rules than product boards, and one
example is the potential need to hotplug SPI devices and/or controllers.

For those cases you might need to use spi_busnum_to_master() to look
up the spi bus master, and will likely need spi_new_device() to provide the
board info based on the board that was hotplugged. Of course, you'd later
call at least spi_unregister_device() when that board is removed.

When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those
configurations will also be dynamic. Fortunately, such devices all support
basic device identification probes, so they should hotplug normally.

---

There is a minimal core of SPI programming interfaces, focussing on
using the driver model to connect controller and protocol drivers using
device tables provided by board specific initialization code. SPI
shows up in sysfs in several locations:

/sys/devices/.../CTLR ... physical node for a given SPI controller

/sys/devices/.../CTLR/spiB.C ... spi_device on bus "B",
chipselect C, accessed through CTLR.

/sys/bus/spi/devices/spiB.C ... symlink to that physical
.../CTLR/spiB.C device

/sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver
that should be used with this device (for hotplug/coldplug)

/sys/bus/spi/drivers/D ... driver for one or more spi_._ devices

/sys/class/spi_master/spiB ... symlink (or actual device node) to
a logical node which could hold class related state for the
controller managing bus "B". All spiB.* devices share one
physical SPI bus segment, with SCLK, MOSI, and MISO.

Note that the actual location of the controller's class state depends
on whether you enabled CONFIG_SYSFS_DEPRECATED or not. At this time,
the only class-specific state is the bus number ("B" in "spiB"), so
those /sys/class entries are only useful to quickly identify busses.

---

http://lxr.free-electrons.com/source/drivers/spi/spidev.c#L52

• SPI has a character major number assigned. We allocate minor numbers
• dynamically using a bitmask. You must use hotplug tools, such as udev
• (or mdev with busybox) to create and destroy the /dev/spidevB.C device
• nodes, since there is no fixed association of minor numbers with any

• particular SPI bus or device.
  /
  #define SPIDEV_MAJOR 153 / assigned */