I want to confirm if I can use the SPI0_CS1 on the 40-pin header on the Jetson Nano as a GPIO and toggle its state without any effect on the SPI0_CS0 using the device MCP2515.
Because I tried to do that and I got warnings in the dmesg from the MCP2515 driver, below I have attached the logs for reference.
[ 1193.158780] mcp251x spi0.0: GPIO lookup for consumer termination
[ 1193.158796] mcp251x spi0.0: using device tree for GPIO lookup
[ 1193.158810] of_get_named_gpiod_flags: can’t parse ‘termination-gpios’ property of node ‘/bus@0/spi@3210000/mcp2515@0[0]’
[ 1193.158829] of_get_named_gpiod_flags: can’t parse ‘termination-gpio’ property of node ‘/bus@0/spi@3210000/mcp2515@0[0]’
[ 1193.158838] mcp251x spi0.0: using lookup tables for GPIO lookup
[ 1193.158841] mcp251x spi0.0: No GPIO consumer termination found
[ 1193.159512] mcp251x spi0.0 can1: MCP2515 successfully initialized.
These warnings only mean the driver tried to find an optional GPIO for termination control, but no valid termination-gpios property was found in the device tree. Since the log ends with MCP2515 successfully initialized, the controller itself was still initialized correctly.
So yes, you can usually ignore these warnings if CAN communication works normally. By themselves they should not affect bus communication. They would only matter if your hardware design expects a GPIO-controlled termination resistor and that GPIO is missing or described incorrectly in the device tree.
Additionally, please reach out to your vendor regarding the MCP2515-specific issue.
I want to use this SPI0_CS1 pin as a GPIO. So, if I configure it as a GPIO, I want to make sure that the SPI0 peripheral with the MISO, MOSI, SCK, and CS0 will work unaffected.
Sure, since MCP2515 is connected and controlled by SPI0_CS0, you should be fine to configure SPI0_CS1 as GPIO for custom use case.
Please just remove spi@1 of the spi@3210000 node in device tree.