[PATCH 27/38] mmc: sdhci-of-esdhc: remove platform_suspend/platform_resume callbacks

Ulf Hansson ulf.hansson at linaro.org
Thu Apr 24 06:15:34 PDT 2014


On 24 April 2014 14:27, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:
> On Thu, Apr 24, 2014 at 01:32:02PM +0200, Ulf Hansson wrote:
>> On 24 April 2014 13:18, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:
>> > That may be the case, but that would be an additional modification, and so
>> > should be a separate patch.
>>
>> I just thought it make sense to include it here - it's really a simple
>> fix, touching the same code as this patch.
>>
>> Additionally, it would simplify this patch since you would be able to
>> use the PM macro.
>
> No, I'm not going to make this change after looking deeper at the existing
> code.
>
> The existing code does this:
>
> sdhci-pltfm.c:
> #ifdef CONFIG_PM
> int sdhci_pltfm_suspend(struct device *dev)
> {
>         struct sdhci_host *host = dev_get_drvdata(dev);
>
>         return sdhci_suspend_host(host);
> }
> EXPORT_SYMBOL_GPL(sdhci_pltfm_suspend);
>
> int sdhci_pltfm_resume(struct device *dev)
> {
>         struct sdhci_host *host = dev_get_drvdata(dev);
>
>         return sdhci_resume_host(host);
> }
> EXPORT_SYMBOL_GPL(sdhci_pltfm_resume);
>
> const struct dev_pm_ops sdhci_pltfm_pmops = {
>         .suspend        = sdhci_pltfm_suspend,
>         .resume         = sdhci_pltfm_resume,
> };
> EXPORT_SYMBOL_GPL(sdhci_pltfm_pmops);
> #endif  /* CONFIG_PM */
>
> sdhci-pltfm.h:
> #ifdef CONFIG_PM
> extern int sdhci_pltfm_suspend(struct device *dev);
> extern int sdhci_pltfm_resume(struct device *dev);
> extern const struct dev_pm_ops sdhci_pltfm_pmops;
> #define SDHCI_PLTFM_PMOPS (&sdhci_pltfm_pmops)
> #else
> #define SDHCI_PLTFM_PMOPS NULL
> #endif
>
> sdhci-of-esdhc.c:
> static struct platform_driver sdhci_esdhc_driver = {
>         .driver = {
>                 .pm = SDHCI_PLTFM_PMOPS,
>
> Changing this to use SIMPLE_DEV_PM_OPS changes the behaviour of this by
> placing the callbacks into the other methods.
>
> Is that change correct?
> Who's going to test that that change doesn't break anything (I don't have
> the hardware, and it's not a transformational change like the rest of the
> patch set, but a functional change)?
> Should this change be made for other SDHCI platforms as well?
>
> Frankly, I'm not happy to make such a change in a series which is supposed
> to be mainly about cleaning up and _not_ introducing functional changes.

Fair enough, let's keep it as is then and let's handle functional
changes separate.

>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.



More information about the linux-arm-kernel mailing list