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

[Chris Packham]

On 31/03/2026 15:21, Conor Dooley wrote:
> 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.
>
I certainly never push anything after 4pm on a Friday :P

>>> 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.

Yes, now it would. I still have access to the platform that I was 
working on for this so I can re-test my original use-case. It is 
dependent on how the spi controller does spi-mem ops so there is a 
chance that platforms that have been added since rely on the current 
behaviour.

> 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...

I just wanted to offer you the option. If it turns out my change is 
getting in your way we can work on an alternative.

>
>>> 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
>>>>