> 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.
Some drivers do do that. They accept a "devno" argument in their init function and then pass it with the SPI calls. On Fri, Jan 8, 2021 at 7:41 PM Brennan Ashton <bash...@brennanashton.com> wrote: > > 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. > > >
