> On 28.03.2015, at 00:42, Mark Brown <[email protected]> wrote:
>
> Since spidev is a detail of how Linux controls a device rather than a
> description of the hardware in the system we should never have a node
> described as "spidev" in DT, any SPI device could be a spidev so this
> is just not a useful description.
>
> In order to help prevent users from writing such device trees generate a
> warning if spidev is instantiated as a DT node without an ID in the match
> table.
>
> Signed-off-by: Mark Brown <[email protected]>
So what is now the “correct way” to create a spidev device via the
device-tree?
There is no update in Documentation/spi/spidev how to achieve this in
a “correct” manner besides using board_info and the mentioned possible
sysfs approach, which is not implemented as an alternative.
If I still put spidev into the device-tree - as there is not other way
to do it as far as I known - then it produces an issue:
[ 328.255338] spidev spi32765.1: buggy DT: spidev listed directly in DT
[ 328.255399] ------------[ cut here ]------------
[ 328.255443] WARNING: CPU: 0 PID: 2968 at drivers/spi/spidev.c:730
spidev_probe+0x198/0x1e4 [spidev]()
[ 328.255457] Modules linked in: spidev(+) spi_bcm2835 bcm2835_wdt bcm2835_dma
virt_dma
... lots more lines with stack-trace ...
So it is just a warning triggered by:
WARN_ON(spi->dev.of_node &&
!of_match_device(spidev_dt_ids, &spi->dev));
But still it is “irritating” as, it produces lots of messages in dmesg.
Note that on a raspberry pi the 2 SPI devices are by default configured
as spidev and only overlays would change the settings to a different
alias. So this change will impact that default immediately.
Thus I wonder if it is wise to produce potential “support issues" for
distributions triggered by this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
