From mboxrd@z Thu Jan 1 00:00:00 1970 From: Meng, Bin Date: Sun, 24 Jan 2021 11:38:28 +0000 Subject: [PATCH] mmc: mmc_spi: Do not drop first RX byte after CMD TX In-Reply-To: <20210124063402.208203-1-jiaxun.yang@flygoat.com> References: <20210124063402.208203-1-jiaxun.yang@flygoat.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de It looks somehow this email did not arrive the mailing list? As for the patch, U-Boot mms_spi driver does nothing wrong. The dropped byte is for Ncr as required by the spec. The issue you mentioned in QEMU is fixed by the following patch: http://patchwork.ozlabs.org/project/qemu-devel/patch/20210123104016.17485-4-bmeng.cn at gmail.com/ Regards, Bin -----Original Message----- From: Jiaxun Yang Sent: Sunday, January 24, 2021 2:34 PM To: u-boot at lists.denx.de Cc: Meng, Bin ; peng.fan at nxp.com; Jiaxun Yang Subject: [PATCH] mmc: mmc_spi: Do not drop first RX byte after CMD TX As per MMC SPI specification, R1 response could just follow the CMD TX. Currently we drop the first RX byte after the CMD TX. It is harmless in realworld as MMC card need time to take command action so the first resp will always be R1b(busy). However in QEMU ssi-sd emulation, R1 resp is just followed after, so R1 will be dropped here. Signed-off-by: Jiaxun Yang --- drivers/mmc/mmc_spi.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c index 46800bbed2..1da963ba1e 100644 --- a/drivers/mmc/mmc_spi.c +++ b/drivers/mmc/mmc_spi.c @@ -94,10 +94,6 @@ static int mmc_spi_sendcmd(struct udevice *dev, if (ret) return ret; - ret = dm_spi_xfer(dev, 1 * 8, NULL, &r, 0); - if (ret) - return ret; - if (!resp || !resp_size) return 0; -- 2.30.0