[PATCH 0/2] spi: more GPIO CS work

[PATCH 0/2] spi: more GPIO CS work

[Chris Packham]

I've got a platform using the BCM 58525 CPU. The hardware design
connects to two SPI devices using a slightly odd arrangement of
GPIOs and native chip select. These patches however should be
relevant to any platform using that CPU with "normal" CS GPIOs

Chris Packham (2):
  spi: bcm-qspi: Convert to use CS GPIO descriptors
  spi: spi-mem: fallback to using transfers when CS gpios are used

 drivers/spi/spi-bcm-qspi.c | 7 +++++--
 drivers/spi/spi-mem.c      | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

-- 
2.24.0

[PATCH 1/2] spi: bcm-qspi: Convert to use CS GPIO descriptors

[Chris Packham]

Set use_gpio_descriptors to true and avoid asserting the native chip
select if the spi core has done it for us.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
 drivers/spi/spi-bcm-qspi.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-bcm-qspi.c b/drivers/spi/spi-bcm-qspi.c
index 7a3531856491..85bad70f59e3 100644
--- a/drivers/spi/spi-bcm-qspi.c
+++ b/drivers/spi/spi-bcm-qspi.c
@@ -803,7 +803,8 @@ static int bcm_qspi_bspi_exec_mem_op(struct spi_device *spi,
 			return -EIO;
 
 	from = op->addr.val;
-	bcm_qspi_chip_select(qspi, spi->chip_select);
+	if (!spi->cs_gpiod)
+		bcm_qspi_chip_select(qspi, spi->chip_select);
 	bcm_qspi_write(qspi, MSPI, MSPI_WRITE_LOCK, 0);
 
 	/*
@@ -882,7 +883,8 @@ static int bcm_qspi_transfer_one(struct spi_master *master,
 	int slots;
 	unsigned long timeo = msecs_to_jiffies(100);
 
-	bcm_qspi_chip_select(qspi, spi->chip_select);
+	if (!spi->cs_gpiod)
+		bcm_qspi_chip_select(qspi, spi->chip_select);
 	qspi->trans_pos.trans = trans;
 	qspi->trans_pos.byte = 0;
 
@@ -1234,6 +1236,7 @@ int bcm_qspi_probe(struct platform_device *pdev,
 	master->cleanup = bcm_qspi_cleanup;
 	master->dev.of_node = dev->of_node;
 	master->num_chipselect = NUM_CHIPSELECT;
+	master->use_gpio_descriptors = true;
 
 	qspi->big_endian = of_device_is_big_endian(dev->of_node);
 
-- 
2.24.0

Applied "spi: bcm-qspi: Convert to use CS GPIO descriptors" to the spi tree

[Mark Brown]

The patch

   spi: bcm-qspi: Convert to use CS GPIO descriptors

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 27fb2313f28d8c82adace68bf49f12fe810ba58c Mon Sep 17 00:00:00 2001
From: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date: Thu, 7 Nov 2019 17:42:34 +1300
Subject: [PATCH] spi: bcm-qspi: Convert to use CS GPIO descriptors

Set use_gpio_descriptors to true and avoid asserting the native chip
select if the spi core has done it for us.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20191107044235.4864-2-chris.packham@alliedtelesis.co.nz
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-bcm-qspi.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-bcm-qspi.c b/drivers/spi/spi-bcm-qspi.c
index 7a3531856491..85bad70f59e3 100644
--- a/drivers/spi/spi-bcm-qspi.c
+++ b/drivers/spi/spi-bcm-qspi.c
@@ -803,7 +803,8 @@ static int bcm_qspi_bspi_exec_mem_op(struct spi_device *spi,
 			return -EIO;
 
 	from = op->addr.val;
-	bcm_qspi_chip_select(qspi, spi->chip_select);
+	if (!spi->cs_gpiod)
+		bcm_qspi_chip_select(qspi, spi->chip_select);
 	bcm_qspi_write(qspi, MSPI, MSPI_WRITE_LOCK, 0);
 
 	/*
@@ -882,7 +883,8 @@ static int bcm_qspi_transfer_one(struct spi_master *master,
 	int slots;
 	unsigned long timeo = msecs_to_jiffies(100);
 
-	bcm_qspi_chip_select(qspi, spi->chip_select);
+	if (!spi->cs_gpiod)
+		bcm_qspi_chip_select(qspi, spi->chip_select);
 	qspi->trans_pos.trans = trans;
 	qspi->trans_pos.byte = 0;
 
@@ -1234,6 +1236,7 @@ int bcm_qspi_probe(struct platform_device *pdev,
 	master->cleanup = bcm_qspi_cleanup;
 	master->dev.of_node = dev->of_node;
 	master->num_chipselect = NUM_CHIPSELECT;
+	master->use_gpio_descriptors = true;
 
 	qspi->big_endian = of_device_is_big_endian(dev->of_node);
 
-- 
2.20.1

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

[Chris Packham]

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.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
 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

Applied "spi: spi-mem: fallback to using transfers when CS gpios are used" to the spi tree

[Mark Brown]

The patch

   spi: spi-mem: fallback to using transfers when CS gpios are used

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 05766050d5bd9af24dcaec6b29255a6f2b324543 Mon Sep 17 00:00:00 2001
From: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date: Thu, 7 Nov 2019 17:42:35 +1300
Subject: [PATCH] spi: spi-mem: fallback to using transfers when CS gpios are
 used

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.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20191107044235.4864-3-chris.packham@alliedtelesis.co.nz
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 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.20.1

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

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.

What am I missing that makes them incompatible?

Cheers,
Conor.

> 
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
>  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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Chris Packham]

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

[1] - 
https://lore.kernel.org/all/20191107044235.4864-1-chris.packham@alliedtelesis.co.nz/

>
> Cheers,
> Conor.
>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>>   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
>>

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3122 bytes --]

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@alliedtelesis.co.nz/
> 
> >
> > Cheers,
> > Conor.
> >
> >> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> >> ---
> >>   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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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@alliedtelesis.co.nz>
>>>> ---
>>>>    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
>>>>