diff mbox series

[v2,1/3] dt-bindings: rtc: pcf2127: Add bindings for nxp,pcf2127

Message ID 20200921054821.26071-1-qiang.zhao@nxp.com
State Changes Requested
Headers show
Series [v2,1/3] dt-bindings: rtc: pcf2127: Add bindings for nxp,pcf2127 | expand

Checks

Context Check Description
robh/dt-meta-schema success
robh/checkpatch warning total: 0 errors, 1 warnings, 41 lines checked

Commit Message

Qiang Zhao Sept. 21, 2020, 5:48 a.m. UTC
From: Zhao Qiang <qiang.zhao@nxp.com>

Add bindings for nxp,pcf2127

Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
---
Changes for v2:
 - modify the format to yaml
 - add compitable "nxp,pca2129"

 .../devicetree/bindings/rtc/nxp,pcf2127.yaml       | 41 ++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml

Comments

Alexandre Belloni Sept. 23, 2020, 9:44 a.m. UTC | #1
Hi,

You forgot to copy the watchdog maintainers, I think such a property
should be discussed with them.

Note that I'm still convinced this is not a complete solution, see:
https://lore.kernel.org/linux-rtc/20200716181816.GF3428@piout.net/

On 21/09/2020 13:48:19+0800, Qiang Zhao wrote:
> From: Zhao Qiang <qiang.zhao@nxp.com>
> 
> Add bindings for nxp,pcf2127
> 
> Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
> ---
> Changes for v2:
>  - modify the format to yaml
>  - add compitable "nxp,pca2129"
> 
>  .../devicetree/bindings/rtc/nxp,pcf2127.yaml       | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
> 
> diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
> new file mode 100644
> index 0000000..226a0b2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/nxp,pcf2127.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PCF RTCs
> +
> +maintainers:
> +  - Qiang Zhao <qiang.zhao@nxp.com>
> +
> +allOf:
> +  - $ref: "rtc.yaml#"
> +
> +properties:
> +  compatible:
> +    enum:
> +      - nxp,pcf2127
> +      - nxp,pcf2129
> +      - nxp,pca2129
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  no-watchdog:
> +    $ref: /schemas/types.yaml#/definitions/flag
> +    description:
> +      With this property, the device will not registered as a watchdog device.
> +
> +  start-year: true
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +...
> -- 
> 2.7.4
>
Qiang Zhao Sept. 24, 2020, 3:20 a.m. UTC | #2
On 21/09/2020 13:48:19+0800, Qiang Zhao wrote:

> -----Original Message-----
> From: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Sent: 2020年9月23日 17:45
> To: Qiang Zhao <qiang.zhao@nxp.com>
> Cc: Wim Van Sebroeck <wim@linux-watchdog.org>; Guenter Roeck
> <linux@roeck-us.net>; linux-watchdog@vger.kernel.org;
> a.zummo@towertech.it; robh+dt@kernel.org; linux-rtc@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de>
> Subject: Re: [Patch v2 1/3] dt-bindings: rtc: pcf2127: Add bindings for
> nxp,pcf2127
> 
> Hi,
> 
> You forgot to copy the watchdog maintainers, I think such a property should be
> discussed with them.
> 
> Note that I'm still convinced this is not a complete solution, see:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kern
> el.org%2Flinux-rtc%2F20200716181816.GF3428%40piout.net%2F&amp;data=
> 02%7C01%7Cqiang.zhao%40nxp.com%7Cb71f79a044b0493d6d4f08d85fa551c
> b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637364510931174
> 355&amp;sdata=%2BOxrzB8RIuxM9Let5slhfCVmMm6PMNoERDeHC9%2Fdxng
> %3D&amp;reserved=0
> 

Yes, you are right, There is not a fundamental solution.
However it somewhat avoid this situation at least.

And if without this issue, 
is it correct to register a rtc device as watchdog no matter it is used as watchdog on the board? 
Every time Linux are booted up, watchdog device should be configured to the right one manually.
So the patch are useful, even though it is not for the issue.

What should we do to really resolve this issue?

Best Regards
Qiang Zhao
Uwe Kleine-König Sept. 24, 2020, 7:04 a.m. UTC | #3
Hello,

