This is board and arch specific and cannot be more generalized than that.
> They will have different requirements for pullups, speed, etc.  The define
> should also start with BOARD_ but some use GPIO_.  This is the case
> for all PINs including UART, GPIO, SPI, USB, etc...
>

I mean after that arch and board-specific config, you end up with a list of
general pins available (CS1, CS2, CS3...) which are equivalent to SPI_* in
that they're valid everywhere and can be used despite architecture, SPI
master or bus number


> and the drivers will already have conditionals on those being defined.
>

Just like SPI_* don't break

>
> SPI is just a little special because you dont _need_ a CS gpio pin,
> but frequently you want it.


You need CS pins when you have more than one SPI device in a bus (something
very frequent). For example, all this comes from the fact that I'm
designing a control system that would benefit from having two CAN busses
instead of just one


> So you end up with the board specific hooks
> for what pin to turn on.
> as is here
>
> https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140
>
> SPI drivers cannot depend on a fixed name for the CS pin because you may
> have multiple instances (what I thought you were asking to support)
>
> It's a fixed name in the sense CS1 is defined in all boards and archs so I
can write my driver using SPI_SELECT with CS1 and it will work everywhere


> You just update the define in your board.h file to include a mapping for
> what
> is wired up to pin 5.


I cannot do that if I'm not a kernel developer

>

> When you are bringing up your board one of the first
> things you should do is define the pins in your board.h
>

I'm not bringing up a new board but connecting an *external* supported chip
to a supported board via a standard bus


> Changing how pins are defined would break everyone so that is unlikely to
> change, and it is also not really something that can easily be mapped to
> Kconfig.
>

It doesn't break anything if it's parallel to everything just like SPI_*
macros are

Grr

Reply via email to