Arnd, > > > > > > > > - all wilink family needs special init command for entering wspi mode. > > > > extra clock cycles should be sent after the spi init command while the > > > > cs pin is high. > > > > - switch to controling the cs pin from the spi driver for achieveing the > > > > above. > > > > - the selected cs gpio is read from the spi device-tree node using the > > > > cs-gpios field and setup as a gpio. > > > > - See the example below for specifying the cs gpio using the cs-gpios > entry > > > > &spi0 { > > > > ... > > > > cs-gpios = <&gpio0 5 0>; > > > > ... > > > > wlcore: wlcore@0 { > > > > compatible = "ti,wl1835"; > > > > ... > > > > ... > > > > }; > > > > }; > > > > > > > > Signed-off-by: Eyal Reizer <eyalr@xxxxxx> > > > > > > I don't think this can work in general: not all SPI hosts uses GPIOs > > > for controlling CS, so the logic can't work, and it's also a > > > layering violation for the driver to look at the parent. > > > > > > I would suggest fixing this using a new API function from the SPI > > > core, if we don't already have a generic way to do it. > > > > > Originally this is what I have done until I was pointed to the generic > > cs-gpio mechanism in the SPI core. > > It is a generic mechanism already in the SPI core driver. > > See: Documentation/devicetree/bindings/spi/spi-bus.txt > > The cs-gpios property is documented as optional, it defines how you should > list the gpios if CS is implemented using gpio, but not all hardware does it like > this. > > > It is also part of the generic spi.h (include/Linux/spi/spi.h), > > already part of " struct spi_device" So it seemed redundant adding > > another mechanism for implementing the same. > > Platform that interact with a wilink need to use it, and platforms > > that don't have this capability will probably not interact with a wilink device > using SPI. > > The cs_gpio field in spi_device belongs to the spi host controller, no other > slave driver uses it. > > I wasn't asking for a duplication of this mechanism, but an interface to use it > properly. Internally, the spi core uses the spi_set_cs() function to pick a CS. > Find a way to use that rather than reimplementing it incorrectly. > Understood. As this special CS manipulation is unique to wspi (wilink spi) I think the best option is to move this gpio allocation into wlcore_spi as a new device tree entry used only by this driver. If you agree I will submit a v3. Best Regards, Eyal -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html