diff mbox

clk: sunxi-ng: select SUNXI_CCU_MULT for sun8i-a83t

Message ID 20170522202951.2896280-1-arnd@arndb.de
State Accepted
Commit b5e53469f35f8f295ae6bbb66604580fc02cfcf4
Headers show

Commit Message

Arnd Bergmann May 22, 2017, 8:29 p.m. UTC
We get a link error when CCU_MULT is not set with the
newly added driver:

drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.1+0x4): undefined reference to `ccu_mult_ops'
drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.3+0x4): undefined reference to `ccu_mult_ops'

Fixes: 46b492116666 ("clk: sunxi-ng: Add driver for A83T CCU")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

---
 drivers/clk/sunxi-ng/Kconfig | 1 +
 1 file changed, 1 insertion(+)

-- 
2.9.0

Comments

Stephen Boyd May 23, 2017, 12:55 a.m. UTC | #1
On 05/22, Arnd Bergmann wrote:
> We get a link error when CCU_MULT is not set with the

> newly added driver:

> 

> drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.1+0x4): undefined reference to `ccu_mult_ops'

> drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.3+0x4): undefined reference to `ccu_mult_ops'

> 

> Fixes: 46b492116666 ("clk: sunxi-ng: Add driver for A83T CCU")

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>


Is there any way we can automate finding these build errors and
prevent them from creeping into the tree? It may be asking too
much, but it seems like we should be able to find these
particular problems with some script that greps for ccu_*_ops and
checks that any file's Kconfig symbol also has that selected.

Anyway, I'm just tired of seeing these sorts of things in my
inbox.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Chen-Yu Tsai May 23, 2017, 7:19 a.m. UTC | #2
On Mon, May 22, 2017 at 05:55:53PM -0700, Stephen Boyd wrote:
> On 05/22, Arnd Bergmann wrote:

> > We get a link error when CCU_MULT is not set with the

> > newly added driver:

> > 

> > drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.1+0x4): undefined reference to `ccu_mult_ops'

> > drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.3+0x4): undefined reference to `ccu_mult_ops'

> > 

> > Fixes: 46b492116666 ("clk: sunxi-ng: Add driver for A83T CCU")

> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>


Acked-by: Chen-Yu Tsai <wens@csie.org>


> Is there any way we can automate finding these build errors and

> prevent them from creeping into the tree? It may be asking too

> much, but it seems like we should be able to find these

> particular problems with some script that greps for ccu_*_ops and

> checks that any file's Kconfig symbol also has that selected.

> 

> Anyway, I'm just tired of seeing these sorts of things in my

> inbox.


The (ugly) script below does the trick, though it does give results
for some symbols that are indirectly selected:

SUN5I_CCU uses SUNXI_CCU_GATE but does not select it
SUN5I_CCU uses SUNXI_CCU_MUX but does not select it
SUN5I_CCU uses SUNXI_CCU_NKMP but does not select it
SUN6I_A31_CCU uses SUNXI_CCU_GATE but does not select it
SUN6I_A31_CCU uses SUNXI_CCU_MUX but does not select it
SUN8I_A23_CCU uses SUNXI_CCU_GATE but does not select it
SUN8I_A23_CCU uses SUNXI_CCU_MUX but does not select it
SUN8I_A33_CCU uses SUNXI_CCU_GATE but does not select it
SUN8I_A33_CCU uses SUNXI_CCU_MUX but does not select it
SUN8I_A83T_CCU uses SUNXI_CCU_MULT but does not select it
SUN8I_H3_CCU uses SUNXI_CCU_GATE but does not select it
SUN8I_H3_CCU uses SUNXI_CCU_MUX but does not select it
SUN8I_V3S_CCU uses SUNXI_CCU_GATE but does not select it
SUN8I_V3S_CCU uses SUNXI_CCU_MUX but does not select it
SUN9I_A80_CCU uses SUNXI_CCU_MUX but does not select it

------------------------------------------------------------------------

#!/bin/bash

LANG=C

for i in drivers/clk/sunxi-ng/ccu-*.o; do
	FILE=`basename $i`
	CLKS=`nm -g $i | grep -P -o "ccu_.*(?=_ops)" | tr [a-z] [A-Z]`
	CFG=`grep $FILE drivers/clk/sunxi-ng/Makefile |
		grep -P -o "(?<=CONFIG_)SUN[A-Z0-9_]*"`

	for clk in $CLKS; do
		perl -0777 -ne "/$CFG(.*?)^(?:config|endif)/sm; print \$1" \
			drivers/clk/sunxi-ng/Kconfig | grep -q "SUNXI_$clk" ||
			echo "$CFG uses SUNXI_$clk but does not select it"
	done
