问题描述

最近在学习Linux驱动开发中SPI总线的驱动框架，但在修改完设备树添加完对应的spi设备节点后，理应在/sys/bus/spi下会有对应的spi设备，我的目录下面没有。

然后我查看了/proc/device-tree，发现有对应的spi设备节点，我就先没有过多理会这个问题。

 

但在写完对应的驱动后加载spi对应的.ko文件，.probe函数没有执行；卸载对应的驱动文件后.remove也没有执行（在终端没有打印对应的语句）。

原因分析：

这时我知道spi驱动和spi设备没有匹配，驱动应该没有什么问题，问题大概率出现在.dts文件中对应的spi设备节点。

解决方案：

我总看我的spi节点中的信息发现不出什么问题，然后我实在没办法，将正点官方的设备树对应的spi节点信息复制到我的设备树下，用修改过后的设备树启动，重新查看/sys/bus/spi/devices，发现出现了一个设备文件，然后重新加载驱动、卸载驱动对应的.probe和.remove都会正常执行了。

正点原子正常节点信息

&ecspi3 {
        fsl,spi-num-chipselects = <1>;
        cs-gpio = <&gpio1 20 GPIO_ACTIVE_LOW>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ecspi3>;
        status = "okay";

	spidev: icm20608@0 {
	compatible = "alientek,icm20608";
        spi-max-frequency = <8000000>;
        reg = <0>;
    };
};

我的有错误的节点信息

&ecspi3 {
	fsl,spi-num-chipselects = <1>;
	cs-gpio = <&gpio1 20 GPIO_ACTIVE_LOW>;			//不能定义成cs-gpios
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_ecspi3>;
	status = "okay";

	spidev: icm20608@0 {
		reg = <0>;
		compatible = "alientek,icm20608";
		spi_max_frequency = <8000000>;
	};
};

 

 

我还是没有发现到底是什么问题，期间我还尝试调整了一下每个属性的顺序，但还是不行。最后我在word中一句一句比较，最终发现了问题。我的是spi_max_frequency，正点原子正常的是spi-max-frequency，然后查看绑定文档确实不是''_''而是''-''。这个不会影响设备树，但可能就会导致内核无法识别到是不是具体的spi设备。

总结

写代码的时候还是仔细一些，可以减少一些奇奇怪怪的bug。不仅仅是spi设备，我猜想其他设备的节点属性信息写错，在对应的总线下可能也不会出现相应的设备文件。（未证实）