+Nicolas,
On 1/25/2021 4:50 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann <[email protected]>
>
> sdhci_pltfm_suspend() is only available when CONFIG_PM_SLEEP
> support is built into the kernel, which caused a regression
> in a recent bugfix:
>
> ld.lld: error: undefined symbol: sdhci_pltfm_suspend
>>>> referenced by sdhci-brcmstb.c
>>>> mmc/host/sdhci-brcmstb.o:(sdhci_brcmstb_shutdown) in archive drivers/built-in.a
>
> Making the call conditional on the symbol fixes the link
> error.
>
> Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend")
> Fixes: e7b5d63a82fe ("mmc: sdhci-brcmstb: Add shutdown callback")
> Cc: [email protected]
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> It would be helpful if someone could test this to ensure that the
> driver works correctly even when CONFIG_PM_SLEEP is disabled
Why not create stubs for sdhci_pltfm_suspend() when CONFIG_PM_SLEEP=n? I
don't think this is going to be a functional issue given that the
purpose of having the .shutdown() function is to save power if we cannot
that is fine, too.
--
Florian
On Mon, 25 Jan 2021 at 18:40, Florian Fainelli <[email protected]> wrote:
>
> +Nicolas,
>
> On 1/25/2021 4:50 AM, Arnd Bergmann wrote:
> > From: Arnd Bergmann <[email protected]>
> >
> > sdhci_pltfm_suspend() is only available when CONFIG_PM_SLEEP
> > support is built into the kernel, which caused a regression
> > in a recent bugfix:
> >
> > ld.lld: error: undefined symbol: sdhci_pltfm_suspend
> >>>> referenced by sdhci-brcmstb.c
> >>>> mmc/host/sdhci-brcmstb.o:(sdhci_brcmstb_shutdown) in archive drivers/built-in.a
> >
> > Making the call conditional on the symbol fixes the link
> > error.
> >
> > Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend")
> > Fixes: e7b5d63a82fe ("mmc: sdhci-brcmstb: Add shutdown callback")
> > Cc: [email protected]
> > Signed-off-by: Arnd Bergmann <[email protected]>
> > ---
> > It would be helpful if someone could test this to ensure that the
> > driver works correctly even when CONFIG_PM_SLEEP is disabled
>
> Why not create stubs for sdhci_pltfm_suspend() when CONFIG_PM_SLEEP=n? I
> don't think this is going to be a functional issue given that the
> purpose of having the .shutdown() function is to save power if we cannot
> that is fine, too.
> --
> Florian
I would prefer this approach - we shouldn't leave stub functions
unimplemented, which is what looks to me.
I just posted a new patch for this, please have a look and test it.
Kind regards
Uffe
> I just posted a new patch for this, please have a look and test it.
>
> Kind regards
> Uffe
I tested your new patch and it works.
Reviewed-and-tested-by: Al Cooper <[email protected]>
Thanks
Al
On Tue, Jan 26, 2021 at 4:55 AM Ulf Hansson <[email protected]> wrote:
>
> On Mon, 25 Jan 2021 at 18:40, Florian Fainelli <[email protected]> wrote:
> >
> > +Nicolas,
> >
> > On 1/25/2021 4:50 AM, Arnd Bergmann wrote:
> > > From: Arnd Bergmann <[email protected]>
> > >
> > > sdhci_pltfm_suspend() is only available when CONFIG_PM_SLEEP
> > > support is built into the kernel, which caused a regression
> > > in a recent bugfix:
> > >
> > > ld.lld: error: undefined symbol: sdhci_pltfm_suspend
> > >>>> referenced by sdhci-brcmstb.c
> > >>>> mmc/host/sdhci-brcmstb.o:(sdhci_brcmstb_shutdown) in archive drivers/built-in.a
> > >
> > > Making the call conditional on the symbol fixes the link
> > > error.
> > >
> > > Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend")
> > > Fixes: e7b5d63a82fe ("mmc: sdhci-brcmstb: Add shutdown callback")
> > > Cc: [email protected]
> > > Signed-off-by: Arnd Bergmann <[email protected]>
> > > ---
> > > It would be helpful if someone could test this to ensure that the
> > > driver works correctly even when CONFIG_PM_SLEEP is disabled
> >
> > Why not create stubs for sdhci_pltfm_suspend() when CONFIG_PM_SLEEP=n? I
> > don't think this is going to be a functional issue given that the
> > purpose of having the .shutdown() function is to save power if we cannot
> > that is fine, too.
> > --
> > Florian
>
> I would prefer this approach - we shouldn't leave stub functions
> unimplemented, which is what looks to me.
>
> I just posted a new patch for this, please have a look and test it.
>
> Kind regards
> Uffe