Re: [PATCH 2/2] spi: spi-mem: fallback to using transfers when CS gpios are used

[Conor Dooley]

On Sun, Mar 29, 2026 at 08:18:22PM +0000, Chris Packham wrote:
> Hi Connor,
> 
> On 28/03/2026 07:29, Conor Dooley wrote:
> > On Thu, Nov 07, 2019 at 05:42:35PM +1300, Chris Packham wrote:
> >> Devices with chip selects driven via GPIO are not compatible with the
> >> spi-mem operations. Fallback to using standard spi transfers when the
> >> device is connected with a gpio CS.
> > Bitta necromancy, but why are they not compatible?
> > Couldn't you have just done an if/else in your driver to call
> > gpiod_set_value(spi_get_csgpiod())?
> >
> > For some context, I've been trying to resolve some issues with using
> > the standard transfers code when used with flash devices in the
> > microchip-core-qspi driver, but if I delete this !mem->spi->cs_gpiod
> > check, and add the aforementioned if/else in my driver, the mem ops
> > work fine.

Turns out, I goofed and it doesn't magically solve my problem. I blame
working too late on a Friday evening. But it should work on my platform,
once I get to the bottom of what's breaking it for both cases.

> > What am I missing that makes them incompatible?
> 
> The cover letter from this series[1] adds a little context. Basically 
> the hardware design I was dealing with is a bit odd. It doesn't wire up 
> GPIOs as chip selects directly it uses a GPIO and some extra logic to 
> steer the native CS. On the BCM58525 the CS appears to be driven 
> automatically (other SoCs that use the bcm-qspi driver appear to be able 
> to explicitly control the chip select). This combined with the ability 
> to offload the various spi-mem operations means we need the spi core to 
> drive the GPIO CS and use the standard spi operations.
> 
> I think that check could probably be replaced with some flag that 
> amounts to disabling the spi-mem ops when we don't have full control 
> over the native CS.

I dunno, that seems likely to cause regressions, no? Devices that didn't
add handing of gpio chip selects in their mem ops code, cos it wasn't
ever called in that case, would regress. Guess could go through and
modify anything with the gpio_descriptors (or w/e it is called) flag,
but opt-in might be safer. I'll think about it when my stuff works...

> 
> [1] - 
> https://lore.kernel.org/all/20191107044235.4864-1-chris.packham@xxxxxxxxxxxxxxxxxxx/
> 
> >
> > Cheers,
> > Conor.
> >
> >> Signed-off-by: Chris Packham <chris.packham@xxxxxxxxxxxxxxxxxxx>
> >> ---
> >>   drivers/spi/spi-mem.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> >> index 9f0fa9f3116d..e5a46f0eb93b 100644
> >> --- a/drivers/spi/spi-mem.c
> >> +++ b/drivers/spi/spi-mem.c
> >> @@ -286,7 +286,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
> >>   	if (!spi_mem_internal_supports_op(mem, op))
> >>   		return -ENOTSUPP;
> >>   
> >> -	if (ctlr->mem_ops) {
> >> +	if (ctlr->mem_ops && !mem->spi->cs_gpiod) {
> >>   		ret = spi_mem_access_start(mem);
> >>   		if (ret)
> >>   			return ret;
> >> -- 
> >> 2.24.0
> >>

Attachment: signature.asc
Description: PGP signature