done

------------------------------------------------------------------------


Regards
ChenYu
Chen-Yu Tsai May 23, 2017, 7:31 a.m. UTC | #3
On Tue, May 23, 2017 at 4:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> We get a link error when CCU_MULT is not set with the

> newly added driver:

>

> drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.1+0x4): undefined reference to `ccu_mult_ops'

> drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.3+0x4): undefined reference to `ccu_mult_ops'

>

> Fixes: 46b492116666 ("clk: sunxi-ng: Add driver for A83T CCU")

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>


Applied.

ChenYu
Arnd Bergmann May 23, 2017, 7:54 a.m. UTC | #4
On Tue, May 23, 2017 at 9:19 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Mon, May 22, 2017 at 05:55:53PM -0700, Stephen Boyd wrote:

>> On 05/22, Arnd Bergmann wrote:

>> > We get a link error when CCU_MULT is not set with the

>> > newly added driver:

>> >

>> > drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.1+0x4): undefined reference to `ccu_mult_ops'

>> > drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.3+0x4): undefined reference to `ccu_mult_ops'

>> >

>> > Fixes: 46b492116666 ("clk: sunxi-ng: Add driver for A83T CCU")

>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>

>

> Acked-by: Chen-Yu Tsai <wens@csie.org>

>

>> Is there any way we can automate finding these build errors and

>> prevent them from creeping into the tree? It may be asking too

>> much, but it seems like we should be able to find these

>> particular problems with some script that greps for ccu_*_ops and

>> checks that any file's Kconfig symbol also has that selected.

>>

>> Anyway, I'm just tired of seeing these sorts of things in my

>> inbox.


Definitely, I'm also tired of writing the patches ;-)

> The (ugly) script below does the trick, though it does give results

> for some symbols that are indirectly selected:

>

> SUN5I_CCU uses SUNXI_CCU_GATE but does not select it

> SUN5I_CCU uses SUNXI_CCU_MUX but does not select it


I think they are all caught implicitly, otherwise I would have run
into them.

> SUN5I_CCU uses SUNXI_CCU_NKMP but does not select it


I sent a patch for this on Feb 14 and again March 13, but haven't
gotten around to resubmit again.

An alternative would be to remove all the dependencies as 'lib-y'
in the Makefile and remove the individual Kconfig symbols. That
way, we would always build all of them when CONFIG_SUNXI_CCU
is enabled, but the linker would drop the ones that do not get
referenced.

         Arnd
Stephen Boyd June 1, 2017, 7:17 a.m. UTC | #5
On 05/23, Arnd Bergmann wrote:
> On Tue, May 23, 2017 at 9:19 AM, Chen-Yu Tsai <wens@csie.org> wrote:

> > On Mon, May 22, 2017 at 05:55:53PM -0700, Stephen Boyd wrote:

> >> On 05/22, Arnd Bergmann wrote:

> >> > We get a link error when CCU_MULT is not set with the

> >> > newly added driver:

> >> >

> >> > drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.1+0x4): undefined reference to `ccu_mult_ops'

> >> > drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.3+0x4): undefined reference to `ccu_mult_ops'

> >> >

> >> > Fixes: 46b492116666 ("clk: sunxi-ng: Add driver for A83T CCU")

> >> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>

> >

> > Acked-by: Chen-Yu Tsai <wens@csie.org>

> >

> >> Is there any way we can automate finding these build errors and

> >> prevent them from creeping into the tree? It may be asking too

> >> much, but it seems like we should be able to find these

> >> particular problems with some script that greps for ccu_*_ops and

> >> checks that any file's Kconfig symbol also has that selected.

> >>

> >> Anyway, I'm just tired of seeing these sorts of things in my

> >> inbox.

> 

> Definitely, I'm also tired of writing the patches ;-)

> 

> > The (ugly) script below does the trick, though it does give results

> > for some symbols that are indirectly selected:

> >

> > SUN5I_CCU uses SUNXI_CCU_GATE but does not select it

