Message ID | 5d04e453a4da5cfafb56695a17157fa3ea296511.1672484831.git.christophe.jaillet@wanadoo.fr |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp3300724wrt; Sat, 31 Dec 2022 03:27:33 -0800 (PST) X-Google-Smtp-Source: AMrXdXuqP+pzeEd2drNyWv6Nz8vdc98FLdpm+mbrl07i+UaQNrmet03XbMRLAikLKBA4230/rSxS X-Received: by 2002:a05:6402:22ad:b0:488:6003:24b6 with SMTP id cx13-20020a05640222ad00b00488600324b6mr1725918edb.40.1672486053181; Sat, 31 Dec 2022 03:27:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672486053; cv=none; d=google.com; s=arc-20160816; b=x0kmzyaMjimbw30MpsvT7uq2xC+LojkQBJqCgVaqZehcwGUPXLPp5+i2Z0YVOF4Lgy +dX2lOTkZga/2hLdIfenWhLqLwqfoPRq5dhS5+9eOqaVVpO2ykJEdBJB2I+y3J49uFn0 3lPyRPqUwbfEoUpEgmcizSj1+sTKx2QgpViTPzenwbk6qyrsU0IUaqCJsfZvSBuEsqfb NLP1BuenxwjubLatiIInd6Y7Z0c2bzNNOXNRWg4euWo8E6uuyf3keiOtF51my6ZEwu4t NRimnSxgR9WxD52FVX90J2oMHdeikFlR5qh8LVVgnyLYfe8S7DNdPtiwjDsaXxV3XMC0 mXZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=zSyFePTDoEDUgYmSWfJbYOVwj8uiYb3AAkUWKWjjeDA=; b=VZ92fmYLALtnlc0CeMvSahRvYtZkZYXd2a7ygnJJiIjHXVB5BX9KQaOK8+RGaEGhlL Ur+X63G/xsplcS1n7HO43YJlgfr6C5k/Is268/XyeUX0ObJPa1gVTEtEf7ys3YXOATcY 7hcF2lXvBuqxc1uYlMxvLLvXZT6uWNrZrb5YaVS7imtulNV0Efua3xwfVL6K74Rati3J eAr0xJ60QKcKCYz6+ywurfRQ7YJ8Pp5ZlQorFeZ3hRk6Lj22Poic1FSr48EebqPtHd/w F8kijtuVrAe0IRuSD3K8J9+98lF8lkOuDHd7YghIAwMktGjUpyM9LvaJOaO51gLZ7HeS wHWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r13-20020aa7da0d000000b0048ba605a150si2418372eds.240.2022.12.31.03.27.09; Sat, 31 Dec 2022 03:27:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229536AbiLaLHe (ORCPT <rfc822;cscallsign@gmail.com> + 99 others); Sat, 31 Dec 2022 06:07:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231958AbiLaLHb (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 31 Dec 2022 06:07:31 -0500 Received: from smtp.smtpout.orange.fr (smtp-30.smtpout.orange.fr [80.12.242.30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4AA2DF55 for <linux-kernel@vger.kernel.org>; Sat, 31 Dec 2022 03:07:30 -0800 (PST) Received: from pop-os.home ([86.243.100.34]) by smtp.orange.fr with ESMTPA id BZi4pTIC3Rn9tBZi4pP7i0; Sat, 31 Dec 2022 12:07:29 +0100 X-ME-Helo: pop-os.home X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Sat, 31 Dec 2022 12:07:29 +0100 X-ME-IP: 86.243.100.34 From: Christophe JAILLET <christophe.jaillet@wanadoo.fr> To: Wim Van Sebroeck <wim@linux-watchdog.org>, Guenter Roeck <linux@roeck-us.net> Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Christophe JAILLET <christophe.jaillet@wanadoo.fr>, linux-watchdog@vger.kernel.org Subject: [PATCH] watchdog: ixp4xx: Use devm_clk_get_enabled() helper Date: Sat, 31 Dec 2022 12:07:27 +0100 Message-Id: <5d04e453a4da5cfafb56695a17157fa3ea296511.1672484831.git.christophe.jaillet@wanadoo.fr> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753728735731088159?= X-GMAIL-MSGID: =?utf-8?q?1753728735731088159?= |
Series |
watchdog: ixp4xx: Use devm_clk_get_enabled() helper
|
|
Commit Message
Christophe JAILLET
Dec. 31, 2022, 11:07 a.m. UTC
The devm_clk_get_enabled() helper:
- calls devm_clk_get()
- calls clk_prepare_enable() and registers what is needed in order to
call clk_disable_unprepare() when needed, as a managed resource.
This simplifies the code and avoids the need of a dedicated function used
with devm_add_action_or_reset().
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Note that I get a compilation error because read_cpuid_id() is not defined
on my system (x86_64).
So I think that a "depends on ARM<something>" in missing in a KConfig file.
Fixing it could help compilation farms build-bots.
---
drivers/watchdog/ixp4xx_wdt.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
Comments
On Sat, Dec 31, 2022 at 12:07:27PM +0100, Christophe JAILLET wrote: > The devm_clk_get_enabled() helper: > - calls devm_clk_get() > - calls clk_prepare_enable() and registers what is needed in order to > call clk_disable_unprepare() when needed, as a managed resource. > > This simplifies the code and avoids the need of a dedicated function used > with devm_add_action_or_reset(). > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > --- > Note that I get a compilation error because read_cpuid_id() is not defined > on my system (x86_64). > So I think that a "depends on ARM<something>" in missing in a KConfig file. It has depends on ARCH_IXP4XX and CONFIG_IXP4XX_WATCHDOG is not set for me after "make allmodconfig". > > Fixing it could help compilation farms build-bots. Mine doesn't see a problem, and I don't recall ever being alerted about one. What am I missing ? Do you see a problem reported anywhere ? Guenter > --- > drivers/watchdog/ixp4xx_wdt.c | 18 +++--------------- > 1 file changed, 3 insertions(+), 15 deletions(-) > > diff --git a/drivers/watchdog/ixp4xx_wdt.c b/drivers/watchdog/ixp4xx_wdt.c > index 281a48d9889f..607ce4b8df57 100644 > --- a/drivers/watchdog/ixp4xx_wdt.c > +++ b/drivers/watchdog/ixp4xx_wdt.c > @@ -112,12 +112,6 @@ static const struct watchdog_info ixp4xx_wdt_info = { > .identity = KBUILD_MODNAME, > }; > > -/* Devres-handled clock disablement */ > -static void ixp4xx_clock_action(void *d) > -{ > - clk_disable_unprepare(d); > -} > - > static int ixp4xx_wdt_probe(struct platform_device *pdev) > { > struct device *dev = &pdev->dev; > @@ -139,16 +133,10 @@ static int ixp4xx_wdt_probe(struct platform_device *pdev) > * Retrieve rate from a fixed clock from the device tree if > * the parent has that, else use the default clock rate. > */ > - clk = devm_clk_get(dev->parent, NULL); > - if (!IS_ERR(clk)) { > - ret = clk_prepare_enable(clk); > - if (ret) > - return ret; > - ret = devm_add_action_or_reset(dev, ixp4xx_clock_action, clk); > - if (ret) > - return ret; > + clk = devm_clk_get_enabled(dev->parent, NULL); > + if (!IS_ERR(clk)) > iwdt->rate = clk_get_rate(clk); > - } > + > if (!iwdt->rate) > iwdt->rate = IXP4XX_TIMER_FREQ; > > -- > 2.34.1 >
Le 01/01/2023 à 00:14, Guenter Roeck a écrit : > On Sat, Dec 31, 2022 at 12:07:27PM +0100, Christophe JAILLET wrote: >> The devm_clk_get_enabled() helper: >> - calls devm_clk_get() >> - calls clk_prepare_enable() and registers what is needed in order to >> call clk_disable_unprepare() when needed, as a managed resource. >> >> This simplifies the code and avoids the need of a dedicated function used >> with devm_add_action_or_reset(). >> >> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> >> --- >> Note that I get a compilation error because read_cpuid_id() is not defined >> on my system (x86_64). >> So I think that a "depends on ARM<something>" in missing in a KConfig file. > > It has > > depends on ARCH_IXP4XX > > and CONFIG_IXP4XX_WATCHDOG is not set for me after "make allmodconfig". Here is what do. make allmodconfig make -j8 drivers/watchdog/ixp4xx_wdt.o And I get: DESCEND objtool CALL scripts/checksyscalls.sh CC drivers/watchdog/ixp4xx_wdt.o drivers/watchdog/ixp4xx_wdt.c: In function ‘ixp4xx_wdt_probe’: drivers/watchdog/ixp4xx_wdt.c:122:15: error: implicit declaration of function ‘read_cpuid_id’ [-Werror=implicit-function-declaration] 122 | if (!(read_cpuid_id() & 0xf) && !cpu_is_ixp46x()) { | ^~~~~~~~~~~~~ cc1: all warnings being treated as errors make[3]: *** [scripts/Makefile.build:252 : drivers/watchdog/ixp4xx_wdt.o] Erreur 1 make[2]: *** [scripts/Makefile.build:504 : drivers/watchdog] Erreur 2 make[1]: *** [scripts/Makefile.build:504 : drivers] Erreur 2 make: *** [Makefile:2011 : .] Erreur 2 I do agree with you that: - Kconfig looks fine config IXP4XX_WATCHDOG tristate "IXP4xx Watchdog" depends on ARCH_IXP4XX - Makefile looks fine obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o - .config looks fine IXP4XX_WATCHDOG is NOT defined - make drivers/watchdog/ looks fine No error and ixp4xx_wdt.o is NOT built. However, in the past (if I recollect correctly :) ), a "make <something_that depends_on_a_config_variable_that_is_not_defined>" returned an error stating that no rule existed to build the specified target. I sometimes needed to tweak the Kconfig files to force some compilation when I didn't have the right tool chain or configuration. It was maybe not the best practice, but it worked most of the time. Now, with the example above, such a compilation attempt is possible. It is maybe normal (because of a change somewhere in the way the kernel is built, because of an updated toolchain on my machine, ...) This is just fine for me, but looked really surprising. That is why I first thought that something was missing in a Kconfig file. So my comments are just a surprise to me to something that seems not to behave the same as before. As far a just a 'make' works as expected, I won't dig further if this behavior is expected or not. It should be a corner case anyway, and for my own use, I would even call it a feature :) (i.e. it saves me some Kconfig modification to test things) CJ > >> >> Fixing it could help compilation farms build-bots. > > Mine doesn't see a problem, and I don't recall ever being alerted about > one. What am I missing ? Do you see a problem reported anywhere ? > > Guenter > >> --- >> drivers/watchdog/ixp4xx_wdt.c | 18 +++--------------- >> 1 file changed, 3 insertions(+), 15 deletions(-) >> >> diff --git a/drivers/watchdog/ixp4xx_wdt.c b/drivers/watchdog/ixp4xx_wdt.c >> index 281a48d9889f..607ce4b8df57 100644 >> --- a/drivers/watchdog/ixp4xx_wdt.c >> +++ b/drivers/watchdog/ixp4xx_wdt.c >> @@ -112,12 +112,6 @@ static const struct watchdog_info ixp4xx_wdt_info = { >> .identity = KBUILD_MODNAME, >> }; >> >> -/* Devres-handled clock disablement */ >> -static void ixp4xx_clock_action(void *d) >> -{ >> - clk_disable_unprepare(d); >> -} >> - >> static int ixp4xx_wdt_probe(struct platform_device *pdev) >> { >> struct device *dev = &pdev->dev; >> @@ -139,16 +133,10 @@ static int ixp4xx_wdt_probe(struct platform_device *pdev) >> * Retrieve rate from a fixed clock from the device tree if >> * the parent has that, else use the default clock rate. >> */ >> - clk = devm_clk_get(dev->parent, NULL); >> - if (!IS_ERR(clk)) { >> - ret = clk_prepare_enable(clk); >> - if (ret) >> - return ret; >> - ret = devm_add_action_or_reset(dev, ixp4xx_clock_action, clk); >> - if (ret) >> - return ret; >> + clk = devm_clk_get_enabled(dev->parent, NULL); >> + if (!IS_ERR(clk)) >> iwdt->rate = clk_get_rate(clk); >> - } >> + >> if (!iwdt->rate) >> iwdt->rate = IXP4XX_TIMER_FREQ; >> >> -- >> 2.34.1 >> >
On Sun, Jan 01, 2023 at 10:35:59AM +0100, Christophe JAILLET wrote: > Le 01/01/2023 à 00:14, Guenter Roeck a écrit : > > On Sat, Dec 31, 2022 at 12:07:27PM +0100, Christophe JAILLET wrote: > > > The devm_clk_get_enabled() helper: > > > - calls devm_clk_get() > > > - calls clk_prepare_enable() and registers what is needed in order to > > > call clk_disable_unprepare() when needed, as a managed resource. > > > > > > This simplifies the code and avoids the need of a dedicated function used > > > with devm_add_action_or_reset(). > > > > > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > > --- > > > Note that I get a compilation error because read_cpuid_id() is not defined > > > on my system (x86_64). > > > So I think that a "depends on ARM<something>" in missing in a KConfig file. > > > > It has > > > > depends on ARCH_IXP4XX > > > > and CONFIG_IXP4XX_WATCHDOG is not set for me after "make allmodconfig". > > Here is what do. > > make allmodconfig > make -j8 drivers/watchdog/ixp4xx_wdt.o > > And I get: > DESCEND objtool > CALL scripts/checksyscalls.sh > CC drivers/watchdog/ixp4xx_wdt.o > drivers/watchdog/ixp4xx_wdt.c: In function ‘ixp4xx_wdt_probe’: > drivers/watchdog/ixp4xx_wdt.c:122:15: error: implicit declaration of > function ‘read_cpuid_id’ [-Werror=implicit-function-declaration] > 122 | if (!(read_cpuid_id() & 0xf) && !cpu_is_ixp46x()) { > | ^~~~~~~~~~~~~ > cc1: all warnings being treated as errors > make[3]: *** [scripts/Makefile.build:252 : drivers/watchdog/ixp4xx_wdt.o] > Erreur 1 > make[2]: *** [scripts/Makefile.build:504 : drivers/watchdog] Erreur 2 > make[1]: *** [scripts/Makefile.build:504 : drivers] Erreur 2 > make: *** [Makefile:2011 : .] Erreur 2 > > > I do agree with you that: > > - Kconfig looks fine > config IXP4XX_WATCHDOG > tristate "IXP4xx Watchdog" > depends on ARCH_IXP4XX > > - Makefile looks fine > obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o > > - .config looks fine > IXP4XX_WATCHDOG is NOT defined > > - make drivers/watchdog/ looks fine > No error and ixp4xx_wdt.o is NOT built. > > > However, in the past (if I recollect correctly :) ), a "make <something_that > depends_on_a_config_variable_that_is_not_defined>" returned an error stating > that no rule existed to build the specified target. > This is not correct. It only applies if the target directory Makefile is excluded by the make flags, or possibly if the target file is a complex one build from various source files. > I sometimes needed to tweak the Kconfig files to force some compilation when > I didn't have the right tool chain or configuration. > It was maybe not the best practice, but it worked most of the time. > > > Now, with the example above, such a compilation attempt is possible. It is > maybe normal (because of a change somewhere in the way the kernel is built, > because of an updated toolchain on my machine, ...) > This is just fine for me, but looked really surprising. > > That is why I first thought that something was missing in a Kconfig file. > > > So my comments are just a surprise to me to something that seems not to > behave the same as before. > I don't think anything changed. It always worked like that for me. I would suggest to go back to an older kernel and try it there. You'll see exactly the same error. Maybe you just never encountered a file like that. So, in other words, what you should have said is "not compile tested". Alternatively, you could install cross compilers and compile test the patches with those. Thanks, Guenter
Le 01/01/2023 à 16:07, Guenter Roeck a écrit : > On Sun, Jan 01, 2023 at 10:35:59AM +0100, Christophe JAILLET wrote: >> Le 01/01/2023 à 00:14, Guenter Roeck a écrit : >>> On Sat, Dec 31, 2022 at 12:07:27PM +0100, Christophe JAILLET wrote: >>>> The devm_clk_get_enabled() helper: >>>> - calls devm_clk_get() >>>> - calls clk_prepare_enable() and registers what is needed in order to >>>> call clk_disable_unprepare() when needed, as a managed resource. >>>> >>>> This simplifies the code and avoids the need of a dedicated function used >>>> with devm_add_action_or_reset(). >>>> >>>> Signed-off-by: Christophe JAILLET <christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@public.gmane.org> >>>> --- >>>> Note that I get a compilation error because read_cpuid_id() is not defined >>>> on my system (x86_64). >>>> So I think that a "depends on ARM<something>" in missing in a KConfig file. >>> >>> It has >>> >>> depends on ARCH_IXP4XX >>> >>> and CONFIG_IXP4XX_WATCHDOG is not set for me after "make allmodconfig". >> >> Here is what do. >> >> make allmodconfig >> make -j8 drivers/watchdog/ixp4xx_wdt.o >> >> And I get: >> DESCEND objtool >> CALL scripts/checksyscalls.sh >> CC drivers/watchdog/ixp4xx_wdt.o >> drivers/watchdog/ixp4xx_wdt.c: In function ‘ixp4xx_wdt_probe’: >> drivers/watchdog/ixp4xx_wdt.c:122:15: error: implicit declaration of >> function ‘read_cpuid_id’ [-Werror=implicit-function-declaration] >> 122 | if (!(read_cpuid_id() & 0xf) && !cpu_is_ixp46x()) { >> | ^~~~~~~~~~~~~ >> cc1: all warnings being treated as errors >> make[3]: *** [scripts/Makefile.build:252 : drivers/watchdog/ixp4xx_wdt.o] >> Erreur 1 >> make[2]: *** [scripts/Makefile.build:504 : drivers/watchdog] Erreur 2 >> make[1]: *** [scripts/Makefile.build:504 : drivers] Erreur 2 >> make: *** [Makefile:2011 : .] Erreur 2 >> >> >> I do agree with you that: >> >> - Kconfig looks fine >> config IXP4XX_WATCHDOG >> tristate "IXP4xx Watchdog" >> depends on ARCH_IXP4XX >> >> - Makefile looks fine >> obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o >> >> - .config looks fine >> IXP4XX_WATCHDOG is NOT defined >> >> - make drivers/watchdog/ looks fine >> No error and ixp4xx_wdt.o is NOT built. >> >> >> However, in the past (if I recollect correctly :) ), a "make <something_that >> depends_on_a_config_variable_that_is_not_defined>" returned an error stating >> that no rule existed to build the specified target. >> > > This is not correct. It only applies if the target directory Makefile is > excluded by the make flags, or possibly if the target file is a complex > one build from various source files. > >> I sometimes needed to tweak the Kconfig files to force some compilation when >> I didn't have the right tool chain or configuration. >> It was maybe not the best practice, but it worked most of the time. >> >> >> Now, with the example above, such a compilation attempt is possible. It is >> maybe normal (because of a change somewhere in the way the kernel is built, >> because of an updated toolchain on my machine, ...) >> This is just fine for me, but looked really surprising. >> >> That is why I first thought that something was missing in a Kconfig file. >> >> >> So my comments are just a surprise to me to something that seems not to >> behave the same as before. >> > I don't think anything changed. It always worked like that for me. > I would suggest to go back to an older kernel and try it there. > You'll see exactly the same error. Maybe you just never encountered > a file like that. git reset --hard next-20210111 (randomly chosen date) make allmodconfig make clean make -j7 drivers/watchdog/ixp4xx_wdt.o (too build most of the needed stuff to build a kernel) touch drivers/watchdog/ixp4xx_wdt.c make -j7 drivers/watchdog/ixp4xx_wdt.o (too build this file only) DESCEND objtool CALL scripts/atomic/check-atomics.sh CALL scripts/checksyscalls.sh make[3]: *** Aucune règle pour fabriquer la cible « drivers/watchdog/ixp4xx_wdt.o ». Arrêt. make[2]: *** [scripts/Makefile.build:471 : __build] Erreur 2 make[1]: *** [scripts/Makefile.build:496 : drivers/watchdog] Erreur 2 make: *** [Makefile:1805 : drivers] Erreur 2 This is what I had in mind. (Aucune règle pour fabriquer la cible... = no rule to build...) So something changed somewhere. Maybe in the way Makefile are now included or not in the build process, as you suggest above. > > So, in other words, what you should have said is "not compile tested". > Alternatively, you could install cross compilers and compile test the > patches with those. > No. The patches HAVE been cross compiled after my initial attempt with my default x86_64 failing built. This one was successfully built using: make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- allmodconfig make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- -j7 drivers/watchdog/ixp4xx_wdt.o The other one was successfully built using: make ARCH=mips CROSS_COMPILE=mips64-linux-gnuabi64- allmodconfig Changing CONFIG_MACH_LOONGSON32 to y, instead of CONFIG_MIPS_GENERIC_KERNEL make ARCH=mips CROSS_COMPILE=mips64-linux-gnuabi64- -j7 drivers/watchdog/loongson1_wdt.o I've long been reluctant to use cross-compiler because of low disk space on my system. But I've changed my mind recently and now I do cross compile. (see [1] if needed as example also with ARCH=arm) My comments below the --- in the patches should not be taken as "I've not managed to build with the patch", but "I've been surprised to get an issue with x86_64, then cross-compiled with the relevant toolchain. Then, I reported what looked like a potential issue when building with x86_64." CJ [1]: https://lore.kernel.org/all/dc5a2157-19c8-4498-6288-d7513ad3dde2@wanadoo.fr/ > > Thanks, > Guenter >
On Sun, Jan 01, 2023 at 06:52:35PM +0100, Christophe JAILLET wrote: [ ... ] > > > > > > Here is what do. > > > > > > make allmodconfig > > > make -j8 drivers/watchdog/ixp4xx_wdt.o > > > > > > And I get: > > > DESCEND objtool > > > CALL scripts/checksyscalls.sh > > > CC drivers/watchdog/ixp4xx_wdt.o > > > drivers/watchdog/ixp4xx_wdt.c: In function ‘ixp4xx_wdt_probe’: > > > drivers/watchdog/ixp4xx_wdt.c:122:15: error: implicit declaration of > > > function ‘read_cpuid_id’ [-Werror=implicit-function-declaration] > > > 122 | if (!(read_cpuid_id() & 0xf) && !cpu_is_ixp46x()) { > > > | ^~~~~~~~~~~~~ > > > cc1: all warnings being treated as errors > > > make[3]: *** [scripts/Makefile.build:252 : drivers/watchdog/ixp4xx_wdt.o] > > > Erreur 1 > > > make[2]: *** [scripts/Makefile.build:504 : drivers/watchdog] Erreur 2 > > > make[1]: *** [scripts/Makefile.build:504 : drivers] Erreur 2 > > > make: *** [Makefile:2011 : .] Erreur 2 > > > > > > > > > I do agree with you that: > > > > > > - Kconfig looks fine > > > config IXP4XX_WATCHDOG > > > tristate "IXP4xx Watchdog" > > > depends on ARCH_IXP4XX > > > > > > - Makefile looks fine > > > obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o > > > > > > - .config looks fine > > > IXP4XX_WATCHDOG is NOT defined > > > > > > - make drivers/watchdog/ looks fine > > > No error and ixp4xx_wdt.o is NOT built. > > > > > > > > > However, in the past (if I recollect correctly :) ), a "make <something_that > > > depends_on_a_config_variable_that_is_not_defined>" returned an error stating > > > that no rule existed to build the specified target. > > > > > > > This is not correct. It only applies if the target directory Makefile is > > excluded by the make flags, or possibly if the target file is a complex > > one build from various source files. > > > > > I sometimes needed to tweak the Kconfig files to force some compilation when > > > I didn't have the right tool chain or configuration. > > > It was maybe not the best practice, but it worked most of the time. > > > > > > > > > Now, with the example above, such a compilation attempt is possible. It is > > > maybe normal (because of a change somewhere in the way the kernel is built, > > > because of an updated toolchain on my machine, ...) > > > This is just fine for me, but looked really surprising. > > > > > > That is why I first thought that something was missing in a Kconfig file. > > > > > > > > > So my comments are just a surprise to me to something that seems not to > > > behave the same as before. > > > > > I don't think anything changed. It always worked like that for me. > > I would suggest to go back to an older kernel and try it there. > > You'll see exactly the same error. Maybe you just never encountered > > a file like that. > > git reset --hard next-20210111 (randomly chosen date) > make allmodconfig > make clean > make -j7 drivers/watchdog/ixp4xx_wdt.o (too build most of the needed stuff > to build a kernel) > touch drivers/watchdog/ixp4xx_wdt.c > make -j7 drivers/watchdog/ixp4xx_wdt.o (too build this file only) > > DESCEND objtool > CALL scripts/atomic/check-atomics.sh > CALL scripts/checksyscalls.sh > make[3]: *** Aucune règle pour fabriquer la cible « > drivers/watchdog/ixp4xx_wdt.o ». Arrêt. > make[2]: *** [scripts/Makefile.build:471 : __build] Erreur 2 > make[1]: *** [scripts/Makefile.build:496 : drivers/watchdog] Erreur 2 > make: *** [Makefile:1805 : drivers] Erreur 2 > Turns out the behavior preferred by you was introduced in v5.4 with commit 394053f4a4b3 ("kbuild: make single targets work more correctly") and undone with commit cc306abd19e8 ("kbuild: fix and refactor single target build") in v6.1. As for what is the expected behavior, I can't say. I for my part had not noticed that the behavior had changed between v5.4 and v6.0. I would suggest to discuss details with Yamada-san. Thanks, Guenter
On Sat, Dec 31, 2022 at 12:07:27PM +0100, Christophe JAILLET wrote: > The devm_clk_get_enabled() helper: > - calls devm_clk_get() > - calls clk_prepare_enable() and registers what is needed in order to > call clk_disable_unprepare() when needed, as a managed resource. > > This simplifies the code and avoids the need of a dedicated function used > with devm_add_action_or_reset(). > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Guenter Roeck <linux@roeck-us.net> > --- > Note that I get a compilation error because read_cpuid_id() is not defined > on my system (x86_64). > So I think that a "depends on ARM<something>" in missing in a KConfig file. > > Fixing it could help compilation farms build-bots. As mentioned, this not how build dependencies work. The code builds fine with arm:allmodconfig. It is not enabled with x86_64:allmodconfig since it depends on ARCH_IXP4XX. It is is not expected to be buildable if ARCH_IXP4XX is not selected. Guenter > --- > drivers/watchdog/ixp4xx_wdt.c | 18 +++--------------- > 1 file changed, 3 insertions(+), 15 deletions(-) > > diff --git a/drivers/watchdog/ixp4xx_wdt.c b/drivers/watchdog/ixp4xx_wdt.c > index 281a48d9889f..607ce4b8df57 100644 > --- a/drivers/watchdog/ixp4xx_wdt.c > +++ b/drivers/watchdog/ixp4xx_wdt.c > @@ -112,12 +112,6 @@ static const struct watchdog_info ixp4xx_wdt_info = { > .identity = KBUILD_MODNAME, > }; > > -/* Devres-handled clock disablement */ > -static void ixp4xx_clock_action(void *d) > -{ > - clk_disable_unprepare(d); > -} > - > static int ixp4xx_wdt_probe(struct platform_device *pdev) > { > struct device *dev = &pdev->dev; > @@ -139,16 +133,10 @@ static int ixp4xx_wdt_probe(struct platform_device *pdev) > * Retrieve rate from a fixed clock from the device tree if > * the parent has that, else use the default clock rate. > */ > - clk = devm_clk_get(dev->parent, NULL); > - if (!IS_ERR(clk)) { > - ret = clk_prepare_enable(clk); > - if (ret) > - return ret; > - ret = devm_add_action_or_reset(dev, ixp4xx_clock_action, clk); > - if (ret) > - return ret; > + clk = devm_clk_get_enabled(dev->parent, NULL); > + if (!IS_ERR(clk)) > iwdt->rate = clk_get_rate(clk); > - } > + > if (!iwdt->rate) > iwdt->rate = IXP4XX_TIMER_FREQ; >
diff --git a/drivers/watchdog/ixp4xx_wdt.c b/drivers/watchdog/ixp4xx_wdt.c index 281a48d9889f..607ce4b8df57 100644 --- a/drivers/watchdog/ixp4xx_wdt.c +++ b/drivers/watchdog/ixp4xx_wdt.c @@ -112,12 +112,6 @@ static const struct watchdog_info ixp4xx_wdt_info = { .identity = KBUILD_MODNAME, }; -/* Devres-handled clock disablement */ -static void ixp4xx_clock_action(void *d) -{ - clk_disable_unprepare(d); -} - static int ixp4xx_wdt_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; @@ -139,16 +133,10 @@ static int ixp4xx_wdt_probe(struct platform_device *pdev) * Retrieve rate from a fixed clock from the device tree if * the parent has that, else use the default clock rate. */ - clk = devm_clk_get(dev->parent, NULL); - if (!IS_ERR(clk)) { - ret = clk_prepare_enable(clk); - if (ret) - return ret; - ret = devm_add_action_or_reset(dev, ixp4xx_clock_action, clk); - if (ret) - return ret; + clk = devm_clk_get_enabled(dev->parent, NULL); + if (!IS_ERR(clk)) iwdt->rate = clk_get_rate(clk); - } + if (!iwdt->rate) iwdt->rate = IXP4XX_TIMER_FREQ;