Hi Mark, On Wed, Sep 27, 2023 at 11:21 AM Mark Brown <broonie@xxxxxxxxxx> wrote: > On Wed, Sep 27, 2023 at 11:10:58AM +0200, Geert Uytterhoeven wrote: > > On Wed, Sep 27, 2023 at 11:00 AM Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > The description is clearly saying there is a chip select, _NO_CS seems > > > entirely inappropriate. It's not specified in the device tree because > > > when there's no chip select for a device it's a fundamental property of > > > how the device is controlled and we don't need any information beyond > > > the compatible. > > > In host mode, it indeed doesn't matter, as you can have only a single > > device connected with SPI_NO_CS. > > In device mode, the device needs to know if it must monitor the chip > > select line or not. > > > In hindsight, I should have kept the question I had written initially, > > but deleted after having read the documentation for the corresponding > > RZ/V2M register bits: > > > What does it mean if this is false? That there is no chip select? > > > So "spi-no-cs" would be the inverse of "renesas,csi-ss". > > I see. Is there any control over what the chip select is when there is > one, in which case we could just look to see if there's one specified? On RZ/V2M there isn't, as there is only a single hardware chip select. On MSIOF, there are 3 hardware chip selects, but apparently only the primary one can be used in target mode. I have to admit I never thought about this before (commit cf9e4784f3bde3e4 ("spi: sh-msiof: Add slave mode support") also predates commit 9cce882bedd2768d ("spi: sh-msiof: Extend support to 3 native chip selects")). Hence the SPI target DT bindings use a single "slave" subnode, without a unit address, thus assuming no explicit (or a default) chip select configuration. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds