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.
Attachment:
signature.asc
Description: PGP signature
