Some drivers do do that. They accept a "devno" argument in their init > function and then pass it with the SPI calls. >
If *every* driver *must* do that, problem solved > > > 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. > > > > > >
