[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1fSmg5ljuPH37Xy@shell.armlinux.org.uk>
Date: Tue, 25 Oct 2022 13:12:10 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Arnd Bergmann <arnd@...db.de>
Cc: Arnd Bergmann <arnd@...nel.org>,
linux-arm-kernel@...ts.infradead.org,
Linus Walleij <linus.walleij@...aro.org>,
Lubomir Rintel <lkundrak@...sk>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH 04/11] ARM: sa1100: make cpufreq driver build standalone
On Tue, Oct 25, 2022 at 12:14:19PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 25, 2022, at 10:28, Russell King (Oracle) wrote:
> > On Fri, Oct 21, 2022 at 05:49:34PM +0200, Arnd Bergmann wrote:
> >> From: Arnd Bergmann <arnd@...db.de>
> >>
> >> Commit 59a2e613d07f ("cpufreq: sa11x0: move cpufreq driver
> >> to drivers/cpufreq") added an unnecessary reference to
> >> mach/generic.h. Just remove it again after moving the code
> >> into the corresponding driver.
> >
> > So how does arch/arm/mach-sa1100/clock.c get the MPLL rate with this
> > change?
>
> You are right, that's broken. It works for the defconfigs that
> enable the cpufreq driver,
Umm. How? I think your testing must be seriously flawed!
You add sa11x0_getspeed() to the sa1110 cpufreq driver as a static
function, which means it won't be visible to clock.c - and clock.c
is always built, and always references sa11x0_getspeed()... so you
should be getting an unconditional build failure at link time and
a compiler warning that sa11x0_getspeed() is not declared.
Are you not seeing that?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists