On Thu, May 14, 2020 at 02:55:58PM +0300, Serge Semin wrote:
> On Thu, May 14, 2020 at 10:31:13AM +0200, Linus Walleij wrote:

> > We had some related discussion what to do with this case
> > when a controller can support active high CS if and only if
> > it is using a GPIO instead of the native CS. We didn't really
> > figure it out, I suppose ideally we should use two flags in the
> > master but that exercise is for another day.

> Even though it might be painful, but as I see it the best way to generically fix
> this problem would be to change the controller->set_cs() callback
> semantics. SPI core should pass a CS activation flag to the set_cs()
> callback instead of the CS pin logical level (just propagate the enable argument
> passed to the spi_set_cs() SPI core method). So if an SPI controller supports
> the Active-high native CS, during the set_cs() callback invocation it would
> analyze the spi_device flags state to figure out whether the slave needs the

The idea with set_cs() is to support controllers that allow the chip
select to be directly managed.  If the controller is interpreting or
automatically managing chip select at all then set_cs() is not likely to
be a good fit, if the controller does support unfiltered management then
anything else is going to result in there being a bunch of duplicate
code between drivers.