[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFoGDHtE8JgLurwuN-W6CmmyBB3GP+7Z-bWqJiWw+TJEaQ@mail.gmail.com>
Date: Tue, 26 Jan 2021 10:55:07 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Florian Fainelli <f.fainelli@...il.com>,
Arnd Bergmann <arnd@...nel.org>,
Nicolas Schichan <nschichan@...ebox.fr>
Cc: Al Cooper <alcooperx@...il.com>,
Adrian Hunter <adrian.hunter@...el.com>,
BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
Arnd Bergmann <arnd@...db.de>,
"# 4.0+" <stable@...r.kernel.org>,
Douglas Anderson <dianders@...omium.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mmc: brcmstb: Fix sdhci_pltfm_suspend link error
On Mon, 25 Jan 2021 at 18:40, Florian Fainelli <f.fainelli@...il.com> wrote:
>
> +Nicolas,
>
> On 1/25/2021 4:50 AM, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@...db.de>
> >
> > 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: stable@...r.kernel.org
> > Signed-off-by: Arnd Bergmann <arnd@...db.de>
> > ---
> > 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
Powered by blists - more mailing lists