Re: [PATCH 3/3] spi: cadence-xspi: add ACMD mode support

["Nuno Sá" <nuno.sa@analog.com>]

On Fri, Oct 30, 2026 at 11:03:07AM +0000, Mark Brown wrote:
> On Fri, Oct 30, 2026 at 10:16:00AM +0000, Nuno Sá wrote:
> > On Thu, Oct 29, 2026 at 04:51:32PM +0000, Mark Brown wrote:
> 
> > > We need some suspend/resume handling to invalidate the configuration
> > > when the IP power goes so we set everything up again.  I'm not seeing
> > > anything here.
> 
> > Yeah, I did saw sashiko complain (and my local LLM also raised it
> > actually) but I do wonder how can that happen? So we need to assume that
> > in suspend we might lose power (maybe because it's regulator powers down)
> > and need to do redo all the important initialization bits?
> 
> Yes, might not even be regulators - some SoCs have good internal power
> domains and can gate parts of themselves very effectively.
> 
> > > > +	if (cdns_xspi_acmd_can_read(cdns_xspi, op))
> > > > +		return 0;
> 
> > > That function has a minimum size but not a maximum size...
> 
> > > > +
> > > >  	op->data.nbytes = clamp_val(op->data.nbytes, 0, cdns_xspi->sdmasize);
> 
> > > ...which we have here?
> 
> > For ACMD, in theory we can just configure UINT32_MAX on the register so
> > not sure if it makes sense to clamp to that?
> 
> No, if that really is the limit it's fine.
> 
> > Conor is pushing against the new bindings and that it should be inferred
> > from the compatible. I tested this on [1] which is not an upstream
> > platform so I wonder if it's ok to add support for the complete
> > integration even if the SoC is not upstream?
> 
> So long as it's an actual SoC that exists rather than some random FPGA
> configuration or whatever upstreaming just the SPI driver is totally
> fine, that's one less piece that needs doing whenever the rest of it is
> handled.

Nice! Then v2 will bring the work for the SoC integration! Yes, real
SoC with two A55 cores and a shark DSP.

- Nuno Sá