Messages in this thread | | | From | Krishna Yarlagadda <> | Subject | RE: [PATCH] spi: tegra210-quad: Fix iterator outside loop | Date | Mon, 27 Feb 2023 19:44:05 +0000 |
| |
> -----Original Message----- > From: Mark Brown <broonie@kernel.org> > Sent: 27 February 2023 23:53 > To: Krishna Yarlagadda <kyarlagadda@nvidia.com> > Cc: linux-spi@vger.kernel.org; linux-tegra@vger.kernel.org; linux- > kernel@vger.kernel.org; thierry.reding@gmail.com; Jonathan Hunter > <jonathanh@nvidia.com>; Sowjanya Komatineni > <skomatineni@nvidia.com>; Laxman Dewangan <ldewangan@nvidia.com> > Subject: Re: [PATCH] spi: tegra210-quad: Fix iterator outside loop > > On Mon, Feb 27, 2023 at 10:36:18AM +0000, Krishna Yarlagadda wrote: > > > > > > > - if (!xfer->cs_change) { > > > > > > - tegra_qspi_transfer_end(spi); > > > > > > - spi_transfer_delay_exec(xfer); > > > > > > - } > > > updating the length of the message. > > > > > This looks like it'll do the wrong thing and do a change on every > > > > > transfer if cs_change isn't set? > > > > > This condition is hit only in data phase which is end of message. > > > > Shouldn't this just be moved into the DATA_TRANSFER case statement? > > Calling transfer_end after updating message length. > > Something seems to be mangled with your quoting/new text here so it's a > bit unclear what you're saying here but if you're saying that this is > due to needing to call tegra_qspi_transfer_end() after updating the > length I'm not sure why - AFAICT that function doesn't reference the > transfer length at all, it just writes out a command to configure the > chip select? There's no issue with the message being finalised since > that happens in the caller. Yes. Length should not matter. Will move into DATA_TRANSFER case. Also need to handle error case.
| |