On 2/04/20 2:54 pm, Michał Mirosław wrote:
> When host controller uses programmable clock presets but doesn't
> advertise programmable clock support, we can only guess what frequency
> it generates. Let's at least return correct SDHCI_PROG_CLOCK_MODE bit
> value in this case.
It sounds like the hardware is broken, so I tend to think a workaround
should be in the relevant vendor driver, because that is where
device-specific information really belongs.
>
> Fixes: 52983382c74f ("mmc: sdhci: enhance preset value function")
> Signed-off-by: Michał Mirosław <mirq-linux@xxxxxxxxxxxx>
> ---
> drivers/mmc/host/sdhci.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 9aa3af5826df..b2dc4f1cfa5c 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1767,11 +1767,10 @@ u16 sdhci_calc_clk(struct sdhci_host *host, unsigned int clock,
>
> pre_val = sdhci_get_preset_value(host);
> div = FIELD_GET(SDHCI_PRESET_SDCLK_FREQ_MASK, pre_val);
> - if (host->clk_mul &&
> - (pre_val & SDHCI_PRESET_CLKGEN_SEL)) {
> + if (pre_val & SDHCI_PRESET_CLKGEN_SEL) {
> clk = SDHCI_PROG_CLOCK_MODE;
> real_div = div + 1;
> - clk_mul = host->clk_mul;
> + clk_mul = host->clk_mul ?: 1;
> } else {
> real_div = max_t(int, 1, div << 1);
> }
>