On Thu, Sep 24, 2020 at 03:20:33AM +0000, Qiang Zhao wrote:
> On 21/09/2020 13:48:19+0800, Qiang Zhao wrote:
> 
> > -----Original Message-----
> > From: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Sent: 2020年9月23日 17:45
> > To: Qiang Zhao <qiang.zhao@nxp.com>
> > Cc: Wim Van Sebroeck <wim@linux-watchdog.org>; Guenter Roeck
> > <linux@roeck-us.net>; linux-watchdog@vger.kernel.org;
> > a.zummo@towertech.it; robh+dt@kernel.org; linux-rtc@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de>
> > Subject: Re: [Patch v2 1/3] dt-bindings: rtc: pcf2127: Add bindings for
> > nxp,pcf2127
> > 
> > Hi,
> > 
> > You forgot to copy the watchdog maintainers, I think such a property should be
> > discussed with them.
> > 
> > Note that I'm still convinced this is not a complete solution, see:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kern
> > el.org%2Flinux-rtc%2F20200716181816.GF3428%40piout.net%2F&amp;data=
> > 02%7C01%7Cqiang.zhao%40nxp.com%7Cb71f79a044b0493d6d4f08d85fa551c
> > b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637364510931174
> > 355&amp;sdata=%2BOxrzB8RIuxM9Let5slhfCVmMm6PMNoERDeHC9%2Fdxng
> > %3D&amp;reserved=0

haha

> Yes, you are right, There is not a fundamental solution.
> However it somewhat avoid this situation at least.
> 
> And if without this issue, 
> is it correct to register a rtc device as watchdog no matter it is used as watchdog on the board? 
> Every time Linux are booted up, watchdog device should be configured to the right one manually.
> So the patch are useful, even though it is not for the issue.
> 
> What should we do to really resolve this issue?

I still think we need a kernel solution here. I would expect that most
assembled pcf2127 chips are unable to act as a watchdog (i.e. don't have
the RST output connected to something that resets the machine).

So my favoured solution would be a positive property like:

	has-watchdog;

or something similar. In my eyes this is definitely something we want to
specify in the device tree because it is a relevant hardware property.
I consider it a bug to give a watchdog device to userspace that isn't
functional.

Best regards
Uwe
Qiang Zhao Sept. 24, 2020, 7:23 a.m. UTC | #4
On Thu, Sep 24, 2020 at 15:05AM +0000, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:

> -----Original Message-----
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Sent: 2020年9月24日 15:05
> To: Qiang Zhao <qiang.zhao@nxp.com>
> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>; Wim Van Sebroeck
> <wim@linux-watchdog.org>; Guenter Roeck <linux@roeck-us.net>;
> linux-watchdog@vger.kernel.org; a.zummo@towertech.it; robh+dt@kernel.org;
> linux-rtc@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; kernel@pengutronix.de
> Subject: Re: [Patch v2 1/3] dt-bindings: rtc: pcf2127: Add bindings for
> nxp,pcf2127
> 
> Hello,
> 
> On Thu, Sep 24, 2020 at 03:20:33AM +0000, Qiang Zhao wrote:
> > On 21/09/2020 13:48:19+0800, Qiang Zhao wrote:
> >
> > > -----Original Message-----
> > > From: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > Sent: 2020年9月23日 17:45
> > > To: Qiang Zhao <qiang.zhao@nxp.com>
> > > Cc: Wim Van Sebroeck <wim@linux-watchdog.org>; Guenter Roeck
> > > <linux@roeck-us.net>; linux-watchdog@vger.kernel.org;
> > > a.zummo@towertech.it; robh+dt@kernel.org; linux-rtc@vger.kernel.org;
> > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Uwe
> > > Kleine-König <u.kleine-koenig@pengutronix.de>
> > > Subject: Re: [Patch v2 1/3] dt-bindings: rtc: pcf2127: Add bindings
> > > for
> > > nxp,pcf2127
> > >
> > > Hi,
> > >
> > > You forgot to copy the watchdog maintainers, I think such a property
> > > should be discussed with them.
> > >
> > > Note that I'm still convinced this is not a complete solution, see:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > > re.kern
> > >
> el.org%2Flinux-rtc%2F20200716181816.GF3428%40piout.net%2F&amp;data=
> > >
> 02%7C01%7Cqiang.zhao%40nxp.com%7Cb71f79a044b0493d6d4f08d85fa551c
> > >
> b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637364510931174
> > >
> 355&amp;sdata=%2BOxrzB8RIuxM9Let5slhfCVmMm6PMNoERDeHC9%2Fdxng
> > > %3D&amp;reserved=0
> 
> haha
> 
> > Yes, you are right, There is not a fundamental solution.
> > However it somewhat avoid this situation at least.
> >
> > And if without this issue,
> > is it correct to register a rtc device as watchdog no matter it is used as
> watchdog on the board?
> > Every time Linux are booted up, watchdog device should be configured to the
> right one manually.
> > So the patch are useful, even though it is not for the issue.
> >
> > What should we do to really resolve this issue?
> 
> I still think we need a kernel solution here. I would expect that most assembled
> pcf2127 chips are unable to act as a watchdog (i.e. don't have the RST output
> connected to something that resets the machine).
> 
> So my favoured solution would be a positive property like:
> 
> 	has-watchdog;
> 
> or something similar. In my eyes this is definitely something we want to specify
> in the device tree because it is a relevant hardware property.
> I consider it a bug to give a watchdog device to userspace that isn't functional.
> 
> Best regards
> Uwe
 
