| Message ID | 20170522202951.2896280-1-arnd@arndb.de (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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(+)