[PATCH v2 1/2] mmc: sdhci-bcm2835: Clean up platform allocations if sdhci init fails.

[PATCH v2 1/2] mmc: sdhci-bcm2835: Clean up platform allocations if sdhci init fails.

[Eric Anholt]

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 drivers/mmc/host/sdhci-bcm2835.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index 0ef0343..32f4046 100644
--- a/drivers/mmc/host/sdhci-bcm2835.c
+++ b/drivers/mmc/host/sdhci-bcm2835.c
@@ -173,8 +173,11 @@ static int bcm2835_sdhci_probe(struct platform_device *pdev)
 		goto err;
 	}
 
-	return sdhci_add_host(host);
+	ret = sdhci_add_host(host);
+	if (ret)
+		goto err;
 
+	return 0;
 err:
 	sdhci_pltfm_free(pdev);
 	return ret;
-- 
2.1.4

[PATCH v2 2/2] mmc: sdhci-bcm2835: Actually enable the clock

[Eric Anholt]

We're currently using a fixed frequency clock specified in the DT, so
enabling is a no-op.  However, the RPi firmware-based clocks driver
can actually disable unused clocks, so when switching to use it we
ended up losing our MMC clock once all devices were probed.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Re-disable our clock on sdhci_add_host() failure.

 drivers/mmc/host/sdhci-bcm2835.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index 32f4046..1c65d46 100644
--- a/drivers/mmc/host/sdhci-bcm2835.c
+++ b/drivers/mmc/host/sdhci-bcm2835.c
@@ -172,12 +172,19 @@ static int bcm2835_sdhci_probe(struct platform_device *pdev)
 		ret = PTR_ERR(pltfm_host->clk);
 		goto err;
 	}
+	ret = clk_prepare_enable(pltfm_host->clk);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to enable host clk\n");
+		goto err;
+	}
 
 	ret = sdhci_add_host(host);
 	if (ret)
-		goto err;
+		goto err_clk;
 
 	return 0;
+err_clk:
+	clk_disable_unprepare(pltfm_host->clk);
 err:
 	sdhci_pltfm_free(pdev);
 	return ret;
-- 
2.1.4

Re: [PATCH v2 1/2] mmc: sdhci-bcm2835: Clean up platform allocations if sdhci init fails.

[Ulf Hansson]

On 29 May 2015 at 23:06, Eric Anholt <eric@anholt.net> wrote:
> Signed-off-by: Eric Anholt <eric@anholt.net>

Thanks, applied!

Kind regards
Uffe

> ---
>  drivers/mmc/host/sdhci-bcm2835.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
> index 0ef0343..32f4046 100644
> --- a/drivers/mmc/host/sdhci-bcm2835.c
> +++ b/drivers/mmc/host/sdhci-bcm2835.c
> @@ -173,8 +173,11 @@ static int bcm2835_sdhci_probe(struct platform_device *pdev)
>                 goto err;
>         }
>
> -       return sdhci_add_host(host);
> +       ret = sdhci_add_host(host);
> +       if (ret)
> +               goto err;
>
> +       return 0;
>  err:
>         sdhci_pltfm_free(pdev);
>         return ret;
> --
> 2.1.4
>

Re: [PATCH v2 2/2] mmc: sdhci-bcm2835: Actually enable the clock

[Ulf Hansson]

On 29 May 2015 at 23:06, Eric Anholt <eric@anholt.net> wrote:
> We're currently using a fixed frequency clock specified in the DT, so
> enabling is a no-op.  However, the RPi firmware-based clocks driver
> can actually disable unused clocks, so when switching to use it we
> ended up losing our MMC clock once all devices were probed.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

Thanks, applied!

Kind regards
Uffe


> ---
>
> v2: Re-disable our clock on sdhci_add_host() failure.
>
>  drivers/mmc/host/sdhci-bcm2835.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
> index 32f4046..1c65d46 100644
> --- a/drivers/mmc/host/sdhci-bcm2835.c
> +++ b/drivers/mmc/host/sdhci-bcm2835.c
> @@ -172,12 +172,19 @@ static int bcm2835_sdhci_probe(struct platform_device *pdev)
>                 ret = PTR_ERR(pltfm_host->clk);
>                 goto err;
>         }
> +       ret = clk_prepare_enable(pltfm_host->clk);
> +       if (ret) {
> +               dev_err(&pdev->dev, "failed to enable host clk\n");
> +               goto err;
> +       }
>
>         ret = sdhci_add_host(host);
>         if (ret)
> -               goto err;
> +               goto err_clk;
>
>         return 0;
> +err_clk:
> +       clk_disable_unprepare(pltfm_host->clk);
>  err:
>         sdhci_pltfm_free(pdev);
>         return ret;
> --
> 2.1.4
>

Re: [PATCH v2 2/2] mmc: sdhci-bcm2835: Actually enable the clock

[Stephen Warren]

On 05/29/2015 03:06 PM, Eric Anholt wrote:
> We're currently using a fixed frequency clock specified in the DT, so
> enabling is a no-op.  However, the RPi firmware-based clocks driver
> can actually disable unused clocks, so when switching to use it we
> ended up losing our MMC clock once all devices were probed.

> diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c

> +	ret = clk_prepare_enable(pltfm_host->clk);
> +	if (ret) {
> +		dev_err(&pdev->dev, "failed to enable host clk\n");
> +		goto err;
> +	}

Given that pltfm_host is a "struct sdhci_pltfm_host" i.e. a type
defined/handled by sdhci-pltfm.c , I'm rather surprised that
sdhci-pltfm.c doesn't do this itself. Wouldn't it make sense for it to
do so?

Re: [PATCH v2 2/2] mmc: sdhci-bcm2835: Actually enable the clock

[Ulf Hansson]

On 5 June 2015 at 04:59, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 05/29/2015 03:06 PM, Eric Anholt wrote:
>> We're currently using a fixed frequency clock specified in the DT, so
>> enabling is a no-op.  However, the RPi firmware-based clocks driver
>> can actually disable unused clocks, so when switching to use it we
>> ended up losing our MMC clock once all devices were probed.
>
>> diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
>
>> +     ret = clk_prepare_enable(pltfm_host->clk);
>> +     if (ret) {
>> +             dev_err(&pdev->dev, "failed to enable host clk\n");
>> +             goto err;
>> +     }
>
> Given that pltfm_host is a "struct sdhci_pltfm_host" i.e. a type
> defined/handled by sdhci-pltfm.c , I'm rather surprised that
> sdhci-pltfm.c doesn't do this itself. Wouldn't it make sense for it to
> do so?

We could likely move additional clock management into the sdhci-pltfm.
So we would then remove some duplicated code, but we would potentially
also loose some in flexibility. It's worth an effort to look into.

Please go ahead and have a try. :-)

Kind regards
Uffe