On Fri, Jan 8, 2021, 10:35 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote:
> > One problem was I didn't understand current CS definition. I thought > > #define GPIO_MCP2515_CS (GPIO_OUTPUT|GPIO_CNF_OUTPP|GPIO_MODE_50MHz|\ > > GPIO_OUTPUT_SET|GPIO_PORTA|GPIO_PIN4) > > created a bitmask named GPIO_MCP2515_CS but no, it creates an ASCII > string > > that does its magic in stm32_configgpio() > > > That doesn't create an ASCII string. GPIOs follow a simple encoding > that changes from chip to chip depending on the capabilities of the > chip. > > The CS pin isn't part of the chip driver because it's (for the most > cases) a normal GPIO that changes from board to board. > The board logic that adds a CS pin is very simple and doesn't require > deep kernel knowledge. > A key exception is when the CS is behind an IO expander. Which the current design allows. The biggest issue I see is that drivers are hard coding the CS reference like the MCP2515 which always uses SPIDEV_CANBUS(0), this should be passed in to the initialization of all SPI devices and owned by the private device structure not hard coded. I could even see the argument for this being part of the generic SPI interface structure. >
