linux-kernel - Re: [PATCH v2] 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: <ZbikovLbujyGS1ub@ninjato>
Date: Tue, 30 Jan 2024 08:26:26 +0100
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: claudiu beznea <claudiu.beznea@...on.dev>
Cc: ulf.hansson@...aro.org, takeshi.saito.xv@...esas.com,
	masaharu.hayakawa.ry@...esas.com, yoshihiro.shimoda.uh@...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 v2] mmc: renesas_sdhi: Fix change point of data handling

Hi Claudiu,

> My understanding was the other way around from this statement found in
> RZ/G3S hw manual:
> 
> "If all of the TAP [i] is OK, the sampling clock position is selected by
> identifying the change point of data.

Yes, it is easy to misunderstand. It should add "and avoid it" or
something. I got an internal diagram which makes it more clear. I just
asked if I can share it with you.

> > I also have a chapter named like this. If you check the diagram, change
> > point is between TAP2 and 3, so the suggested TAP to use is 6 or 7. As
> > far away as possible from the change point.
> 
> My understanding was different here as of the following hw manual statement:
> 
> "As the width of the input data is 1 (UI), select TAP6 or TAP7 which is
> 
> *the median* of next TAP3 from TAP3"
> 
> I understand from this that the median value should be considered here.

Sorry, can't follow you here. "Select TAP6 or TAP7" is clear to me. But
it doesn't really matter why it was misleading...

> > However, with some SD cards, I also see the EIO error you see. So, there
> > might be room to improve TAP selection when all TAPs are good. I need to
> > check if this is really is the same case for the SD cards in question.
> 
> Maybe better would be to change this condition:
> 
> 			if (cmpngu_data != cmpngd_data)
> 				set_bit(i, priv->smpcmp);
> 
> like this:
> 			if (cmpngu_data == cmpngd_data)
> 				set_bit(i, priv->smpcmp);
> 
> ?
> 
> I need to check it, though.

But isn't it equal to the current code then? (Except for one thing: the
smpcmp bit is only set when there is no cmd error. I need to double
check but I think I like that.)

Happy hacking,

   Wolfram


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