Received-SPF: pass (google.com: domain of linux-kernel+bounces-15332-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: "Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>
Date: Wed, 3 Jan 2024 10:20:43 +0100
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: "Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>,
	Avri Altman <Avri.Altman@wdc.com>,
	"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	"christian.loehle@arm.com" <christian.loehle@arm.com>,
	"jinpu.wang@ionos.com" <jinpu.wang@ionos.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"beanhuo@micron.com" <beanhuo@micron.com>,
	"yibin.ding@unisoc.com" <yibin.ding@unisoc.com>,
	"victor.shih@genesyslogic.com.tw" <victor.shih@genesyslogic.com.tw>,
	"asuk4.q@gmail.com" <asuk4.q@gmail.com>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"yangyingliang@huawei.com" <yangyingliang@huawei.com>,
	"yebin10@huawei.com" <yebin10@huawei.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mmc: rpmb: do not force a retune before RPMB switch
Message-ID: <ZZUm68tU9zHsC+X+@trux>
References: <20231204150111.3320071-1-jorge@foundries.io>
 <f83933d3-6426-425c-903e-abbd2691e84a@intel.com>
 <DM6PR04MB6575A30D162378E82B4D7DDEFC84A@DM6PR04MB6575.namprd04.prod.outlook.com>
 <ZXBGTxS7sUSILtLs@trax>
 <ZXbBhjZIn5sj6EYO@trax>
 <ZZPoRPxdWXuT+cEo@trax>
 <b88eca08-7f20-4287-802c-ae1c8e3cd5cf@intel.com>
 <ZZSH1ykwP45fZaLh@trax>
 <d1fac554-4a51-409e-bc52-100a6bb4f5dd@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d1fac554-4a51-409e-bc52-100a6bb4f5dd@intel.com>

On 03/01/24 10:03:38, Adrian Hunter wrote:
> Thanks for doing that!  That seems to explain the mystery.
>
> You could hack the test to get an idea of how many successful
> iterations there are before getting an error.
>
> For SDHCI, one difference between tuning and re-tuning is the
> setting of bit-7 "Sampling Clock Select" of "Host Control 2 Register".
> It is initially 0 and then set to 1 after the successful tuning.
> Essentially, leaving it set to 1 is meant to speed up the re-tuning.
> You could try setting it to zero instead, and see if that helps.
> e.g.
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index c79f73459915..714d8cc39709 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2732,6 +2732,7 @@ void sdhci_start_tuning(struct sdhci_host *host)
>  	ctrl |= SDHCI_CTRL_EXEC_TUNING;
>  	if (host->quirks2 & SDHCI_QUIRK2_TUNING_WORK_AROUND)
>  		ctrl |= SDHCI_CTRL_TUNED_CLK;
> +	ctrl &= ~SDHCI_CTRL_TUNED_CLK;
>  	sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
>
>  	/*
>


Yes with that change, the re-tuning reliability test does pass.

root@uz3cg-dwg-sec:/sys/kernel/debug/mmc0#  echo 52 > /sys/kernel/debug/mmc0/mmc0\:0001/test
[  237.833585] mmc0: Starting tests of card mmc0:0001...
[  237.838759] mmc0: Test case 52. Re-tuning reliability...
[  267.845403] mmc0: Result: OK
[  267.848365] mmc0: Tests completed.


Unfortunately I still see the error when looping on RPMB reads.

For instance with this test script
 $ while true; do rpmb_read m4hash; usleep 300; done

I can see the error triggering on the serial port after a minute or so.
[  151.682907] sdhci-arasan ff160000.mmc: __mmc_blk_ioctl_cmd: data error -84

Causing OP-TEE to panic since the RPMB read returns an error
E/TC:? 0
E/TC:? 0 TA panicked with code 0xffff0000
E/LD:  Status of TA 22250a54-0bf1-48fe-8002-7b20f1c9c9b1
E/LD:   arch: aarch64
[...]

if anything else springs to your mind I am happy to test of course - there are
so many tunnables in this subsystem that experience is this area has exponential
value (and I dont have much).

Would it make sense if re-tuning requests are rejected unless a minimum number
of jiffies have passed? should I try that as a change?

or maybe delay a bit longer the RPMB access after a retune request?