linux-kernel - Re: [PATCH v3] mmc: renesas_sdhi: Fix change point of data handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZcDdn2AVz8FIXzak@shikoro>
Date: Mon, 5 Feb 2024 14:07:43 +0100
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Claudiu <claudiu.beznea@...on.dev>
Cc: ulf.hansson@...aro.org, yoshihiro.shimoda.uh@...esas.com,
	masaharu.hayakawa.ry@...esas.com, takeshi.saito.xv@...esas.com,
	linux-mmc@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH v3] mmc: renesas_sdhi: Fix change point of data handling

Hi Claudiu,

thanks for the updated version!

> To comply with this, the patch checks if this mismatch is present and
> updates the priv->smpcmp mask only if it is not. Previous code checked if
> the value of SMPCMP register was zero. However, on RZ/G3S, this leads to
> failues as it may happen, e.g., the following:
> CMPNGU=0x0e, CMPNGD=0x0e, SMPCMP=0x000e000e.

Can you add the current TAP number (variable 'i') to this printout?
According to my understanding, we should only mark this TAP good if it
is in the range 5-7. I need to double check with Renesas, though.

> Along with it, as mmc_send_tuning() may return with error even before the
> MMC command reach the controller (and because at that point cmd_error = 0),
> the update of priv->smpcmp mask has been done only if the return value of
> mmc_send_tuning(mmc, opcode, &cmd_error) is 0 (success).

This is a needed change, for sure.

> This change has been checked on the devices with the following DTSes by
> doing 100 consecutive boots and checking for the tuning failure message:

Boot failure is one test. Read/write tests should be another, I think.
Because if we select a bad TAP, bad things might happen later. To reduce
the amount of testing, read/write testing could only be triggered if the
new code path was excecuted?

Happy hacking,

   Wolfram


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)