linux-kernel - Re: [PATCH V3 1/2] mmc: sdhci: Introduce max_timeout_count variable in sdhci

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: <d0aec4e6-e803-70c0-74a5-8de51e0ffe7e@intel.com>
Date:   Fri, 6 Aug 2021 17:30:50 +0300
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Sarthak Garg <sartgarg@...eaurora.org>, ulf.hansson@...aro.org
Cc:     vbadigan@...eaurora.org, stummala@...eaurora.org,
        linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH V3 1/2] mmc: sdhci: Introduce max_timeout_count variable
 in sdhci_host

On 6/08/21 9:54 am, Sarthak Garg wrote:
> Introduce max_timeout_count variable in the sdhci_host structure
> and use in timeout calculation. By default its set to 0xE
> (max timeout register value as per SDHC spec). But at the same time
> vendors drivers can update it if they support different max timeout
> register value than 0xE.
> 
> Signed-off-by: Sarthak Garg <sartgarg@...eaurora.org>

Acked-by: Adrian Hunter <adrian.hunter@...el.com>

> ---
>  drivers/mmc/host/sdhci.c | 16 +++++++++-------
>  drivers/mmc/host/sdhci.h |  1 +
>  2 files changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index aba6e10..613e1ab 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -934,21 +934,21 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd,
>  
>  	/*
>  	 * If the host controller provides us with an incorrect timeout
> -	 * value, just skip the check and use 0xE.  The hardware may take
> +	 * value, just skip the check and use the maximum. The hardware may take
>  	 * longer to time out, but that's much better than having a too-short
>  	 * timeout value.
>  	 */
>  	if (host->quirks & SDHCI_QUIRK_BROKEN_TIMEOUT_VAL)
> -		return 0xE;
> +		return host->max_timeout_count;
>  
>  	/* Unspecified command, asume max */
>  	if (cmd == NULL)
> -		return 0xE;
> +		return host->max_timeout_count;
>  
>  	data = cmd->data;
>  	/* Unspecified timeout, assume max */
>  	if (!data && !cmd->busy_timeout)
> -		return 0xE;
> +		return host->max_timeout_count;
>  
>  	/* timeout in us */
>  	target_timeout = sdhci_target_timeout(host, cmd, data);
> @@ -968,15 +968,15 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd,
>  	while (current_timeout < target_timeout) {
>  		count++;
>  		current_timeout <<= 1;
> -		if (count >= 0xF)
> +		if (count > host->max_timeout_count)
>  			break;
>  	}
>  
> -	if (count >= 0xF) {
> +	if (count > host->max_timeout_count) {
>  		if (!(host->quirks2 & SDHCI_QUIRK2_DISABLE_HW_TIMEOUT))
>  			DBG("Too large timeout 0x%x requested for CMD%d!\n",
>  			    count, cmd->opcode);
> -		count = 0xE;
> +		count = host->max_timeout_count;
>  	} else {
>  		*too_big = false;
>  	}
> @@ -3940,6 +3940,8 @@ struct sdhci_host *sdhci_alloc_host(struct device *dev,
>  	 */
>  	host->adma_table_cnt = SDHCI_MAX_SEGS * 2 + 1;
>  
> +	host->max_timeout_count = 0xE;
> +
>  	return host;
>  }
>  
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 074dc18..e8d04e4 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -517,6 +517,7 @@ struct sdhci_host {
>  
>  	unsigned int max_clk;	/* Max possible freq (MHz) */
>  	unsigned int timeout_clk;	/* Timeout freq (KHz) */
> +	u8 max_timeout_count;	/* Vendor specific max timeout count */
>  	unsigned int clk_mul;	/* Clock Muliplier value */
>  
>  	unsigned int clock;	/* Current clock (MHz) */
>