I strongly agree with you! It should be positive property.
However, we couldn't identify which board are using pcf2127 as watchdog,
So we are unable to modify the boards' dts to correct (watchdog or not) in this patchset.

I noticed that only LS series platforms and imx6 have pcf2127 node, as far as I know, the LS platforms don't use it as watchdog,
But I am not sure about imx6

> 
> --
> Pengutronix e.K.                           | Uwe Kleine-König
> |
> Industrial Linux Solutions                 | https://www.pengutronix.de/ |
Best Regards
Qiang Zhao
Alexandre Belloni Sept. 24, 2020, 7:47 a.m. UTC | #5
Hi,

On 24/09/2020 07:23:18+0000, Qiang Zhao wrote:
> > > Yes, you are right, There is not a fundamental solution.
> > > However it somewhat avoid this situation at least.
> > >
> > > And if without this issue,
> > > is it correct to register a rtc device as watchdog no matter it is used as
> > watchdog on the board?
> > > Every time Linux are booted up, watchdog device should be configured to the
> > right one manually.
> > > So the patch are useful, even though it is not for the issue.
> > >
> > > What should we do to really resolve this issue?
> > 
> > I still think we need a kernel solution here. I would expect that most assembled
> > pcf2127 chips are unable to act as a watchdog (i.e. don't have the RST output
> > connected to something that resets the machine).
> > 
> > So my favoured solution would be a positive property like:
> > 
> > 	has-watchdog;
> > 
> > or something similar. In my eyes this is definitely something we want to specify
> > in the device tree because it is a relevant hardware property.
> > I consider it a bug to give a watchdog device to userspace that isn't functional.
> > 
> > Best regards
> > Uwe
>  
> I strongly agree with you! It should be positive property.
> However, we couldn't identify which board are using pcf2127 as watchdog,
> So we are unable to modify the boards' dts to correct (watchdog or not) in this patchset.
> 
> I noticed that only LS series platforms and imx6 have pcf2127 node, as far as I know, the LS platforms don't use it as watchdog,
> But I am not sure about imx6
> 

I don't think there is any user upstream and it is recent engouh that we
can probably make that a positive property.

Bruno, is it ok for you? you are the only know user of the feature.
Uwe Kleine-König Sept. 24, 2020, 10:52 a.m. UTC | #6
Hello,

now that there are two people stumbling over the pcf2127 driver
providing a non-functional watchdog device, here comes an RFC patch to
address this.

Note this is only compile tested and dt-documentation is still missing.
Still send this series because the cleanup is nice independent of this
discussion and to have something to argue about.

Does someone can offer a better name than "has-watchdog", is there a
scheme that could be used already that I'm not aware of?

Best regards
Uwe

Uwe Kleine-König (2):
  rtc: pcf2127: move watchdog initialisation to a separate function
  [RFC] rtc: pcf2127: only use watchdog when explicitly available

 drivers/rtc/rtc-pcf2127.c | 57 ++++++++++++++++++++++-----------------
 1 file changed, 32 insertions(+), 25 deletions(-)
Bruno Thomsen Sept. 24, 2020, 4:59 p.m. UTC | #7
Den tor. 24. sep. 2020 kl. 09.47 skrev Alexandre Belloni
<alexandre.belloni@bootlin.com>:
>
> Hi,
>
> On 24/09/2020 07:23:18+0000, Qiang Zhao wrote:
> > > > Yes, you are right, There is not a fundamental solution.
> > > > However it somewhat avoid this situation at least.
> > > >
> > > > And if without this issue,
> > > > is it correct to register a rtc device as watchdog no matter it is used as
> > > watchdog on the board?
> > > > Every time Linux are booted up, watchdog device should be configured to the
> > > right one manually.
> > > > So the patch are useful, even though it is not for the issue.
> > > >
> > > > What should we do to really resolve this issue?
> > >
> > > I still think we need a kernel solution here. I would expect that most assembled
> > > pcf2127 chips are unable to act as a watchdog (i.e. don't have the RST output
> > > connected to something that resets the machine).
> > >
> > > So my favoured solution would be a positive property like:
> > >
> > >     has-watchdog;
> > >
> > > or something similar. In my eyes this is definitely something we want to specify
> > > in the device tree because it is a relevant hardware property.
> > > I consider it a bug to give a watchdog device to userspace that isn't functional.
> > >
> > > Best regards
> > > Uwe
> >
> > I strongly agree with you! It should be positive property.
> > However, we couldn't identify which board are using pcf2127 as watchdog,
> > So we are unable to modify the boards' dts to correct (watchdog or not) in this patchset.
> >
> > I noticed that only LS series platforms and imx6 have pcf2127 node, as far as I know, the LS platforms don't use it as watchdog,
> > But I am not sure about imx6
> >
>
> I don't think there is any user upstream and it is recent engouh that we
> can probably make that a positive property.
>
> Bruno, is it ok for you? you are the only know user of the feature.

