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

[permalink] [raw]

Subject: [Patch v2 2/3] rtc: pcf2127: add "no-watchdog" property

From: Zhao Qiang <[email protected]>

Commit 0e735eaae165 ("rtc: pcf2127: add watchdog feature support")
adds watchdog feature for pcf2127, then it will be registered as
a watchdog device even though it is not used as watchdog.
Pcf2127 always be registered as watchdog0(default watchdog device),
even though it is not used as watchdog, meanwhile there is another
real watchdog device registered as watchdog1.
So add "no-watchdog" property, if the node has this property,
driver will not register it as a watchdog device

Signed-off-by: Zhao Qiang <[email protected]>
---
drivers/rtc/rtc-pcf2127.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index ed63169..b50158a 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -624,9 +624,11 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
set_bit(WDOG_HW_RUNNING, &pcf2127->wdd.status);

#ifdef CONFIG_WATCHDOG
- ret = devm_watchdog_register_device(dev, &pcf2127->wdd);
- if (ret)
- return ret;
+ if (!of_property_read_bool(dev->of_node, "no-watchdog")) {
+ ret = devm_watchdog_register_device(dev, &pcf2127->wdd);
+ if (ret)
+ return ret;
+ }
#endif /* CONFIG_WATCHDOG */

/*
--
2.7.4

2020-09-23 09:46:19

[permalink] [raw]

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://lore.kernel.org/linux-rtc/[email protected]/

On 21/09/2020 13:48:19+0800, Qiang Zhao wrote:
> From: Zhao Qiang <[email protected]>
>
> Add bindings for nxp,pcf2127
>
> Signed-off-by: Zhao Qiang <[email protected]>
> ---
> 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 <[email protected]>
> +
> +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
>

--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

2020-09-24 03:21:52

[permalink] [raw]

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

On 21/09/2020 13:48:19+0800, Qiang Zhao wrote:

> -----Original Message-----
> From: Alexandre Belloni <[email protected]>
> Sent: 2020年9月23日 17:45
> To: Qiang Zhao <[email protected]>
> Cc: Wim Van Sebroeck <[email protected]>; Guenter Roeck
> <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Uwe Kleine-König
> <[email protected]>
> 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&data=
> 02%7C01%7Cqiang.zhao%40nxp.com%7Cb71f79a044b0493d6d4f08d85fa551c
> b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637364510931174
> 355&sdata=%2BOxrzB8RIuxM9Let5slhfCVmMm6PMNoERDeHC9%2Fdxng
> %3D&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

2020-09-24 07:06:59

[permalink] [raw]

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 <[email protected]>
> > Sent: 2020年9月23日 17:45
> > To: Qiang Zhao <[email protected]>
> > Cc: Wim Van Sebroeck <[email protected]>; Guenter Roeck
> > <[email protected]>; [email protected];
> > [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; Uwe Kleine-König
> > <[email protected]>
> > 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&data=
> > 02%7C01%7Cqiang.zhao%40nxp.com%7Cb71f79a044b0493d6d4f08d85fa551c
> > b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637364510931174
> > 355&sdata=%2BOxrzB8RIuxM9Let5slhfCVmMm6PMNoERDeHC9%2Fdxng
> > %3D&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

--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |

Attachments:

(No filename) (2.43 kB)
signature.asc (499.00 B)
Download all attachments

2020-09-24 07:24:47

[permalink] [raw]

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

On Thu, Sep 24, 2020 at 15:05AM +0000, Uwe Kleine-König <[email protected]> wrote:

> -----Original Message-----
> From: Uwe Kleine-König <[email protected]>
> Sent: 2020年9月24日 15:05
> To: Qiang Zhao <[email protected]>
> Cc: Alexandre Belloni <[email protected]>; Wim Van Sebroeck
> <[email protected]>; Guenter Roeck <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]
> 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 <[email protected]>
> > > Sent: 2020年9月23日 17:45
> > > To: Qiang Zhao <[email protected]>
> > > Cc: Wim Van Sebroeck <[email protected]>; Guenter Roeck
> > > <[email protected]>; [email protected];
> > > [email protected]; [email protected]; [email protected];
> > > [email protected]; [email protected]; Uwe
> > > Kleine-König <[email protected]>
> > > 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&data=
> > >
> 02%7C01%7Cqiang.zhao%40nxp.com%7Cb71f79a044b0493d6d4f08d85fa551c
> > >
> b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637364510931174
> > >
> 355&sdata=%2BOxrzB8RIuxM9Let5slhfCVmMm6PMNoERDeHC9%2Fdxng
> > > %3D&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

2020-09-24 07:48:58

[permalink] [raw]

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

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.

--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

2020-09-24 10:56:37

[permalink] [raw]

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

2020-09-24 10:57:45

[permalink] [raw]

Subject: [PATCH 1/2] rtc: pcf2127: move watchdog initialisation to a separate function

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 <[email protected]>
---
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);

/*
* Disable battery low/switch-over timestamp and interrupts.
--
2.28.0

2020-09-24 17:01:31

by Bruno Thomsen

[permalink] [raw]

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

Den tor. 24. sep. 2020 kl. 09.47 skrev Alexandre Belloni
<[email protected]>:
>
> 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/[email protected]/

2020-09-27 07:54:21

by Bruno Thomsen

[permalink] [raw]

Subject: Re: [PATCH 1/2] rtc: pcf2127: move watchdog initialisation to a separate function

Den tor. 24. sep. 2020 kl. 12.53 skrev Uwe Kleine-König
<[email protected]>:
>
> 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 <[email protected]>
> ---
> 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
>

2020-10-26 08:20:52

[permalink] [raw]

Subject: RE: [PATCH 0/2] rtc: pcf2127: only use watchdog when explicitly available

Any update for this patchset?

Best Regards
Qiang Zhao

> -----Original Message-----
> From: Uwe Kleine-König <[email protected]>
> Sent: 2020年9月24日 18:53
> To: Alexandre Belloni <[email protected]>; Qiang Zhao
> <[email protected]>; Bruno Thomsen <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> Wim Van Sebroeck <[email protected]>; Guenter Roeck
> <[email protected]>
> 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

2020-10-27 00:04:43

by Guenter Roeck

[permalink] [raw]

Subject: Re: [PATCH 0/2] rtc: pcf2127: only use watchdog when explicitly available

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 <[email protected]>
> > > Sent: 2020年9月24日 18:53
> > > To: Alexandre Belloni <[email protected]>; Qiang Zhao
> > > <[email protected]>; Bruno Thomsen <[email protected]>
> > > Cc: [email protected]; [email protected];
> > > [email protected]; [email protected];
> > > [email protected]; [email protected]; [email protected];
> > > Wim Van Sebroeck <[email protected]>; Guenter Roeck
> > > <[email protected]>
> > > 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

2020-10-27 06:58:34

[permalink] [raw]

Subject: Re: [PATCH 0/2] rtc: pcf2127: only use watchdog when explicitly available

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 <[email protected]>
> > Sent: 2020年9月24日 18:53
> > To: Alexandre Belloni <[email protected]>; Qiang Zhao
> > <[email protected]>; Bruno Thomsen <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected];
> > Wim Van Sebroeck <[email protected]>; Guenter Roeck
> > <[email protected]>
> > 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

2020-11-30 09:56:01

[permalink] [raw]

Subject: Re: [PATCH 0/2] rtc: pcf2127: only use watchdog when explicitly available

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

2020-12-04 09:33:31

[permalink] [raw]

Subject: Re: [PATCH 0/2] rtc: pcf2127: only use watchdog when explicitly available

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.

--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

2020-12-13 03:54:52

[permalink] [raw]

Subject: [PATCH v2 0/3] add reset-source RTC binding, update pcf2127 driver

This is a resend of Uwe's pcf2127 patches, prepended by a dt-binding
patch adding a reset-source property, as suggested by Alexandre.

Rasmus Villemoes (1):
dt-bindings: rtc: add reset-source property

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

.../devicetree/bindings/rtc/rtc.yaml | 5 ++
drivers/rtc/rtc-pcf2127.c | 55 +++++++++++--------
2 files changed, 37 insertions(+), 23 deletions(-)

--
2.23.0

2020-12-13 03:55:51

[permalink] [raw]

Subject: [PATCH v2 2/3] rtc: pcf2127: move watchdog initialisation to a separate function

From: Uwe Kleine-König <[email protected]>

The obvious advantages are:

- The compiler 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 <[email protected]>
[RV: check return value of pcf2127_watchdog_init(), per Bruno]
Signed-off-by: Rasmus Villemoes <[email protected]>
---
drivers/rtc/rtc-pcf2127.c | 54 ++++++++++++++++++++++-----------------
1 file changed, 31 insertions(+), 23 deletions(-)

diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index 07a5630ec841..aebf85fcc328 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,9 @@ 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);
+ ret = pcf2127_watchdog_init(dev, pcf2127);
if (ret)
return ret;
-#endif /* CONFIG_WATCHDOG */