> > SUN5I_CCU uses SUNXI_CCU_MUX but does not select it

> 

> I think they are all caught implicitly, otherwise I would have run

> into them.

> 

> > SUN5I_CCU uses SUNXI_CCU_NKMP but does not select it

> 

> I sent a patch for this on Feb 14 and again March 13, but haven't

> gotten around to resubmit again.

> 

> An alternative would be to remove all the dependencies as 'lib-y'

> in the Makefile and remove the individual Kconfig symbols. That

> way, we would always build all of them when CONFIG_SUNXI_CCU

> is enabled, but the linker would drop the ones that do not get

> referenced.


In this case you're right, and we should change them to lib-y in
the Makefile and then let the linker figure this all out. No more
dependency patches. I think we only need to do this sort of
Kconfig stuff when we want to make a library .ko file that each
SoC specific driver depends on for common code.

It would be cool if the build system could figure that all out
for us, and let us have something like modlib-y that makes it a
library (archive) if all objects depending on it are builtin and
we have CONFIG_MODULES=n, or makes it into an object file if
something is builtin that depends on it, or makes it into a
module if everything that depends on it is a module.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Arnd Bergmann June 1, 2017, 9:07 a.m. UTC | #6
On Thu, Jun 1, 2017 at 9:17 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 05/23, Arnd Bergmann wrote:

>> On Tue, May 23, 2017 at 9:19 AM, Chen-Yu Tsai <wens@csie.org> wrote:

>> An alternative would be to remove all the dependencies as 'lib-y'

>> in the Makefile and remove the individual Kconfig symbols. That

>> way, we would always build all of them when CONFIG_SUNXI_CCU

>> is enabled, but the linker would drop the ones that do not get

>> referenced.

>

> In this case you're right, and we should change them to lib-y in

> the Makefile and then let the linker figure this all out. No more

> dependency patches. I think we only need to do this sort of

> Kconfig stuff when we want to make a library .ko file that each

> SoC specific driver depends on for common code.

>

> It would be cool if the build system could figure that all out

> for us, and let us have something like modlib-y that makes it a

> library (archive) if all objects depending on it are builtin and

> we have CONFIG_MODULES=n, or makes it into an object file if

> something is builtin that depends on it, or makes it into a

> module if everything that depends on it is a module.


In this case, there are no loadable modules, the sunxi clk drivers
can only be built-in, which should simplify the problem a lot.

       Arnd
Maxime Ripard June 2, 2017, 12:15 p.m. UTC | #7
On Thu, Jun 01, 2017 at 11:07:46AM +0200, Arnd Bergmann wrote:
> On Thu, Jun 1, 2017 at 9:17 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:

> > On 05/23, Arnd Bergmann wrote:

> >> On Tue, May 23, 2017 at 9:19 AM, Chen-Yu Tsai <wens@csie.org> wrote:

> >> An alternative would be to remove all the dependencies as 'lib-y'

> >> in the Makefile and remove the individual Kconfig symbols. That

> >> way, we would always build all of them when CONFIG_SUNXI_CCU

> >> is enabled, but the linker would drop the ones that do not get

> >> referenced.

> >

> > In this case you're right, and we should change them to lib-y in

> > the Makefile and then let the linker figure this all out. No more

> > dependency patches. I think we only need to do this sort of

> > Kconfig stuff when we want to make a library .ko file that each

> > SoC specific driver depends on for common code.

> >

> > It would be cool if the build system could figure that all out

> > for us, and let us have something like modlib-y that makes it a

> > library (archive) if all objects depending on it are builtin and

> > we have CONFIG_MODULES=n, or makes it into an object file if

> > something is builtin that depends on it, or makes it into a

> > module if everything that depends on it is a module.

> 

> In this case, there are no loadable modules, the sunxi clk drivers

> can only be built-in, which should simplify the problem a lot.


Using the linker to drop the useless stuff seems like a good idea. Do
you want to send a patch for it?

Maxim

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
diff mbox

Patch

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index a384c695b388..67acef3d2494 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -121,6 +121,7 @@  config SUN8I_A83T_CCU
 	select SUNXI_CCU_DIV
 	select SUNXI_CCU_GATE
 	select SUNXI_CCU_MP
+	select SUNXI_CCU_MULT
 	select SUNXI_CCU_MUX
 	select SUNXI_CCU_NKMP
 	select SUNXI_CCU_NM