Hi

This seems like an okay solution to me.

I have a patch series on the way with a new product dts[1] that is
using the watchdog
feature in the pcf2127 chip.

I know that the watchdog feature is used by other products with
out-of-tree dts, but I
will make sure to give them a heads up.

/Bruno

[1] https://lore.kernel.org/linux-arm-kernel/20200923154024.11417-2-bruno.thomsen@gmail.com/
Bruno Thomsen Sept. 27, 2020, 7:50 a.m. UTC | #8
Den tor. 24. sep. 2020 kl. 12.53 skrev Uwe Kleine-König
<u.kleine-koenig@pengutronix.de>:
>
> The obvious advantages are:
>
>  - The linker can drop the watchdog functions if CONFIG_WATCHDOG is off.
>  - All watchdog stuff grouped together with only a single function call
>    left in generic code.
>  - Watchdog register is only read when it is actually used.
>  - Less #ifdefery
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
>  drivers/rtc/rtc-pcf2127.c | 56 ++++++++++++++++++++++-----------------
>  1 file changed, 31 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
> index ed6316992cbb..5b1f1949b5e5 100644
> --- a/drivers/rtc/rtc-pcf2127.c
> +++ b/drivers/rtc/rtc-pcf2127.c
> @@ -335,6 +335,36 @@ static const struct watchdog_ops pcf2127_watchdog_ops = {
>         .set_timeout = pcf2127_wdt_set_timeout,
>  };
>
> +static int pcf2127_watchdog_init(struct device *dev, struct pcf2127 *pcf2127)
> +{
> +       u32 wdd_timeout;
> +       int ret;
> +
> +       if (!IS_ENABLED(CONFIG_WATCHDOG))
> +               return 0;
> +
> +       pcf2127->wdd.parent = dev;
> +       pcf2127->wdd.info = &pcf2127_wdt_info;
> +       pcf2127->wdd.ops = &pcf2127_watchdog_ops;
> +       pcf2127->wdd.min_timeout = PCF2127_WD_VAL_MIN;
> +       pcf2127->wdd.max_timeout = PCF2127_WD_VAL_MAX;
> +       pcf2127->wdd.timeout = PCF2127_WD_VAL_DEFAULT;
> +       pcf2127->wdd.min_hw_heartbeat_ms = 500;
> +       pcf2127->wdd.status = WATCHDOG_NOWAYOUT_INIT_STATUS;
> +
> +       watchdog_set_drvdata(&pcf2127->wdd, pcf2127);
> +
> +       /* Test if watchdog timer is started by bootloader */
> +       ret = regmap_read(pcf2127->regmap, PCF2127_REG_WD_VAL, &wdd_timeout);
> +       if (ret)
> +               return ret;
> +
> +       if (wdd_timeout)
> +               set_bit(WDOG_HW_RUNNING, &pcf2127->wdd.status);
> +
> +       return devm_watchdog_register_device(dev, &pcf2127->wdd);
> +}
> +
>  /* Alarm */
>  static int pcf2127_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
>  {
> @@ -536,7 +566,6 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
>                          int alarm_irq, const char *name, bool has_nvmem)
>  {
>         struct pcf2127 *pcf2127;
> -       u32 wdd_timeout;
>         int ret = 0;
>
>         dev_dbg(dev, "%s\n", __func__);
> @@ -575,17 +604,6 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
>                 pcf2127->rtc->ops = &pcf2127_rtc_alrm_ops;
>         }
>
> -       pcf2127->wdd.parent = dev;
> -       pcf2127->wdd.info = &pcf2127_wdt_info;
> -       pcf2127->wdd.ops = &pcf2127_watchdog_ops;
> -       pcf2127->wdd.min_timeout = PCF2127_WD_VAL_MIN;
> -       pcf2127->wdd.max_timeout = PCF2127_WD_VAL_MAX;
> -       pcf2127->wdd.timeout = PCF2127_WD_VAL_DEFAULT;
> -       pcf2127->wdd.min_hw_heartbeat_ms = 500;
> -       pcf2127->wdd.status = WATCHDOG_NOWAYOUT_INIT_STATUS;
> -
> -       watchdog_set_drvdata(&pcf2127->wdd, pcf2127);
> -
>         if (has_nvmem) {
>                 struct nvmem_config nvmem_cfg = {
>                         .priv = pcf2127,
> @@ -615,19 +633,7 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
>                 return ret;
>         }
>
> -       /* Test if watchdog timer is started by bootloader */
> -       ret = regmap_read(pcf2127->regmap, PCF2127_REG_WD_VAL, &wdd_timeout);
> -       if (ret)
> -               return ret;
> -
> -       if (wdd_timeout)
> -               set_bit(WDOG_HW_RUNNING, &pcf2127->wdd.status);
> -
> -#ifdef CONFIG_WATCHDOG
> -       ret = devm_watchdog_register_device(dev, &pcf2127->wdd);
> -       if (ret)
> -               return ret;
> -#endif /* CONFIG_WATCHDOG */
> +       pcf2127_watchdog_init(dev, pcf2127);

The code refactoring seems like a good idea Uwe, but the new
pcf2127_watchdog_init() is not a void function. If the return
value is not handled, it will change driver behavior. Correct
handling should look like this:

ret = pcf2127_watchdog_init(dev, pcf2127);
if (ret)
        return ret;

/Bruno

>         /*
>          * Disable battery low/switch-over timestamp and interrupts.
> --
> 2.28.0
>
Bruno Thomsen Sept. 27, 2020, 8:09 a.m. UTC | #9
Den tor. 24. sep. 2020 kl. 12.53 skrev Uwe Kleine-König
<u.kleine-koenig@pengutronix.de>:
>
> Most boards using the pcf2127 chip (in my bubble) don't make use of the
> watchdog functionality and the respective output is not connected. The
> effect on such a board is that there is a watchdog device provided that
> doesn't work.
>
> So only register the watchdog if the device tree has a "has-watchdog"
> property.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
>  drivers/rtc/rtc-pcf2127.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
> index 5b1f1949b5e5..8bd89d641578 100644
> --- a/drivers/rtc/rtc-pcf2127.c
> +++ b/drivers/rtc/rtc-pcf2127.c
> @@ -340,7 +340,8 @@ static int pcf2127_watchdog_init(struct device *dev, struct pcf2127 *pcf2127)
>         u32 wdd_timeout;
>         int ret;
>
> -       if (!IS_ENABLED(CONFIG_WATCHDOG))
> +       if (!IS_ENABLED(CONFIG_WATCHDOG) ||
> +           !device_property_read_bool(dev, "has-watchdog"))
>                 return 0;

I don't think the compiler can remove the function if
CONFIG_WATCHDOG is disabled due to the device tree
value check. Maybe it can if split into 2 conditions.

if (!IS_ENABLED(CONFIG_WATCHDOG))
        return 0;
if (!device_property_read_bool(dev, "has-watchdog"))
        return 0;

/Bruno

>
>         pcf2127->wdd.parent = dev;
> --
> 2.28.0
>
Guenter Roeck Sept. 27, 2020, 3:54 p.m. UTC | #10
On 9/27/20 1:09 AM, Bruno Thomsen wrote:
> Den tor. 24. sep. 2020 kl. 12.53 skrev Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de>:
>>
>> Most boards using the pcf2127 chip (in my bubble) don't make use of the
>> watchdog functionality and the respective output is not connected. The
>> effect on such a board is that there is a watchdog device provided that
>> doesn't work.
>>
>> So only register the watchdog if the device tree has a "has-watchdog"
>> property.
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> ---
>>  drivers/rtc/rtc-pcf2127.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
>> index 5b1f1949b5e5..8bd89d641578 100644
>> --- a/drivers/rtc/rtc-pcf2127.c
>> +++ b/drivers/rtc/rtc-pcf2127.c
>> @@ -340,7 +340,8 @@ static int pcf2127_watchdog_init(struct device *dev, struct pcf2127 *pcf2127)
>>         u32 wdd_timeout;
>>         int ret;
>>
>> -       if (!IS_ENABLED(CONFIG_WATCHDOG))
>> +       if (!IS_ENABLED(CONFIG_WATCHDOG) ||
>> +           !device_property_read_bool(dev, "has-watchdog"))
>>                 return 0;
> 
> I don't think the compiler can remove the function if
> CONFIG_WATCHDOG is disabled due to the device tree
> value check. Maybe it can if split into 2 conditions.
> 

If the first part of the expression is always false, the second
part should not even be evaluated. Either case, the code now
hard depends on the compiler optimizing the code away.
It calls devm_watchdog_register_device() which doesn't exist
if CONFIG_WATCHDOG is not enabled. I didn't know that this is safe,
and I would personally not want to rely on it, but we live and
learn.

Guenter

> if (!IS_ENABLED(CONFIG_WATCHDOG))
>         return 0;
> if (!device_property_read_bool(dev, "has-watchdog"))
>         return 0;
> 
> /Bruno
> 
>>
>>         pcf2127->wdd.parent = dev;
>> --
>> 2.28.0
>>
Uwe Kleine-König Sept. 28, 2020, 8:43 a.m. UTC | #11
On Sun, Sep 27, 2020 at 08:54:47AM -0700, Guenter Roeck wrote:
> On 9/27/20 1:09 AM, Bruno Thomsen wrote:
> > Den tor. 24. sep. 2020 kl. 12.53 skrev Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de>:
> >>
> >> Most boards using the pcf2127 chip (in my bubble) don't make use of the
> >> watchdog functionality and the respective output is not connected. The
> >> effect on such a board is that there is a watchdog device provided that
> >> doesn't work.
> >>
> >> So only register the watchdog if the device tree has a "has-watchdog"
> >> property.
> >>
> >> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> >> ---
> >>  drivers/rtc/rtc-pcf2127.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
> >> index 5b1f1949b5e5..8bd89d641578 100644
> >> --- a/drivers/rtc/rtc-pcf2127.c
> >> +++ b/drivers/rtc/rtc-pcf2127.c
> >> @@ -340,7 +340,8 @@ static int pcf2127_watchdog_init(struct device *dev, struct pcf2127 *pcf2127)
> >>         u32 wdd_timeout;
> >>         int ret;
> >>
> >> -       if (!IS_ENABLED(CONFIG_WATCHDOG))
> >> +       if (!IS_ENABLED(CONFIG_WATCHDOG) ||
> >> +           !device_property_read_bool(dev, "has-watchdog"))
> >>                 return 0;
> > 
> > I don't think the compiler can remove the function if
> > CONFIG_WATCHDOG is disabled due to the device tree
> > value check. Maybe it can if split into 2 conditions.
> > 
> 
> If the first part of the expression is always false, the second
> part should not even be evaluated.

This is wrong. For || the second expression isn't evaluated if the first
evaluates to true (and the whole expression becomes true). This is the
intended behaviour: If CONFIG_WATCHDOG is off, we don't need to check
for the dt property and just skip the watchdog part.

> Either case, the code now hard depends on the compiler optimizing the
> code away.
> 
> It calls devm_watchdog_register_device() which doesn't exist
> if CONFIG_WATCHDOG is not enabled. I didn't know that this is safe,
> and I would personally not want to rely on it, but we live and
> learn.

AFAICT this is save and used in other places in the kernel, too.  This
is one of the reasons why you cannot compile the kernel with -O0.

Best regards
Uwe
Guenter Roeck Sept. 28, 2020, 4:26 p.m. UTC | #12
On Mon, Sep 28, 2020 at 10:43:43AM +0200, Uwe Kleine-König wrote:
> On Sun, Sep 27, 2020 at 08:54:47AM -0700, Guenter Roeck wrote:
> > On 9/27/20 1:09 AM, Bruno Thomsen wrote:
> > > Den tor. 24. sep. 2020 kl. 12.53 skrev Uwe Kleine-König
> > > <u.kleine-koenig@pengutronix.de>:
> > >>
> > >> Most boards using the pcf2127 chip (in my bubble) don't make use of the
> > >> watchdog functionality and the respective output is not connected. The
> > >> effect on such a board is that there is a watchdog device provided that
> > >> doesn't work.
> > >>
> > >> So only register the watchdog if the device tree has a "has-watchdog"
> > >> property.
> > >>
> > >> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > >> ---
> > >>  drivers/rtc/rtc-pcf2127.c | 3 ++-
> > >>  1 file changed, 2 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
> > >> index 5b1f1949b5e5..8bd89d641578 100644
> > >> --- a/drivers/rtc/rtc-pcf2127.c
> > >> +++ b/drivers/rtc/rtc-pcf2127.c
> > >> @@ -340,7 +340,8 @@ static int pcf2127_watchdog_init(struct device *dev, struct pcf2127 *pcf2127)
> > >>         u32 wdd_timeout;
> > >>         int ret;
> > >>
> > >> -       if (!IS_ENABLED(CONFIG_WATCHDOG))
> > >> +       if (!IS_ENABLED(CONFIG_WATCHDOG) ||
> > >> +           !device_property_read_bool(dev, "has-watchdog"))
> > >>                 return 0;
> > > 
> > > I don't think the compiler can remove the function if
> > > CONFIG_WATCHDOG is disabled due to the device tree
> > > value check. Maybe it can if split into 2 conditions.
> > > 
> > 
> > If the first part of the expression is always false, the second
> > part should not even be evaluated.
> 
> This is wrong. For || the second expression isn't evaluated if the first
> evaluates to true (and the whole expression becomes true). This is the
> intended behaviour: If CONFIG_WATCHDOG is off, we don't need to check
> for the dt property and just skip the watchdog part.
> 
Sorry, I meant to say "If the first part of the expression is always true".

Guenter

> > Either case, the code now hard depends on the compiler optimizing the
> > code away.
> > 
> > It calls devm_watchdog_register_device() which doesn't exist
> > if CONFIG_WATCHDOG is not enabled. I didn't know that this is safe,
> > and I would personally not want to rely on it, but we live and
> > learn.
> 
> AFAICT this is save and used in other places in the kernel, too.  This
> is one of the reasons why you cannot compile the kernel with -O0.
> 
> Best regards
> Uwe
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-König            |
> Industrial Linux Solutions                 | https://www.pengutronix.de/ |
Qiang Zhao Oct. 26, 2020, 7:23 a.m. UTC | #13
Any update for this patchset?

Best Regards
Qiang Zhao

> -----Original Message-----
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Sent: 2020年9月24日 18:53
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Qiang Zhao
> <qiang.zhao@nxp.com>; Bruno Thomsen <bruno.thomsen@gmail.com>
> Cc: linux-rtc@vger.kernel.org; a.zummo@towertech.it;
> linux-watchdog@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; robh+dt@kernel.org; kernel@pengutronix.de;
> Wim Van Sebroeck <wim@linux-watchdog.org>; Guenter Roeck
> <linux@roeck-us.net>
> Subject: [PATCH 0/2] rtc: pcf2127: only use watchdog when explicitly available
> 
> Hello,
> 
> now that there are two people stumbling over the pcf2127 driver providing a
> non-functional watchdog device, here comes an RFC patch to address this.
> 
> Note this is only compile tested and dt-documentation is still missing.
> Still send this series because the cleanup is nice independent of this discussion
> and to have something to argue about.
> 
> Does someone can offer a better name than "has-watchdog", is there a scheme
> that could be used already that I'm not aware of?
> 
> Best regards
> Uwe
> 
> Uwe Kleine-König (2):
>   rtc: pcf2127: move watchdog initialisation to a separate function
>   [RFC] rtc: pcf2127: only use watchdog when explicitly available
> 
>  drivers/rtc/rtc-pcf2127.c | 57 ++++++++++++++++++++++-----------------
>  1 file changed, 32 insertions(+), 25 deletions(-)
> 
> --
> 2.28.0
Alexandre Belloni Oct. 26, 2020, 8:48 p.m. UTC | #14
On 26/10/2020 07:23:26+0000, Qiang Zhao wrote:
> Any update for this patchset?
> 

The whole point would be to get the DT and the watchdog maintainers
agree on the property name. Once done, the driver implementation is
trivial and will get applied.

> Best Regards
> Qiang Zhao
> 
> > -----Original Message-----
> > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > Sent: 2020年9月24日 18:53
> > To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Qiang Zhao
> > <qiang.zhao@nxp.com>; Bruno Thomsen <bruno.thomsen@gmail.com>
> > Cc: linux-rtc@vger.kernel.org; a.zummo@towertech.it;
> > linux-watchdog@vger.kernel.org; devicetree@vger.kernel.org;
> > linux-kernel@vger.kernel.org; robh+dt@kernel.org; kernel@pengutronix.de;
> > Wim Van Sebroeck <wim@linux-watchdog.org>; Guenter Roeck
> > <linux@roeck-us.net>
> > Subject: [PATCH 0/2] rtc: pcf2127: only use watchdog when explicitly available
> > 
> > Hello,
> > 
> > now that there are two people stumbling over the pcf2127 driver providing a
> > non-functional watchdog device, here comes an RFC patch to address this.
> > 
> > Note this is only compile tested and dt-documentation is still missing.
> > Still send this series because the cleanup is nice independent of this discussion
> > and to have something to argue about.
> > 
> > Does someone can offer a better name than "has-watchdog", is there a scheme
> > that could be used already that I'm not aware of?
> > 
> > Best regards
> > Uwe
> > 
> > Uwe Kleine-König (2):
> >   rtc: pcf2127: move watchdog initialisation to a separate function
> >   [RFC] rtc: pcf2127: only use watchdog when explicitly available
> > 
> >  drivers/rtc/rtc-pcf2127.c | 57 ++++++++++++++++++++++-----------------
> >  1 file changed, 32 insertions(+), 25 deletions(-)
> > 
> > --
> > 2.28.0
>
Guenter Roeck Oct. 26, 2020, 9:29 p.m. UTC | #15
On Mon, Oct 26, 2020 at 09:48:11PM +0100, Alexandre Belloni wrote:
> On 26/10/2020 07:23:26+0000, Qiang Zhao wrote:
> > Any update for this patchset?
> > 
> 
> The whole point would be to get the DT and the watchdog maintainers
> agree on the property name. Once done, the driver implementation is
> trivial and will get applied.
> 

DT maintainers make that decision.

Guenter

> > Best Regards
> > Qiang Zhao
> > 
> > > -----Original Message-----
> > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > Sent: 2020年9月24日 18:53
> > > To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Qiang Zhao
> > > <qiang.zhao@nxp.com>; Bruno Thomsen <bruno.thomsen@gmail.com>
> > > Cc: linux-rtc@vger.kernel.org; a.zummo@towertech.it;
> > > linux-watchdog@vger.kernel.org; devicetree@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; robh+dt@kernel.org; kernel@pengutronix.de;
> > > Wim Van Sebroeck <wim@linux-watchdog.org>; Guenter Roeck
> > > <linux@roeck-us.net>
> > > Subject: [PATCH 0/2] rtc: pcf2127: only use watchdog when explicitly available
> > > 
> > > Hello,
> > > 
> > > now that there are two people stumbling over the pcf2127 driver providing a
> > > non-functional watchdog device, here comes an RFC patch to address this.
> > > 
> > > Note this is only compile tested and dt-documentation is still missing.
> > > Still send this series because the cleanup is nice independent of this discussion
> > > and to have something to argue about.
> > > 
> > > Does someone can offer a better name than "has-watchdog", is there a scheme
> > > that could be used already that I'm not aware of?
> > > 
> > > Best regards
> > > Uwe
> > > 
> > > Uwe Kleine-König (2):
> > >   rtc: pcf2127: move watchdog initialisation to a separate function
> > >   [RFC] rtc: pcf2127: only use watchdog when explicitly available
> > > 
> > >  drivers/rtc/rtc-pcf2127.c | 57 ++++++++++++++++++++++-----------------
> > >  1 file changed, 32 insertions(+), 25 deletions(-)
> > > 
> > > --
> > > 2.28.0
> > 
> 
> -- 
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Rasmus Villemoes Nov. 30, 2020, 9:51 a.m. UTC | #16
On 24/09/2020 12.52, Uwe Kleine-König wrote:
> Hello,
> 
> now that there are two people stumbling over the pcf2127 driver
> providing a non-functional watchdog device, here comes an RFC patch to
> address this.

I just want to add a "me too" here, as I'm also now affected by the
pcf2127 exposing a watchdog device (1) it didn't use to (affecting what
/dev/watchdog0 means) and (2) is not actually hooked up in hardware.

So can we please move forward with adding the has-watchdog opt-in DT
property so existing boards will not be affected?

Thanks,
Rasmus
Alexandre Belloni Dec. 4, 2020, 9:27 a.m. UTC | #17
On 30/11/2020 10:51:41+0100, Rasmus Villemoes wrote:
> On 24/09/2020 12.52, Uwe Kleine-König wrote:
> > Hello,
> > 
> > now that there are two people stumbling over the pcf2127 driver
> > providing a non-functional watchdog device, here comes an RFC patch to
> > address this.
> 
> I just want to add a "me too" here, as I'm also now affected by the
> pcf2127 exposing a watchdog device (1) it didn't use to (affecting what
> /dev/watchdog0 means) and (2) is not actually hooked up in hardware.
> 
> So can we please move forward with adding the has-watchdog opt-in DT
> property so existing boards will not be affected?
> 

Well, someone has to get that property reviewed by Rob. Maybe this could
be reset-source as we have wakeup-source.
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
new file mode 100644
index 0000000..226a0b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
@@ -0,0 +1,41 @@ 
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nxp,pcf2127.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PCF RTCs
+
+maintainers:
+  - Qiang Zhao <qiang.zhao@nxp.com>
+
+allOf:
+  - $ref: "rtc.yaml#"
+
+properties:
+  compatible:
+    enum:
+      - nxp,pcf2127
+      - nxp,pcf2129
+      - nxp,pca2129
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  no-watchdog:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      With this property, the device will not registered as a watchdog device.
+
+  start-year: true
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+...