/*
* Disable battery low/switch-over timestamp and interrupts.
--
2.23.0

2020-12-13 03:56:10

[permalink] [raw]

Subject: [PATCH v2 3/3] rtc: pcf2127: only use watchdog when explicitly available

From: Uwe Kleine-König <[email protected]>

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 "reset-source"
property.

Signed-off-by: Uwe Kleine-König <[email protected]>
[RV: s/has-watchdog/reset-source/]
Signed-off-by: Rasmus Villemoes <[email protected]>
---
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 aebf85fcc328..f3d4eac4f230 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, "reset-source"))
return 0;

pcf2127->wdd.parent = dev;
--
2.23.0

2020-12-13 03:58:07

[permalink] [raw]

Subject: [PATCH v2 1/3] dt-bindings: rtc: add reset-source property

Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
if the reset pin is not actually wired up, the driver exposes a
watchdog device that doesn't actually work.

Provide a standard binding that can be used to indicate that a given
RTC can perform a reset of the machine, similar to wakeup-source.

Suggested-by: Alexandre Belloni <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
---
Documentation/devicetree/bindings/rtc/rtc.yaml | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml
index ee237b2ed66a..b5e24dc24b0b 100644
--- a/Documentation/devicetree/bindings/rtc/rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/rtc.yaml
@@ -47,4 +47,9 @@ properties:
description:
Enables wake up of host system on alarm.

+ reset-source:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The RTC is able to reset the machine.
+
...
--
2.23.0

2020-12-13 05:19:23

[permalink] [raw]

Subject: Re: [PATCH v2 1/3] dt-bindings: rtc: add reset-source property

On Fri, Dec 11, 2020 at 3:56 PM Rasmus Villemoes
<[email protected]> wrote:
>
> Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
> if the reset pin is not actually wired up, the driver exposes a
> watchdog device that doesn't actually work.
>
> Provide a standard binding that can be used to indicate that a given
> RTC can perform a reset of the machine, similar to wakeup-source.

Why not use the watchdog 'timeout-sec' property?

Please send DT patches to the DT list.

>
> Suggested-by: Alexandre Belloni <[email protected]>
> Signed-off-by: Rasmus Villemoes <[email protected]>
> ---
> Documentation/devicetree/bindings/rtc/rtc.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml
> index ee237b2ed66a..b5e24dc24b0b 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/rtc.yaml
> @@ -47,4 +47,9 @@ properties:
> description:
> Enables wake up of host system on alarm.
>
> + reset-source:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + The RTC is able to reset the machine.
> +
> ...
> --
> 2.23.0
>

2020-12-13 05:43:56

[permalink] [raw]

Subject: Re: [PATCH v2 1/3] dt-bindings: rtc: add reset-source property

On 11/12/2020 23.30, Rob Herring wrote:
> On Fri, Dec 11, 2020 at 3:56 PM Rasmus Villemoes
> <[email protected]> wrote:
>>
>> Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
>> if the reset pin is not actually wired up, the driver exposes a
>> watchdog device that doesn't actually work.
>>
>> Provide a standard binding that can be used to indicate that a given
>> RTC can perform a reset of the machine, similar to wakeup-source.
>
> Why not use the watchdog 'timeout-sec' property?

Wouldn't that be overloading that property? AFAIU, that is used to ask
the kernel to program an initial timeout value into the watchdog device.
But what if one doesn't want to start the watchdog device at kernel
boot, but just indicate that the RTC has that capability?

It's quite possible that if it can act as a watchdog device (and
has-watchdog was also suggested), one would also want timeout-sec and
other watchdog bindings to apply. But that can be added later, by those
who actually want that.

For now, I'd really like to get my board booting again (or rather, not
get reset by the real watchdog just because the pcf2127 driver now
exposes something as /dev/wathdog0, pushing the real one to
/dev/wathcdog1 which doesn't get pinged from userspace).

Rasmus

2020-12-13 14:28:04

[permalink] [raw]

Subject: Re: [PATCH v2 1/3] dt-bindings: rtc: add reset-source property

On Fri, Dec 11, 2020 at 10:56:09PM +0100, Rasmus Villemoes wrote:
> Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
> if the reset pin is not actually wired up, the driver exposes a
> watchdog device that doesn't actually work.
>
> Provide a standard binding that can be used to indicate that a given
> RTC can perform a reset of the machine, similar to wakeup-source.
>
> Suggested-by: Alexandre Belloni <[email protected]>
> Signed-off-by: Rasmus Villemoes <[email protected]>
> ---
> Documentation/devicetree/bindings/rtc/rtc.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml
> index ee237b2ed66a..b5e24dc24b0b 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/rtc.yaml
> @@ -47,4 +47,9 @@ properties:
> description:
> Enables wake up of host system on alarm.
>
> + reset-source:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + The RTC is able to reset the machine.

Thanks for picking that up.

Acked-by: Uwe Kleine-K?nig <[email protected]>

Note that the patch "rtc: pcf2127: move watchdog initialisation to a
separate function" is already in next.

Best regards
Uwe

--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |

Attachments:

(No filename) (1.51 kB)
signature.asc (499.00 B)
Download all attachments

2020-12-17 16:55:21

[permalink] [raw]

Subject: Re: [PATCH v2 1/3] dt-bindings: rtc: add reset-source property

On Fri, Dec 11, 2020 at 5:10 PM Rasmus Villemoes
<[email protected]> wrote:
>
> On 11/12/2020 23.30, Rob Herring wrote:
> > On Fri, Dec 11, 2020 at 3:56 PM Rasmus Villemoes
> > <[email protected]> wrote:
> >>
> >> Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
> >> if the reset pin is not actually wired up, the driver exposes a
> >> watchdog device that doesn't actually work.
> >>
> >> Provide a standard binding that can be used to indicate that a given
> >> RTC can perform a reset of the machine, similar to wakeup-source.
> >
> > Why not use the watchdog 'timeout-sec' property?
>
> Wouldn't that be overloading that property? AFAIU, that is used to ask
> the kernel to program an initial timeout value into the watchdog device.
> But what if one doesn't want to start the watchdog device at kernel
> boot, but just indicate that the RTC has that capability?

Yeah, I guess you're right.

> It's quite possible that if it can act as a watchdog device (and
> has-watchdog was also suggested), one would also want timeout-sec and
> other watchdog bindings to apply. But that can be added later, by those
> who actually want that.
>
> For now, I'd really like to get my board booting again (or rather, not
> get reset by the real watchdog just because the pcf2127 driver now
> exposes something as /dev/wathdog0, pushing the real one to
> /dev/wathcdog1 which doesn't get pinged from userspace).

I'm wondering how you solve which wdog to ping when there are multiple
without relying on numbering. I guess 'reset-source' will solve that
even if that's not your current fix. So I guess I'm fine with this.

But you need to send to the DT list so checks are run.

Rob

2020-12-17 18:14:45

[permalink] [raw]

Subject: Re: [PATCH v2 1/3] dt-bindings: rtc: add reset-source property

On Thu, Dec 17, 2020 at 10:51:08AM -0600, Rob Herring wrote:
> On Fri, Dec 11, 2020 at 5:10 PM Rasmus Villemoes
> <[email protected]> wrote:
> >
> > On 11/12/2020 23.30, Rob Herring wrote:
> > > On Fri, Dec 11, 2020 at 3:56 PM Rasmus Villemoes
> > > <[email protected]> wrote:
> > >>
> > >> Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
> > >> if the reset pin is not actually wired up, the driver exposes a
> > >> watchdog device that doesn't actually work.
> > >>
> > >> Provide a standard binding that can be used to indicate that a given
> > >> RTC can perform a reset of the machine, similar to wakeup-source.
> > >
> > > Why not use the watchdog 'timeout-sec' property?
> >
> > Wouldn't that be overloading that property? AFAIU, that is used to ask
> > the kernel to program an initial timeout value into the watchdog device.
> > But what if one doesn't want to start the watchdog device at kernel
> > boot, but just indicate that the RTC has that capability?
>
> Yeah, I guess you're right.

I agree, too. The initial suggestion looks fine.

> > It's quite possible that if it can act as a watchdog device (and
> > has-watchdog was also suggested), one would also want timeout-sec and
> > other watchdog bindings to apply. But that can be added later, by those
> > who actually want that.
> >
> > For now, I'd really like to get my board booting again (or rather, not
> > get reset by the real watchdog just because the pcf2127 driver now
> > exposes something as /dev/wathdog0, pushing the real one to
> > /dev/wathcdog1 which doesn't get pinged from userspace).
>
> I'm wondering how you solve which wdog to ping when there are multiple
> without relying on numbering. I guess 'reset-source' will solve that
> even if that's not your current fix. So I guess I'm fine with this.

I guess you'd need some udev magic that ensures that the right watchdog
always gets the same number.

Best regards
Uwe

--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |

Attachments:

(No filename) (2.10 kB)
signature.asc (499.00 B)
Download all attachments

2020-12-17 19:05:59

[permalink] [raw]

Subject: Re: [PATCH v2 1/3] dt-bindings: rtc: add reset-source property

On Thu, Dec 17, 2020 at 12:12 PM Uwe Kleine-König
<[email protected]> wrote:
>
> On Thu, Dec 17, 2020 at 10:51:08AM -0600, Rob Herring wrote:
> > On Fri, Dec 11, 2020 at 5:10 PM Rasmus Villemoes
> > <[email protected]> wrote:
> > >
> > > On 11/12/2020 23.30, Rob Herring wrote:
> > > > On Fri, Dec 11, 2020 at 3:56 PM Rasmus Villemoes
> > > > <[email protected]> wrote:
> > > >>
> > > >> Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
> > > >> if the reset pin is not actually wired up, the driver exposes a
> > > >> watchdog device that doesn't actually work.
> > > >>
> > > >> Provide a standard binding that can be used to indicate that a given
> > > >> RTC can perform a reset of the machine, similar to wakeup-source.
> > > >
> > > > Why not use the watchdog 'timeout-sec' property?
> > >
> > > Wouldn't that be overloading that property? AFAIU, that is used to ask
> > > the kernel to program an initial timeout value into the watchdog device.
> > > But what if one doesn't want to start the watchdog device at kernel
> > > boot, but just indicate that the RTC has that capability?
> >
> > Yeah, I guess you're right.
>
> I agree, too. The initial suggestion looks fine.
>
> > > It's quite possible that if it can act as a watchdog device (and
> > > has-watchdog was also suggested), one would also want timeout-sec and
> > > other watchdog bindings to apply. But that can be added later, by those
> > > who actually want that.
> > >
> > > For now, I'd really like to get my board booting again (or rather, not
> > > get reset by the real watchdog just because the pcf2127 driver now
> > > exposes something as /dev/wathdog0, pushing the real one to
> > > /dev/wathcdog1 which doesn't get pinged from userspace).
> >
> > I'm wondering how you solve which wdog to ping when there are multiple
> > without relying on numbering. I guess 'reset-source' will solve that
> > even if that's not your current fix. So I guess I'm fine with this.
>
> I guess you'd need some udev magic that ensures that the right watchdog
> always gets the same number.

Why involve udev and keep the magic numbering important? Provide
enough details on watchdogs' features so an intelligent decision can
be made. It's the same thing every time folks try to number things in
DT.

Rob

2020-12-17 20:30:13

[permalink] [raw]

Subject: Re: [PATCH v2 1/3] dt-bindings: rtc: add reset-source property

On Thu, Dec 17, 2020 at 01:02:32PM -0600, Rob Herring wrote:
> On Thu, Dec 17, 2020 at 12:12 PM Uwe Kleine-K?nig
> <[email protected]> wrote:
> >
> > On Thu, Dec 17, 2020 at 10:51:08AM -0600, Rob Herring wrote:
> > > On Fri, Dec 11, 2020 at 5:10 PM Rasmus Villemoes
> > > <[email protected]> wrote:
> > > >
> > > > On 11/12/2020 23.30, Rob Herring wrote:
> > > > > On Fri, Dec 11, 2020 at 3:56 PM Rasmus Villemoes
> > > > > <[email protected]> wrote:
> > > > >>
> > > > >> Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
> > > > >> if the reset pin is not actually wired up, the driver exposes a
> > > > >> watchdog device that doesn't actually work.
> > > > >>
> > > > >> Provide a standard binding that can be used to indicate that a given
> > > > >> RTC can perform a reset of the machine, similar to wakeup-source.
> > > > >
> > > > > Why not use the watchdog 'timeout-sec' property?
> > > >
> > > > Wouldn't that be overloading that property? AFAIU, that is used to ask
> > > > the kernel to program an initial timeout value into the watchdog device.
> > > > But what if one doesn't want to start the watchdog device at kernel
> > > > boot, but just indicate that the RTC has that capability?
> > >
> > > Yeah, I guess you're right.
> >
> > I agree, too. The initial suggestion looks fine.
> >
> > > > It's quite possible that if it can act as a watchdog device (and
> > > > has-watchdog was also suggested), one would also want timeout-sec and
> > > > other watchdog bindings to apply. But that can be added later, by those
> > > > who actually want that.
> > > >
> > > > For now, I'd really like to get my board booting again (or rather, not
> > > > get reset by the real watchdog just because the pcf2127 driver now
> > > > exposes something as /dev/wathdog0, pushing the real one to
> > > > /dev/wathcdog1 which doesn't get pinged from userspace).
> > >
> > > I'm wondering how you solve which wdog to ping when there are multiple
> > > without relying on numbering. I guess 'reset-source' will solve that
> > > even if that's not your current fix. So I guess I'm fine with this.
> >
> > I guess you'd need some udev magic that ensures that the right watchdog
> > always gets the same number.
>
> Why involve udev and keep the magic numbering important? Provide
> enough details on watchdogs' features so an intelligent decision can
> be made. It's the same thing every time folks try to number things in
> DT.

Note that it was you wanted to solve the more complicated problem about
selecting the right watchdog from a set of several working watchdogs.
The problem here is easier: We have machines with two watchdog devices
and only one of them is actually working. So the straight forward thing
to do is to not provide the watchdog device for the rtc chip that cannot
reset the system.

Best regards
Uwe

--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |

Attachments:

(No filename) (3.02 kB)
signature.asc (499.00 B)
Download all attachments

2020-12-18 10:13:36

[permalink] [raw]

Subject: [PATCH v3 0/2] add reset-source RTC binding, update pcf2127 driver

This adds a reset-source RTC DT binding, as suggested by Alexandre,
and resends Uwe's patch making use of that property in pcf2127 driver
to avoid the driver exposing a watchdog that doesn't work (and
potentially shuffling the enumeration of the existing devices that do
work).

v3: elide the refactoring patch already in -next (5d78533a0c53 - rtc:
pcf2127: move watchdog initialisation to a separate function), make
sure to cc the DT binding list.

Applies on top of next-20201218.

Rasmus Villemoes (1):
dt-bindings: rtc: add reset-source property

Uwe Kleine-König (1):
rtc: pcf2127: only use watchdog when explicitly available

Documentation/devicetree/bindings/rtc/rtc.yaml | 5 +++++
drivers/rtc/rtc-pcf2127.c | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)

--
2.23.0

2020-12-18 10:13:42

[permalink] [raw]

Subject: [PATCH v3 1/2] dt-bindings: rtc: add reset-source property

Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
if the reset pin is not actually wired up, the driver exposes a
watchdog device that doesn't actually work.

Provide a standard binding that can be used to indicate that a given
RTC can perform a reset of the machine, similar to wakeup-source.

Suggested-by: Alexandre Belloni <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
---
Documentation/devicetree/bindings/rtc/rtc.yaml | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml
index 8acd2de3de3a..d30dc045aac6 100644
--- a/Documentation/devicetree/bindings/rtc/rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/rtc.yaml
@@ -63,6 +63,11 @@ properties:
description:
Enables wake up of host system on alarm.

+ reset-source:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The RTC is able to reset the machine.
+
additionalProperties: true

...
--
2.23.0

2020-12-18 10:14:16

[permalink] [raw]

Subject: [PATCH v3 2/2] rtc: pcf2127: only use watchdog when explicitly available

From: Uwe Kleine-König <[email protected]>

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 "reset-source"
property.

Signed-off-by: Uwe Kleine-König <[email protected]>
[RV: s/has-watchdog/reset-source/]
Signed-off-by: Rasmus Villemoes <[email protected]>
---
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 33fa8b17b79c..39a7b5116aa4 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -336,7 +336,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, "reset-source"))
return 0;

pcf2127->wdd.parent = dev;
--
2.23.0

2020-12-18 21:21:28

[permalink] [raw]

Subject: Re: [PATCH v3 1/2] dt-bindings: rtc: add reset-source property

On Fri, Dec 18, 2020 at 4:11 AM Rasmus Villemoes
<[email protected]> wrote:
>
> Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But
> if the reset pin is not actually wired up, the driver exposes a
> watchdog device that doesn't actually work.
>
> Provide a standard binding that can be used to indicate that a given
> RTC can perform a reset of the machine, similar to wakeup-source.
>
> Suggested-by: Alexandre Belloni <[email protected]>
> Signed-off-by: Rasmus Villemoes <[email protected]>
> ---
> Documentation/devicetree/bindings/rtc/rtc.yaml | 5 +++++
> 1 file changed, 5 insertions(+)

Reviewed-by: Rob Herring <[email protected]>

2020-12-19 01:00:21