From: Conor Dooley <conor.dooley@microchip.com>

Hey Mark,

Got a couple of patches here, the first two deal with an issue that a
customer reported where using a mixed configuration of the built-in chip
select and a gpio lead to data corruption. Turned out, the built-in chip
select always gets activated at the moment even if a gpio-cs is being
used. With that fixed, I noticed that any read with multiple data lines
was not working properly, so patch two changes how the driver deals with
emulating mem-ops. The remaining patches are things I consider fixes but
not meaningful enough to get a Fixes tag. LMK if you want em split out
to be put on for-next rather than for-current.

Cheers,
Conor.

CC: Conor Dooley <conor.dooley@microchip.com>
CC: Daire McNamara <daire.mcnamara@microchip.com>
CC: Mark Brown <broonie@kernel.org>
CC: Cyril Jean <cyril.jean@microchip.com>
CC: Valentina.FernandezAlanis@microchip.com
CC: linux-riscv@lists.infradead.org
CC: linux-spi@vger.kernel.org
CC: linux-kernel@vger.kernel.org

Conor Dooley (5):
  spi: microchip-core-qspi: control built-in cs manually
  spi: microchip-core-qspi: don't attempt to transmit during emulated
    read-only dual/quad operations
  spi: microchip-core-qspi: report device on which timeout occured
    instead of which controller
  spi: microchip-core-qspi: remove an unused define
  spi: microchip-core-qspi: remove some inline markings

 drivers/spi/spi-microchip-core-qspi.c | 105 ++++++++++++++++++++------
 1 file changed, 83 insertions(+), 22 deletions(-)

-- 
2.53.0

On Wed, Apr 22, 2026 at 04:15:41PM +0100, Conor Dooley wrote:

> Got a couple of patches here, the first two deal with an issue that a
> customer reported where using a mixed configuration of the built-in chip
> select and a gpio lead to data corruption. Turned out, the built-in chip
> select always gets activated at the moment even if a gpio-cs is being
> used. With that fixed, I noticed that any read with multiple data lines
> was not working properly, so patch two changes how the driver deals with
> emulating mem-ops. The remaining patches are things I consider fixes but
> not meaningful enough to get a Fixes tag. LMK if you want em split out
> to be put on for-next rather than for-current.

I don't know what for-current is but they certainly don't apply against
for-7.1 which is the only active branch given that v7.0 released (and he
same content as for-linus and for-next as a result).  It would be
convenient to split the fixes and cleanups, unless there's actul
dependencies.

On Wed, Apr 22, 2026 at 04:25:43PM +0100, Mark Brown wrote:
> On Wed, Apr 22, 2026 at 04:15:41PM +0100, Conor Dooley wrote:
> 
> > Got a couple of patches here, the first two deal with an issue that a
> > customer reported where using a mixed configuration of the built-in chip
> > select and a gpio lead to data corruption. Turned out, the built-in chip
> > select always gets activated at the moment even if a gpio-cs is being
> > used. With that fixed, I noticed that any read with multiple data lines
> > was not working properly, so patch two changes how the driver deals with
> > emulating mem-ops. The remaining patches are things I consider fixes but
> > not meaningful enough to get a Fixes tag. LMK if you want em split out
> > to be put on for-next rather than for-current.
> 
> I don't know what for-current is but they certainly don't apply against
> for-7.1 which is the only active branch given that v7.0 released (and he
> same content as for-linus and for-next as a result).

Ah I forgot about that widespread devm_ removal series.

> It would be
> convenient to split the fixes and cleanups, unless there's actul
> dependencies.

Sure. I'll rebase, split and resend. There shouldn't be any meaningful
dependencies.