* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-10-23 10:40 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-10-23 10:40 UTC (permalink / raw) To: linux-arm-kernel, linux-watchdog; +Cc: Timo Kokkonen By default the driver will start a kernel timer which keeps on kicking the watchdog HW until user space has opened the watchdog device. Usually this is desirable as the watchdog HW is running by default and the user space may not have any watchdog daemon running at all. However, on production systems it may be mandatory that also early crashes and lockups will lead to a watchdog reset, even if they happen before the user space has opened the watchdog device. To resolve the issue, add a new device tree property "atmel,no-early-timer" which will prevent the kernel timer from pinging the watchdog HW on behalf of user space. The default is still to use kernel timer, but more strict behavior can be enabled via the device tree property. Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> --- Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ drivers/watchdog/at91sam9_wdt.c | 6 +++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt index f90e294..1b9289e 100644 --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt @@ -28,6 +28,10 @@ Optional properties: entering idle state. - atmel,dbg-halt : Should be present if you want to stop the watchdog when entering debug state. +- atmel,no-early-timer : Should be present if you want to let the + watchdog timer to expire even before user space has opened the + device. If not set, a kernel timer will keep on pinging the + watchdog until it is opened. Example: watchdog@fffffd40 { diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c index 489729b..8cac712 100644 --- a/drivers/watchdog/at91sam9_wdt.c +++ b/drivers/watchdog/at91sam9_wdt.c @@ -89,6 +89,7 @@ struct at91wdt { u32 mr_mask; unsigned long heartbeat; /* WDT heartbeat in jiffies */ bool nowayout; + bool no_early_timer; unsigned int irq; }; @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) { struct at91wdt *wdt = (struct at91wdt *)data; if (time_before(jiffies, wdt->next_heartbeat) || - !watchdog_active(&wdt->wdd)) { + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { at91_wdt_reset(wdt); mod_timer(&wdt->timer, jiffies + wdt->heartbeat); } else { @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) wdt->mr |= max | ((max - min) << 16); + if (of_property_read_bool(np, "atmel,no-early-timer")) + wdt->no_early_timer = 1; + return 0; } #else -- 1.9.1 ^ permalink raw reply related [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-10-23 10:40 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-10-23 10:40 UTC (permalink / raw) To: linux-arm-kernel By default the driver will start a kernel timer which keeps on kicking the watchdog HW until user space has opened the watchdog device. Usually this is desirable as the watchdog HW is running by default and the user space may not have any watchdog daemon running at all. However, on production systems it may be mandatory that also early crashes and lockups will lead to a watchdog reset, even if they happen before the user space has opened the watchdog device. To resolve the issue, add a new device tree property "atmel,no-early-timer" which will prevent the kernel timer from pinging the watchdog HW on behalf of user space. The default is still to use kernel timer, but more strict behavior can be enabled via the device tree property. Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> --- Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ drivers/watchdog/at91sam9_wdt.c | 6 +++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt index f90e294..1b9289e 100644 --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt @@ -28,6 +28,10 @@ Optional properties: entering idle state. - atmel,dbg-halt : Should be present if you want to stop the watchdog when entering debug state. +- atmel,no-early-timer : Should be present if you want to let the + watchdog timer to expire even before user space has opened the + device. If not set, a kernel timer will keep on pinging the + watchdog until it is opened. Example: watchdog at fffffd40 { diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c index 489729b..8cac712 100644 --- a/drivers/watchdog/at91sam9_wdt.c +++ b/drivers/watchdog/at91sam9_wdt.c @@ -89,6 +89,7 @@ struct at91wdt { u32 mr_mask; unsigned long heartbeat; /* WDT heartbeat in jiffies */ bool nowayout; + bool no_early_timer; unsigned int irq; }; @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) { struct at91wdt *wdt = (struct at91wdt *)data; if (time_before(jiffies, wdt->next_heartbeat) || - !watchdog_active(&wdt->wdd)) { + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { at91_wdt_reset(wdt); mod_timer(&wdt->timer, jiffies + wdt->heartbeat); } else { @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) wdt->mr |= max | ((max - min) << 16); + if (of_property_read_bool(np, "atmel,no-early-timer")) + wdt->no_early_timer = 1; + return 0; } #else -- 1.9.1 ^ permalink raw reply related [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-10-23 10:40 ` Timo Kokkonen @ 2014-11-12 8:20 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-12 8:20 UTC (permalink / raw) To: linux-arm-kernel, linux-watchdog Hi, On 10/23/14 13:40, Timo Kokkonen wrote: > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "atmel,no-early-timer" which will prevent the kernel timer from > pinging the watchdog HW on behalf of user space. The default is still > to use kernel timer, but more strict behavior can be enabled via the > device tree property. > Any thoughts on this one? Should I resend this with some more people or lists to get someone to comment or review this patch? Thanks, -Timo > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > --- > Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > drivers/watchdog/at91sam9_wdt.c | 6 +++++- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > index f90e294..1b9289e 100644 > --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > @@ -28,6 +28,10 @@ Optional properties: > entering idle state. > - atmel,dbg-halt : Should be present if you want to stop the watchdog when > entering debug state. > +- atmel,no-early-timer : Should be present if you want to let the > + watchdog timer to expire even before user space has opened the > + device. If not set, a kernel timer will keep on pinging the > + watchdog until it is opened. > > Example: > watchdog@fffffd40 { > diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c > index 489729b..8cac712 100644 > --- a/drivers/watchdog/at91sam9_wdt.c > +++ b/drivers/watchdog/at91sam9_wdt.c > @@ -89,6 +89,7 @@ struct at91wdt { > u32 mr_mask; > unsigned long heartbeat; /* WDT heartbeat in jiffies */ > bool nowayout; > + bool no_early_timer; > unsigned int irq; > }; > > @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) > { > struct at91wdt *wdt = (struct at91wdt *)data; > if (time_before(jiffies, wdt->next_heartbeat) || > - !watchdog_active(&wdt->wdd)) { > + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { > at91_wdt_reset(wdt); > mod_timer(&wdt->timer, jiffies + wdt->heartbeat); > } else { > @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) > > wdt->mr |= max | ((max - min) << 16); > > + if (of_property_read_bool(np, "atmel,no-early-timer")) > + wdt->no_early_timer = 1; > + > return 0; > } > #else > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-12 8:20 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-12 8:20 UTC (permalink / raw) To: linux-arm-kernel Hi, On 10/23/14 13:40, Timo Kokkonen wrote: > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "atmel,no-early-timer" which will prevent the kernel timer from > pinging the watchdog HW on behalf of user space. The default is still > to use kernel timer, but more strict behavior can be enabled via the > device tree property. > Any thoughts on this one? Should I resend this with some more people or lists to get someone to comment or review this patch? Thanks, -Timo > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > --- > Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > drivers/watchdog/at91sam9_wdt.c | 6 +++++- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > index f90e294..1b9289e 100644 > --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > @@ -28,6 +28,10 @@ Optional properties: > entering idle state. > - atmel,dbg-halt : Should be present if you want to stop the watchdog when > entering debug state. > +- atmel,no-early-timer : Should be present if you want to let the > + watchdog timer to expire even before user space has opened the > + device. If not set, a kernel timer will keep on pinging the > + watchdog until it is opened. > > Example: > watchdog at fffffd40 { > diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c > index 489729b..8cac712 100644 > --- a/drivers/watchdog/at91sam9_wdt.c > +++ b/drivers/watchdog/at91sam9_wdt.c > @@ -89,6 +89,7 @@ struct at91wdt { > u32 mr_mask; > unsigned long heartbeat; /* WDT heartbeat in jiffies */ > bool nowayout; > + bool no_early_timer; > unsigned int irq; > }; > > @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) > { > struct at91wdt *wdt = (struct at91wdt *)data; > if (time_before(jiffies, wdt->next_heartbeat) || > - !watchdog_active(&wdt->wdd)) { > + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { > at91_wdt_reset(wdt); > mod_timer(&wdt->timer, jiffies + wdt->heartbeat); > } else { > @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) > > wdt->mr |= max | ((max - min) << 16); > > + if (of_property_read_bool(np, "atmel,no-early-timer")) > + wdt->no_early_timer = 1; > + > return 0; > } > #else > ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-12 8:20 ` Timo Kokkonen @ 2014-11-13 9:12 ` Nicolas Ferre -1 siblings, 0 replies; 110+ messages in thread From: Nicolas Ferre @ 2014-11-13 9:12 UTC (permalink / raw) To: Timo Kokkonen, linux-watchdog Cc: linux-arm-kernel, Alexandre Belloni, Boris BREZILLON On 12/11/2014 09:20, Timo Kokkonen : > Hi, > > On 10/23/14 13:40, Timo Kokkonen wrote: >> By default the driver will start a kernel timer which keeps on kicking >> the watchdog HW until user space has opened the watchdog >> device. Usually this is desirable as the watchdog HW is running by >> default and the user space may not have any watchdog daemon running at >> all. >> >> However, on production systems it may be mandatory that also early >> crashes and lockups will lead to a watchdog reset, even if they happen >> before the user space has opened the watchdog device. >> >> To resolve the issue, add a new device tree property >> "atmel,no-early-timer" which will prevent the kernel timer from >> pinging the watchdog HW on behalf of user space. The default is still >> to use kernel timer, but more strict behavior can be enabled via the >> device tree property. >> > > Any thoughts on this one? Should I resend this with some more people or > lists to get someone to comment or review this patch? I would like to know if this property added to the device-tree is already defined by another watchdog timer. Indeed, it seems a pretty generic behavior and I am surprised it doesn't have an already existing implementation. ... >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >> --- >> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >> 2 files changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> index f90e294..1b9289e 100644 >> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> @@ -28,6 +28,10 @@ Optional properties: >> entering idle state. >> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >> entering debug state. >> +- atmel,no-early-timer : Should be present if you want to let the >> + watchdog timer to expire even before user space has opened the >> + device. If not set, a kernel timer will keep on pinging the >> + watchdog until it is opened. >> >> Example: >> watchdog@fffffd40 { >> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c >> index 489729b..8cac712 100644 >> --- a/drivers/watchdog/at91sam9_wdt.c >> +++ b/drivers/watchdog/at91sam9_wdt.c >> @@ -89,6 +89,7 @@ struct at91wdt { >> u32 mr_mask; >> unsigned long heartbeat; /* WDT heartbeat in jiffies */ >> bool nowayout; >> + bool no_early_timer; >> unsigned int irq; >> }; >> >> @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) >> { >> struct at91wdt *wdt = (struct at91wdt *)data; >> if (time_before(jiffies, wdt->next_heartbeat) || >> - !watchdog_active(&wdt->wdd)) { >> + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { ... Nitpicking: there seems to be a indentation mismatch here: use tab + spaces to align to previous line... >> at91_wdt_reset(wdt); >> mod_timer(&wdt->timer, jiffies + wdt->heartbeat); >> } else { >> @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) >> >> wdt->mr |= max | ((max - min) << 16); >> >> + if (of_property_read_bool(np, "atmel,no-early-timer")) >> + wdt->no_early_timer = 1; >> + >> return 0; >> } >> #else Otherwise, it seems clean. Can you please re-send a version with the Device tree maintainer in CC? Best regards, -- Nicolas Ferre ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-13 9:12 ` Nicolas Ferre 0 siblings, 0 replies; 110+ messages in thread From: Nicolas Ferre @ 2014-11-13 9:12 UTC (permalink / raw) To: linux-arm-kernel On 12/11/2014 09:20, Timo Kokkonen : > Hi, > > On 10/23/14 13:40, Timo Kokkonen wrote: >> By default the driver will start a kernel timer which keeps on kicking >> the watchdog HW until user space has opened the watchdog >> device. Usually this is desirable as the watchdog HW is running by >> default and the user space may not have any watchdog daemon running at >> all. >> >> However, on production systems it may be mandatory that also early >> crashes and lockups will lead to a watchdog reset, even if they happen >> before the user space has opened the watchdog device. >> >> To resolve the issue, add a new device tree property >> "atmel,no-early-timer" which will prevent the kernel timer from >> pinging the watchdog HW on behalf of user space. The default is still >> to use kernel timer, but more strict behavior can be enabled via the >> device tree property. >> > > Any thoughts on this one? Should I resend this with some more people or > lists to get someone to comment or review this patch? I would like to know if this property added to the device-tree is already defined by another watchdog timer. Indeed, it seems a pretty generic behavior and I am surprised it doesn't have an already existing implementation. ... >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >> --- >> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >> 2 files changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> index f90e294..1b9289e 100644 >> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> @@ -28,6 +28,10 @@ Optional properties: >> entering idle state. >> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >> entering debug state. >> +- atmel,no-early-timer : Should be present if you want to let the >> + watchdog timer to expire even before user space has opened the >> + device. If not set, a kernel timer will keep on pinging the >> + watchdog until it is opened. >> >> Example: >> watchdog at fffffd40 { >> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c >> index 489729b..8cac712 100644 >> --- a/drivers/watchdog/at91sam9_wdt.c >> +++ b/drivers/watchdog/at91sam9_wdt.c >> @@ -89,6 +89,7 @@ struct at91wdt { >> u32 mr_mask; >> unsigned long heartbeat; /* WDT heartbeat in jiffies */ >> bool nowayout; >> + bool no_early_timer; >> unsigned int irq; >> }; >> >> @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) >> { >> struct at91wdt *wdt = (struct at91wdt *)data; >> if (time_before(jiffies, wdt->next_heartbeat) || >> - !watchdog_active(&wdt->wdd)) { >> + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { ... Nitpicking: there seems to be a indentation mismatch here: use tab + spaces to align to previous line... >> at91_wdt_reset(wdt); >> mod_timer(&wdt->timer, jiffies + wdt->heartbeat); >> } else { >> @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) >> >> wdt->mr |= max | ((max - min) << 16); >> >> + if (of_property_read_bool(np, "atmel,no-early-timer")) >> + wdt->no_early_timer = 1; >> + >> return 0; >> } >> #else Otherwise, it seems clean. Can you please re-send a version with the Device tree maintainer in CC? Best regards, -- Nicolas Ferre ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-13 9:12 ` Nicolas Ferre @ 2014-11-14 8:40 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-14 8:40 UTC (permalink / raw) To: Nicolas Ferre, linux-watchdog Cc: linux-arm-kernel, Alexandre Belloni, Boris BREZILLON Hi, On 11/13/14 11:12, Nicolas Ferre wrote: > On 12/11/2014 09:20, Timo Kokkonen : >> Hi, >> >> >> Any thoughts on this one? Should I resend this with some more people or >> lists to get someone to comment or review this patch? > > I would like to know if this property added to the device-tree is > already defined by another watchdog timer. As far as I know, no. And I didn't even think about it. But after taking a quick look at Documentation/devicetree/bindings/watchdog directory, it seems there are only a few bindings that are commong among the watchdog drivers.. > Indeed, it seems a pretty generic behavior and I am surprised it doesn't > have an already existing implementation. Yeah, I think it would be a good idea to use a generic property name for it. I don't think it makes sense to make any changes to the watchdog core driver for this, it is quite hardware specific thing after all. But the policy is generic and could be supported with other drivers too. There are other products out there that have this kind of requirement already and I guess they all just hack the driver to keep the watchdog running to make sure the device gets reset if user space did not open the device for some reason. If we are about to go with a generic property name, I think it needs to be something more descriptive with respect to the desired policy. So, how about a property name "enable-early-reset". If set to 1, the watchdog HW is left running and reset will happen unless user space does something about it. If left undefined or has value 0, act just like now? How about that? -Timo > > ... > >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>> --- >>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >>> 2 files changed, 9 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> index f90e294..1b9289e 100644 >>> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> @@ -28,6 +28,10 @@ Optional properties: >>> entering idle state. >>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >>> entering debug state. >>> +- atmel,no-early-timer : Should be present if you want to let the >>> + watchdog timer to expire even before user space has opened the >>> + device. If not set, a kernel timer will keep on pinging the >>> + watchdog until it is opened. >>> >>> Example: >>> watchdog@fffffd40 { >>> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c >>> index 489729b..8cac712 100644 >>> --- a/drivers/watchdog/at91sam9_wdt.c >>> +++ b/drivers/watchdog/at91sam9_wdt.c >>> @@ -89,6 +89,7 @@ struct at91wdt { >>> u32 mr_mask; >>> unsigned long heartbeat; /* WDT heartbeat in jiffies */ >>> bool nowayout; >>> + bool no_early_timer; >>> unsigned int irq; >>> }; >>> >>> @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) >>> { >>> struct at91wdt *wdt = (struct at91wdt *)data; >>> if (time_before(jiffies, wdt->next_heartbeat) || >>> - !watchdog_active(&wdt->wdd)) { >>> + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { > > ... Nitpicking: there seems to be a indentation mismatch here: use tab + > spaces to align to previous line... > >>> at91_wdt_reset(wdt); >>> mod_timer(&wdt->timer, jiffies + wdt->heartbeat); >>> } else { >>> @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) >>> >>> wdt->mr |= max | ((max - min) << 16); >>> >>> + if (of_property_read_bool(np, "atmel,no-early-timer")) >>> + wdt->no_early_timer = 1; >>> + >>> return 0; >>> } >>> #else > > Otherwise, it seems clean. Can you please re-send a version with the > Device tree maintainer in CC? > > Best regards, > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-14 8:40 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-14 8:40 UTC (permalink / raw) To: linux-arm-kernel Hi, On 11/13/14 11:12, Nicolas Ferre wrote: > On 12/11/2014 09:20, Timo Kokkonen : >> Hi, >> >> >> Any thoughts on this one? Should I resend this with some more people or >> lists to get someone to comment or review this patch? > > I would like to know if this property added to the device-tree is > already defined by another watchdog timer. As far as I know, no. And I didn't even think about it. But after taking a quick look at Documentation/devicetree/bindings/watchdog directory, it seems there are only a few bindings that are commong among the watchdog drivers.. > Indeed, it seems a pretty generic behavior and I am surprised it doesn't > have an already existing implementation. Yeah, I think it would be a good idea to use a generic property name for it. I don't think it makes sense to make any changes to the watchdog core driver for this, it is quite hardware specific thing after all. But the policy is generic and could be supported with other drivers too. There are other products out there that have this kind of requirement already and I guess they all just hack the driver to keep the watchdog running to make sure the device gets reset if user space did not open the device for some reason. If we are about to go with a generic property name, I think it needs to be something more descriptive with respect to the desired policy. So, how about a property name "enable-early-reset". If set to 1, the watchdog HW is left running and reset will happen unless user space does something about it. If left undefined or has value 0, act just like now? How about that? -Timo > > ... > >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>> --- >>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >>> 2 files changed, 9 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> index f90e294..1b9289e 100644 >>> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> @@ -28,6 +28,10 @@ Optional properties: >>> entering idle state. >>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >>> entering debug state. >>> +- atmel,no-early-timer : Should be present if you want to let the >>> + watchdog timer to expire even before user space has opened the >>> + device. If not set, a kernel timer will keep on pinging the >>> + watchdog until it is opened. >>> >>> Example: >>> watchdog at fffffd40 { >>> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c >>> index 489729b..8cac712 100644 >>> --- a/drivers/watchdog/at91sam9_wdt.c >>> +++ b/drivers/watchdog/at91sam9_wdt.c >>> @@ -89,6 +89,7 @@ struct at91wdt { >>> u32 mr_mask; >>> unsigned long heartbeat; /* WDT heartbeat in jiffies */ >>> bool nowayout; >>> + bool no_early_timer; >>> unsigned int irq; >>> }; >>> >>> @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) >>> { >>> struct at91wdt *wdt = (struct at91wdt *)data; >>> if (time_before(jiffies, wdt->next_heartbeat) || >>> - !watchdog_active(&wdt->wdd)) { >>> + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { > > ... Nitpicking: there seems to be a indentation mismatch here: use tab + > spaces to align to previous line... > >>> at91_wdt_reset(wdt); >>> mod_timer(&wdt->timer, jiffies + wdt->heartbeat); >>> } else { >>> @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) >>> >>> wdt->mr |= max | ((max - min) << 16); >>> >>> + if (of_property_read_bool(np, "atmel,no-early-timer")) >>> + wdt->no_early_timer = 1; >>> + >>> return 0; >>> } >>> #else > > Otherwise, it seems clean. Can you please re-send a version with the > Device tree maintainer in CC? > > Best regards, > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-14 8:40 ` Timo Kokkonen @ 2014-11-21 12:23 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-21 12:23 UTC (permalink / raw) To: linux-arm-kernel, linux-watchdog, nicolas.ferre Cc: alexandre.belloni, boris.brezillon, Timo Kokkonen By default the driver will start a kernel timer which keeps on kicking the watchdog HW until user space has opened the watchdog device. Usually this is desirable as the watchdog HW is running by default and the user space may not have any watchdog daemon running at all. However, on production systems it may be mandatory that also early crashes and lockups will lead to a watchdog reset, even if they happen before the user space has opened the watchdog device. To resolve the issue, add a new device tree property "enable-early-reset" which will prevent the kernel timer from pinging the watchdog HW on behalf of user space. The default is still to use kernel timer, but more strict behavior can be enabled via the device tree property. Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> --- Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ drivers/watchdog/at91sam9_wdt.c | 6 +++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt index f90e294..a0b7b75 100644 --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt @@ -28,6 +28,10 @@ Optional properties: entering idle state. - atmel,dbg-halt : Should be present if you want to stop the watchdog when entering debug state. +- enable-early-reset : Should be present if you want to let the + watchdog timer to expire even before user space has opened the + device. If not set, a kernel timer will keep on pinging the + watchdog until it is opened. Example: watchdog@fffffd40 { diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c index 489729b..78b1977 100644 --- a/drivers/watchdog/at91sam9_wdt.c +++ b/drivers/watchdog/at91sam9_wdt.c @@ -89,6 +89,7 @@ struct at91wdt { u32 mr_mask; unsigned long heartbeat; /* WDT heartbeat in jiffies */ bool nowayout; + bool no_early_timer; unsigned int irq; }; @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) { struct at91wdt *wdt = (struct at91wdt *)data; if (time_before(jiffies, wdt->next_heartbeat) || - !watchdog_active(&wdt->wdd)) { + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { at91_wdt_reset(wdt); mod_timer(&wdt->timer, jiffies + wdt->heartbeat); } else { @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) wdt->mr |= max | ((max - min) << 16); + if (of_property_read_bool(np, "enable-early-reset")) + wdt->no_early_timer = 1; + return 0; } #else -- 2.1.0 ^ permalink raw reply related [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-21 12:23 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-21 12:23 UTC (permalink / raw) To: linux-arm-kernel By default the driver will start a kernel timer which keeps on kicking the watchdog HW until user space has opened the watchdog device. Usually this is desirable as the watchdog HW is running by default and the user space may not have any watchdog daemon running at all. However, on production systems it may be mandatory that also early crashes and lockups will lead to a watchdog reset, even if they happen before the user space has opened the watchdog device. To resolve the issue, add a new device tree property "enable-early-reset" which will prevent the kernel timer from pinging the watchdog HW on behalf of user space. The default is still to use kernel timer, but more strict behavior can be enabled via the device tree property. Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> --- Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ drivers/watchdog/at91sam9_wdt.c | 6 +++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt index f90e294..a0b7b75 100644 --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt @@ -28,6 +28,10 @@ Optional properties: entering idle state. - atmel,dbg-halt : Should be present if you want to stop the watchdog when entering debug state. +- enable-early-reset : Should be present if you want to let the + watchdog timer to expire even before user space has opened the + device. If not set, a kernel timer will keep on pinging the + watchdog until it is opened. Example: watchdog at fffffd40 { diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c index 489729b..78b1977 100644 --- a/drivers/watchdog/at91sam9_wdt.c +++ b/drivers/watchdog/at91sam9_wdt.c @@ -89,6 +89,7 @@ struct at91wdt { u32 mr_mask; unsigned long heartbeat; /* WDT heartbeat in jiffies */ bool nowayout; + bool no_early_timer; unsigned int irq; }; @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) { struct at91wdt *wdt = (struct at91wdt *)data; if (time_before(jiffies, wdt->next_heartbeat) || - !watchdog_active(&wdt->wdd)) { + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { at91_wdt_reset(wdt); mod_timer(&wdt->timer, jiffies + wdt->heartbeat); } else { @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) wdt->mr |= max | ((max - min) << 16); + if (of_property_read_bool(np, "enable-early-reset")) + wdt->no_early_timer = 1; + return 0; } #else -- 2.1.0 ^ permalink raw reply related [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-21 12:23 ` Timo Kokkonen @ 2014-11-27 6:53 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-27 6:53 UTC (permalink / raw) To: linux-arm-kernel, linux-watchdog, nicolas.ferre Cc: alexandre.belloni, boris.brezillon Hi, On 21.11.2014 14:23, Timo Kokkonen wrote: > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "enable-early-reset" which will prevent the kernel timer from pinging > the watchdog HW on behalf of user space. The default is still to use > kernel timer, but more strict behavior can be enabled via the device > tree property. > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> I forgot to put the PATCHv2 on the subject line.. But anyway, any thoughts about it? Is there something that should be done to get it forward? Thanks, -Timo > --- > Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > drivers/watchdog/at91sam9_wdt.c | 6 +++++- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > index f90e294..a0b7b75 100644 > --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > @@ -28,6 +28,10 @@ Optional properties: > entering idle state. > - atmel,dbg-halt : Should be present if you want to stop the watchdog when > entering debug state. > +- enable-early-reset : Should be present if you want to let the > + watchdog timer to expire even before user space has opened the > + device. If not set, a kernel timer will keep on pinging the > + watchdog until it is opened. > > Example: > watchdog@fffffd40 { > diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c > index 489729b..78b1977 100644 > --- a/drivers/watchdog/at91sam9_wdt.c > +++ b/drivers/watchdog/at91sam9_wdt.c > @@ -89,6 +89,7 @@ struct at91wdt { > u32 mr_mask; > unsigned long heartbeat; /* WDT heartbeat in jiffies */ > bool nowayout; > + bool no_early_timer; > unsigned int irq; > }; > > @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) > { > struct at91wdt *wdt = (struct at91wdt *)data; > if (time_before(jiffies, wdt->next_heartbeat) || > - !watchdog_active(&wdt->wdd)) { > + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { > at91_wdt_reset(wdt); > mod_timer(&wdt->timer, jiffies + wdt->heartbeat); > } else { > @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) > > wdt->mr |= max | ((max - min) << 16); > > + if (of_property_read_bool(np, "enable-early-reset")) > + wdt->no_early_timer = 1; > + > return 0; > } > #else > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-27 6:53 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-27 6:53 UTC (permalink / raw) To: linux-arm-kernel Hi, On 21.11.2014 14:23, Timo Kokkonen wrote: > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "enable-early-reset" which will prevent the kernel timer from pinging > the watchdog HW on behalf of user space. The default is still to use > kernel timer, but more strict behavior can be enabled via the device > tree property. > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> I forgot to put the PATCHv2 on the subject line.. But anyway, any thoughts about it? Is there something that should be done to get it forward? Thanks, -Timo > --- > Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > drivers/watchdog/at91sam9_wdt.c | 6 +++++- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > index f90e294..a0b7b75 100644 > --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > @@ -28,6 +28,10 @@ Optional properties: > entering idle state. > - atmel,dbg-halt : Should be present if you want to stop the watchdog when > entering debug state. > +- enable-early-reset : Should be present if you want to let the > + watchdog timer to expire even before user space has opened the > + device. If not set, a kernel timer will keep on pinging the > + watchdog until it is opened. > > Example: > watchdog at fffffd40 { > diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c > index 489729b..78b1977 100644 > --- a/drivers/watchdog/at91sam9_wdt.c > +++ b/drivers/watchdog/at91sam9_wdt.c > @@ -89,6 +89,7 @@ struct at91wdt { > u32 mr_mask; > unsigned long heartbeat; /* WDT heartbeat in jiffies */ > bool nowayout; > + bool no_early_timer; > unsigned int irq; > }; > > @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) > { > struct at91wdt *wdt = (struct at91wdt *)data; > if (time_before(jiffies, wdt->next_heartbeat) || > - !watchdog_active(&wdt->wdd)) { > + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { > at91_wdt_reset(wdt); > mod_timer(&wdt->timer, jiffies + wdt->heartbeat); > } else { > @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) > > wdt->mr |= max | ((max - min) << 16); > > + if (of_property_read_bool(np, "enable-early-reset")) > + wdt->no_early_timer = 1; > + > return 0; > } > #else > ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-27 6:53 ` Timo Kokkonen @ 2014-11-27 9:22 ` Nicolas Ferre -1 siblings, 0 replies; 110+ messages in thread From: Nicolas Ferre @ 2014-11-27 9:22 UTC (permalink / raw) To: Timo Kokkonen, linux-arm-kernel, linux-watchdog, alexandre.belloni, boris.brezillon On 27/11/2014 07:53, Timo Kokkonen wrote: > Hi, > > On 21.11.2014 14:23, Timo Kokkonen wrote: >> By default the driver will start a kernel timer which keeps on kicking >> the watchdog HW until user space has opened the watchdog >> device. Usually this is desirable as the watchdog HW is running by >> default and the user space may not have any watchdog daemon running at >> all. >> >> However, on production systems it may be mandatory that also early >> crashes and lockups will lead to a watchdog reset, even if they happen >> before the user space has opened the watchdog device. >> >> To resolve the issue, add a new device tree property >> "enable-early-reset" which will prevent the kernel timer from pinging >> the watchdog HW on behalf of user space. The default is still to use >> kernel timer, but more strict behavior can be enabled via the device >> tree property. >> >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > > I forgot to put the PATCHv2 on the subject line.. But anyway, any > thoughts about it? Is there something that should be done to get it forward? Sorry for not having come back to you quickly. The only thing that tend to prevent me from taking this patch is the fact that this DT property is mostly a software, Linux-specific one... Which is somehow not covered by the DT. This might explain as well why this property is not present on other SoCs. Can we have other people's advices? Bye, >> --- >> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >> 2 files changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> index f90e294..a0b7b75 100644 >> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> @@ -28,6 +28,10 @@ Optional properties: >> entering idle state. >> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >> entering debug state. >> +- enable-early-reset : Should be present if you want to let the >> + watchdog timer to expire even before user space has opened the >> + device. If not set, a kernel timer will keep on pinging the >> + watchdog until it is opened. >> >> Example: >> watchdog@fffffd40 { >> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c >> index 489729b..78b1977 100644 >> --- a/drivers/watchdog/at91sam9_wdt.c >> +++ b/drivers/watchdog/at91sam9_wdt.c >> @@ -89,6 +89,7 @@ struct at91wdt { >> u32 mr_mask; >> unsigned long heartbeat; /* WDT heartbeat in jiffies */ >> bool nowayout; >> + bool no_early_timer; >> unsigned int irq; >> }; >> >> @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) >> { >> struct at91wdt *wdt = (struct at91wdt *)data; >> if (time_before(jiffies, wdt->next_heartbeat) || >> - !watchdog_active(&wdt->wdd)) { >> + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { >> at91_wdt_reset(wdt); >> mod_timer(&wdt->timer, jiffies + wdt->heartbeat); >> } else { >> @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) >> >> wdt->mr |= max | ((max - min) << 16); >> >> + if (of_property_read_bool(np, "enable-early-reset")) >> + wdt->no_early_timer = 1; >> + >> return 0; >> } >> #else >> > > -- Nicolas Ferre ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-27 9:22 ` Nicolas Ferre 0 siblings, 0 replies; 110+ messages in thread From: Nicolas Ferre @ 2014-11-27 9:22 UTC (permalink / raw) To: linux-arm-kernel On 27/11/2014 07:53, Timo Kokkonen wrote: > Hi, > > On 21.11.2014 14:23, Timo Kokkonen wrote: >> By default the driver will start a kernel timer which keeps on kicking >> the watchdog HW until user space has opened the watchdog >> device. Usually this is desirable as the watchdog HW is running by >> default and the user space may not have any watchdog daemon running at >> all. >> >> However, on production systems it may be mandatory that also early >> crashes and lockups will lead to a watchdog reset, even if they happen >> before the user space has opened the watchdog device. >> >> To resolve the issue, add a new device tree property >> "enable-early-reset" which will prevent the kernel timer from pinging >> the watchdog HW on behalf of user space. The default is still to use >> kernel timer, but more strict behavior can be enabled via the device >> tree property. >> >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > > I forgot to put the PATCHv2 on the subject line.. But anyway, any > thoughts about it? Is there something that should be done to get it forward? Sorry for not having come back to you quickly. The only thing that tend to prevent me from taking this patch is the fact that this DT property is mostly a software, Linux-specific one... Which is somehow not covered by the DT. This might explain as well why this property is not present on other SoCs. Can we have other people's advices? Bye, >> --- >> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >> 2 files changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> index f90e294..a0b7b75 100644 >> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> @@ -28,6 +28,10 @@ Optional properties: >> entering idle state. >> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >> entering debug state. >> +- enable-early-reset : Should be present if you want to let the >> + watchdog timer to expire even before user space has opened the >> + device. If not set, a kernel timer will keep on pinging the >> + watchdog until it is opened. >> >> Example: >> watchdog at fffffd40 { >> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c >> index 489729b..78b1977 100644 >> --- a/drivers/watchdog/at91sam9_wdt.c >> +++ b/drivers/watchdog/at91sam9_wdt.c >> @@ -89,6 +89,7 @@ struct at91wdt { >> u32 mr_mask; >> unsigned long heartbeat; /* WDT heartbeat in jiffies */ >> bool nowayout; >> + bool no_early_timer; >> unsigned int irq; >> }; >> >> @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) >> { >> struct at91wdt *wdt = (struct at91wdt *)data; >> if (time_before(jiffies, wdt->next_heartbeat) || >> - !watchdog_active(&wdt->wdd)) { >> + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { >> at91_wdt_reset(wdt); >> mod_timer(&wdt->timer, jiffies + wdt->heartbeat); >> } else { >> @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) >> >> wdt->mr |= max | ((max - min) << 16); >> >> + if (of_property_read_bool(np, "enable-early-reset")) >> + wdt->no_early_timer = 1; >> + >> return 0; >> } >> #else >> > > -- Nicolas Ferre ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-27 9:22 ` Nicolas Ferre @ 2014-11-27 17:23 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2014-11-27 17:23 UTC (permalink / raw) To: Nicolas Ferre, Timo Kokkonen, linux-arm-kernel, linux-watchdog, alexandre.belloni, boris.brezillon On 11/27/2014 01:22 AM, Nicolas Ferre wrote: > On 27/11/2014 07:53, Timo Kokkonen wrote: >> Hi, >> >> On 21.11.2014 14:23, Timo Kokkonen wrote: >>> By default the driver will start a kernel timer which keeps on kicking >>> the watchdog HW until user space has opened the watchdog >>> device. Usually this is desirable as the watchdog HW is running by >>> default and the user space may not have any watchdog daemon running at >>> all. >>> >>> However, on production systems it may be mandatory that also early >>> crashes and lockups will lead to a watchdog reset, even if they happen >>> before the user space has opened the watchdog device. >>> >>> To resolve the issue, add a new device tree property >>> "enable-early-reset" which will prevent the kernel timer from pinging >>> the watchdog HW on behalf of user space. The default is still to use >>> kernel timer, but more strict behavior can be enabled via the device >>> tree property. >>> >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >> >> I forgot to put the PATCHv2 on the subject line.. But anyway, any >> thoughts about it? Is there something that should be done to get it forward? > > Sorry for not having come back to you quickly. > > The only thing that tend to prevent me from taking this patch is the > fact that this DT property is mostly a software, Linux-specific one... > Which is somehow not covered by the DT. > This might explain as well why this property is not present on other SoCs. > > Can we have other people's advices? > We have been thinking about a more generic (infrastructure based) solution for the problem at hand, but that was a bit more complex and would specify the actual timeout during boot, not just a boolean like suggested here. As for DT not supposed to be used for configuration, that is really a tricky problem which is hard to solve. I seem to recall, though, that it may be now acceptable under certain conditions. A module parameter might be easier. Guenter > Bye, > >>> --- >>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >>> 2 files changed, 9 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> index f90e294..a0b7b75 100644 >>> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> @@ -28,6 +28,10 @@ Optional properties: >>> entering idle state. >>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >>> entering debug state. >>> +- enable-early-reset : Should be present if you want to let the >>> + watchdog timer to expire even before user space has opened the >>> + device. If not set, a kernel timer will keep on pinging the >>> + watchdog until it is opened. >>> >>> Example: >>> watchdog@fffffd40 { >>> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c >>> index 489729b..78b1977 100644 >>> --- a/drivers/watchdog/at91sam9_wdt.c >>> +++ b/drivers/watchdog/at91sam9_wdt.c >>> @@ -89,6 +89,7 @@ struct at91wdt { >>> u32 mr_mask; >>> unsigned long heartbeat; /* WDT heartbeat in jiffies */ >>> bool nowayout; >>> + bool no_early_timer; >>> unsigned int irq; >>> }; >>> >>> @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) >>> { >>> struct at91wdt *wdt = (struct at91wdt *)data; >>> if (time_before(jiffies, wdt->next_heartbeat) || >>> - !watchdog_active(&wdt->wdd)) { >>> + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { >>> at91_wdt_reset(wdt); >>> mod_timer(&wdt->timer, jiffies + wdt->heartbeat); >>> } else { >>> @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) >>> >>> wdt->mr |= max | ((max - min) << 16); >>> >>> + if (of_property_read_bool(np, "enable-early-reset")) >>> + wdt->no_early_timer = 1; >>> + >>> return 0; >>> } >>> #else >>> >> >> > > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-27 17:23 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2014-11-27 17:23 UTC (permalink / raw) To: linux-arm-kernel On 11/27/2014 01:22 AM, Nicolas Ferre wrote: > On 27/11/2014 07:53, Timo Kokkonen wrote: >> Hi, >> >> On 21.11.2014 14:23, Timo Kokkonen wrote: >>> By default the driver will start a kernel timer which keeps on kicking >>> the watchdog HW until user space has opened the watchdog >>> device. Usually this is desirable as the watchdog HW is running by >>> default and the user space may not have any watchdog daemon running at >>> all. >>> >>> However, on production systems it may be mandatory that also early >>> crashes and lockups will lead to a watchdog reset, even if they happen >>> before the user space has opened the watchdog device. >>> >>> To resolve the issue, add a new device tree property >>> "enable-early-reset" which will prevent the kernel timer from pinging >>> the watchdog HW on behalf of user space. The default is still to use >>> kernel timer, but more strict behavior can be enabled via the device >>> tree property. >>> >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >> >> I forgot to put the PATCHv2 on the subject line.. But anyway, any >> thoughts about it? Is there something that should be done to get it forward? > > Sorry for not having come back to you quickly. > > The only thing that tend to prevent me from taking this patch is the > fact that this DT property is mostly a software, Linux-specific one... > Which is somehow not covered by the DT. > This might explain as well why this property is not present on other SoCs. > > Can we have other people's advices? > We have been thinking about a more generic (infrastructure based) solution for the problem at hand, but that was a bit more complex and would specify the actual timeout during boot, not just a boolean like suggested here. As for DT not supposed to be used for configuration, that is really a tricky problem which is hard to solve. I seem to recall, though, that it may be now acceptable under certain conditions. A module parameter might be easier. Guenter > Bye, > >>> --- >>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >>> 2 files changed, 9 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> index f90e294..a0b7b75 100644 >>> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>> @@ -28,6 +28,10 @@ Optional properties: >>> entering idle state. >>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >>> entering debug state. >>> +- enable-early-reset : Should be present if you want to let the >>> + watchdog timer to expire even before user space has opened the >>> + device. If not set, a kernel timer will keep on pinging the >>> + watchdog until it is opened. >>> >>> Example: >>> watchdog at fffffd40 { >>> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c >>> index 489729b..78b1977 100644 >>> --- a/drivers/watchdog/at91sam9_wdt.c >>> +++ b/drivers/watchdog/at91sam9_wdt.c >>> @@ -89,6 +89,7 @@ struct at91wdt { >>> u32 mr_mask; >>> unsigned long heartbeat; /* WDT heartbeat in jiffies */ >>> bool nowayout; >>> + bool no_early_timer; >>> unsigned int irq; >>> }; >>> >>> @@ -122,7 +123,7 @@ static void at91_ping(unsigned long data) >>> { >>> struct at91wdt *wdt = (struct at91wdt *)data; >>> if (time_before(jiffies, wdt->next_heartbeat) || >>> - !watchdog_active(&wdt->wdd)) { >>> + (!watchdog_active(&wdt->wdd) && !wdt->no_early_timer)) { >>> at91_wdt_reset(wdt); >>> mod_timer(&wdt->timer, jiffies + wdt->heartbeat); >>> } else { >>> @@ -316,6 +317,9 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) >>> >>> wdt->mr |= max | ((max - min) << 16); >>> >>> + if (of_property_read_bool(np, "enable-early-reset")) >>> + wdt->no_early_timer = 1; >>> + >>> return 0; >>> } >>> #else >>> >> >> > > ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-27 17:23 ` Guenter Roeck @ 2014-11-27 19:06 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2014-11-27 19:06 UTC (permalink / raw) To: Guenter Roeck Cc: Nicolas Ferre, Timo Kokkonen, linux-arm-kernel, linux-watchdog, alexandre.belloni Hi Guenter, On Thu, 27 Nov 2014 09:23:30 -0800 Guenter Roeck <linux@roeck-us.net> wrote: > On 11/27/2014 01:22 AM, Nicolas Ferre wrote: > > On 27/11/2014 07:53, Timo Kokkonen wrote: > >> Hi, > >> > >> On 21.11.2014 14:23, Timo Kokkonen wrote: > >>> By default the driver will start a kernel timer which keeps on kicking > >>> the watchdog HW until user space has opened the watchdog > >>> device. Usually this is desirable as the watchdog HW is running by > >>> default and the user space may not have any watchdog daemon running at > >>> all. > >>> > >>> However, on production systems it may be mandatory that also early > >>> crashes and lockups will lead to a watchdog reset, even if they happen > >>> before the user space has opened the watchdog device. > >>> > >>> To resolve the issue, add a new device tree property > >>> "enable-early-reset" which will prevent the kernel timer from pinging > >>> the watchdog HW on behalf of user space. The default is still to use > >>> kernel timer, but more strict behavior can be enabled via the device > >>> tree property. > >>> > >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > >> > >> I forgot to put the PATCHv2 on the subject line.. But anyway, any > >> thoughts about it? Is there something that should be done to get it forward? > > > > Sorry for not having come back to you quickly. > > > > The only thing that tend to prevent me from taking this patch is the > > fact that this DT property is mostly a software, Linux-specific one... > > Which is somehow not covered by the DT. > > This might explain as well why this property is not present on other SoCs. > > > > Can we have other people's advices? > > > > We have been thinking about a more generic (infrastructure based) solution > for the problem at hand, but that was a bit more complex and would specify > the actual timeout during boot, not just a boolean like suggested here. Can't we keep the same timeout (the one specified in the timeout-sec property) ? > > As for DT not supposed to be used for configuration, that is really a > tricky problem which is hard to solve. I seem to recall, though, that > it may be now acceptable under certain conditions. A module parameter > might be easier. I'm not a big fan of passing these kind information through module params, cause it's kind of hard to assign parameters when you have multiple device instances (it might not be applicable to watchdog devices though). Moreover, adding more module parameters will just expand the cmdline and make it less and less readable. Anyway, this is not my call to make :-). Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-27 19:06 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2014-11-27 19:06 UTC (permalink / raw) To: linux-arm-kernel Hi Guenter, On Thu, 27 Nov 2014 09:23:30 -0800 Guenter Roeck <linux@roeck-us.net> wrote: > On 11/27/2014 01:22 AM, Nicolas Ferre wrote: > > On 27/11/2014 07:53, Timo Kokkonen wrote: > >> Hi, > >> > >> On 21.11.2014 14:23, Timo Kokkonen wrote: > >>> By default the driver will start a kernel timer which keeps on kicking > >>> the watchdog HW until user space has opened the watchdog > >>> device. Usually this is desirable as the watchdog HW is running by > >>> default and the user space may not have any watchdog daemon running at > >>> all. > >>> > >>> However, on production systems it may be mandatory that also early > >>> crashes and lockups will lead to a watchdog reset, even if they happen > >>> before the user space has opened the watchdog device. > >>> > >>> To resolve the issue, add a new device tree property > >>> "enable-early-reset" which will prevent the kernel timer from pinging > >>> the watchdog HW on behalf of user space. The default is still to use > >>> kernel timer, but more strict behavior can be enabled via the device > >>> tree property. > >>> > >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > >> > >> I forgot to put the PATCHv2 on the subject line.. But anyway, any > >> thoughts about it? Is there something that should be done to get it forward? > > > > Sorry for not having come back to you quickly. > > > > The only thing that tend to prevent me from taking this patch is the > > fact that this DT property is mostly a software, Linux-specific one... > > Which is somehow not covered by the DT. > > This might explain as well why this property is not present on other SoCs. > > > > Can we have other people's advices? > > > > We have been thinking about a more generic (infrastructure based) solution > for the problem at hand, but that was a bit more complex and would specify > the actual timeout during boot, not just a boolean like suggested here. Can't we keep the same timeout (the one specified in the timeout-sec property) ? > > As for DT not supposed to be used for configuration, that is really a > tricky problem which is hard to solve. I seem to recall, though, that > it may be now acceptable under certain conditions. A module parameter > might be easier. I'm not a big fan of passing these kind information through module params, cause it's kind of hard to assign parameters when you have multiple device instances (it might not be applicable to watchdog devices though). Moreover, adding more module parameters will just expand the cmdline and make it less and less readable. Anyway, this is not my call to make :-). Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-27 19:06 ` Boris Brezillon @ 2014-11-27 19:31 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2014-11-27 19:31 UTC (permalink / raw) To: Boris Brezillon Cc: Nicolas Ferre, Timo Kokkonen, linux-arm-kernel, linux-watchdog, alexandre.belloni On 11/27/2014 11:06 AM, Boris Brezillon wrote: > Hi Guenter, > > On Thu, 27 Nov 2014 09:23:30 -0800 > Guenter Roeck <linux@roeck-us.net> wrote: > >> On 11/27/2014 01:22 AM, Nicolas Ferre wrote: >>> On 27/11/2014 07:53, Timo Kokkonen wrote: >>>> Hi, >>>> >>>> On 21.11.2014 14:23, Timo Kokkonen wrote: >>>>> By default the driver will start a kernel timer which keeps on kicking >>>>> the watchdog HW until user space has opened the watchdog >>>>> device. Usually this is desirable as the watchdog HW is running by >>>>> default and the user space may not have any watchdog daemon running at >>>>> all. >>>>> >>>>> However, on production systems it may be mandatory that also early >>>>> crashes and lockups will lead to a watchdog reset, even if they happen >>>>> before the user space has opened the watchdog device. >>>>> >>>>> To resolve the issue, add a new device tree property >>>>> "enable-early-reset" which will prevent the kernel timer from pinging >>>>> the watchdog HW on behalf of user space. The default is still to use >>>>> kernel timer, but more strict behavior can be enabled via the device >>>>> tree property. >>>>> >>>>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>>> >>>> I forgot to put the PATCHv2 on the subject line.. But anyway, any >>>> thoughts about it? Is there something that should be done to get it forward? >>> >>> Sorry for not having come back to you quickly. >>> >>> The only thing that tend to prevent me from taking this patch is the >>> fact that this DT property is mostly a software, Linux-specific one... >>> Which is somehow not covered by the DT. >>> This might explain as well why this property is not present on other SoCs. >>> >>> Can we have other people's advices? >>> >> >> We have been thinking about a more generic (infrastructure based) solution >> for the problem at hand, but that was a bit more complex and would specify >> the actual timeout during boot, not just a boolean like suggested here. > > Can't we keep the same timeout (the one specified in the timeout-sec > property) ? > That doesn't take into account systems where - for whatever reason - the initial timeout needs to be longer. I do not think it is a good idea to unnecessarily limit functionality. We may make the additional timeout optional - in that case timeout-sec could be used as default. >> >> As for DT not supposed to be used for configuration, that is really a >> tricky problem which is hard to solve. I seem to recall, though, that >> it may be now acceptable under certain conditions. A module parameter >> might be easier. > > I'm not a big fan of passing these kind information through module > params, cause it's kind of hard to assign parameters when you have > multiple device instances (it might not be applicable to watchdog > devices though). > Moreover, adding more module parameters will just expand the cmdline > and make it less and less readable. > Agreed but ... > Anyway, this is not my call to make :-). it isn't us who restrict the DT scope (though of course timeout-sec _is_ configuration, but that was before things got more restrictive). Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-27 19:31 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2014-11-27 19:31 UTC (permalink / raw) To: linux-arm-kernel On 11/27/2014 11:06 AM, Boris Brezillon wrote: > Hi Guenter, > > On Thu, 27 Nov 2014 09:23:30 -0800 > Guenter Roeck <linux@roeck-us.net> wrote: > >> On 11/27/2014 01:22 AM, Nicolas Ferre wrote: >>> On 27/11/2014 07:53, Timo Kokkonen wrote: >>>> Hi, >>>> >>>> On 21.11.2014 14:23, Timo Kokkonen wrote: >>>>> By default the driver will start a kernel timer which keeps on kicking >>>>> the watchdog HW until user space has opened the watchdog >>>>> device. Usually this is desirable as the watchdog HW is running by >>>>> default and the user space may not have any watchdog daemon running at >>>>> all. >>>>> >>>>> However, on production systems it may be mandatory that also early >>>>> crashes and lockups will lead to a watchdog reset, even if they happen >>>>> before the user space has opened the watchdog device. >>>>> >>>>> To resolve the issue, add a new device tree property >>>>> "enable-early-reset" which will prevent the kernel timer from pinging >>>>> the watchdog HW on behalf of user space. The default is still to use >>>>> kernel timer, but more strict behavior can be enabled via the device >>>>> tree property. >>>>> >>>>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>>> >>>> I forgot to put the PATCHv2 on the subject line.. But anyway, any >>>> thoughts about it? Is there something that should be done to get it forward? >>> >>> Sorry for not having come back to you quickly. >>> >>> The only thing that tend to prevent me from taking this patch is the >>> fact that this DT property is mostly a software, Linux-specific one... >>> Which is somehow not covered by the DT. >>> This might explain as well why this property is not present on other SoCs. >>> >>> Can we have other people's advices? >>> >> >> We have been thinking about a more generic (infrastructure based) solution >> for the problem at hand, but that was a bit more complex and would specify >> the actual timeout during boot, not just a boolean like suggested here. > > Can't we keep the same timeout (the one specified in the timeout-sec > property) ? > That doesn't take into account systems where - for whatever reason - the initial timeout needs to be longer. I do not think it is a good idea to unnecessarily limit functionality. We may make the additional timeout optional - in that case timeout-sec could be used as default. >> >> As for DT not supposed to be used for configuration, that is really a >> tricky problem which is hard to solve. I seem to recall, though, that >> it may be now acceptable under certain conditions. A module parameter >> might be easier. > > I'm not a big fan of passing these kind information through module > params, cause it's kind of hard to assign parameters when you have > multiple device instances (it might not be applicable to watchdog > devices though). > Moreover, adding more module parameters will just expand the cmdline > and make it less and less readable. > Agreed but ... > Anyway, this is not my call to make :-). it isn't us who restrict the DT scope (though of course timeout-sec _is_ configuration, but that was before things got more restrictive). Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-27 19:31 ` Guenter Roeck @ 2014-11-28 0:30 ` Alexandre Belloni -1 siblings, 0 replies; 110+ messages in thread From: Alexandre Belloni @ 2014-11-28 0:30 UTC (permalink / raw) To: Guenter Roeck Cc: Boris Brezillon, Nicolas Ferre, Timo Kokkonen, linux-arm-kernel, linux-watchdog On 27/11/2014 at 11:31:36 -0800, Guenter Roeck wrote : > On 11/27/2014 11:06 AM, Boris Brezillon wrote: > >>As for DT not supposed to be used for configuration, that is really a > >>tricky problem which is hard to solve. I seem to recall, though, that > >>it may be now acceptable under certain conditions. A module parameter > >>might be easier. > > > >I'm not a big fan of passing these kind information through module > >params, cause it's kind of hard to assign parameters when you have > >multiple device instances (it might not be applicable to watchdog > >devices though). > >Moreover, adding more module parameters will just expand the cmdline > >and make it less and less readable. > > > Agreed but ... > > >Anyway, this is not my call to make :-). > > it isn't us who restrict the DT scope (though of course timeout-sec > _is_ configuration, but that was before things got more restrictive). > My understanding is that it is OK if this is something you need at boot time versus something you can configure from userspace later. But I'm not a DT expert ;) -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-28 0:30 ` Alexandre Belloni 0 siblings, 0 replies; 110+ messages in thread From: Alexandre Belloni @ 2014-11-28 0:30 UTC (permalink / raw) To: linux-arm-kernel On 27/11/2014 at 11:31:36 -0800, Guenter Roeck wrote : > On 11/27/2014 11:06 AM, Boris Brezillon wrote: > >>As for DT not supposed to be used for configuration, that is really a > >>tricky problem which is hard to solve. I seem to recall, though, that > >>it may be now acceptable under certain conditions. A module parameter > >>might be easier. > > > >I'm not a big fan of passing these kind information through module > >params, cause it's kind of hard to assign parameters when you have > >multiple device instances (it might not be applicable to watchdog > >devices though). > >Moreover, adding more module parameters will just expand the cmdline > >and make it less and less readable. > > > Agreed but ... > > >Anyway, this is not my call to make :-). > > it isn't us who restrict the DT scope (though of course timeout-sec > _is_ configuration, but that was before things got more restrictive). > My understanding is that it is OK if this is something you need at boot time versus something you can configure from userspace later. But I'm not a DT expert ;) -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-27 19:31 ` Guenter Roeck @ 2014-11-28 6:40 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-28 6:40 UTC (permalink / raw) To: Guenter Roeck, Boris Brezillon Cc: Nicolas Ferre, linux-arm-kernel, linux-watchdog, alexandre.belloni Hi Guenter, Boris, On 27.11.2014 21:31, Guenter Roeck wrote: > On 11/27/2014 11:06 AM, Boris Brezillon wrote: >> Hi Guenter, >> >> On Thu, 27 Nov 2014 09:23:30 -0800 >> Guenter Roeck <linux@roeck-us.net> wrote: >> >>> On 11/27/2014 01:22 AM, Nicolas Ferre wrote: >>>> On 27/11/2014 07:53, Timo Kokkonen wrote: >>>>> Hi, >>>>> >>>>> On 21.11.2014 14:23, Timo Kokkonen wrote: >>>>>> By default the driver will start a kernel timer which keeps on >>>>>> kicking >>>>>> the watchdog HW until user space has opened the watchdog >>>>>> device. Usually this is desirable as the watchdog HW is running by >>>>>> default and the user space may not have any watchdog daemon >>>>>> running at >>>>>> all. >>>>>> >>>>>> However, on production systems it may be mandatory that also early >>>>>> crashes and lockups will lead to a watchdog reset, even if they >>>>>> happen >>>>>> before the user space has opened the watchdog device. >>>>>> >>>>>> To resolve the issue, add a new device tree property >>>>>> "enable-early-reset" which will prevent the kernel timer from pinging >>>>>> the watchdog HW on behalf of user space. The default is still to use >>>>>> kernel timer, but more strict behavior can be enabled via the device >>>>>> tree property. >>>>>> >>>>>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>>>> >>>>> I forgot to put the PATCHv2 on the subject line.. But anyway, any >>>>> thoughts about it? Is there something that should be done to get it >>>>> forward? >>>> >>>> Sorry for not having come back to you quickly. >>>> >>>> The only thing that tend to prevent me from taking this patch is the >>>> fact that this DT property is mostly a software, Linux-specific one... >>>> Which is somehow not covered by the DT. >>>> This might explain as well why this property is not present on other >>>> SoCs. >>>> >>>> Can we have other people's advices? >>>> >>> >>> We have been thinking about a more generic (infrastructure based) >>> solution >>> for the problem at hand, but that was a bit more complex and would >>> specify >>> the actual timeout during boot, not just a boolean like suggested here. >> >> Can't we keep the same timeout (the one specified in the timeout-sec >> property) ? >> > That doesn't take into account systems where - for whatever reason - > the initial timeout needs to be longer. I do not think it is a good idea > to unnecessarily limit functionality. We may make the additional timeout > optional - in that case timeout-sec could be used as default. How about a property called early-keepalive-sec that, when set above zero, specifies the timeout how long the device is kept alive by the driver. And if set to zero, it just uses what ever defaults there are and lets the HW run until user space wakes up or device resets. >>> >>> As for DT not supposed to be used for configuration, that is really a >>> tricky problem which is hard to solve. I seem to recall, though, that >>> it may be now acceptable under certain conditions. A module parameter >>> might be easier. >> >> I'm not a big fan of passing these kind information through module >> params, cause it's kind of hard to assign parameters when you have >> multiple device instances (it might not be applicable to watchdog >> devices though). >> Moreover, adding more module parameters will just expand the cmdline >> and make it less and less readable. >> > Agreed but ... > >> Anyway, this is not my call to make :-). > > it isn't us who restrict the DT scope (though of course timeout-sec > _is_ configuration, but that was before things got more restrictive). The way I see it this new property we are talking about is no different in principle to the ones we already have there. We are just filling in the gap between boot loader and user space to enable consistent behaviour through out the entire boot up sequence. There are dozens of devices that already hack around this one way or another. DT bindings is simply the most convenient and flexible way to do it. -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-28 6:40 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-28 6:40 UTC (permalink / raw) To: linux-arm-kernel Hi Guenter, Boris, On 27.11.2014 21:31, Guenter Roeck wrote: > On 11/27/2014 11:06 AM, Boris Brezillon wrote: >> Hi Guenter, >> >> On Thu, 27 Nov 2014 09:23:30 -0800 >> Guenter Roeck <linux@roeck-us.net> wrote: >> >>> On 11/27/2014 01:22 AM, Nicolas Ferre wrote: >>>> On 27/11/2014 07:53, Timo Kokkonen wrote: >>>>> Hi, >>>>> >>>>> On 21.11.2014 14:23, Timo Kokkonen wrote: >>>>>> By default the driver will start a kernel timer which keeps on >>>>>> kicking >>>>>> the watchdog HW until user space has opened the watchdog >>>>>> device. Usually this is desirable as the watchdog HW is running by >>>>>> default and the user space may not have any watchdog daemon >>>>>> running at >>>>>> all. >>>>>> >>>>>> However, on production systems it may be mandatory that also early >>>>>> crashes and lockups will lead to a watchdog reset, even if they >>>>>> happen >>>>>> before the user space has opened the watchdog device. >>>>>> >>>>>> To resolve the issue, add a new device tree property >>>>>> "enable-early-reset" which will prevent the kernel timer from pinging >>>>>> the watchdog HW on behalf of user space. The default is still to use >>>>>> kernel timer, but more strict behavior can be enabled via the device >>>>>> tree property. >>>>>> >>>>>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>>>> >>>>> I forgot to put the PATCHv2 on the subject line.. But anyway, any >>>>> thoughts about it? Is there something that should be done to get it >>>>> forward? >>>> >>>> Sorry for not having come back to you quickly. >>>> >>>> The only thing that tend to prevent me from taking this patch is the >>>> fact that this DT property is mostly a software, Linux-specific one... >>>> Which is somehow not covered by the DT. >>>> This might explain as well why this property is not present on other >>>> SoCs. >>>> >>>> Can we have other people's advices? >>>> >>> >>> We have been thinking about a more generic (infrastructure based) >>> solution >>> for the problem at hand, but that was a bit more complex and would >>> specify >>> the actual timeout during boot, not just a boolean like suggested here. >> >> Can't we keep the same timeout (the one specified in the timeout-sec >> property) ? >> > That doesn't take into account systems where - for whatever reason - > the initial timeout needs to be longer. I do not think it is a good idea > to unnecessarily limit functionality. We may make the additional timeout > optional - in that case timeout-sec could be used as default. How about a property called early-keepalive-sec that, when set above zero, specifies the timeout how long the device is kept alive by the driver. And if set to zero, it just uses what ever defaults there are and lets the HW run until user space wakes up or device resets. >>> >>> As for DT not supposed to be used for configuration, that is really a >>> tricky problem which is hard to solve. I seem to recall, though, that >>> it may be now acceptable under certain conditions. A module parameter >>> might be easier. >> >> I'm not a big fan of passing these kind information through module >> params, cause it's kind of hard to assign parameters when you have >> multiple device instances (it might not be applicable to watchdog >> devices though). >> Moreover, adding more module parameters will just expand the cmdline >> and make it less and less readable. >> > Agreed but ... > >> Anyway, this is not my call to make :-). > > it isn't us who restrict the DT scope (though of course timeout-sec > _is_ configuration, but that was before things got more restrictive). The way I see it this new property we are talking about is no different in principle to the ones we already have there. We are just filling in the gap between boot loader and user space to enable consistent behaviour through out the entire boot up sequence. There are dozens of devices that already hack around this one way or another. DT bindings is simply the most convenient and flexible way to do it. -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-21 12:23 ` Timo Kokkonen @ 2014-11-27 19:00 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2014-11-27 19:00 UTC (permalink / raw) To: Timo Kokkonen Cc: linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni Hi Timo, Sorry for the late reply. On Fri, 21 Nov 2014 14:23:30 +0200 Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "enable-early-reset" which will prevent the kernel timer from pinging > the watchdog HW on behalf of user space. The default is still to use > kernel timer, but more strict behavior can be enabled via the device > tree property. > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > --- > Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > drivers/watchdog/at91sam9_wdt.c | 6 +++++- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > index f90e294..a0b7b75 100644 > --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > @@ -28,6 +28,10 @@ Optional properties: > entering idle state. > - atmel,dbg-halt : Should be present if you want to stop the watchdog when > entering debug state. > +- enable-early-reset : Should be present if you want to let the > + watchdog timer to expire even before user space has opened the > + device. If not set, a kernel timer will keep on pinging the > + watchdog until it is opened. If you want to make this property generic, maybe you should document it in a generic binding doc (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). Once you're at it, maybe you could document the generic timeout-sec property in this file. Moreover, you might want to parse this property in watchdog_core.c and store the information in the watchdog_device struct. Apart from that, I'm not opposed to the approach, and I'm fine with the current implementation. Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-27 19:00 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2014-11-27 19:00 UTC (permalink / raw) To: linux-arm-kernel Hi Timo, Sorry for the late reply. On Fri, 21 Nov 2014 14:23:30 +0200 Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "enable-early-reset" which will prevent the kernel timer from pinging > the watchdog HW on behalf of user space. The default is still to use > kernel timer, but more strict behavior can be enabled via the device > tree property. > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > --- > Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > drivers/watchdog/at91sam9_wdt.c | 6 +++++- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > index f90e294..a0b7b75 100644 > --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > @@ -28,6 +28,10 @@ Optional properties: > entering idle state. > - atmel,dbg-halt : Should be present if you want to stop the watchdog when > entering debug state. > +- enable-early-reset : Should be present if you want to let the > + watchdog timer to expire even before user space has opened the > + device. If not set, a kernel timer will keep on pinging the > + watchdog until it is opened. If you want to make this property generic, maybe you should document it in a generic binding doc (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). Once you're at it, maybe you could document the generic timeout-sec property in this file. Moreover, you might want to parse this property in watchdog_core.c and store the information in the watchdog_device struct. Apart from that, I'm not opposed to the approach, and I'm fine with the current implementation. Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-27 19:00 ` Boris Brezillon @ 2014-11-28 6:42 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-28 6:42 UTC (permalink / raw) To: Boris Brezillon Cc: linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni Hi Boris, Thanks for the comments. On 27.11.2014 21:00, Boris Brezillon wrote: > Hi Timo, > > Sorry for the late reply. > > On Fri, 21 Nov 2014 14:23:30 +0200 > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >> By default the driver will start a kernel timer which keeps on kicking >> the watchdog HW until user space has opened the watchdog >> device. Usually this is desirable as the watchdog HW is running by >> default and the user space may not have any watchdog daemon running at >> all. >> >> However, on production systems it may be mandatory that also early >> crashes and lockups will lead to a watchdog reset, even if they happen >> before the user space has opened the watchdog device. >> >> To resolve the issue, add a new device tree property >> "enable-early-reset" which will prevent the kernel timer from pinging >> the watchdog HW on behalf of user space. The default is still to use >> kernel timer, but more strict behavior can be enabled via the device >> tree property. >> >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >> --- >> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >> 2 files changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> index f90e294..a0b7b75 100644 >> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> @@ -28,6 +28,10 @@ Optional properties: >> entering idle state. >> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >> entering debug state. >> +- enable-early-reset : Should be present if you want to let the >> + watchdog timer to expire even before user space has opened the >> + device. If not set, a kernel timer will keep on pinging the >> + watchdog until it is opened. > > If you want to make this property generic, maybe you should document it > in a generic binding doc > (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). > Once you're at it, maybe you could document the generic timeout-sec > property in this file. > Moreover, you might want to parse this property in watchdog_core.c and > store the information in the watchdog_device struct. Yeah, I can take a look at it. Thanks, -Timo > Apart from that, I'm not opposed to the approach, and I'm fine with the > current implementation. > > Regards, > > Boris > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-11-28 6:42 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-11-28 6:42 UTC (permalink / raw) To: linux-arm-kernel Hi Boris, Thanks for the comments. On 27.11.2014 21:00, Boris Brezillon wrote: > Hi Timo, > > Sorry for the late reply. > > On Fri, 21 Nov 2014 14:23:30 +0200 > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >> By default the driver will start a kernel timer which keeps on kicking >> the watchdog HW until user space has opened the watchdog >> device. Usually this is desirable as the watchdog HW is running by >> default and the user space may not have any watchdog daemon running at >> all. >> >> However, on production systems it may be mandatory that also early >> crashes and lockups will lead to a watchdog reset, even if they happen >> before the user space has opened the watchdog device. >> >> To resolve the issue, add a new device tree property >> "enable-early-reset" which will prevent the kernel timer from pinging >> the watchdog HW on behalf of user space. The default is still to use >> kernel timer, but more strict behavior can be enabled via the device >> tree property. >> >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >> --- >> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >> 2 files changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> index f90e294..a0b7b75 100644 >> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> @@ -28,6 +28,10 @@ Optional properties: >> entering idle state. >> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >> entering debug state. >> +- enable-early-reset : Should be present if you want to let the >> + watchdog timer to expire even before user space has opened the >> + device. If not set, a kernel timer will keep on pinging the >> + watchdog until it is opened. > > If you want to make this property generic, maybe you should document it > in a generic binding doc > (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). > Once you're at it, maybe you could document the generic timeout-sec > property in this file. > Moreover, you might want to parse this property in watchdog_core.c and > store the information in the watchdog_device struct. Yeah, I can take a look at it. Thanks, -Timo > Apart from that, I'm not opposed to the approach, and I'm fine with the > current implementation. > > Regards, > > Boris > ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-11-27 19:00 ` Boris Brezillon @ 2014-12-05 12:57 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-12-05 12:57 UTC (permalink / raw) To: Boris Brezillon Cc: linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni On 27.11.2014 21:00, Boris Brezillon wrote: > Hi Timo, > > Sorry for the late reply. > > On Fri, 21 Nov 2014 14:23:30 +0200 > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >> By default the driver will start a kernel timer which keeps on kicking >> the watchdog HW until user space has opened the watchdog >> device. Usually this is desirable as the watchdog HW is running by >> default and the user space may not have any watchdog daemon running at >> all. >> >> However, on production systems it may be mandatory that also early >> crashes and lockups will lead to a watchdog reset, even if they happen >> before the user space has opened the watchdog device. >> >> To resolve the issue, add a new device tree property >> "enable-early-reset" which will prevent the kernel timer from pinging >> the watchdog HW on behalf of user space. The default is still to use >> kernel timer, but more strict behavior can be enabled via the device >> tree property. >> >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >> --- >> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >> 2 files changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> index f90e294..a0b7b75 100644 >> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> @@ -28,6 +28,10 @@ Optional properties: >> entering idle state. >> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >> entering debug state. >> +- enable-early-reset : Should be present if you want to let the >> + watchdog timer to expire even before user space has opened the >> + device. If not set, a kernel timer will keep on pinging the >> + watchdog until it is opened. > > If you want to make this property generic, maybe you should document it > in a generic binding doc > (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). > Once you're at it, maybe you could document the generic timeout-sec > property in this file. > Moreover, you might want to parse this property in watchdog_core.c and > store the information in the watchdog_device struct. I gave a little thought about this today and we could maybe have it like watchdog_init_timeout() is today. But I can't really think of any generic handling for this property, anything else except storing the parsed value to a variable in watchdog_device struct. Everything else is HW specific, except how we read the variable.. If we had some logic or checking for this variable (other than to check it is not negative) maybe then it would make sense. So I could write a patch to document generic watchdog properties in Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else generic that would go there except timeout-sec and enable-early-reset?) and change this patch so that it doesn't document anything in atmel-wdt.txt as we already have it documented in generic watchdog.txt. Sounds good? Thanks, -Timo > Apart from that, I'm not opposed to the approach, and I'm fine with the > current implementation. > > Regards, > > Boris > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-12-05 12:57 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-12-05 12:57 UTC (permalink / raw) To: linux-arm-kernel On 27.11.2014 21:00, Boris Brezillon wrote: > Hi Timo, > > Sorry for the late reply. > > On Fri, 21 Nov 2014 14:23:30 +0200 > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >> By default the driver will start a kernel timer which keeps on kicking >> the watchdog HW until user space has opened the watchdog >> device. Usually this is desirable as the watchdog HW is running by >> default and the user space may not have any watchdog daemon running at >> all. >> >> However, on production systems it may be mandatory that also early >> crashes and lockups will lead to a watchdog reset, even if they happen >> before the user space has opened the watchdog device. >> >> To resolve the issue, add a new device tree property >> "enable-early-reset" which will prevent the kernel timer from pinging >> the watchdog HW on behalf of user space. The default is still to use >> kernel timer, but more strict behavior can be enabled via the device >> tree property. >> >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >> --- >> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >> 2 files changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> index f90e294..a0b7b75 100644 >> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >> @@ -28,6 +28,10 @@ Optional properties: >> entering idle state. >> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >> entering debug state. >> +- enable-early-reset : Should be present if you want to let the >> + watchdog timer to expire even before user space has opened the >> + device. If not set, a kernel timer will keep on pinging the >> + watchdog until it is opened. > > If you want to make this property generic, maybe you should document it > in a generic binding doc > (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). > Once you're at it, maybe you could document the generic timeout-sec > property in this file. > Moreover, you might want to parse this property in watchdog_core.c and > store the information in the watchdog_device struct. I gave a little thought about this today and we could maybe have it like watchdog_init_timeout() is today. But I can't really think of any generic handling for this property, anything else except storing the parsed value to a variable in watchdog_device struct. Everything else is HW specific, except how we read the variable.. If we had some logic or checking for this variable (other than to check it is not negative) maybe then it would make sense. So I could write a patch to document generic watchdog properties in Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else generic that would go there except timeout-sec and enable-early-reset?) and change this patch so that it doesn't document anything in atmel-wdt.txt as we already have it documented in generic watchdog.txt. Sounds good? Thanks, -Timo > Apart from that, I'm not opposed to the approach, and I'm fine with the > current implementation. > > Regards, > > Boris > ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-12-05 12:57 ` Timo Kokkonen @ 2014-12-05 14:12 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2014-12-05 14:12 UTC (permalink / raw) To: Timo Kokkonen Cc: linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni Hi Timo, On Fri, 05 Dec 2014 14:57:05 +0200 Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > On 27.11.2014 21:00, Boris Brezillon wrote: > > Hi Timo, > > > > Sorry for the late reply. > > > > On Fri, 21 Nov 2014 14:23:30 +0200 > > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > > >> By default the driver will start a kernel timer which keeps on kicking > >> the watchdog HW until user space has opened the watchdog > >> device. Usually this is desirable as the watchdog HW is running by > >> default and the user space may not have any watchdog daemon running at > >> all. > >> > >> However, on production systems it may be mandatory that also early > >> crashes and lockups will lead to a watchdog reset, even if they happen > >> before the user space has opened the watchdog device. > >> > >> To resolve the issue, add a new device tree property > >> "enable-early-reset" which will prevent the kernel timer from pinging > >> the watchdog HW on behalf of user space. The default is still to use > >> kernel timer, but more strict behavior can be enabled via the device > >> tree property. > >> > >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > >> --- > >> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > >> drivers/watchdog/at91sam9_wdt.c | 6 +++++- > >> 2 files changed, 9 insertions(+), 1 deletion(-) > >> > >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >> index f90e294..a0b7b75 100644 > >> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >> @@ -28,6 +28,10 @@ Optional properties: > >> entering idle state. > >> - atmel,dbg-halt : Should be present if you want to stop the watchdog when > >> entering debug state. > >> +- enable-early-reset : Should be present if you want to let the > >> + watchdog timer to expire even before user space has opened the > >> + device. If not set, a kernel timer will keep on pinging the > >> + watchdog until it is opened. > > > > If you want to make this property generic, maybe you should document it > > in a generic binding doc > > (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). > > Once you're at it, maybe you could document the generic timeout-sec > > property in this file. > > Moreover, you might want to parse this property in watchdog_core.c and > > store the information in the watchdog_device struct. > > I gave a little thought about this today and we could maybe have it like > watchdog_init_timeout() is today. But I can't really think of any > generic handling for this property, anything else except storing the > parsed value to a variable in watchdog_device struct. Everything else is > HW specific, except how we read the variable.. If we had some logic or > checking for this variable (other than to check it is not negative) > maybe then it would make sense. Okay, I'm fine with keeping this DT property parsing out of the core. > > So I could write a patch to document generic watchdog properties in > Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else > generic that would go there except timeout-sec and enable-early-reset?) I'm not sure you and Guenter agreed on the 'early-keepalive-sec' property (and this one won't be used in atmel driver since you can't change the timeout once set), so I'd say the timeout-sec and enable-early-reset are the only common properties for now. > and change this patch so that it doesn't document anything in > atmel-wdt.txt as we already have it documented in generic watchdog.txt. > > Sounds good? Yes, sounds good to me. Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-12-05 14:12 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2014-12-05 14:12 UTC (permalink / raw) To: linux-arm-kernel Hi Timo, On Fri, 05 Dec 2014 14:57:05 +0200 Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > On 27.11.2014 21:00, Boris Brezillon wrote: > > Hi Timo, > > > > Sorry for the late reply. > > > > On Fri, 21 Nov 2014 14:23:30 +0200 > > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > > >> By default the driver will start a kernel timer which keeps on kicking > >> the watchdog HW until user space has opened the watchdog > >> device. Usually this is desirable as the watchdog HW is running by > >> default and the user space may not have any watchdog daemon running at > >> all. > >> > >> However, on production systems it may be mandatory that also early > >> crashes and lockups will lead to a watchdog reset, even if they happen > >> before the user space has opened the watchdog device. > >> > >> To resolve the issue, add a new device tree property > >> "enable-early-reset" which will prevent the kernel timer from pinging > >> the watchdog HW on behalf of user space. The default is still to use > >> kernel timer, but more strict behavior can be enabled via the device > >> tree property. > >> > >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > >> --- > >> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > >> drivers/watchdog/at91sam9_wdt.c | 6 +++++- > >> 2 files changed, 9 insertions(+), 1 deletion(-) > >> > >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >> index f90e294..a0b7b75 100644 > >> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >> @@ -28,6 +28,10 @@ Optional properties: > >> entering idle state. > >> - atmel,dbg-halt : Should be present if you want to stop the watchdog when > >> entering debug state. > >> +- enable-early-reset : Should be present if you want to let the > >> + watchdog timer to expire even before user space has opened the > >> + device. If not set, a kernel timer will keep on pinging the > >> + watchdog until it is opened. > > > > If you want to make this property generic, maybe you should document it > > in a generic binding doc > > (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). > > Once you're at it, maybe you could document the generic timeout-sec > > property in this file. > > Moreover, you might want to parse this property in watchdog_core.c and > > store the information in the watchdog_device struct. > > I gave a little thought about this today and we could maybe have it like > watchdog_init_timeout() is today. But I can't really think of any > generic handling for this property, anything else except storing the > parsed value to a variable in watchdog_device struct. Everything else is > HW specific, except how we read the variable.. If we had some logic or > checking for this variable (other than to check it is not negative) > maybe then it would make sense. Okay, I'm fine with keeping this DT property parsing out of the core. > > So I could write a patch to document generic watchdog properties in > Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else > generic that would go there except timeout-sec and enable-early-reset?) I'm not sure you and Guenter agreed on the 'early-keepalive-sec' property (and this one won't be used in atmel driver since you can't change the timeout once set), so I'd say the timeout-sec and enable-early-reset are the only common properties for now. > and change this patch so that it doesn't document anything in > atmel-wdt.txt as we already have it documented in generic watchdog.txt. > > Sounds good? Yes, sounds good to me. Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-12-05 14:12 ` Boris Brezillon @ 2014-12-05 18:42 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-12-05 18:42 UTC (permalink / raw) To: Boris Brezillon, linux Cc: linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni On 05.12.2014 16:12, Boris Brezillon wrote: > Hi Timo, > > On Fri, 05 Dec 2014 14:57:05 +0200 > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >> On 27.11.2014 21:00, Boris Brezillon wrote: >>> Hi Timo, >>> >>> Sorry for the late reply. >>> >>> On Fri, 21 Nov 2014 14:23:30 +0200 >>> Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: >>> >>>> By default the driver will start a kernel timer which keeps on kicking >>>> the watchdog HW until user space has opened the watchdog >>>> device. Usually this is desirable as the watchdog HW is running by >>>> default and the user space may not have any watchdog daemon running at >>>> all. >>>> >>>> However, on production systems it may be mandatory that also early >>>> crashes and lockups will lead to a watchdog reset, even if they happen >>>> before the user space has opened the watchdog device. >>>> >>>> To resolve the issue, add a new device tree property >>>> "enable-early-reset" which will prevent the kernel timer from pinging >>>> the watchdog HW on behalf of user space. The default is still to use >>>> kernel timer, but more strict behavior can be enabled via the device >>>> tree property. >>>> >>>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>>> --- >>>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >>>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >>>> 2 files changed, 9 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>> index f90e294..a0b7b75 100644 >>>> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>> @@ -28,6 +28,10 @@ Optional properties: >>>> entering idle state. >>>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >>>> entering debug state. >>>> +- enable-early-reset : Should be present if you want to let the >>>> + watchdog timer to expire even before user space has opened the >>>> + device. If not set, a kernel timer will keep on pinging the >>>> + watchdog until it is opened. >>> >>> If you want to make this property generic, maybe you should document it >>> in a generic binding doc >>> (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). >>> Once you're at it, maybe you could document the generic timeout-sec >>> property in this file. >>> Moreover, you might want to parse this property in watchdog_core.c and >>> store the information in the watchdog_device struct. >> >> I gave a little thought about this today and we could maybe have it like >> watchdog_init_timeout() is today. But I can't really think of any >> generic handling for this property, anything else except storing the >> parsed value to a variable in watchdog_device struct. Everything else is >> HW specific, except how we read the variable.. If we had some logic or >> checking for this variable (other than to check it is not negative) >> maybe then it would make sense. > > Okay, I'm fine with keeping this DT property parsing out of the core. Ok, good. >> >> So I could write a patch to document generic watchdog properties in >> Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else >> generic that would go there except timeout-sec and enable-early-reset?) > > I'm not sure you and Guenter agreed on the 'early-keepalive-sec' > property (and this one won't be used in atmel driver since you can't > change the timeout once set), so I'd say the timeout-sec and > enable-early-reset are the only common properties for now. Actually it can be done in Atmel driver as well. It already has a timer that keeps on pinging the watchdog until user space opens it. We just modify the code so that it keeps on pinging the watchdog until early-keepalive-sec has expired. No need to change the HW timeouts at all. And I rather have it implemented that way anyway, the 16 second timeout is a little tight if there happens to be a lot of stuff already in the early user space. Yeah, I didn't get anything back from Guenter about my early-keepalive-sec property proposal. Frankly, I already forgot about it my self already. I guess I'll get back to you with v3 set once I get time for it. Probably easiest to continue from there. Thanks for the feedback! -Timo >> and change this patch so that it doesn't document anything in >> atmel-wdt.txt as we already have it documented in generic watchdog.txt. >> >> Sounds good? > > Yes, sounds good to me. > > Regards, > > Boris > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-12-05 18:42 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-12-05 18:42 UTC (permalink / raw) To: linux-arm-kernel On 05.12.2014 16:12, Boris Brezillon wrote: > Hi Timo, > > On Fri, 05 Dec 2014 14:57:05 +0200 > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >> On 27.11.2014 21:00, Boris Brezillon wrote: >>> Hi Timo, >>> >>> Sorry for the late reply. >>> >>> On Fri, 21 Nov 2014 14:23:30 +0200 >>> Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: >>> >>>> By default the driver will start a kernel timer which keeps on kicking >>>> the watchdog HW until user space has opened the watchdog >>>> device. Usually this is desirable as the watchdog HW is running by >>>> default and the user space may not have any watchdog daemon running at >>>> all. >>>> >>>> However, on production systems it may be mandatory that also early >>>> crashes and lockups will lead to a watchdog reset, even if they happen >>>> before the user space has opened the watchdog device. >>>> >>>> To resolve the issue, add a new device tree property >>>> "enable-early-reset" which will prevent the kernel timer from pinging >>>> the watchdog HW on behalf of user space. The default is still to use >>>> kernel timer, but more strict behavior can be enabled via the device >>>> tree property. >>>> >>>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>>> --- >>>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >>>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >>>> 2 files changed, 9 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>> index f90e294..a0b7b75 100644 >>>> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>> @@ -28,6 +28,10 @@ Optional properties: >>>> entering idle state. >>>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >>>> entering debug state. >>>> +- enable-early-reset : Should be present if you want to let the >>>> + watchdog timer to expire even before user space has opened the >>>> + device. If not set, a kernel timer will keep on pinging the >>>> + watchdog until it is opened. >>> >>> If you want to make this property generic, maybe you should document it >>> in a generic binding doc >>> (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). >>> Once you're at it, maybe you could document the generic timeout-sec >>> property in this file. >>> Moreover, you might want to parse this property in watchdog_core.c and >>> store the information in the watchdog_device struct. >> >> I gave a little thought about this today and we could maybe have it like >> watchdog_init_timeout() is today. But I can't really think of any >> generic handling for this property, anything else except storing the >> parsed value to a variable in watchdog_device struct. Everything else is >> HW specific, except how we read the variable.. If we had some logic or >> checking for this variable (other than to check it is not negative) >> maybe then it would make sense. > > Okay, I'm fine with keeping this DT property parsing out of the core. Ok, good. >> >> So I could write a patch to document generic watchdog properties in >> Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else >> generic that would go there except timeout-sec and enable-early-reset?) > > I'm not sure you and Guenter agreed on the 'early-keepalive-sec' > property (and this one won't be used in atmel driver since you can't > change the timeout once set), so I'd say the timeout-sec and > enable-early-reset are the only common properties for now. Actually it can be done in Atmel driver as well. It already has a timer that keeps on pinging the watchdog until user space opens it. We just modify the code so that it keeps on pinging the watchdog until early-keepalive-sec has expired. No need to change the HW timeouts at all. And I rather have it implemented that way anyway, the 16 second timeout is a little tight if there happens to be a lot of stuff already in the early user space. Yeah, I didn't get anything back from Guenter about my early-keepalive-sec property proposal. Frankly, I already forgot about it my self already. I guess I'll get back to you with v3 set once I get time for it. Probably easiest to continue from there. Thanks for the feedback! -Timo >> and change this patch so that it doesn't document anything in >> atmel-wdt.txt as we already have it documented in generic watchdog.txt. >> >> Sounds good? > > Yes, sounds good to me. > > Regards, > > Boris > ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-12-05 18:42 ` Timo Kokkonen @ 2014-12-05 19:02 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2014-12-05 19:02 UTC (permalink / raw) To: Timo Kokkonen Cc: Boris Brezillon, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni On Fri, Dec 05, 2014 at 08:42:07PM +0200, Timo Kokkonen wrote: > On 05.12.2014 16:12, Boris Brezillon wrote: > >Hi Timo, > > > >On Fri, 05 Dec 2014 14:57:05 +0200 > >Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > > >>On 27.11.2014 21:00, Boris Brezillon wrote: > >>>Hi Timo, > >>> > >>>Sorry for the late reply. > >>> > >>>On Fri, 21 Nov 2014 14:23:30 +0200 > >>>Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >>> > >>>>By default the driver will start a kernel timer which keeps on kicking > >>>>the watchdog HW until user space has opened the watchdog > >>>>device. Usually this is desirable as the watchdog HW is running by > >>>>default and the user space may not have any watchdog daemon running at > >>>>all. > >>>> > >>>>However, on production systems it may be mandatory that also early > >>>>crashes and lockups will lead to a watchdog reset, even if they happen > >>>>before the user space has opened the watchdog device. > >>>> > >>>>To resolve the issue, add a new device tree property > >>>>"enable-early-reset" which will prevent the kernel timer from pinging > >>>>the watchdog HW on behalf of user space. The default is still to use > >>>>kernel timer, but more strict behavior can be enabled via the device > >>>>tree property. > >>>> > >>>>Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > >>>>--- > >>>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > >>>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- > >>>> 2 files changed, 9 insertions(+), 1 deletion(-) > >>>> > >>>>diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>index f90e294..a0b7b75 100644 > >>>>--- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>+++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>@@ -28,6 +28,10 @@ Optional properties: > >>>> entering idle state. > >>>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when > >>>> entering debug state. > >>>>+- enable-early-reset : Should be present if you want to let the > >>>>+ watchdog timer to expire even before user space has opened the > >>>>+ device. If not set, a kernel timer will keep on pinging the > >>>>+ watchdog until it is opened. > >>> > >>>If you want to make this property generic, maybe you should document it > >>>in a generic binding doc > >>>(Documentation/devicetree/bindings/watchdog/watchdog.txt ?). > >>>Once you're at it, maybe you could document the generic timeout-sec > >>>property in this file. > >>>Moreover, you might want to parse this property in watchdog_core.c and > >>>store the information in the watchdog_device struct. > >> > >>I gave a little thought about this today and we could maybe have it like > >>watchdog_init_timeout() is today. But I can't really think of any > >>generic handling for this property, anything else except storing the > >>parsed value to a variable in watchdog_device struct. Everything else is > >>HW specific, except how we read the variable.. If we had some logic or > >>checking for this variable (other than to check it is not negative) > >>maybe then it would make sense. > > > >Okay, I'm fine with keeping this DT property parsing out of the core. > > Ok, good. > > >> > >>So I could write a patch to document generic watchdog properties in > >>Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else > >>generic that would go there except timeout-sec and enable-early-reset?) > > > >I'm not sure you and Guenter agreed on the 'early-keepalive-sec' > >property (and this one won't be used in atmel driver since you can't > >change the timeout once set), so I'd say the timeout-sec and > >enable-early-reset are the only common properties for now. > > Actually it can be done in Atmel driver as well. It already has a > timer that keeps on pinging the watchdog until user space opens it. > We just modify the code so that it keeps on pinging the watchdog > until early-keepalive-sec has expired. No need to change the HW > timeouts at all. And I rather have it implemented that way anyway, > the 16 second timeout is a little tight if there happens to be a lot > of stuff already in the early user space. > > Yeah, I didn't get anything back from Guenter about my > early-keepalive-sec property proposal. Frankly, I already forgot > about it my self already. I guess I'll get back to you with v3 set > once I get time for it. Probably easiest to continue from there. > Sorry for that, folks. I have been a bit overwhelmed in the last cycle. early-timeout-sec seems to be the best property name to me right now. It is aligned with the existing timeout-sec. early-keepalive-sec seems kind of different just for the purpose of being different. Not sure about how to name enable-early-reset. I'd prefer to have something generic, even if only implemented in a single driver for now, but I don't really know right now what that might/should look like. Maybe just "enable-early" to indicate that the watchdog should be enabled during init ? Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-12-05 19:02 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2014-12-05 19:02 UTC (permalink / raw) To: linux-arm-kernel On Fri, Dec 05, 2014 at 08:42:07PM +0200, Timo Kokkonen wrote: > On 05.12.2014 16:12, Boris Brezillon wrote: > >Hi Timo, > > > >On Fri, 05 Dec 2014 14:57:05 +0200 > >Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > > >>On 27.11.2014 21:00, Boris Brezillon wrote: > >>>Hi Timo, > >>> > >>>Sorry for the late reply. > >>> > >>>On Fri, 21 Nov 2014 14:23:30 +0200 > >>>Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >>> > >>>>By default the driver will start a kernel timer which keeps on kicking > >>>>the watchdog HW until user space has opened the watchdog > >>>>device. Usually this is desirable as the watchdog HW is running by > >>>>default and the user space may not have any watchdog daemon running at > >>>>all. > >>>> > >>>>However, on production systems it may be mandatory that also early > >>>>crashes and lockups will lead to a watchdog reset, even if they happen > >>>>before the user space has opened the watchdog device. > >>>> > >>>>To resolve the issue, add a new device tree property > >>>>"enable-early-reset" which will prevent the kernel timer from pinging > >>>>the watchdog HW on behalf of user space. The default is still to use > >>>>kernel timer, but more strict behavior can be enabled via the device > >>>>tree property. > >>>> > >>>>Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > >>>>--- > >>>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > >>>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- > >>>> 2 files changed, 9 insertions(+), 1 deletion(-) > >>>> > >>>>diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>index f90e294..a0b7b75 100644 > >>>>--- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>+++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>@@ -28,6 +28,10 @@ Optional properties: > >>>> entering idle state. > >>>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when > >>>> entering debug state. > >>>>+- enable-early-reset : Should be present if you want to let the > >>>>+ watchdog timer to expire even before user space has opened the > >>>>+ device. If not set, a kernel timer will keep on pinging the > >>>>+ watchdog until it is opened. > >>> > >>>If you want to make this property generic, maybe you should document it > >>>in a generic binding doc > >>>(Documentation/devicetree/bindings/watchdog/watchdog.txt ?). > >>>Once you're at it, maybe you could document the generic timeout-sec > >>>property in this file. > >>>Moreover, you might want to parse this property in watchdog_core.c and > >>>store the information in the watchdog_device struct. > >> > >>I gave a little thought about this today and we could maybe have it like > >>watchdog_init_timeout() is today. But I can't really think of any > >>generic handling for this property, anything else except storing the > >>parsed value to a variable in watchdog_device struct. Everything else is > >>HW specific, except how we read the variable.. If we had some logic or > >>checking for this variable (other than to check it is not negative) > >>maybe then it would make sense. > > > >Okay, I'm fine with keeping this DT property parsing out of the core. > > Ok, good. > > >> > >>So I could write a patch to document generic watchdog properties in > >>Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else > >>generic that would go there except timeout-sec and enable-early-reset?) > > > >I'm not sure you and Guenter agreed on the 'early-keepalive-sec' > >property (and this one won't be used in atmel driver since you can't > >change the timeout once set), so I'd say the timeout-sec and > >enable-early-reset are the only common properties for now. > > Actually it can be done in Atmel driver as well. It already has a > timer that keeps on pinging the watchdog until user space opens it. > We just modify the code so that it keeps on pinging the watchdog > until early-keepalive-sec has expired. No need to change the HW > timeouts at all. And I rather have it implemented that way anyway, > the 16 second timeout is a little tight if there happens to be a lot > of stuff already in the early user space. > > Yeah, I didn't get anything back from Guenter about my > early-keepalive-sec property proposal. Frankly, I already forgot > about it my self already. I guess I'll get back to you with v3 set > once I get time for it. Probably easiest to continue from there. > Sorry for that, folks. I have been a bit overwhelmed in the last cycle. early-timeout-sec seems to be the best property name to me right now. It is aligned with the existing timeout-sec. early-keepalive-sec seems kind of different just for the purpose of being different. Not sure about how to name enable-early-reset. I'd prefer to have something generic, even if only implemented in a single driver for now, but I don't really know right now what that might/should look like. Maybe just "enable-early" to indicate that the watchdog should be enabled during init ? Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-12-05 19:02 ` Guenter Roeck @ 2014-12-05 20:32 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-12-05 20:32 UTC (permalink / raw) To: Guenter Roeck Cc: Boris Brezillon, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni On 05.12.2014 21:02, Guenter Roeck wrote: > On Fri, Dec 05, 2014 at 08:42:07PM +0200, Timo Kokkonen wrote: >> On 05.12.2014 16:12, Boris Brezillon wrote: >>> Hi Timo, >>> >>> On Fri, 05 Dec 2014 14:57:05 +0200 >>> Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: >>> >>>> On 27.11.2014 21:00, Boris Brezillon wrote: >>>>> Hi Timo, >>>>> >>>>> Sorry for the late reply. >>>>> >>>>> On Fri, 21 Nov 2014 14:23:30 +0200 >>>>> Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: >>>>> >>>>>> By default the driver will start a kernel timer which keeps on kicking >>>>>> the watchdog HW until user space has opened the watchdog >>>>>> device. Usually this is desirable as the watchdog HW is running by >>>>>> default and the user space may not have any watchdog daemon running at >>>>>> all. >>>>>> >>>>>> However, on production systems it may be mandatory that also early >>>>>> crashes and lockups will lead to a watchdog reset, even if they happen >>>>>> before the user space has opened the watchdog device. >>>>>> >>>>>> To resolve the issue, add a new device tree property >>>>>> "enable-early-reset" which will prevent the kernel timer from pinging >>>>>> the watchdog HW on behalf of user space. The default is still to use >>>>>> kernel timer, but more strict behavior can be enabled via the device >>>>>> tree property. >>>>>> >>>>>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>>>>> --- >>>>>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >>>>>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >>>>>> 2 files changed, 9 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>>>> index f90e294..a0b7b75 100644 >>>>>> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>>>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>>>> @@ -28,6 +28,10 @@ Optional properties: >>>>>> entering idle state. >>>>>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >>>>>> entering debug state. >>>>>> +- enable-early-reset : Should be present if you want to let the >>>>>> + watchdog timer to expire even before user space has opened the >>>>>> + device. If not set, a kernel timer will keep on pinging the >>>>>> + watchdog until it is opened. >>>>> >>>>> If you want to make this property generic, maybe you should document it >>>>> in a generic binding doc >>>>> (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). >>>>> Once you're at it, maybe you could document the generic timeout-sec >>>>> property in this file. >>>>> Moreover, you might want to parse this property in watchdog_core.c and >>>>> store the information in the watchdog_device struct. >>>> >>>> I gave a little thought about this today and we could maybe have it like >>>> watchdog_init_timeout() is today. But I can't really think of any >>>> generic handling for this property, anything else except storing the >>>> parsed value to a variable in watchdog_device struct. Everything else is >>>> HW specific, except how we read the variable.. If we had some logic or >>>> checking for this variable (other than to check it is not negative) >>>> maybe then it would make sense. >>> >>> Okay, I'm fine with keeping this DT property parsing out of the core. >> >> Ok, good. >> >>>> >>>> So I could write a patch to document generic watchdog properties in >>>> Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else >>>> generic that would go there except timeout-sec and enable-early-reset?) >>> >>> I'm not sure you and Guenter agreed on the 'early-keepalive-sec' >>> property (and this one won't be used in atmel driver since you can't >>> change the timeout once set), so I'd say the timeout-sec and >>> enable-early-reset are the only common properties for now. >> >> Actually it can be done in Atmel driver as well. It already has a >> timer that keeps on pinging the watchdog until user space opens it. >> We just modify the code so that it keeps on pinging the watchdog >> until early-keepalive-sec has expired. No need to change the HW >> timeouts at all. And I rather have it implemented that way anyway, >> the 16 second timeout is a little tight if there happens to be a lot >> of stuff already in the early user space. >> >> Yeah, I didn't get anything back from Guenter about my >> early-keepalive-sec property proposal. Frankly, I already forgot >> about it my self already. I guess I'll get back to you with v3 set >> once I get time for it. Probably easiest to continue from there. >> > Sorry for that, folks. I have been a bit overwhelmed in the last cycle. > > early-timeout-sec seems to be the best property name to me right now. > It is aligned with the existing timeout-sec. early-keepalive-sec seems > kind of different just for the purpose of being different. early-timeout-sec sounds good to me. I'll go with that. > Not sure about how to name enable-early-reset. I'd prefer to have something > generic, even if only implemented in a single driver for now, but I don't > really know right now what that might/should look like. Maybe just > "enable-early" to indicate that the watchdog should be enabled during init ? Do we need the enable-early or such property at all? Just leave early-timeout-sec to zero and then let it behave just like enable-early would do? -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-12-05 20:32 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-12-05 20:32 UTC (permalink / raw) To: linux-arm-kernel On 05.12.2014 21:02, Guenter Roeck wrote: > On Fri, Dec 05, 2014 at 08:42:07PM +0200, Timo Kokkonen wrote: >> On 05.12.2014 16:12, Boris Brezillon wrote: >>> Hi Timo, >>> >>> On Fri, 05 Dec 2014 14:57:05 +0200 >>> Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: >>> >>>> On 27.11.2014 21:00, Boris Brezillon wrote: >>>>> Hi Timo, >>>>> >>>>> Sorry for the late reply. >>>>> >>>>> On Fri, 21 Nov 2014 14:23:30 +0200 >>>>> Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: >>>>> >>>>>> By default the driver will start a kernel timer which keeps on kicking >>>>>> the watchdog HW until user space has opened the watchdog >>>>>> device. Usually this is desirable as the watchdog HW is running by >>>>>> default and the user space may not have any watchdog daemon running at >>>>>> all. >>>>>> >>>>>> However, on production systems it may be mandatory that also early >>>>>> crashes and lockups will lead to a watchdog reset, even if they happen >>>>>> before the user space has opened the watchdog device. >>>>>> >>>>>> To resolve the issue, add a new device tree property >>>>>> "enable-early-reset" which will prevent the kernel timer from pinging >>>>>> the watchdog HW on behalf of user space. The default is still to use >>>>>> kernel timer, but more strict behavior can be enabled via the device >>>>>> tree property. >>>>>> >>>>>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>>>>> --- >>>>>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ >>>>>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- >>>>>> 2 files changed, 9 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>>>> index f90e294..a0b7b75 100644 >>>>>> --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>>>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt >>>>>> @@ -28,6 +28,10 @@ Optional properties: >>>>>> entering idle state. >>>>>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when >>>>>> entering debug state. >>>>>> +- enable-early-reset : Should be present if you want to let the >>>>>> + watchdog timer to expire even before user space has opened the >>>>>> + device. If not set, a kernel timer will keep on pinging the >>>>>> + watchdog until it is opened. >>>>> >>>>> If you want to make this property generic, maybe you should document it >>>>> in a generic binding doc >>>>> (Documentation/devicetree/bindings/watchdog/watchdog.txt ?). >>>>> Once you're at it, maybe you could document the generic timeout-sec >>>>> property in this file. >>>>> Moreover, you might want to parse this property in watchdog_core.c and >>>>> store the information in the watchdog_device struct. >>>> >>>> I gave a little thought about this today and we could maybe have it like >>>> watchdog_init_timeout() is today. But I can't really think of any >>>> generic handling for this property, anything else except storing the >>>> parsed value to a variable in watchdog_device struct. Everything else is >>>> HW specific, except how we read the variable.. If we had some logic or >>>> checking for this variable (other than to check it is not negative) >>>> maybe then it would make sense. >>> >>> Okay, I'm fine with keeping this DT property parsing out of the core. >> >> Ok, good. >> >>>> >>>> So I could write a patch to document generic watchdog properties in >>>> Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else >>>> generic that would go there except timeout-sec and enable-early-reset?) >>> >>> I'm not sure you and Guenter agreed on the 'early-keepalive-sec' >>> property (and this one won't be used in atmel driver since you can't >>> change the timeout once set), so I'd say the timeout-sec and >>> enable-early-reset are the only common properties for now. >> >> Actually it can be done in Atmel driver as well. It already has a >> timer that keeps on pinging the watchdog until user space opens it. >> We just modify the code so that it keeps on pinging the watchdog >> until early-keepalive-sec has expired. No need to change the HW >> timeouts at all. And I rather have it implemented that way anyway, >> the 16 second timeout is a little tight if there happens to be a lot >> of stuff already in the early user space. >> >> Yeah, I didn't get anything back from Guenter about my >> early-keepalive-sec property proposal. Frankly, I already forgot >> about it my self already. I guess I'll get back to you with v3 set >> once I get time for it. Probably easiest to continue from there. >> > Sorry for that, folks. I have been a bit overwhelmed in the last cycle. > > early-timeout-sec seems to be the best property name to me right now. > It is aligned with the existing timeout-sec. early-keepalive-sec seems > kind of different just for the purpose of being different. early-timeout-sec sounds good to me. I'll go with that. > Not sure about how to name enable-early-reset. I'd prefer to have something > generic, even if only implemented in a single driver for now, but I don't > really know right now what that might/should look like. Maybe just > "enable-early" to indicate that the watchdog should be enabled during init ? Do we need the enable-early or such property at all? Just leave early-timeout-sec to zero and then let it behave just like enable-early would do? -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-12-05 20:32 ` Timo Kokkonen @ 2014-12-05 21:39 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2014-12-05 21:39 UTC (permalink / raw) To: Timo Kokkonen Cc: Boris Brezillon, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni On Fri, Dec 05, 2014 at 10:32:48PM +0200, Timo Kokkonen wrote: > On 05.12.2014 21:02, Guenter Roeck wrote: > >On Fri, Dec 05, 2014 at 08:42:07PM +0200, Timo Kokkonen wrote: > >>On 05.12.2014 16:12, Boris Brezillon wrote: > >>>Hi Timo, > >>> > >>>On Fri, 05 Dec 2014 14:57:05 +0200 > >>>Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >>> > >>>>On 27.11.2014 21:00, Boris Brezillon wrote: > >>>>>Hi Timo, > >>>>> > >>>>>Sorry for the late reply. > >>>>> > >>>>>On Fri, 21 Nov 2014 14:23:30 +0200 > >>>>>Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >>>>> > >>>>>>By default the driver will start a kernel timer which keeps on kicking > >>>>>>the watchdog HW until user space has opened the watchdog > >>>>>>device. Usually this is desirable as the watchdog HW is running by > >>>>>>default and the user space may not have any watchdog daemon running at > >>>>>>all. > >>>>>> > >>>>>>However, on production systems it may be mandatory that also early > >>>>>>crashes and lockups will lead to a watchdog reset, even if they happen > >>>>>>before the user space has opened the watchdog device. > >>>>>> > >>>>>>To resolve the issue, add a new device tree property > >>>>>>"enable-early-reset" which will prevent the kernel timer from pinging > >>>>>>the watchdog HW on behalf of user space. The default is still to use > >>>>>>kernel timer, but more strict behavior can be enabled via the device > >>>>>>tree property. > >>>>>> > >>>>>>Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > >>>>>>--- > >>>>>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > >>>>>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- > >>>>>> 2 files changed, 9 insertions(+), 1 deletion(-) > >>>>>> > >>>>>>diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>>>index f90e294..a0b7b75 100644 > >>>>>>--- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>>>+++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>>>@@ -28,6 +28,10 @@ Optional properties: > >>>>>> entering idle state. > >>>>>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when > >>>>>> entering debug state. > >>>>>>+- enable-early-reset : Should be present if you want to let the > >>>>>>+ watchdog timer to expire even before user space has opened the > >>>>>>+ device. If not set, a kernel timer will keep on pinging the > >>>>>>+ watchdog until it is opened. > >>>>> > >>>>>If you want to make this property generic, maybe you should document it > >>>>>in a generic binding doc > >>>>>(Documentation/devicetree/bindings/watchdog/watchdog.txt ?). > >>>>>Once you're at it, maybe you could document the generic timeout-sec > >>>>>property in this file. > >>>>>Moreover, you might want to parse this property in watchdog_core.c and > >>>>>store the information in the watchdog_device struct. > >>>> > >>>>I gave a little thought about this today and we could maybe have it like > >>>>watchdog_init_timeout() is today. But I can't really think of any > >>>>generic handling for this property, anything else except storing the > >>>>parsed value to a variable in watchdog_device struct. Everything else is > >>>>HW specific, except how we read the variable.. If we had some logic or > >>>>checking for this variable (other than to check it is not negative) > >>>>maybe then it would make sense. > >>> > >>>Okay, I'm fine with keeping this DT property parsing out of the core. > >> > >>Ok, good. > >> > >>>> > >>>>So I could write a patch to document generic watchdog properties in > >>>>Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else > >>>>generic that would go there except timeout-sec and enable-early-reset?) > >>> > >>>I'm not sure you and Guenter agreed on the 'early-keepalive-sec' > >>>property (and this one won't be used in atmel driver since you can't > >>>change the timeout once set), so I'd say the timeout-sec and > >>>enable-early-reset are the only common properties for now. > >> > >>Actually it can be done in Atmel driver as well. It already has a > >>timer that keeps on pinging the watchdog until user space opens it. > >>We just modify the code so that it keeps on pinging the watchdog > >>until early-keepalive-sec has expired. No need to change the HW > >>timeouts at all. And I rather have it implemented that way anyway, > >>the 16 second timeout is a little tight if there happens to be a lot > >>of stuff already in the early user space. > >> > >>Yeah, I didn't get anything back from Guenter about my > >>early-keepalive-sec property proposal. Frankly, I already forgot > >>about it my self already. I guess I'll get back to you with v3 set > >>once I get time for it. Probably easiest to continue from there. > >> > >Sorry for that, folks. I have been a bit overwhelmed in the last cycle. > > > >early-timeout-sec seems to be the best property name to me right now. > >It is aligned with the existing timeout-sec. early-keepalive-sec seems > >kind of different just for the purpose of being different. > > early-timeout-sec sounds good to me. I'll go with that. > > >Not sure about how to name enable-early-reset. I'd prefer to have something > >generic, even if only implemented in a single driver for now, but I don't > >really know right now what that might/should look like. Maybe just > >"enable-early" to indicate that the watchdog should be enabled during init ? > > Do we need the enable-early or such property at all? Just leave > early-timeout-sec to zero and then let it behave just like > enable-early would do? > Problem is that the possible conditions are all over the place for "early" watchdog handling. - Disable watchdog - Enable watchdog (or keep it enabled), and keep it alive until user space kicks in (ie possibly forever) - Enable watchdog or keep it enabled, and keep it alive for a specified period of time. - Keep watchdog enabled if it is already enabled, otherwise keep it disabled. There are probably more conditions which I don't recall right now. Which of those conditions would you address with "early-timeout = <0>;" ? "enable watchdog early and keep it alive until user space kicks in", or "keep watchdog enabled if already running, and set specified early timeout" ? One could argue either way which one of the two meanings it should be. Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-12-05 21:39 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2014-12-05 21:39 UTC (permalink / raw) To: linux-arm-kernel On Fri, Dec 05, 2014 at 10:32:48PM +0200, Timo Kokkonen wrote: > On 05.12.2014 21:02, Guenter Roeck wrote: > >On Fri, Dec 05, 2014 at 08:42:07PM +0200, Timo Kokkonen wrote: > >>On 05.12.2014 16:12, Boris Brezillon wrote: > >>>Hi Timo, > >>> > >>>On Fri, 05 Dec 2014 14:57:05 +0200 > >>>Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >>> > >>>>On 27.11.2014 21:00, Boris Brezillon wrote: > >>>>>Hi Timo, > >>>>> > >>>>>Sorry for the late reply. > >>>>> > >>>>>On Fri, 21 Nov 2014 14:23:30 +0200 > >>>>>Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >>>>> > >>>>>>By default the driver will start a kernel timer which keeps on kicking > >>>>>>the watchdog HW until user space has opened the watchdog > >>>>>>device. Usually this is desirable as the watchdog HW is running by > >>>>>>default and the user space may not have any watchdog daemon running at > >>>>>>all. > >>>>>> > >>>>>>However, on production systems it may be mandatory that also early > >>>>>>crashes and lockups will lead to a watchdog reset, even if they happen > >>>>>>before the user space has opened the watchdog device. > >>>>>> > >>>>>>To resolve the issue, add a new device tree property > >>>>>>"enable-early-reset" which will prevent the kernel timer from pinging > >>>>>>the watchdog HW on behalf of user space. The default is still to use > >>>>>>kernel timer, but more strict behavior can be enabled via the device > >>>>>>tree property. > >>>>>> > >>>>>>Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > >>>>>>--- > >>>>>> Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++ > >>>>>> drivers/watchdog/at91sam9_wdt.c | 6 +++++- > >>>>>> 2 files changed, 9 insertions(+), 1 deletion(-) > >>>>>> > >>>>>>diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>>>index f90e294..a0b7b75 100644 > >>>>>>--- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>>>+++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt > >>>>>>@@ -28,6 +28,10 @@ Optional properties: > >>>>>> entering idle state. > >>>>>> - atmel,dbg-halt : Should be present if you want to stop the watchdog when > >>>>>> entering debug state. > >>>>>>+- enable-early-reset : Should be present if you want to let the > >>>>>>+ watchdog timer to expire even before user space has opened the > >>>>>>+ device. If not set, a kernel timer will keep on pinging the > >>>>>>+ watchdog until it is opened. > >>>>> > >>>>>If you want to make this property generic, maybe you should document it > >>>>>in a generic binding doc > >>>>>(Documentation/devicetree/bindings/watchdog/watchdog.txt ?). > >>>>>Once you're at it, maybe you could document the generic timeout-sec > >>>>>property in this file. > >>>>>Moreover, you might want to parse this property in watchdog_core.c and > >>>>>store the information in the watchdog_device struct. > >>>> > >>>>I gave a little thought about this today and we could maybe have it like > >>>>watchdog_init_timeout() is today. But I can't really think of any > >>>>generic handling for this property, anything else except storing the > >>>>parsed value to a variable in watchdog_device struct. Everything else is > >>>>HW specific, except how we read the variable.. If we had some logic or > >>>>checking for this variable (other than to check it is not negative) > >>>>maybe then it would make sense. > >>> > >>>Okay, I'm fine with keeping this DT property parsing out of the core. > >> > >>Ok, good. > >> > >>>> > >>>>So I could write a patch to document generic watchdog properties in > >>>>Documentation/devicetree/bindings/watchdog/watchdog.txt (anything else > >>>>generic that would go there except timeout-sec and enable-early-reset?) > >>> > >>>I'm not sure you and Guenter agreed on the 'early-keepalive-sec' > >>>property (and this one won't be used in atmel driver since you can't > >>>change the timeout once set), so I'd say the timeout-sec and > >>>enable-early-reset are the only common properties for now. > >> > >>Actually it can be done in Atmel driver as well. It already has a > >>timer that keeps on pinging the watchdog until user space opens it. > >>We just modify the code so that it keeps on pinging the watchdog > >>until early-keepalive-sec has expired. No need to change the HW > >>timeouts at all. And I rather have it implemented that way anyway, > >>the 16 second timeout is a little tight if there happens to be a lot > >>of stuff already in the early user space. > >> > >>Yeah, I didn't get anything back from Guenter about my > >>early-keepalive-sec property proposal. Frankly, I already forgot > >>about it my self already. I guess I'll get back to you with v3 set > >>once I get time for it. Probably easiest to continue from there. > >> > >Sorry for that, folks. I have been a bit overwhelmed in the last cycle. > > > >early-timeout-sec seems to be the best property name to me right now. > >It is aligned with the existing timeout-sec. early-keepalive-sec seems > >kind of different just for the purpose of being different. > > early-timeout-sec sounds good to me. I'll go with that. > > >Not sure about how to name enable-early-reset. I'd prefer to have something > >generic, even if only implemented in a single driver for now, but I don't > >really know right now what that might/should look like. Maybe just > >"enable-early" to indicate that the watchdog should be enabled during init ? > > Do we need the enable-early or such property at all? Just leave > early-timeout-sec to zero and then let it behave just like > enable-early would do? > Problem is that the possible conditions are all over the place for "early" watchdog handling. - Disable watchdog - Enable watchdog (or keep it enabled), and keep it alive until user space kicks in (ie possibly forever) - Enable watchdog or keep it enabled, and keep it alive for a specified period of time. - Keep watchdog enabled if it is already enabled, otherwise keep it disabled. There are probably more conditions which I don't recall right now. Which of those conditions would you address with "early-timeout = <0>;" ? "enable watchdog early and keep it alive until user space kicks in", or "keep watchdog enabled if already running, and set specified early timeout" ? One could argue either way which one of the two meanings it should be. Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-12-05 21:39 ` Guenter Roeck @ 2014-12-06 10:11 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-12-06 10:11 UTC (permalink / raw) To: Guenter Roeck Cc: Boris Brezillon, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni On 05.12.2014 23:39, Guenter Roeck wrote: > On Fri, Dec 05, 2014 at 10:32:48PM +0200, Timo Kokkonen wrote: >> On 05.12.2014 21:02, Guenter Roeck wrote: >>> Not sure about how to name enable-early-reset. I'd prefer to have something >>> generic, even if only implemented in a single driver for now, but I don't >>> really know right now what that might/should look like. Maybe just >>> "enable-early" to indicate that the watchdog should be enabled during init ? >> >> Do we need the enable-early or such property at all? Just leave >> early-timeout-sec to zero and then let it behave just like >> enable-early would do? >> > > Problem is that the possible conditions are all over the place > for "early" watchdog handling. > > - Disable watchdog > - Enable watchdog (or keep it enabled), and keep it alive > until user space kicks in (ie possibly forever) > - Enable watchdog or keep it enabled, and keep it alive > for a specified period of time. > - Keep watchdog enabled if it is already enabled, otherwise > keep it disabled. > > There are probably more conditions which I don't recall right now. > Which of those conditions would you address with "early-timeout = <0>;" ? > "enable watchdog early and keep it alive until user space kicks in", > or "keep watchdog enabled if already running, and set specified early > timeout" ? One could argue either way which one of the two meanings > it should be. Okay, let me elaborate my point of view a bit. The use case we are concerned about is that we have a device that we rather not let freeze up at any point. This is what we use the watchdog for. The only missing corner case right now is the point where kernel driver initializes the watchdog hardware and pings it on behalf of user space until a watchdog daemon opens it and starts kicking. This is kind of bad as kernel might lock up or user space might crash before we get to the point where the daemon starts taking care of petting the watchdog. So this is what we are trying to fix. Right. Some other hardware behave differently to the one in Atmel. They might have watchdog stopped by bootloader or it might not be running at all until someone starts it. What do do with such case? If we are still concerned about the same use case I described above, I would say the reasonable thing to do is to make sure the watchdog is started as early as possible and not stopped at any point at all, if possible. If it needs to be explicitly enabled, bootloader should do it. If it didn't do it, then kernel should do it. Now that I think of it, what we really are interested in is to defer starting of the watchdog to give user space more time to start up. In Atmel HW it's more tricky as the driver can't be stopped. And in other hardware we could simply disable it altogether until we enable it after specific timeout, but we might crash before the timeout expires, in which case we would not get a chance to enable it. So the right thing to do is to enable the watchdog as early as possible, kick it on behalf of the user space until the timeout expires. Special case would be when the timeout is zero, when we just ensure watchdog is running but we don't do anything to prolong the first expiration. I can't think of any other use case someone would be interested in, but I'm positive that there are plenty of products on the market right now that have the requirement for race free guarantee that watchdog never stops. So given the conditions you listed, what I think is really important to fix is "Enable watchdog or keep it enabled, and keep it alive for a specified period of time". The only other choice we have right now is "Disable watchdog and let user space enabled it later, if ever". Yeah, maybe we could cover those other use cases too. Maybe someone is using bootloader to decide what to do with watchdog and kernel should somehow respect that. I don't know if that makes sense or if it would be reasonable assumption.. Any more thoughts? Thanks, -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2014-12-06 10:11 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2014-12-06 10:11 UTC (permalink / raw) To: linux-arm-kernel On 05.12.2014 23:39, Guenter Roeck wrote: > On Fri, Dec 05, 2014 at 10:32:48PM +0200, Timo Kokkonen wrote: >> On 05.12.2014 21:02, Guenter Roeck wrote: >>> Not sure about how to name enable-early-reset. I'd prefer to have something >>> generic, even if only implemented in a single driver for now, but I don't >>> really know right now what that might/should look like. Maybe just >>> "enable-early" to indicate that the watchdog should be enabled during init ? >> >> Do we need the enable-early or such property at all? Just leave >> early-timeout-sec to zero and then let it behave just like >> enable-early would do? >> > > Problem is that the possible conditions are all over the place > for "early" watchdog handling. > > - Disable watchdog > - Enable watchdog (or keep it enabled), and keep it alive > until user space kicks in (ie possibly forever) > - Enable watchdog or keep it enabled, and keep it alive > for a specified period of time. > - Keep watchdog enabled if it is already enabled, otherwise > keep it disabled. > > There are probably more conditions which I don't recall right now. > Which of those conditions would you address with "early-timeout = <0>;" ? > "enable watchdog early and keep it alive until user space kicks in", > or "keep watchdog enabled if already running, and set specified early > timeout" ? One could argue either way which one of the two meanings > it should be. Okay, let me elaborate my point of view a bit. The use case we are concerned about is that we have a device that we rather not let freeze up at any point. This is what we use the watchdog for. The only missing corner case right now is the point where kernel driver initializes the watchdog hardware and pings it on behalf of user space until a watchdog daemon opens it and starts kicking. This is kind of bad as kernel might lock up or user space might crash before we get to the point where the daemon starts taking care of petting the watchdog. So this is what we are trying to fix. Right. Some other hardware behave differently to the one in Atmel. They might have watchdog stopped by bootloader or it might not be running at all until someone starts it. What do do with such case? If we are still concerned about the same use case I described above, I would say the reasonable thing to do is to make sure the watchdog is started as early as possible and not stopped at any point at all, if possible. If it needs to be explicitly enabled, bootloader should do it. If it didn't do it, then kernel should do it. Now that I think of it, what we really are interested in is to defer starting of the watchdog to give user space more time to start up. In Atmel HW it's more tricky as the driver can't be stopped. And in other hardware we could simply disable it altogether until we enable it after specific timeout, but we might crash before the timeout expires, in which case we would not get a chance to enable it. So the right thing to do is to enable the watchdog as early as possible, kick it on behalf of the user space until the timeout expires. Special case would be when the timeout is zero, when we just ensure watchdog is running but we don't do anything to prolong the first expiration. I can't think of any other use case someone would be interested in, but I'm positive that there are plenty of products on the market right now that have the requirement for race free guarantee that watchdog never stops. So given the conditions you listed, what I think is really important to fix is "Enable watchdog or keep it enabled, and keep it alive for a specified period of time". The only other choice we have right now is "Disable watchdog and let user space enabled it later, if ever". Yeah, maybe we could cover those other use cases too. Maybe someone is using bootloader to decide what to do with watchdog and kernel should somehow respect that. I don't know if that makes sense or if it would be reasonable assumption.. Any more thoughts? Thanks, -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2014-12-06 10:11 ` Timo Kokkonen @ 2015-01-13 14:53 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-01-13 14:53 UTC (permalink / raw) To: Timo Kokkonen Cc: Boris Brezillon, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni On 12/06/2014 02:11 AM, Timo Kokkonen wrote: > On 05.12.2014 23:39, Guenter Roeck wrote: >> On Fri, Dec 05, 2014 at 10:32:48PM +0200, Timo Kokkonen wrote: >>> On 05.12.2014 21:02, Guenter Roeck wrote: > >>>> Not sure about how to name enable-early-reset. I'd prefer to have something >>>> generic, even if only implemented in a single driver for now, but I don't >>>> really know right now what that might/should look like. Maybe just >>>> "enable-early" to indicate that the watchdog should be enabled during init ? >>> >>> Do we need the enable-early or such property at all? Just leave >>> early-timeout-sec to zero and then let it behave just like >>> enable-early would do? >>> >> >> Problem is that the possible conditions are all over the place >> for "early" watchdog handling. >> >> - Disable watchdog >> - Enable watchdog (or keep it enabled), and keep it alive >> until user space kicks in (ie possibly forever) >> - Enable watchdog or keep it enabled, and keep it alive >> for a specified period of time. >> - Keep watchdog enabled if it is already enabled, otherwise >> keep it disabled. >> >> There are probably more conditions which I don't recall right now. >> Which of those conditions would you address with "early-timeout = <0>;" ? >> "enable watchdog early and keep it alive until user space kicks in", >> or "keep watchdog enabled if already running, and set specified early >> timeout" ? One could argue either way which one of the two meanings >> it should be. > > Okay, let me elaborate my point of view a bit. > > The use case we are concerned about is that we have a device that we rather not let freeze up at any point. This is what we use the watchdog for. The only missing corner case right now is the point where kernel driver initializes the watchdog hardware and pings it on behalf of user space until a watchdog daemon opens it and starts kicking. This is kind of bad as kernel might lock up or user space might crash before we get to the point where the daemon starts taking care of petting the watchdog. So this is what we are trying to fix. > > Right. Some other hardware behave differently to the one in Atmel. They might have watchdog stopped by bootloader or it might not be running at all until someone starts it. What do do with such case? If we are still concerned about the same use case I described above, I would say the reasonable thing to do is to make sure the watchdog is started as early as possible and not stopped at any point at all, if possible. If it needs to be explicitly enabled, bootloader should do it. If it didn't do it, then kernel should do it. > > Now that I think of it, what we really are interested in is to defer starting of the watchdog to give user space more time to start up. In Atmel HW it's more tricky as the driver can't be stopped. And in other hardware we could simply disable it altogether until we enable it after specific timeout, but we might crash before the timeout expires, in which case we would not get a chance to enable it. So the right thing to do is to enable the watchdog as early as possible, kick it on behalf of the user space until the timeout expires. Special case would be when the timeout is zero, when we just ensure watchdog is running but we don't do anything to prolong the first expiration. > > I can't think of any other use case someone would be interested in, but I'm positive that there are plenty of products on the market right now that have the requirement for race free guarantee that watchdog never stops. > > So given the conditions you listed, what I think is really important to fix is "Enable watchdog or keep it enabled, and keep it alive for a specified period of time". The only other choice we have right now is "Disable watchdog and let user space enabled it later, if ever". Yeah, maybe we could cover those other use cases too. Maybe someone is using bootloader to decide what to do with watchdog and kernel should somehow respect that. I don't know if that makes sense or if it would be reasonable assumption.. > > Any more thoughts? > To make progress, can you update the patch using early-timeout-sec as discussed ? Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-01-13 14:53 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-01-13 14:53 UTC (permalink / raw) To: linux-arm-kernel On 12/06/2014 02:11 AM, Timo Kokkonen wrote: > On 05.12.2014 23:39, Guenter Roeck wrote: >> On Fri, Dec 05, 2014 at 10:32:48PM +0200, Timo Kokkonen wrote: >>> On 05.12.2014 21:02, Guenter Roeck wrote: > >>>> Not sure about how to name enable-early-reset. I'd prefer to have something >>>> generic, even if only implemented in a single driver for now, but I don't >>>> really know right now what that might/should look like. Maybe just >>>> "enable-early" to indicate that the watchdog should be enabled during init ? >>> >>> Do we need the enable-early or such property at all? Just leave >>> early-timeout-sec to zero and then let it behave just like >>> enable-early would do? >>> >> >> Problem is that the possible conditions are all over the place >> for "early" watchdog handling. >> >> - Disable watchdog >> - Enable watchdog (or keep it enabled), and keep it alive >> until user space kicks in (ie possibly forever) >> - Enable watchdog or keep it enabled, and keep it alive >> for a specified period of time. >> - Keep watchdog enabled if it is already enabled, otherwise >> keep it disabled. >> >> There are probably more conditions which I don't recall right now. >> Which of those conditions would you address with "early-timeout = <0>;" ? >> "enable watchdog early and keep it alive until user space kicks in", >> or "keep watchdog enabled if already running, and set specified early >> timeout" ? One could argue either way which one of the two meanings >> it should be. > > Okay, let me elaborate my point of view a bit. > > The use case we are concerned about is that we have a device that we rather not let freeze up at any point. This is what we use the watchdog for. The only missing corner case right now is the point where kernel driver initializes the watchdog hardware and pings it on behalf of user space until a watchdog daemon opens it and starts kicking. This is kind of bad as kernel might lock up or user space might crash before we get to the point where the daemon starts taking care of petting the watchdog. So this is what we are trying to fix. > > Right. Some other hardware behave differently to the one in Atmel. They might have watchdog stopped by bootloader or it might not be running at all until someone starts it. What do do with such case? If we are still concerned about the same use case I described above, I would say the reasonable thing to do is to make sure the watchdog is started as early as possible and not stopped at any point at all, if possible. If it needs to be explicitly enabled, bootloader should do it. If it didn't do it, then kernel should do it. > > Now that I think of it, what we really are interested in is to defer starting of the watchdog to give user space more time to start up. In Atmel HW it's more tricky as the driver can't be stopped. And in other hardware we could simply disable it altogether until we enable it after specific timeout, but we might crash before the timeout expires, in which case we would not get a chance to enable it. So the right thing to do is to enable the watchdog as early as possible, kick it on behalf of the user space until the timeout expires. Special case would be when the timeout is zero, when we just ensure watchdog is running but we don't do anything to prolong the first expiration. > > I can't think of any other use case someone would be interested in, but I'm positive that there are plenty of products on the market right now that have the requirement for race free guarantee that watchdog never stops. > > So given the conditions you listed, what I think is really important to fix is "Enable watchdog or keep it enabled, and keep it alive for a specified period of time". The only other choice we have right now is "Disable watchdog and let user space enabled it later, if ever". Yeah, maybe we could cover those other use cases too. Maybe someone is using bootloader to decide what to do with watchdog and kernel should somehow respect that. I don't know if that makes sense or if it would be reasonable assumption.. > > Any more thoughts? > To make progress, can you update the patch using early-timeout-sec as discussed ? Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-01-13 14:53 ` Guenter Roeck @ 2015-01-14 6:09 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-01-14 6:09 UTC (permalink / raw) To: Guenter Roeck Cc: Boris Brezillon, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni On 13.01.2015 16:53, Guenter Roeck wrote: > On 12/06/2014 02:11 AM, Timo Kokkonen wrote: >> On 05.12.2014 23:39, Guenter Roeck wrote: >>> On Fri, Dec 05, 2014 at 10:32:48PM +0200, Timo Kokkonen wrote: >>>> On 05.12.2014 21:02, Guenter Roeck wrote: >> >>>>> Not sure about how to name enable-early-reset. I'd prefer to have >>>>> something >>>>> generic, even if only implemented in a single driver for now, but I >>>>> don't >>>>> really know right now what that might/should look like. Maybe just >>>>> "enable-early" to indicate that the watchdog should be enabled >>>>> during init ? >>>> >>>> Do we need the enable-early or such property at all? Just leave >>>> early-timeout-sec to zero and then let it behave just like >>>> enable-early would do? >>>> >>> >>> Problem is that the possible conditions are all over the place >>> for "early" watchdog handling. >>> >>> - Disable watchdog >>> - Enable watchdog (or keep it enabled), and keep it alive >>> until user space kicks in (ie possibly forever) >>> - Enable watchdog or keep it enabled, and keep it alive >>> for a specified period of time. >>> - Keep watchdog enabled if it is already enabled, otherwise >>> keep it disabled. >>> >>> There are probably more conditions which I don't recall right now. >>> Which of those conditions would you address with "early-timeout = >>> <0>;" ? >>> "enable watchdog early and keep it alive until user space kicks in", >>> or "keep watchdog enabled if already running, and set specified early >>> timeout" ? One could argue either way which one of the two meanings >>> it should be. >> >> Okay, let me elaborate my point of view a bit. >> >> The use case we are concerned about is that we have a device that we >> rather not let freeze up at any point. This is what we use the >> watchdog for. The only missing corner case right now is the point >> where kernel driver initializes the watchdog hardware and pings it on >> behalf of user space until a watchdog daemon opens it and starts >> kicking. This is kind of bad as kernel might lock up or user space >> might crash before we get to the point where the daemon starts taking >> care of petting the watchdog. So this is what we are trying to fix. >> >> Right. Some other hardware behave differently to the one in Atmel. >> They might have watchdog stopped by bootloader or it might not be >> running at all until someone starts it. What do do with such case? If >> we are still concerned about the same use case I described above, I >> would say the reasonable thing to do is to make sure the watchdog is >> started as early as possible and not stopped at any point at all, if >> possible. If it needs to be explicitly enabled, bootloader should do >> it. If it didn't do it, then kernel should do it. >> >> Now that I think of it, what we really are interested in is to defer >> starting of the watchdog to give user space more time to start up. In >> Atmel HW it's more tricky as the driver can't be stopped. And in other >> hardware we could simply disable it altogether until we enable it >> after specific timeout, but we might crash before the timeout expires, >> in which case we would not get a chance to enable it. So the right >> thing to do is to enable the watchdog as early as possible, kick it on >> behalf of the user space until the timeout expires. Special case would >> be when the timeout is zero, when we just ensure watchdog is running >> but we don't do anything to prolong the first expiration. >> >> I can't think of any other use case someone would be interested in, >> but I'm positive that there are plenty of products on the market right >> now that have the requirement for race free guarantee that watchdog >> never stops. >> >> So given the conditions you listed, what I think is really important >> to fix is "Enable watchdog or keep it enabled, and keep it alive for a >> specified period of time". The only other choice we have right now is >> "Disable watchdog and let user space enabled it later, if ever". Yeah, >> maybe we could cover those other use cases too. Maybe someone is using >> bootloader to decide what to do with watchdog and kernel should >> somehow respect that. I don't know if that makes sense or if it would >> be reasonable assumption.. >> >> Any more thoughts? >> > To make progress, can you update the patch using early-timeout-sec as > discussed ? > Sorry, I have been heavily distracted with other work recently and I haven't been able to make any progress with this. Thanks for reminding me, I'll try to allocate some time for this in near future. -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-01-14 6:09 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-01-14 6:09 UTC (permalink / raw) To: linux-arm-kernel On 13.01.2015 16:53, Guenter Roeck wrote: > On 12/06/2014 02:11 AM, Timo Kokkonen wrote: >> On 05.12.2014 23:39, Guenter Roeck wrote: >>> On Fri, Dec 05, 2014 at 10:32:48PM +0200, Timo Kokkonen wrote: >>>> On 05.12.2014 21:02, Guenter Roeck wrote: >> >>>>> Not sure about how to name enable-early-reset. I'd prefer to have >>>>> something >>>>> generic, even if only implemented in a single driver for now, but I >>>>> don't >>>>> really know right now what that might/should look like. Maybe just >>>>> "enable-early" to indicate that the watchdog should be enabled >>>>> during init ? >>>> >>>> Do we need the enable-early or such property at all? Just leave >>>> early-timeout-sec to zero and then let it behave just like >>>> enable-early would do? >>>> >>> >>> Problem is that the possible conditions are all over the place >>> for "early" watchdog handling. >>> >>> - Disable watchdog >>> - Enable watchdog (or keep it enabled), and keep it alive >>> until user space kicks in (ie possibly forever) >>> - Enable watchdog or keep it enabled, and keep it alive >>> for a specified period of time. >>> - Keep watchdog enabled if it is already enabled, otherwise >>> keep it disabled. >>> >>> There are probably more conditions which I don't recall right now. >>> Which of those conditions would you address with "early-timeout = >>> <0>;" ? >>> "enable watchdog early and keep it alive until user space kicks in", >>> or "keep watchdog enabled if already running, and set specified early >>> timeout" ? One could argue either way which one of the two meanings >>> it should be. >> >> Okay, let me elaborate my point of view a bit. >> >> The use case we are concerned about is that we have a device that we >> rather not let freeze up at any point. This is what we use the >> watchdog for. The only missing corner case right now is the point >> where kernel driver initializes the watchdog hardware and pings it on >> behalf of user space until a watchdog daemon opens it and starts >> kicking. This is kind of bad as kernel might lock up or user space >> might crash before we get to the point where the daemon starts taking >> care of petting the watchdog. So this is what we are trying to fix. >> >> Right. Some other hardware behave differently to the one in Atmel. >> They might have watchdog stopped by bootloader or it might not be >> running at all until someone starts it. What do do with such case? If >> we are still concerned about the same use case I described above, I >> would say the reasonable thing to do is to make sure the watchdog is >> started as early as possible and not stopped at any point at all, if >> possible. If it needs to be explicitly enabled, bootloader should do >> it. If it didn't do it, then kernel should do it. >> >> Now that I think of it, what we really are interested in is to defer >> starting of the watchdog to give user space more time to start up. In >> Atmel HW it's more tricky as the driver can't be stopped. And in other >> hardware we could simply disable it altogether until we enable it >> after specific timeout, but we might crash before the timeout expires, >> in which case we would not get a chance to enable it. So the right >> thing to do is to enable the watchdog as early as possible, kick it on >> behalf of the user space until the timeout expires. Special case would >> be when the timeout is zero, when we just ensure watchdog is running >> but we don't do anything to prolong the first expiration. >> >> I can't think of any other use case someone would be interested in, >> but I'm positive that there are plenty of products on the market right >> now that have the requirement for race free guarantee that watchdog >> never stops. >> >> So given the conditions you listed, what I think is really important >> to fix is "Enable watchdog or keep it enabled, and keep it alive for a >> specified period of time". The only other choice we have right now is >> "Disable watchdog and let user space enabled it later, if ever". Yeah, >> maybe we could cover those other use cases too. Maybe someone is using >> bootloader to decide what to do with watchdog and kernel should >> somehow respect that. I don't know if that makes sense or if it would >> be reasonable assumption.. >> >> Any more thoughts? >> > To make progress, can you update the patch using early-timeout-sec as > discussed ? > Sorry, I have been heavily distracted with other work recently and I haven't been able to make any progress with this. Thanks for reminding me, I'll try to allocate some time for this in near future. -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCHv3 0/2] watchdog: Introduce "early-timeout-sec" property 2015-01-13 14:53 ` Guenter Roeck @ 2015-02-18 12:57 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-18 12:57 UTC (permalink / raw) To: boris.brezillon, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni Cc: Timo Kokkonen Currently we have no means to adjust the watchdog behavior on early start up before user space has opened the device. The generic behavior among the watchdog drivers is to not start the watchdog at all (or disable it, if possible, or in case at91sam9_wdt, start a kernel timer that keeps on pinging the watchdog on behalf of user space until a watchdog daemon opens it). This unfortunately opens a time window between starting the driver and starting the user space watchdog daemon where a crash of the kernel or user space might prevent the watchdog from ever resetting the device at all. This is obviously bad on production systems. Introduce a new device tree property that, when set, changes the watchdog driver behavior in such way that there no longer is any window where crash is not caught by the watchdog. This is the third version of this patch. Previous versions of the patch were using an atmel specific property name. This patch uses a generic name instead as the functionality itself has nothing atmel related. I am also introducing watchdog.txt for describing the generic watchdog device tree bindings as there was no such file before. Timo Kokkonen (2): devicetree: Document generic watchdog properties at91sam9_wdt: Allow watchdog to reset device at early boot .../devicetree/bindings/watchdog/watchdog.txt | 19 +++++++++++++++++++ drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- 2 files changed, 27 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/watchdog/watchdog.txt -- 2.1.0 ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCHv3 0/2] watchdog: Introduce "early-timeout-sec" property @ 2015-02-18 12:57 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-18 12:57 UTC (permalink / raw) To: linux-arm-kernel Currently we have no means to adjust the watchdog behavior on early start up before user space has opened the device. The generic behavior among the watchdog drivers is to not start the watchdog at all (or disable it, if possible, or in case at91sam9_wdt, start a kernel timer that keeps on pinging the watchdog on behalf of user space until a watchdog daemon opens it). This unfortunately opens a time window between starting the driver and starting the user space watchdog daemon where a crash of the kernel or user space might prevent the watchdog from ever resetting the device at all. This is obviously bad on production systems. Introduce a new device tree property that, when set, changes the watchdog driver behavior in such way that there no longer is any window where crash is not caught by the watchdog. This is the third version of this patch. Previous versions of the patch were using an atmel specific property name. This patch uses a generic name instead as the functionality itself has nothing atmel related. I am also introducing watchdog.txt for describing the generic watchdog device tree bindings as there was no such file before. Timo Kokkonen (2): devicetree: Document generic watchdog properties at91sam9_wdt: Allow watchdog to reset device at early boot .../devicetree/bindings/watchdog/watchdog.txt | 19 +++++++++++++++++++ drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- 2 files changed, 27 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/watchdog/watchdog.txt -- 2.1.0 ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 1/2] devicetree: Document generic watchdog properties 2015-02-18 12:57 ` Timo Kokkonen @ 2015-02-18 12:57 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-18 12:57 UTC (permalink / raw) To: boris.brezillon, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni Cc: Timo Kokkonen There is no documentation for the watchdog properties that are common among most of the watchdog drivers. Add document where these generic properties can be described and told how they should be used in drivers. Start from the "timeout-sec" property. Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> --- Documentation/devicetree/bindings/watchdog/watchdog.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/watchdog.txt diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt new file mode 100644 index 0000000..7e3686c --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt @@ -0,0 +1,12 @@ +These properties are common among most watchdog drivers. Any driver +that requires the functionality listed below should implement them +using these definitions. + +Optional properties: +- timeout-sec: Contains the watchdog timeout in seconds. + +Example: + +watchdog { + timeout-sec = <60>; +}; -- 2.1.0 ^ permalink raw reply related [flat|nested] 110+ messages in thread
* [PATCH 1/2] devicetree: Document generic watchdog properties @ 2015-02-18 12:57 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-18 12:57 UTC (permalink / raw) To: linux-arm-kernel There is no documentation for the watchdog properties that are common among most of the watchdog drivers. Add document where these generic properties can be described and told how they should be used in drivers. Start from the "timeout-sec" property. Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> --- Documentation/devicetree/bindings/watchdog/watchdog.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/watchdog.txt diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt new file mode 100644 index 0000000..7e3686c --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt @@ -0,0 +1,12 @@ +These properties are common among most watchdog drivers. Any driver +that requires the functionality listed below should implement them +using these definitions. + +Optional properties: +- timeout-sec: Contains the watchdog timeout in seconds. + +Example: + +watchdog { + timeout-sec = <60>; +}; -- 2.1.0 ^ permalink raw reply related [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 12:57 ` Timo Kokkonen @ 2015-02-18 12:57 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-18 12:57 UTC (permalink / raw) To: boris.brezillon, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni Cc: Timo Kokkonen By default the driver will start a kernel timer which keeps on kicking the watchdog HW until user space has opened the watchdog device. Usually this is desirable as the watchdog HW is running by default and the user space may not have any watchdog daemon running at all. However, on production systems it may be mandatory that also early crashes and lockups will lead to a watchdog reset, even if they happen before the user space has opened the watchdog device. To resolve the issue, add a new device tree property "early-timeout-sec" which will let the kernel timer to ping the watchdog HW only as long as the specified timeout permits. The default is still to use kernel timer, but more strict behavior can be enabled via the device tree property. Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> --- Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt index 7e3686c..32647cf 100644 --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt @@ -4,9 +4,16 @@ using these definitions. Optional properties: - timeout-sec: Contains the watchdog timeout in seconds. +- early-timeout-sec: If present, specifies a timeout value in seconds + that the driver keeps on ticking the watchdog HW on behalf of user + space. Once this timeout expires watchdog is left to expire in + timeout-sec seconds. If this propery is set to zero, watchdog is + started (or left running) so that a reset occurs in timeout-sec + since the watchdog was started. Example: watchdog { timeout-sec = <60>; + early-timeout-sec = <120>; }; diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c index 6df9405..1b40bfa 100644 --- a/drivers/watchdog/at91sam9_wdt.c +++ b/drivers/watchdog/at91sam9_wdt.c @@ -89,6 +89,8 @@ struct at91wdt { u32 mr_mask; unsigned long heartbeat; /* WDT heartbeat in jiffies */ bool nowayout; + /* Timeout in jiffies for stopping the early timer */ + unsigned long early_timer; unsigned int irq; }; @@ -122,7 +124,8 @@ static void at91_ping(unsigned long data) { struct at91wdt *wdt = (struct at91wdt *)data; if (time_before(jiffies, wdt->next_heartbeat) || - !watchdog_active(&wdt->wdd)) { + (time_before(jiffies, wdt->early_timer) && + !watchdog_active(&wdt->wdd))) { at91_wdt_reset(wdt); mod_timer(&wdt->timer, jiffies + wdt->heartbeat); } else { @@ -316,6 +319,10 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) wdt->mr |= max | ((max - min) << 16); + if (!of_property_read_u32_index(np, "early-timeout-sec", 0, + (u32 *)&wdt->early_timer)) + wdt->early_timer = wdt->early_timer * HZ + jiffies; + return 0; } #else -- 2.1.0 ^ permalink raw reply related [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-18 12:57 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-18 12:57 UTC (permalink / raw) To: linux-arm-kernel By default the driver will start a kernel timer which keeps on kicking the watchdog HW until user space has opened the watchdog device. Usually this is desirable as the watchdog HW is running by default and the user space may not have any watchdog daemon running at all. However, on production systems it may be mandatory that also early crashes and lockups will lead to a watchdog reset, even if they happen before the user space has opened the watchdog device. To resolve the issue, add a new device tree property "early-timeout-sec" which will let the kernel timer to ping the watchdog HW only as long as the specified timeout permits. The default is still to use kernel timer, but more strict behavior can be enabled via the device tree property. Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> --- Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt index 7e3686c..32647cf 100644 --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt @@ -4,9 +4,16 @@ using these definitions. Optional properties: - timeout-sec: Contains the watchdog timeout in seconds. +- early-timeout-sec: If present, specifies a timeout value in seconds + that the driver keeps on ticking the watchdog HW on behalf of user + space. Once this timeout expires watchdog is left to expire in + timeout-sec seconds. If this propery is set to zero, watchdog is + started (or left running) so that a reset occurs in timeout-sec + since the watchdog was started. Example: watchdog { timeout-sec = <60>; + early-timeout-sec = <120>; }; diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c index 6df9405..1b40bfa 100644 --- a/drivers/watchdog/at91sam9_wdt.c +++ b/drivers/watchdog/at91sam9_wdt.c @@ -89,6 +89,8 @@ struct at91wdt { u32 mr_mask; unsigned long heartbeat; /* WDT heartbeat in jiffies */ bool nowayout; + /* Timeout in jiffies for stopping the early timer */ + unsigned long early_timer; unsigned int irq; }; @@ -122,7 +124,8 @@ static void at91_ping(unsigned long data) { struct at91wdt *wdt = (struct at91wdt *)data; if (time_before(jiffies, wdt->next_heartbeat) || - !watchdog_active(&wdt->wdd)) { + (time_before(jiffies, wdt->early_timer) && + !watchdog_active(&wdt->wdd))) { at91_wdt_reset(wdt); mod_timer(&wdt->timer, jiffies + wdt->heartbeat); } else { @@ -316,6 +319,10 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) wdt->mr |= max | ((max - min) << 16); + if (!of_property_read_u32_index(np, "early-timeout-sec", 0, + (u32 *)&wdt->early_timer)) + wdt->early_timer = wdt->early_timer * HZ + jiffies; + return 0; } #else -- 2.1.0 ^ permalink raw reply related [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 12:57 ` Timo Kokkonen @ 2015-02-18 13:21 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-18 13:21 UTC (permalink / raw) To: Timo Kokkonen Cc: linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni Hi Timo, On Wed, 18 Feb 2015 14:57:22 +0200 Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "early-timeout-sec" which will let the kernel timer to ping the > watchdog HW only as long as the specified timeout permits. The default > is still to use kernel timer, but more strict behavior can be enabled > via the device tree property. > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > --- > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt > index 7e3686c..32647cf 100644 > --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt > +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt > @@ -4,9 +4,16 @@ using these definitions. > > Optional properties: > - timeout-sec: Contains the watchdog timeout in seconds. > +- early-timeout-sec: If present, specifies a timeout value in seconds > + that the driver keeps on ticking the watchdog HW on behalf of user > + space. Once this timeout expires watchdog is left to expire in > + timeout-sec seconds. If this propery is set to zero, watchdog is > + started (or left running) so that a reset occurs in timeout-sec > + since the watchdog was started. > > Example: > > watchdog { > timeout-sec = <60>; > + early-timeout-sec = <120>; > }; IMHO the documentation update should be self-contained (it should be done in a separate patch). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-18 13:21 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-18 13:21 UTC (permalink / raw) To: linux-arm-kernel Hi Timo, On Wed, 18 Feb 2015 14:57:22 +0200 Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "early-timeout-sec" which will let the kernel timer to ping the > watchdog HW only as long as the specified timeout permits. The default > is still to use kernel timer, but more strict behavior can be enabled > via the device tree property. > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > --- > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt > index 7e3686c..32647cf 100644 > --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt > +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt > @@ -4,9 +4,16 @@ using these definitions. > > Optional properties: > - timeout-sec: Contains the watchdog timeout in seconds. > +- early-timeout-sec: If present, specifies a timeout value in seconds > + that the driver keeps on ticking the watchdog HW on behalf of user > + space. Once this timeout expires watchdog is left to expire in > + timeout-sec seconds. If this propery is set to zero, watchdog is > + started (or left running) so that a reset occurs in timeout-sec > + since the watchdog was started. > > Example: > > watchdog { > timeout-sec = <60>; > + early-timeout-sec = <120>; > }; IMHO the documentation update should be self-contained (it should be done in a separate patch). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 12:57 ` Timo Kokkonen @ 2015-02-18 13:59 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-18 13:59 UTC (permalink / raw) To: Timo Kokkonen, boris.brezillon, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni On 02/18/2015 04:57 AM, Timo Kokkonen wrote: > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "early-timeout-sec" which will let the kernel timer to ping the > watchdog HW only as long as the specified timeout permits. The default > is still to use kernel timer, but more strict behavior can be enabled > via the device tree property. > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > --- > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt > index 7e3686c..32647cf 100644 > --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt > +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt > @@ -4,9 +4,16 @@ using these definitions. > > Optional properties: > - timeout-sec: Contains the watchdog timeout in seconds. > +- early-timeout-sec: If present, specifies a timeout value in seconds > + that the driver keeps on ticking the watchdog HW on behalf of user > + space. Once this timeout expires watchdog is left to expire in > + timeout-sec seconds. If this propery is set to zero, watchdog is > + started (or left running) so that a reset occurs in timeout-sec > + since the watchdog was started. > > Example: > > watchdog { > timeout-sec = <60>; > + early-timeout-sec = <120>; That is not a generic property as you defined it; if so, it would have to be implemented in the watchdog core code, not in the at91 code. You'll have to document it in the bindings description for at91sam9_wdt. Guenter > }; > diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c > index 6df9405..1b40bfa 100644 > --- a/drivers/watchdog/at91sam9_wdt.c > +++ b/drivers/watchdog/at91sam9_wdt.c > @@ -89,6 +89,8 @@ struct at91wdt { > u32 mr_mask; > unsigned long heartbeat; /* WDT heartbeat in jiffies */ > bool nowayout; > + /* Timeout in jiffies for stopping the early timer */ > + unsigned long early_timer; > unsigned int irq; > }; > > @@ -122,7 +124,8 @@ static void at91_ping(unsigned long data) > { > struct at91wdt *wdt = (struct at91wdt *)data; > if (time_before(jiffies, wdt->next_heartbeat) || > - !watchdog_active(&wdt->wdd)) { > + (time_before(jiffies, wdt->early_timer) && > + !watchdog_active(&wdt->wdd))) { > at91_wdt_reset(wdt); > mod_timer(&wdt->timer, jiffies + wdt->heartbeat); > } else { > @@ -316,6 +319,10 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) > > wdt->mr |= max | ((max - min) << 16); > > + if (!of_property_read_u32_index(np, "early-timeout-sec", 0, > + (u32 *)&wdt->early_timer)) > + wdt->early_timer = wdt->early_timer * HZ + jiffies; > + > return 0; > } > #else > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-18 13:59 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-18 13:59 UTC (permalink / raw) To: linux-arm-kernel On 02/18/2015 04:57 AM, Timo Kokkonen wrote: > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "early-timeout-sec" which will let the kernel timer to ping the > watchdog HW only as long as the specified timeout permits. The default > is still to use kernel timer, but more strict behavior can be enabled > via the device tree property. > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > --- > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt > index 7e3686c..32647cf 100644 > --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt > +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt > @@ -4,9 +4,16 @@ using these definitions. > > Optional properties: > - timeout-sec: Contains the watchdog timeout in seconds. > +- early-timeout-sec: If present, specifies a timeout value in seconds > + that the driver keeps on ticking the watchdog HW on behalf of user > + space. Once this timeout expires watchdog is left to expire in > + timeout-sec seconds. If this propery is set to zero, watchdog is > + started (or left running) so that a reset occurs in timeout-sec > + since the watchdog was started. > > Example: > > watchdog { > timeout-sec = <60>; > + early-timeout-sec = <120>; That is not a generic property as you defined it; if so, it would have to be implemented in the watchdog core code, not in the at91 code. You'll have to document it in the bindings description for at91sam9_wdt. Guenter > }; > diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c > index 6df9405..1b40bfa 100644 > --- a/drivers/watchdog/at91sam9_wdt.c > +++ b/drivers/watchdog/at91sam9_wdt.c > @@ -89,6 +89,8 @@ struct at91wdt { > u32 mr_mask; > unsigned long heartbeat; /* WDT heartbeat in jiffies */ > bool nowayout; > + /* Timeout in jiffies for stopping the early timer */ > + unsigned long early_timer; > unsigned int irq; > }; > > @@ -122,7 +124,8 @@ static void at91_ping(unsigned long data) > { > struct at91wdt *wdt = (struct at91wdt *)data; > if (time_before(jiffies, wdt->next_heartbeat) || > - !watchdog_active(&wdt->wdd)) { > + (time_before(jiffies, wdt->early_timer) && > + !watchdog_active(&wdt->wdd))) { > at91_wdt_reset(wdt); > mod_timer(&wdt->timer, jiffies + wdt->heartbeat); > } else { > @@ -316,6 +319,10 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) > > wdt->mr |= max | ((max - min) << 16); > > + if (!of_property_read_u32_index(np, "early-timeout-sec", 0, > + (u32 *)&wdt->early_timer)) > + wdt->early_timer = wdt->early_timer * HZ + jiffies; > + > return 0; > } > #else > ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 13:59 ` Guenter Roeck @ 2015-02-18 14:17 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-18 14:17 UTC (permalink / raw) To: Guenter Roeck Cc: Timo Kokkonen, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni Hi Guenter, On Wed, 18 Feb 2015 05:59:01 -0800 Guenter Roeck <linux@roeck-us.net> wrote: > On 02/18/2015 04:57 AM, Timo Kokkonen wrote: > > By default the driver will start a kernel timer which keeps on kicking > > the watchdog HW until user space has opened the watchdog > > device. Usually this is desirable as the watchdog HW is running by > > default and the user space may not have any watchdog daemon running at > > all. > > > > However, on production systems it may be mandatory that also early > > crashes and lockups will lead to a watchdog reset, even if they happen > > before the user space has opened the watchdog device. > > > > To resolve the issue, add a new device tree property > > "early-timeout-sec" which will let the kernel timer to ping the > > watchdog HW only as long as the specified timeout permits. The default > > is still to use kernel timer, but more strict behavior can be enabled > > via the device tree property. > > > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > > --- > > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt > > index 7e3686c..32647cf 100644 > > --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt > > +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt > > @@ -4,9 +4,16 @@ using these definitions. > > > > Optional properties: > > - timeout-sec: Contains the watchdog timeout in seconds. > > +- early-timeout-sec: If present, specifies a timeout value in seconds > > + that the driver keeps on ticking the watchdog HW on behalf of user > > + space. Once this timeout expires watchdog is left to expire in > > + timeout-sec seconds. If this propery is set to zero, watchdog is > > + started (or left running) so that a reset occurs in timeout-sec > > + since the watchdog was started. > > > > Example: > > > > watchdog { > > timeout-sec = <60>; > > + early-timeout-sec = <120>; > > That is not a generic property as you defined it; if so, > it would have to be implemented in the watchdog core code, > not in the at91 code. You'll have to document it in the bindings > description for at91sam9_wdt. Then, if this is a controller specific property, it should be defined with the 'atmel,' prefix. We're kind of looping here: the initial discussion was "is there a need for this property to be a generic one ?", and now you're saying no, while you previously left the door opened. Tomi is proposing a generic approach, as you asked him to. I agree that parsing the property in core code and making its value part of the generic watchdog struct makes sense (that's what I proposed to Tomi a few weeks ago). Anyway, I'm fine with both approaches (generic and controller specific), so I'll let you decide in the end. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-18 14:17 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-18 14:17 UTC (permalink / raw) To: linux-arm-kernel Hi Guenter, On Wed, 18 Feb 2015 05:59:01 -0800 Guenter Roeck <linux@roeck-us.net> wrote: > On 02/18/2015 04:57 AM, Timo Kokkonen wrote: > > By default the driver will start a kernel timer which keeps on kicking > > the watchdog HW until user space has opened the watchdog > > device. Usually this is desirable as the watchdog HW is running by > > default and the user space may not have any watchdog daemon running at > > all. > > > > However, on production systems it may be mandatory that also early > > crashes and lockups will lead to a watchdog reset, even if they happen > > before the user space has opened the watchdog device. > > > > To resolve the issue, add a new device tree property > > "early-timeout-sec" which will let the kernel timer to ping the > > watchdog HW only as long as the specified timeout permits. The default > > is still to use kernel timer, but more strict behavior can be enabled > > via the device tree property. > > > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > > --- > > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt > > index 7e3686c..32647cf 100644 > > --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt > > +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt > > @@ -4,9 +4,16 @@ using these definitions. > > > > Optional properties: > > - timeout-sec: Contains the watchdog timeout in seconds. > > +- early-timeout-sec: If present, specifies a timeout value in seconds > > + that the driver keeps on ticking the watchdog HW on behalf of user > > + space. Once this timeout expires watchdog is left to expire in > > + timeout-sec seconds. If this propery is set to zero, watchdog is > > + started (or left running) so that a reset occurs in timeout-sec > > + since the watchdog was started. > > > > Example: > > > > watchdog { > > timeout-sec = <60>; > > + early-timeout-sec = <120>; > > That is not a generic property as you defined it; if so, > it would have to be implemented in the watchdog core code, > not in the at91 code. You'll have to document it in the bindings > description for at91sam9_wdt. Then, if this is a controller specific property, it should be defined with the 'atmel,' prefix. We're kind of looping here: the initial discussion was "is there a need for this property to be a generic one ?", and now you're saying no, while you previously left the door opened. Tomi is proposing a generic approach, as you asked him to. I agree that parsing the property in core code and making its value part of the generic watchdog struct makes sense (that's what I proposed to Tomi a few weeks ago). Anyway, I'm fine with both approaches (generic and controller specific), so I'll let you decide in the end. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 14:17 ` Boris Brezillon @ 2015-02-18 14:50 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-18 14:50 UTC (permalink / raw) To: Boris Brezillon Cc: Timo Kokkonen, linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni On 02/18/2015 06:17 AM, Boris Brezillon wrote: > Hi Guenter, > > On Wed, 18 Feb 2015 05:59:01 -0800 > Guenter Roeck <linux@roeck-us.net> wrote: > >> On 02/18/2015 04:57 AM, Timo Kokkonen wrote: >>> By default the driver will start a kernel timer which keeps on kicking >>> the watchdog HW until user space has opened the watchdog >>> device. Usually this is desirable as the watchdog HW is running by >>> default and the user space may not have any watchdog daemon running at >>> all. >>> >>> However, on production systems it may be mandatory that also early >>> crashes and lockups will lead to a watchdog reset, even if they happen >>> before the user space has opened the watchdog device. >>> >>> To resolve the issue, add a new device tree property >>> "early-timeout-sec" which will let the kernel timer to ping the >>> watchdog HW only as long as the specified timeout permits. The default >>> is still to use kernel timer, but more strict behavior can be enabled >>> via the device tree property. >>> >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>> --- >>> Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ >>> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- >>> 2 files changed, 15 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt >>> index 7e3686c..32647cf 100644 >>> --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt >>> +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt >>> @@ -4,9 +4,16 @@ using these definitions. >>> >>> Optional properties: >>> - timeout-sec: Contains the watchdog timeout in seconds. >>> +- early-timeout-sec: If present, specifies a timeout value in seconds >>> + that the driver keeps on ticking the watchdog HW on behalf of user >>> + space. Once this timeout expires watchdog is left to expire in >>> + timeout-sec seconds. If this propery is set to zero, watchdog is >>> + started (or left running) so that a reset occurs in timeout-sec >>> + since the watchdog was started. >>> >>> Example: >>> >>> watchdog { >>> timeout-sec = <60>; >>> + early-timeout-sec = <120>; >> >> That is not a generic property as you defined it; if so, >> it would have to be implemented in the watchdog core code, >> not in the at91 code. You'll have to document it in the bindings >> description for at91sam9_wdt. > > Then, if this is a controller specific property, it should be defined > with the 'atmel,' prefix. > We're kind of looping here: the initial discussion was "is there a need > for this property to be a generic one ?", and now you're saying no, > while you previously left the door opened. > > Tomi is proposing a generic approach, as you asked him to. I agree that > parsing the property in core code and making its value part of the > generic watchdog struct makes sense (that's what I proposed to Tomi a > few weeks ago). > Hmm ... the problem here is that the property description creates the assumption or expectation that the property is used if defined, which is not the case. I am not sure how to best resolve this. Maybe a comment in the property description stating that implementation of is device (driver) dependent ? After all, that is true for the timeout-sec property as well. Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-18 14:50 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-18 14:50 UTC (permalink / raw) To: linux-arm-kernel On 02/18/2015 06:17 AM, Boris Brezillon wrote: > Hi Guenter, > > On Wed, 18 Feb 2015 05:59:01 -0800 > Guenter Roeck <linux@roeck-us.net> wrote: > >> On 02/18/2015 04:57 AM, Timo Kokkonen wrote: >>> By default the driver will start a kernel timer which keeps on kicking >>> the watchdog HW until user space has opened the watchdog >>> device. Usually this is desirable as the watchdog HW is running by >>> default and the user space may not have any watchdog daemon running at >>> all. >>> >>> However, on production systems it may be mandatory that also early >>> crashes and lockups will lead to a watchdog reset, even if they happen >>> before the user space has opened the watchdog device. >>> >>> To resolve the issue, add a new device tree property >>> "early-timeout-sec" which will let the kernel timer to ping the >>> watchdog HW only as long as the specified timeout permits. The default >>> is still to use kernel timer, but more strict behavior can be enabled >>> via the device tree property. >>> >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>> --- >>> Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ >>> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- >>> 2 files changed, 15 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt >>> index 7e3686c..32647cf 100644 >>> --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt >>> +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt >>> @@ -4,9 +4,16 @@ using these definitions. >>> >>> Optional properties: >>> - timeout-sec: Contains the watchdog timeout in seconds. >>> +- early-timeout-sec: If present, specifies a timeout value in seconds >>> + that the driver keeps on ticking the watchdog HW on behalf of user >>> + space. Once this timeout expires watchdog is left to expire in >>> + timeout-sec seconds. If this propery is set to zero, watchdog is >>> + started (or left running) so that a reset occurs in timeout-sec >>> + since the watchdog was started. >>> >>> Example: >>> >>> watchdog { >>> timeout-sec = <60>; >>> + early-timeout-sec = <120>; >> >> That is not a generic property as you defined it; if so, >> it would have to be implemented in the watchdog core code, >> not in the at91 code. You'll have to document it in the bindings >> description for at91sam9_wdt. > > Then, if this is a controller specific property, it should be defined > with the 'atmel,' prefix. > We're kind of looping here: the initial discussion was "is there a need > for this property to be a generic one ?", and now you're saying no, > while you previously left the door opened. > > Tomi is proposing a generic approach, as you asked him to. I agree that > parsing the property in core code and making its value part of the > generic watchdog struct makes sense (that's what I proposed to Tomi a > few weeks ago). > Hmm ... the problem here is that the property description creates the assumption or expectation that the property is used if defined, which is not the case. I am not sure how to best resolve this. Maybe a comment in the property description stating that implementation of is device (driver) dependent ? After all, that is true for the timeout-sec property as well. Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 14:50 ` Guenter Roeck @ 2015-02-18 16:00 ` Alexandre Belloni -1 siblings, 0 replies; 110+ messages in thread From: Alexandre Belloni @ 2015-02-18 16:00 UTC (permalink / raw) To: Guenter Roeck Cc: Boris Brezillon, nicolas.ferre, Timo Kokkonen, linux-watchdog, linux-arm-kernel Hi, On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : > >>> Optional properties: > >>> - timeout-sec: Contains the watchdog timeout in seconds. > >>>+- early-timeout-sec: If present, specifies a timeout value in seconds > >>>+ that the driver keeps on ticking the watchdog HW on behalf of user > >>>+ space. Once this timeout expires watchdog is left to expire in > >>>+ timeout-sec seconds. If this propery is set to zero, watchdog is > >>>+ started (or left running) so that a reset occurs in timeout-sec > >>>+ since the watchdog was started. > >>> > >>> Example: > >>> > >>> watchdog { > >>> timeout-sec = <60>; > >>>+ early-timeout-sec = <120>; > >> > >>That is not a generic property as you defined it; if so, > >>it would have to be implemented in the watchdog core code, > >>not in the at91 code. You'll have to document it in the bindings > >>description for at91sam9_wdt. > > > >Then, if this is a controller specific property, it should be defined > >with the 'atmel,' prefix. > >We're kind of looping here: the initial discussion was "is there a need > >for this property to be a generic one ?", and now you're saying no, > >while you previously left the door opened. > > > >Tomi is proposing a generic approach, as you asked him to. I agree that > >parsing the property in core code and making its value part of the > >generic watchdog struct makes sense (that's what I proposed to Tomi a > >few weeks ago). > > > Hmm ... the problem here is that the property description creates the > assumption or expectation that the property is used if defined, > which is not the case. > > I am not sure how to best resolve this. Maybe a comment in the property > description stating that implementation of is device (driver) dependent ? > After all, that is true for the timeout-sec property as well. > I would leave it in the generic file and state that it may not be implemented in the driver. That way, the property is documented for new driver writers. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-18 16:00 ` Alexandre Belloni 0 siblings, 0 replies; 110+ messages in thread From: Alexandre Belloni @ 2015-02-18 16:00 UTC (permalink / raw) To: linux-arm-kernel Hi, On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : > >>> Optional properties: > >>> - timeout-sec: Contains the watchdog timeout in seconds. > >>>+- early-timeout-sec: If present, specifies a timeout value in seconds > >>>+ that the driver keeps on ticking the watchdog HW on behalf of user > >>>+ space. Once this timeout expires watchdog is left to expire in > >>>+ timeout-sec seconds. If this propery is set to zero, watchdog is > >>>+ started (or left running) so that a reset occurs in timeout-sec > >>>+ since the watchdog was started. > >>> > >>> Example: > >>> > >>> watchdog { > >>> timeout-sec = <60>; > >>>+ early-timeout-sec = <120>; > >> > >>That is not a generic property as you defined it; if so, > >>it would have to be implemented in the watchdog core code, > >>not in the at91 code. You'll have to document it in the bindings > >>description for at91sam9_wdt. > > > >Then, if this is a controller specific property, it should be defined > >with the 'atmel,' prefix. > >We're kind of looping here: the initial discussion was "is there a need > >for this property to be a generic one ?", and now you're saying no, > >while you previously left the door opened. > > > >Tomi is proposing a generic approach, as you asked him to. I agree that > >parsing the property in core code and making its value part of the > >generic watchdog struct makes sense (that's what I proposed to Tomi a > >few weeks ago). > > > Hmm ... the problem here is that the property description creates the > assumption or expectation that the property is used if defined, > which is not the case. > > I am not sure how to best resolve this. Maybe a comment in the property > description stating that implementation of is device (driver) dependent ? > After all, that is true for the timeout-sec property as well. > I would leave it in the generic file and state that it may not be implemented in the driver. That way, the property is documented for new driver writers. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 16:00 ` Alexandre Belloni @ 2015-02-18 17:50 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-18 17:50 UTC (permalink / raw) To: Alexandre Belloni Cc: Boris Brezillon, nicolas.ferre, Timo Kokkonen, linux-watchdog, linux-arm-kernel On Wed, Feb 18, 2015 at 05:00:33PM +0100, Alexandre Belloni wrote: > Hi, > > On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : > > >>> Optional properties: > > >>> - timeout-sec: Contains the watchdog timeout in seconds. > > >>>+- early-timeout-sec: If present, specifies a timeout value in seconds > > >>>+ that the driver keeps on ticking the watchdog HW on behalf of user > > >>>+ space. Once this timeout expires watchdog is left to expire in > > >>>+ timeout-sec seconds. If this propery is set to zero, watchdog is > > >>>+ started (or left running) so that a reset occurs in timeout-sec > > >>>+ since the watchdog was started. > > >>> > > >>> Example: > > >>> > > >>> watchdog { > > >>> timeout-sec = <60>; > > >>>+ early-timeout-sec = <120>; > > >> > > >>That is not a generic property as you defined it; if so, > > >>it would have to be implemented in the watchdog core code, > > >>not in the at91 code. You'll have to document it in the bindings > > >>description for at91sam9_wdt. > > > > > >Then, if this is a controller specific property, it should be defined > > >with the 'atmel,' prefix. > > >We're kind of looping here: the initial discussion was "is there a need > > >for this property to be a generic one ?", and now you're saying no, > > >while you previously left the door opened. > > > > > >Tomi is proposing a generic approach, as you asked him to. I agree that > > >parsing the property in core code and making its value part of the > > >generic watchdog struct makes sense (that's what I proposed to Tomi a > > >few weeks ago). > > > > > Hmm ... the problem here is that the property description creates the > > assumption or expectation that the property is used if defined, > > which is not the case. > > > > I am not sure how to best resolve this. Maybe a comment in the property > > description stating that implementation of is device (driver) dependent ? > > After all, that is true for the timeout-sec property as well. > > > > I would leave it in the generic file and state that it may not be > implemented in the driver. That way, the property is documented for new > driver writers. > Yes, that would be fine ok me. Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-18 17:50 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-18 17:50 UTC (permalink / raw) To: linux-arm-kernel On Wed, Feb 18, 2015 at 05:00:33PM +0100, Alexandre Belloni wrote: > Hi, > > On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : > > >>> Optional properties: > > >>> - timeout-sec: Contains the watchdog timeout in seconds. > > >>>+- early-timeout-sec: If present, specifies a timeout value in seconds > > >>>+ that the driver keeps on ticking the watchdog HW on behalf of user > > >>>+ space. Once this timeout expires watchdog is left to expire in > > >>>+ timeout-sec seconds. If this propery is set to zero, watchdog is > > >>>+ started (or left running) so that a reset occurs in timeout-sec > > >>>+ since the watchdog was started. > > >>> > > >>> Example: > > >>> > > >>> watchdog { > > >>> timeout-sec = <60>; > > >>>+ early-timeout-sec = <120>; > > >> > > >>That is not a generic property as you defined it; if so, > > >>it would have to be implemented in the watchdog core code, > > >>not in the at91 code. You'll have to document it in the bindings > > >>description for at91sam9_wdt. > > > > > >Then, if this is a controller specific property, it should be defined > > >with the 'atmel,' prefix. > > >We're kind of looping here: the initial discussion was "is there a need > > >for this property to be a generic one ?", and now you're saying no, > > >while you previously left the door opened. > > > > > >Tomi is proposing a generic approach, as you asked him to. I agree that > > >parsing the property in core code and making its value part of the > > >generic watchdog struct makes sense (that's what I proposed to Tomi a > > >few weeks ago). > > > > > Hmm ... the problem here is that the property description creates the > > assumption or expectation that the property is used if defined, > > which is not the case. > > > > I am not sure how to best resolve this. Maybe a comment in the property > > description stating that implementation of is device (driver) dependent ? > > After all, that is true for the timeout-sec property as well. > > > > I would leave it in the generic file and state that it may not be > implemented in the driver. That way, the property is documented for new > driver writers. > Yes, that would be fine ok me. Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 17:50 ` Guenter Roeck @ 2015-02-18 20:21 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-18 20:21 UTC (permalink / raw) To: Timo Kokkonen Cc: Guenter Roeck, Alexandre Belloni, nicolas.ferre, linux-watchdog, linux-arm-kernel On Wed, 18 Feb 2015 09:50:02 -0800 Guenter Roeck <linux@roeck-us.net> wrote: > On Wed, Feb 18, 2015 at 05:00:33PM +0100, Alexandre Belloni wrote: > > Hi, > > > > On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : > > > >>> Optional properties: > > > >>> - timeout-sec: Contains the watchdog timeout in seconds. > > > >>>+- early-timeout-sec: If present, specifies a timeout value in seconds > > > >>>+ that the driver keeps on ticking the watchdog HW on behalf of user > > > >>>+ space. Once this timeout expires watchdog is left to expire in > > > >>>+ timeout-sec seconds. If this propery is set to zero, watchdog is > > > >>>+ started (or left running) so that a reset occurs in timeout-sec > > > >>>+ since the watchdog was started. > > > >>> > > > >>> Example: > > > >>> > > > >>> watchdog { > > > >>> timeout-sec = <60>; > > > >>>+ early-timeout-sec = <120>; > > > >> > > > >>That is not a generic property as you defined it; if so, > > > >>it would have to be implemented in the watchdog core code, > > > >>not in the at91 code. You'll have to document it in the bindings > > > >>description for at91sam9_wdt. > > > > > > > >Then, if this is a controller specific property, it should be defined > > > >with the 'atmel,' prefix. > > > >We're kind of looping here: the initial discussion was "is there a need > > > >for this property to be a generic one ?", and now you're saying no, > > > >while you previously left the door opened. > > > > > > > >Tomi is proposing a generic approach, as you asked him to. I agree that > > > >parsing the property in core code and making its value part of the > > > >generic watchdog struct makes sense (that's what I proposed to Tomi a > > > >few weeks ago). > > > > > > > Hmm ... the problem here is that the property description creates the > > > assumption or expectation that the property is used if defined, > > > which is not the case. > > > > > > I am not sure how to best resolve this. Maybe a comment in the property > > > description stating that implementation of is device (driver) dependent ? > > > After all, that is true for the timeout-sec property as well. > > > > > > > I would leave it in the generic file and state that it may not be > > implemented in the driver. That way, the property is documented for new > > driver writers. > > > Yes, that would be fine ok me. Great! Timo can you change the documentation accordingly ? -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-18 20:21 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-18 20:21 UTC (permalink / raw) To: linux-arm-kernel On Wed, 18 Feb 2015 09:50:02 -0800 Guenter Roeck <linux@roeck-us.net> wrote: > On Wed, Feb 18, 2015 at 05:00:33PM +0100, Alexandre Belloni wrote: > > Hi, > > > > On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : > > > >>> Optional properties: > > > >>> - timeout-sec: Contains the watchdog timeout in seconds. > > > >>>+- early-timeout-sec: If present, specifies a timeout value in seconds > > > >>>+ that the driver keeps on ticking the watchdog HW on behalf of user > > > >>>+ space. Once this timeout expires watchdog is left to expire in > > > >>>+ timeout-sec seconds. If this propery is set to zero, watchdog is > > > >>>+ started (or left running) so that a reset occurs in timeout-sec > > > >>>+ since the watchdog was started. > > > >>> > > > >>> Example: > > > >>> > > > >>> watchdog { > > > >>> timeout-sec = <60>; > > > >>>+ early-timeout-sec = <120>; > > > >> > > > >>That is not a generic property as you defined it; if so, > > > >>it would have to be implemented in the watchdog core code, > > > >>not in the at91 code. You'll have to document it in the bindings > > > >>description for at91sam9_wdt. > > > > > > > >Then, if this is a controller specific property, it should be defined > > > >with the 'atmel,' prefix. > > > >We're kind of looping here: the initial discussion was "is there a need > > > >for this property to be a generic one ?", and now you're saying no, > > > >while you previously left the door opened. > > > > > > > >Tomi is proposing a generic approach, as you asked him to. I agree that > > > >parsing the property in core code and making its value part of the > > > >generic watchdog struct makes sense (that's what I proposed to Tomi a > > > >few weeks ago). > > > > > > > Hmm ... the problem here is that the property description creates the > > > assumption or expectation that the property is used if defined, > > > which is not the case. > > > > > > I am not sure how to best resolve this. Maybe a comment in the property > > > description stating that implementation of is device (driver) dependent ? > > > After all, that is true for the timeout-sec property as well. > > > > > > > I would leave it in the generic file and state that it may not be > > implemented in the driver. That way, the property is documented for new > > driver writers. > > > Yes, that would be fine ok me. Great! Timo can you change the documentation accordingly ? -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 20:21 ` Boris Brezillon @ 2015-02-19 6:02 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-19 6:02 UTC (permalink / raw) To: Boris Brezillon Cc: Guenter Roeck, Alexandre Belloni, nicolas.ferre, linux-watchdog, linux-arm-kernel Hi, On 18.02.2015 22:21, Boris Brezillon wrote: > On Wed, 18 Feb 2015 09:50:02 -0800 > Guenter Roeck <linux@roeck-us.net> wrote: > >> On Wed, Feb 18, 2015 at 05:00:33PM +0100, Alexandre Belloni wrote: >>> Hi, >>> >>> On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : >>>>>>> Optional properties: >>>>>>> - timeout-sec: Contains the watchdog timeout in seconds. >>>>>>> +- early-timeout-sec: If present, specifies a timeout value in seconds >>>>>>> + that the driver keeps on ticking the watchdog HW on behalf of user >>>>>>> + space. Once this timeout expires watchdog is left to expire in >>>>>>> + timeout-sec seconds. If this propery is set to zero, watchdog is >>>>>>> + started (or left running) so that a reset occurs in timeout-sec >>>>>>> + since the watchdog was started. >>>>>>> >>>>>>> Example: >>>>>>> >>>>>>> watchdog { >>>>>>> timeout-sec = <60>; >>>>>>> + early-timeout-sec = <120>; >>>>>> >>>>>> That is not a generic property as you defined it; if so, >>>>>> it would have to be implemented in the watchdog core code, >>>>>> not in the at91 code. You'll have to document it in the bindings >>>>>> description for at91sam9_wdt. >>>>> >>>>> Then, if this is a controller specific property, it should be defined >>>>> with the 'atmel,' prefix. >>>>> We're kind of looping here: the initial discussion was "is there a need >>>>> for this property to be a generic one ?", and now you're saying no, >>>>> while you previously left the door opened. >>>>> >>>>> Tomi is proposing a generic approach, as you asked him to. I agree that >>>>> parsing the property in core code and making its value part of the >>>>> generic watchdog struct makes sense (that's what I proposed to Tomi a >>>>> few weeks ago). >>>>> >>>> Hmm ... the problem here is that the property description creates the >>>> assumption or expectation that the property is used if defined, >>>> which is not the case. >>>> >>>> I am not sure how to best resolve this. Maybe a comment in the property >>>> description stating that implementation of is device (driver) dependent ? >>>> After all, that is true for the timeout-sec property as well. >>>> >>> >>> I would leave it in the generic file and state that it may not be >>> implemented in the driver. That way, the property is documented for new >>> driver writers. >>> >> Yes, that would be fine ok me. > > Great! > Timo can you change the documentation accordingly ? Yes, sure. Will send v4 soon. -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-19 6:02 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-19 6:02 UTC (permalink / raw) To: linux-arm-kernel Hi, On 18.02.2015 22:21, Boris Brezillon wrote: > On Wed, 18 Feb 2015 09:50:02 -0800 > Guenter Roeck <linux@roeck-us.net> wrote: > >> On Wed, Feb 18, 2015 at 05:00:33PM +0100, Alexandre Belloni wrote: >>> Hi, >>> >>> On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : >>>>>>> Optional properties: >>>>>>> - timeout-sec: Contains the watchdog timeout in seconds. >>>>>>> +- early-timeout-sec: If present, specifies a timeout value in seconds >>>>>>> + that the driver keeps on ticking the watchdog HW on behalf of user >>>>>>> + space. Once this timeout expires watchdog is left to expire in >>>>>>> + timeout-sec seconds. If this propery is set to zero, watchdog is >>>>>>> + started (or left running) so that a reset occurs in timeout-sec >>>>>>> + since the watchdog was started. >>>>>>> >>>>>>> Example: >>>>>>> >>>>>>> watchdog { >>>>>>> timeout-sec = <60>; >>>>>>> + early-timeout-sec = <120>; >>>>>> >>>>>> That is not a generic property as you defined it; if so, >>>>>> it would have to be implemented in the watchdog core code, >>>>>> not in the at91 code. You'll have to document it in the bindings >>>>>> description for at91sam9_wdt. >>>>> >>>>> Then, if this is a controller specific property, it should be defined >>>>> with the 'atmel,' prefix. >>>>> We're kind of looping here: the initial discussion was "is there a need >>>>> for this property to be a generic one ?", and now you're saying no, >>>>> while you previously left the door opened. >>>>> >>>>> Tomi is proposing a generic approach, as you asked him to. I agree that >>>>> parsing the property in core code and making its value part of the >>>>> generic watchdog struct makes sense (that's what I proposed to Tomi a >>>>> few weeks ago). >>>>> >>>> Hmm ... the problem here is that the property description creates the >>>> assumption or expectation that the property is used if defined, >>>> which is not the case. >>>> >>>> I am not sure how to best resolve this. Maybe a comment in the property >>>> description stating that implementation of is device (driver) dependent ? >>>> After all, that is true for the timeout-sec property as well. >>>> >>> >>> I would leave it in the generic file and state that it may not be >>> implemented in the driver. That way, the property is documented for new >>> driver writers. >>> >> Yes, that would be fine ok me. > > Great! > Timo can you change the documentation accordingly ? Yes, sure. Will send v4 soon. -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 16:00 ` Alexandre Belloni @ 2015-02-18 21:11 ` Rob Herring -1 siblings, 0 replies; 110+ messages in thread From: Rob Herring @ 2015-02-18 21:11 UTC (permalink / raw) To: Alexandre Belloni Cc: Guenter Roeck, Boris Brezillon, Timo Kokkonen, Nicolas Ferre, linux-watchdog, linux-arm-kernel On Wed, Feb 18, 2015 at 10:00 AM, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote: > Hi, > > On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : >> >>> Optional properties: >> >>> - timeout-sec: Contains the watchdog timeout in seconds. >> >>>+- early-timeout-sec: If present, specifies a timeout value in seconds >> >>>+ that the driver keeps on ticking the watchdog HW on behalf of user >> >>>+ space. Once this timeout expires watchdog is left to expire in >> >>>+ timeout-sec seconds. If this propery is set to zero, watchdog is >> >>>+ started (or left running) so that a reset occurs in timeout-sec >> >>>+ since the watchdog was started. >> >>> >> >>> Example: >> >>> >> >>> watchdog { >> >>> timeout-sec = <60>; >> >>>+ early-timeout-sec = <120>; >> >> >> >>That is not a generic property as you defined it; if so, >> >>it would have to be implemented in the watchdog core code, >> >>not in the at91 code. You'll have to document it in the bindings >> >>description for at91sam9_wdt. >> > >> >Then, if this is a controller specific property, it should be defined >> >with the 'atmel,' prefix. >> >We're kind of looping here: the initial discussion was "is there a need >> >for this property to be a generic one ?", and now you're saying no, >> >while you previously left the door opened. >> > >> >Tomi is proposing a generic approach, as you asked him to. I agree that >> >parsing the property in core code and making its value part of the >> >generic watchdog struct makes sense (that's what I proposed to Tomi a >> >few weeks ago). >> > >> Hmm ... the problem here is that the property description creates the >> assumption or expectation that the property is used if defined, >> which is not the case. >> >> I am not sure how to best resolve this. Maybe a comment in the property >> description stating that implementation of is device (driver) dependent ? >> After all, that is true for the timeout-sec property as well. >> > > I would leave it in the generic file and state that it may not be > implemented in the driver. That way, the property is documented for new > driver writers. That is pretty much true of any optional property. Whether implemented in the driver or core is an implementation detail that does not belong in the binding. I find this property pretty questionable. Certainly having the kernel service a watchdog either enabled at reset, in the bootloader, or by the kernel is a useful feature. A timeout for "how long userspace watchdog daemon takes to start" does not belong in DT. timeout-sec should be the default/initial timeout and long enough for userspace to start. Userspace can then change it to a more suitable value. Rob ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-18 21:11 ` Rob Herring 0 siblings, 0 replies; 110+ messages in thread From: Rob Herring @ 2015-02-18 21:11 UTC (permalink / raw) To: linux-arm-kernel On Wed, Feb 18, 2015 at 10:00 AM, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote: > Hi, > > On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : >> >>> Optional properties: >> >>> - timeout-sec: Contains the watchdog timeout in seconds. >> >>>+- early-timeout-sec: If present, specifies a timeout value in seconds >> >>>+ that the driver keeps on ticking the watchdog HW on behalf of user >> >>>+ space. Once this timeout expires watchdog is left to expire in >> >>>+ timeout-sec seconds. If this propery is set to zero, watchdog is >> >>>+ started (or left running) so that a reset occurs in timeout-sec >> >>>+ since the watchdog was started. >> >>> >> >>> Example: >> >>> >> >>> watchdog { >> >>> timeout-sec = <60>; >> >>>+ early-timeout-sec = <120>; >> >> >> >>That is not a generic property as you defined it; if so, >> >>it would have to be implemented in the watchdog core code, >> >>not in the at91 code. You'll have to document it in the bindings >> >>description for at91sam9_wdt. >> > >> >Then, if this is a controller specific property, it should be defined >> >with the 'atmel,' prefix. >> >We're kind of looping here: the initial discussion was "is there a need >> >for this property to be a generic one ?", and now you're saying no, >> >while you previously left the door opened. >> > >> >Tomi is proposing a generic approach, as you asked him to. I agree that >> >parsing the property in core code and making its value part of the >> >generic watchdog struct makes sense (that's what I proposed to Tomi a >> >few weeks ago). >> > >> Hmm ... the problem here is that the property description creates the >> assumption or expectation that the property is used if defined, >> which is not the case. >> >> I am not sure how to best resolve this. Maybe a comment in the property >> description stating that implementation of is device (driver) dependent ? >> After all, that is true for the timeout-sec property as well. >> > > I would leave it in the generic file and state that it may not be > implemented in the driver. That way, the property is documented for new > driver writers. That is pretty much true of any optional property. Whether implemented in the driver or core is an implementation detail that does not belong in the binding. I find this property pretty questionable. Certainly having the kernel service a watchdog either enabled at reset, in the bootloader, or by the kernel is a useful feature. A timeout for "how long userspace watchdog daemon takes to start" does not belong in DT. timeout-sec should be the default/initial timeout and long enough for userspace to start. Userspace can then change it to a more suitable value. Rob ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 21:11 ` Rob Herring @ 2015-02-19 6:14 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-19 6:14 UTC (permalink / raw) To: Rob Herring, Alexandre Belloni Cc: Guenter Roeck, Boris Brezillon, Nicolas Ferre, linux-watchdog, linux-arm-kernel Hi, On 18.02.2015 23:11, Rob Herring wrote: > On Wed, Feb 18, 2015 at 10:00 AM, Alexandre Belloni > <alexandre.belloni@free-electrons.com> wrote: >> Hi, >> >> On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : >>>>>> Optional properties: >>>>>> - timeout-sec: Contains the watchdog timeout in seconds. >>>>>> +- early-timeout-sec: If present, specifies a timeout value in seconds >>>>>> + that the driver keeps on ticking the watchdog HW on behalf of user >>>>>> + space. Once this timeout expires watchdog is left to expire in >>>>>> + timeout-sec seconds. If this propery is set to zero, watchdog is >>>>>> + started (or left running) so that a reset occurs in timeout-sec >>>>>> + since the watchdog was started. >>>>>> >>>>>> Example: >>>>>> >>>>>> watchdog { >>>>>> timeout-sec = <60>; >>>>>> + early-timeout-sec = <120>; >>>>> >>>>> That is not a generic property as you defined it; if so, >>>>> it would have to be implemented in the watchdog core code, >>>>> not in the at91 code. You'll have to document it in the bindings >>>>> description for at91sam9_wdt. >>>> >>>> Then, if this is a controller specific property, it should be defined >>>> with the 'atmel,' prefix. >>>> We're kind of looping here: the initial discussion was "is there a need >>>> for this property to be a generic one ?", and now you're saying no, >>>> while you previously left the door opened. >>>> >>>> Tomi is proposing a generic approach, as you asked him to. I agree that >>>> parsing the property in core code and making its value part of the >>>> generic watchdog struct makes sense (that's what I proposed to Tomi a >>>> few weeks ago). >>>> >>> Hmm ... the problem here is that the property description creates the >>> assumption or expectation that the property is used if defined, >>> which is not the case. >>> >>> I am not sure how to best resolve this. Maybe a comment in the property >>> description stating that implementation of is device (driver) dependent ? >>> After all, that is true for the timeout-sec property as well. >>> >> >> I would leave it in the generic file and state that it may not be >> implemented in the driver. That way, the property is documented for new >> driver writers. > > That is pretty much true of any optional property. Whether implemented > in the driver or core is an implementation detail that does not belong > in the binding. > > I find this property pretty questionable. Certainly having the kernel > service a watchdog either enabled at reset, in the bootloader, or by > the kernel is a useful feature. A timeout for "how long userspace > watchdog daemon takes to start" does not belong in DT. timeout-sec > should be the default/initial timeout and long enough for userspace to > start. Userspace can then change it to a more suitable value. That would be a good workaround if we had enough time in the watchdog HW to wait long enough for the user space to start up. For example in atmel HW the maximum is 16 seconds, which may not be enough for the kernel to boot up and the user space to start the watchdog daemon. But even that is not enough as all of the watchdog drivers attempt to *disable* the watchdog device before user space opens it. What good is a watchdog if it is disabled by the kernel and we got stuck before the daemon wakes up and re-enables it? This the problem with all of the watchdog drivers right now. There are plenty of products out there that can't deal with this kind of limitation. They are all hacking around it one way or another. If there is a crash, the watchdog must reset the device. I can't think of any other run time way to configure the watchdog for this kind of situation than having a device tree property for it. What I am proposing here is a way to solve this without hacking. I was told to think also a way to defer starting the watchdog for a given timeout so that user space would have more time to wake up, which sounded like a good idea. And this obviously needs to be implemented so that the watchdog is guaranteed to reset the device should there be a crash of any kind that prevents the watchdog daemon from starting up. There are a lot of details that need to be taken care of properly and therefore watchdog core can't do much about it, which is why I thought there is no much point trying to do it in watchdog core. But never the less I can try to state this in the documentation just to make clear what we are trying to solve here. Thanks for all the good comments! -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-19 6:14 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-19 6:14 UTC (permalink / raw) To: linux-arm-kernel Hi, On 18.02.2015 23:11, Rob Herring wrote: > On Wed, Feb 18, 2015 at 10:00 AM, Alexandre Belloni > <alexandre.belloni@free-electrons.com> wrote: >> Hi, >> >> On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : >>>>>> Optional properties: >>>>>> - timeout-sec: Contains the watchdog timeout in seconds. >>>>>> +- early-timeout-sec: If present, specifies a timeout value in seconds >>>>>> + that the driver keeps on ticking the watchdog HW on behalf of user >>>>>> + space. Once this timeout expires watchdog is left to expire in >>>>>> + timeout-sec seconds. If this propery is set to zero, watchdog is >>>>>> + started (or left running) so that a reset occurs in timeout-sec >>>>>> + since the watchdog was started. >>>>>> >>>>>> Example: >>>>>> >>>>>> watchdog { >>>>>> timeout-sec = <60>; >>>>>> + early-timeout-sec = <120>; >>>>> >>>>> That is not a generic property as you defined it; if so, >>>>> it would have to be implemented in the watchdog core code, >>>>> not in the at91 code. You'll have to document it in the bindings >>>>> description for at91sam9_wdt. >>>> >>>> Then, if this is a controller specific property, it should be defined >>>> with the 'atmel,' prefix. >>>> We're kind of looping here: the initial discussion was "is there a need >>>> for this property to be a generic one ?", and now you're saying no, >>>> while you previously left the door opened. >>>> >>>> Tomi is proposing a generic approach, as you asked him to. I agree that >>>> parsing the property in core code and making its value part of the >>>> generic watchdog struct makes sense (that's what I proposed to Tomi a >>>> few weeks ago). >>>> >>> Hmm ... the problem here is that the property description creates the >>> assumption or expectation that the property is used if defined, >>> which is not the case. >>> >>> I am not sure how to best resolve this. Maybe a comment in the property >>> description stating that implementation of is device (driver) dependent ? >>> After all, that is true for the timeout-sec property as well. >>> >> >> I would leave it in the generic file and state that it may not be >> implemented in the driver. That way, the property is documented for new >> driver writers. > > That is pretty much true of any optional property. Whether implemented > in the driver or core is an implementation detail that does not belong > in the binding. > > I find this property pretty questionable. Certainly having the kernel > service a watchdog either enabled at reset, in the bootloader, or by > the kernel is a useful feature. A timeout for "how long userspace > watchdog daemon takes to start" does not belong in DT. timeout-sec > should be the default/initial timeout and long enough for userspace to > start. Userspace can then change it to a more suitable value. That would be a good workaround if we had enough time in the watchdog HW to wait long enough for the user space to start up. For example in atmel HW the maximum is 16 seconds, which may not be enough for the kernel to boot up and the user space to start the watchdog daemon. But even that is not enough as all of the watchdog drivers attempt to *disable* the watchdog device before user space opens it. What good is a watchdog if it is disabled by the kernel and we got stuck before the daemon wakes up and re-enables it? This the problem with all of the watchdog drivers right now. There are plenty of products out there that can't deal with this kind of limitation. They are all hacking around it one way or another. If there is a crash, the watchdog must reset the device. I can't think of any other run time way to configure the watchdog for this kind of situation than having a device tree property for it. What I am proposing here is a way to solve this without hacking. I was told to think also a way to defer starting the watchdog for a given timeout so that user space would have more time to wake up, which sounded like a good idea. And this obviously needs to be implemented so that the watchdog is guaranteed to reset the device should there be a crash of any kind that prevents the watchdog daemon from starting up. There are a lot of details that need to be taken care of properly and therefore watchdog core can't do much about it, which is why I thought there is no much point trying to do it in watchdog core. But never the less I can try to state this in the documentation just to make clear what we are trying to solve here. Thanks for all the good comments! -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-19 6:14 ` Timo Kokkonen @ 2015-02-20 14:06 ` Rob Herring -1 siblings, 0 replies; 110+ messages in thread From: Rob Herring @ 2015-02-20 14:06 UTC (permalink / raw) To: Timo Kokkonen Cc: Alexandre Belloni, Guenter Roeck, Boris Brezillon, Nicolas Ferre, linux-watchdog, linux-arm-kernel On Thu, Feb 19, 2015 at 12:14 AM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > Hi, > > > On 18.02.2015 23:11, Rob Herring wrote: >> >> On Wed, Feb 18, 2015 at 10:00 AM, Alexandre Belloni >> <alexandre.belloni@free-electrons.com> wrote: >>> >>> Hi, >>> >>> On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : >>>>>>> >>>>>>> Optional properties: >>>>>>> - timeout-sec: Contains the watchdog timeout in seconds. >>>>>>> +- early-timeout-sec: If present, specifies a timeout value in >>>>>>> seconds >>>>>>> + that the driver keeps on ticking the watchdog HW on behalf of user >>>>>>> + space. Once this timeout expires watchdog is left to expire in >>>>>>> + timeout-sec seconds. If this propery is set to zero, watchdog is >>>>>>> + started (or left running) so that a reset occurs in timeout-sec >>>>>>> + since the watchdog was started. >>>>>>> >>>>>>> Example: >>>>>>> >>>>>>> watchdog { >>>>>>> timeout-sec = <60>; >>>>>>> + early-timeout-sec = <120>; >>>>>> >>>>>> >>>>>> That is not a generic property as you defined it; if so, >>>>>> it would have to be implemented in the watchdog core code, >>>>>> not in the at91 code. You'll have to document it in the bindings >>>>>> description for at91sam9_wdt. >>>>> >>>>> >>>>> Then, if this is a controller specific property, it should be defined >>>>> with the 'atmel,' prefix. >>>>> We're kind of looping here: the initial discussion was "is there a need >>>>> for this property to be a generic one ?", and now you're saying no, >>>>> while you previously left the door opened. >>>>> >>>>> Tomi is proposing a generic approach, as you asked him to. I agree that >>>>> parsing the property in core code and making its value part of the >>>>> generic watchdog struct makes sense (that's what I proposed to Tomi a >>>>> few weeks ago). >>>>> >>>> Hmm ... the problem here is that the property description creates the >>>> assumption or expectation that the property is used if defined, >>>> which is not the case. >>>> >>>> I am not sure how to best resolve this. Maybe a comment in the property >>>> description stating that implementation of is device (driver) dependent >>>> ? >>>> After all, that is true for the timeout-sec property as well. >>>> >>> >>> I would leave it in the generic file and state that it may not be >>> implemented in the driver. That way, the property is documented for new >>> driver writers. >> >> >> That is pretty much true of any optional property. Whether implemented >> in the driver or core is an implementation detail that does not belong >> in the binding. >> >> I find this property pretty questionable. Certainly having the kernel >> service a watchdog either enabled at reset, in the bootloader, or by >> the kernel is a useful feature. A timeout for "how long userspace >> watchdog daemon takes to start" does not belong in DT. timeout-sec >> should be the default/initial timeout and long enough for userspace to >> start. Userspace can then change it to a more suitable value. > > > That would be a good workaround if we had enough time in the watchdog HW to > wait long enough for the user space to start up. For example in atmel HW the > maximum is 16 seconds, which may not be enough for the kernel to boot up and > the user space to start the watchdog daemon. Well, the 16 sec maximum may be something useful to put into the DT as that actually is a property of the h/w. > But even that is not enough as all of the watchdog drivers attempt to > *disable* the watchdog device before user space opens it. What good is a > watchdog if it is disabled by the kernel and we got stuck before the daemon > wakes up and re-enables it? This the problem with all of the watchdog > drivers right now. There are plenty of products out there that can't deal > with this kind of limitation. They are all hacking around it one way or > another. If there is a crash, the watchdog must reset the device. I can't > think of any other run time way to configure the watchdog for this kind of > situation than having a device tree property for it. I fully agree the current design is broken. We should fix that in a generic way. > What I am proposing here is a way to solve this without hacking. I was told > to think also a way to defer starting the watchdog for a given timeout so > that user space would have more time to wake up, which sounded like a good > idea. And this obviously needs to be implemented so that the watchdog is > guaranteed to reset the device should there be a crash of any kind that > prevents the watchdog daemon from starting up. There are a lot of details > that need to be taken care of properly and therefore watchdog core can't do > much about it, which is why I thought there is no much point trying to do it > in watchdog core. Deferring would assume that the watchdog is not already enabled. Putting in how long the kernel should service the watchdog in DT is like putting soft or hard lockup detection times into DT. These are kernel settings. If you need to change this, you should update your kernel or kernel settings, not the DT. Rob > > But never the less I can try to state this in the documentation just to make > clear what we are trying to solve here. > > Thanks for all the good comments! > > -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 14:06 ` Rob Herring 0 siblings, 0 replies; 110+ messages in thread From: Rob Herring @ 2015-02-20 14:06 UTC (permalink / raw) To: linux-arm-kernel On Thu, Feb 19, 2015 at 12:14 AM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > Hi, > > > On 18.02.2015 23:11, Rob Herring wrote: >> >> On Wed, Feb 18, 2015 at 10:00 AM, Alexandre Belloni >> <alexandre.belloni@free-electrons.com> wrote: >>> >>> Hi, >>> >>> On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : >>>>>>> >>>>>>> Optional properties: >>>>>>> - timeout-sec: Contains the watchdog timeout in seconds. >>>>>>> +- early-timeout-sec: If present, specifies a timeout value in >>>>>>> seconds >>>>>>> + that the driver keeps on ticking the watchdog HW on behalf of user >>>>>>> + space. Once this timeout expires watchdog is left to expire in >>>>>>> + timeout-sec seconds. If this propery is set to zero, watchdog is >>>>>>> + started (or left running) so that a reset occurs in timeout-sec >>>>>>> + since the watchdog was started. >>>>>>> >>>>>>> Example: >>>>>>> >>>>>>> watchdog { >>>>>>> timeout-sec = <60>; >>>>>>> + early-timeout-sec = <120>; >>>>>> >>>>>> >>>>>> That is not a generic property as you defined it; if so, >>>>>> it would have to be implemented in the watchdog core code, >>>>>> not in the at91 code. You'll have to document it in the bindings >>>>>> description for at91sam9_wdt. >>>>> >>>>> >>>>> Then, if this is a controller specific property, it should be defined >>>>> with the 'atmel,' prefix. >>>>> We're kind of looping here: the initial discussion was "is there a need >>>>> for this property to be a generic one ?", and now you're saying no, >>>>> while you previously left the door opened. >>>>> >>>>> Tomi is proposing a generic approach, as you asked him to. I agree that >>>>> parsing the property in core code and making its value part of the >>>>> generic watchdog struct makes sense (that's what I proposed to Tomi a >>>>> few weeks ago). >>>>> >>>> Hmm ... the problem here is that the property description creates the >>>> assumption or expectation that the property is used if defined, >>>> which is not the case. >>>> >>>> I am not sure how to best resolve this. Maybe a comment in the property >>>> description stating that implementation of is device (driver) dependent >>>> ? >>>> After all, that is true for the timeout-sec property as well. >>>> >>> >>> I would leave it in the generic file and state that it may not be >>> implemented in the driver. That way, the property is documented for new >>> driver writers. >> >> >> That is pretty much true of any optional property. Whether implemented >> in the driver or core is an implementation detail that does not belong >> in the binding. >> >> I find this property pretty questionable. Certainly having the kernel >> service a watchdog either enabled at reset, in the bootloader, or by >> the kernel is a useful feature. A timeout for "how long userspace >> watchdog daemon takes to start" does not belong in DT. timeout-sec >> should be the default/initial timeout and long enough for userspace to >> start. Userspace can then change it to a more suitable value. > > > That would be a good workaround if we had enough time in the watchdog HW to > wait long enough for the user space to start up. For example in atmel HW the > maximum is 16 seconds, which may not be enough for the kernel to boot up and > the user space to start the watchdog daemon. Well, the 16 sec maximum may be something useful to put into the DT as that actually is a property of the h/w. > But even that is not enough as all of the watchdog drivers attempt to > *disable* the watchdog device before user space opens it. What good is a > watchdog if it is disabled by the kernel and we got stuck before the daemon > wakes up and re-enables it? This the problem with all of the watchdog > drivers right now. There are plenty of products out there that can't deal > with this kind of limitation. They are all hacking around it one way or > another. If there is a crash, the watchdog must reset the device. I can't > think of any other run time way to configure the watchdog for this kind of > situation than having a device tree property for it. I fully agree the current design is broken. We should fix that in a generic way. > What I am proposing here is a way to solve this without hacking. I was told > to think also a way to defer starting the watchdog for a given timeout so > that user space would have more time to wake up, which sounded like a good > idea. And this obviously needs to be implemented so that the watchdog is > guaranteed to reset the device should there be a crash of any kind that > prevents the watchdog daemon from starting up. There are a lot of details > that need to be taken care of properly and therefore watchdog core can't do > much about it, which is why I thought there is no much point trying to do it > in watchdog core. Deferring would assume that the watchdog is not already enabled. Putting in how long the kernel should service the watchdog in DT is like putting soft or hard lockup detection times into DT. These are kernel settings. If you need to change this, you should update your kernel or kernel settings, not the DT. Rob > > But never the less I can try to state this in the documentation just to make > clear what we are trying to solve here. > > Thanks for all the good comments! > > -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-20 14:06 ` Rob Herring @ 2015-02-20 16:28 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-20 16:28 UTC (permalink / raw) To: Rob Herring Cc: Timo Kokkonen, Alexandre Belloni, Boris Brezillon, Nicolas Ferre, linux-watchdog, linux-arm-kernel On Fri, Feb 20, 2015 at 08:06:23AM -0600, Rob Herring wrote: > On Thu, Feb 19, 2015 at 12:14 AM, Timo Kokkonen > <timo.kokkonen@offcode.fi> wrote: > > Hi, > > > > > > On 18.02.2015 23:11, Rob Herring wrote: > >> > >> On Wed, Feb 18, 2015 at 10:00 AM, Alexandre Belloni > >> <alexandre.belloni@free-electrons.com> wrote: > >>> > >>> Hi, > >>> > >>> On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : > >>>>>>> > >>>>>>> Optional properties: > >>>>>>> - timeout-sec: Contains the watchdog timeout in seconds. > >>>>>>> +- early-timeout-sec: If present, specifies a timeout value in > >>>>>>> seconds > >>>>>>> + that the driver keeps on ticking the watchdog HW on behalf of user > >>>>>>> + space. Once this timeout expires watchdog is left to expire in > >>>>>>> + timeout-sec seconds. If this propery is set to zero, watchdog is > >>>>>>> + started (or left running) so that a reset occurs in timeout-sec > >>>>>>> + since the watchdog was started. > >>>>>>> > >>>>>>> Example: > >>>>>>> > >>>>>>> watchdog { > >>>>>>> timeout-sec = <60>; > >>>>>>> + early-timeout-sec = <120>; > >>>>>> > >>>>>> > >>>>>> That is not a generic property as you defined it; if so, > >>>>>> it would have to be implemented in the watchdog core code, > >>>>>> not in the at91 code. You'll have to document it in the bindings > >>>>>> description for at91sam9_wdt. > >>>>> > >>>>> > >>>>> Then, if this is a controller specific property, it should be defined > >>>>> with the 'atmel,' prefix. > >>>>> We're kind of looping here: the initial discussion was "is there a need > >>>>> for this property to be a generic one ?", and now you're saying no, > >>>>> while you previously left the door opened. > >>>>> > >>>>> Tomi is proposing a generic approach, as you asked him to. I agree that > >>>>> parsing the property in core code and making its value part of the > >>>>> generic watchdog struct makes sense (that's what I proposed to Tomi a > >>>>> few weeks ago). > >>>>> > >>>> Hmm ... the problem here is that the property description creates the > >>>> assumption or expectation that the property is used if defined, > >>>> which is not the case. > >>>> > >>>> I am not sure how to best resolve this. Maybe a comment in the property > >>>> description stating that implementation of is device (driver) dependent > >>>> ? > >>>> After all, that is true for the timeout-sec property as well. > >>>> > >>> > >>> I would leave it in the generic file and state that it may not be > >>> implemented in the driver. That way, the property is documented for new > >>> driver writers. > >> > >> > >> That is pretty much true of any optional property. Whether implemented > >> in the driver or core is an implementation detail that does not belong > >> in the binding. > >> > >> I find this property pretty questionable. Certainly having the kernel > >> service a watchdog either enabled at reset, in the bootloader, or by > >> the kernel is a useful feature. A timeout for "how long userspace > >> watchdog daemon takes to start" does not belong in DT. timeout-sec > >> should be the default/initial timeout and long enough for userspace to > >> start. Userspace can then change it to a more suitable value. > > > > > > That would be a good workaround if we had enough time in the watchdog HW to > > wait long enough for the user space to start up. For example in atmel HW the > > maximum is 16 seconds, which may not be enough for the kernel to boot up and > > the user space to start the watchdog daemon. > > Well, the 16 sec maximum may be something useful to put into the DT as > that actually is a property of the h/w. > > > But even that is not enough as all of the watchdog drivers attempt to > > *disable* the watchdog device before user space opens it. What good is a > > watchdog if it is disabled by the kernel and we got stuck before the daemon > > wakes up and re-enables it? This the problem with all of the watchdog > > drivers right now. There are plenty of products out there that can't deal > > with this kind of limitation. They are all hacking around it one way or > > another. If there is a crash, the watchdog must reset the device. I can't > > think of any other run time way to configure the watchdog for this kind of > > situation than having a device tree property for it. > > I fully agree the current design is broken. We should fix that in a > generic way. > > > What I am proposing here is a way to solve this without hacking. I was told > > to think also a way to defer starting the watchdog for a given timeout so > > that user space would have more time to wake up, which sounded like a good > > idea. And this obviously needs to be implemented so that the watchdog is > > guaranteed to reset the device should there be a crash of any kind that > > prevents the watchdog daemon from starting up. There are a lot of details > > that need to be taken care of properly and therefore watchdog core can't do > > much about it, which is why I thought there is no much point trying to do it > > in watchdog core. > > Deferring would assume that the watchdog is not already enabled. > > Putting in how long the kernel should service the watchdog in DT is > like putting soft or hard lockup detection times into DT. These are > kernel settings. If you need to change this, you should update your > kernel or kernel settings, not the DT. > The time to userspace handover may differ from HW variant to HW variant. Some may load faster, some may load slower. Similar, the runtime watchdog timeout may be different from system to system. On a system with faster CPU, and/or one with faster io, one may want (or need) a faster watchdog timeout. I assumed that was accepted and understood when the timeout-sec property was introduced a long time ago, but maybe not. Yes, the problem should be resolved in a generic way. This has been on my mind for a long time, including the problem if a watchdog should or should not stay or become enabled during early boot. All those are system properties which should be addressed generically, and there should be a means to express those properties in devicetree. Problem goes back into the old back-and-forth of what can be in devicetree or not. Sorting that out always takes a long time and a substantial amount of effort. Unfortunately, I don't have that time (writing the code would probably be trivial in comparison). If someone is willing and able to spend the necessary time to negotiate acceptable devicetree properties and to write the necessary code, I'll be more than happy to review and as much as possible test the resulting patches, and I am sure that Wim will be happy to accept them. Until then we'll have to live with what we have today. Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 16:28 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-20 16:28 UTC (permalink / raw) To: linux-arm-kernel On Fri, Feb 20, 2015 at 08:06:23AM -0600, Rob Herring wrote: > On Thu, Feb 19, 2015 at 12:14 AM, Timo Kokkonen > <timo.kokkonen@offcode.fi> wrote: > > Hi, > > > > > > On 18.02.2015 23:11, Rob Herring wrote: > >> > >> On Wed, Feb 18, 2015 at 10:00 AM, Alexandre Belloni > >> <alexandre.belloni@free-electrons.com> wrote: > >>> > >>> Hi, > >>> > >>> On 18/02/2015 at 06:50:44 -0800, Guenter Roeck wrote : > >>>>>>> > >>>>>>> Optional properties: > >>>>>>> - timeout-sec: Contains the watchdog timeout in seconds. > >>>>>>> +- early-timeout-sec: If present, specifies a timeout value in > >>>>>>> seconds > >>>>>>> + that the driver keeps on ticking the watchdog HW on behalf of user > >>>>>>> + space. Once this timeout expires watchdog is left to expire in > >>>>>>> + timeout-sec seconds. If this propery is set to zero, watchdog is > >>>>>>> + started (or left running) so that a reset occurs in timeout-sec > >>>>>>> + since the watchdog was started. > >>>>>>> > >>>>>>> Example: > >>>>>>> > >>>>>>> watchdog { > >>>>>>> timeout-sec = <60>; > >>>>>>> + early-timeout-sec = <120>; > >>>>>> > >>>>>> > >>>>>> That is not a generic property as you defined it; if so, > >>>>>> it would have to be implemented in the watchdog core code, > >>>>>> not in the at91 code. You'll have to document it in the bindings > >>>>>> description for at91sam9_wdt. > >>>>> > >>>>> > >>>>> Then, if this is a controller specific property, it should be defined > >>>>> with the 'atmel,' prefix. > >>>>> We're kind of looping here: the initial discussion was "is there a need > >>>>> for this property to be a generic one ?", and now you're saying no, > >>>>> while you previously left the door opened. > >>>>> > >>>>> Tomi is proposing a generic approach, as you asked him to. I agree that > >>>>> parsing the property in core code and making its value part of the > >>>>> generic watchdog struct makes sense (that's what I proposed to Tomi a > >>>>> few weeks ago). > >>>>> > >>>> Hmm ... the problem here is that the property description creates the > >>>> assumption or expectation that the property is used if defined, > >>>> which is not the case. > >>>> > >>>> I am not sure how to best resolve this. Maybe a comment in the property > >>>> description stating that implementation of is device (driver) dependent > >>>> ? > >>>> After all, that is true for the timeout-sec property as well. > >>>> > >>> > >>> I would leave it in the generic file and state that it may not be > >>> implemented in the driver. That way, the property is documented for new > >>> driver writers. > >> > >> > >> That is pretty much true of any optional property. Whether implemented > >> in the driver or core is an implementation detail that does not belong > >> in the binding. > >> > >> I find this property pretty questionable. Certainly having the kernel > >> service a watchdog either enabled at reset, in the bootloader, or by > >> the kernel is a useful feature. A timeout for "how long userspace > >> watchdog daemon takes to start" does not belong in DT. timeout-sec > >> should be the default/initial timeout and long enough for userspace to > >> start. Userspace can then change it to a more suitable value. > > > > > > That would be a good workaround if we had enough time in the watchdog HW to > > wait long enough for the user space to start up. For example in atmel HW the > > maximum is 16 seconds, which may not be enough for the kernel to boot up and > > the user space to start the watchdog daemon. > > Well, the 16 sec maximum may be something useful to put into the DT as > that actually is a property of the h/w. > > > But even that is not enough as all of the watchdog drivers attempt to > > *disable* the watchdog device before user space opens it. What good is a > > watchdog if it is disabled by the kernel and we got stuck before the daemon > > wakes up and re-enables it? This the problem with all of the watchdog > > drivers right now. There are plenty of products out there that can't deal > > with this kind of limitation. They are all hacking around it one way or > > another. If there is a crash, the watchdog must reset the device. I can't > > think of any other run time way to configure the watchdog for this kind of > > situation than having a device tree property for it. > > I fully agree the current design is broken. We should fix that in a > generic way. > > > What I am proposing here is a way to solve this without hacking. I was told > > to think also a way to defer starting the watchdog for a given timeout so > > that user space would have more time to wake up, which sounded like a good > > idea. And this obviously needs to be implemented so that the watchdog is > > guaranteed to reset the device should there be a crash of any kind that > > prevents the watchdog daemon from starting up. There are a lot of details > > that need to be taken care of properly and therefore watchdog core can't do > > much about it, which is why I thought there is no much point trying to do it > > in watchdog core. > > Deferring would assume that the watchdog is not already enabled. > > Putting in how long the kernel should service the watchdog in DT is > like putting soft or hard lockup detection times into DT. These are > kernel settings. If you need to change this, you should update your > kernel or kernel settings, not the DT. > The time to userspace handover may differ from HW variant to HW variant. Some may load faster, some may load slower. Similar, the runtime watchdog timeout may be different from system to system. On a system with faster CPU, and/or one with faster io, one may want (or need) a faster watchdog timeout. I assumed that was accepted and understood when the timeout-sec property was introduced a long time ago, but maybe not. Yes, the problem should be resolved in a generic way. This has been on my mind for a long time, including the problem if a watchdog should or should not stay or become enabled during early boot. All those are system properties which should be addressed generically, and there should be a means to express those properties in devicetree. Problem goes back into the old back-and-forth of what can be in devicetree or not. Sorting that out always takes a long time and a substantial amount of effort. Unfortunately, I don't have that time (writing the code would probably be trivial in comparison). If someone is willing and able to spend the necessary time to negotiate acceptable devicetree properties and to write the necessary code, I'll be more than happy to review and as much as possible test the resulting patches, and I am sure that Wim will be happy to accept them. Until then we'll have to live with what we have today. Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-20 16:28 ` Guenter Roeck @ 2015-02-20 19:43 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-20 19:43 UTC (permalink / raw) To: Guenter Roeck, Rob Herring Cc: Timo Kokkonen, Alexandre Belloni, Nicolas Ferre, linux-watchdog, linux-arm-kernel On Fri, 20 Feb 2015 08:28:55 -0800 Guenter Roeck <linux@roeck-us.net> wrote: > On Fri, Feb 20, 2015 at 08:06:23AM -0600, Rob Herring wrote: > > On Thu, Feb 19, 2015 at 12:14 AM, Timo Kokkonen > > <timo.kokkonen@offcode.fi> wrote: > > > Hi, > > > [...] > > > What I am proposing here is a way to solve this without hacking. I was told > > > to think also a way to defer starting the watchdog for a given timeout so > > > that user space would have more time to wake up, which sounded like a good > > > idea. And this obviously needs to be implemented so that the watchdog is > > > guaranteed to reset the device should there be a crash of any kind that > > > prevents the watchdog daemon from starting up. There are a lot of details > > > that need to be taken care of properly and therefore watchdog core can't do > > > much about it, which is why I thought there is no much point trying to do it > > > in watchdog core. > > > > Deferring would assume that the watchdog is not already enabled. > > > > Putting in how long the kernel should service the watchdog in DT is > > like putting soft or hard lockup detection times into DT. These are > > kernel settings. If you need to change this, you should update your > > kernel or kernel settings, not the DT. > > > The time to userspace handover may differ from HW variant to HW variant. > Some may load faster, some may load slower. > > Similar, the runtime watchdog timeout may be different from system > to system. On a system with faster CPU, and/or one with faster io, > one may want (or need) a faster watchdog timeout. I assumed that > was accepted and understood when the timeout-sec property was > introduced a long time ago, but maybe not. > > Yes, the problem should be resolved in a generic way. This has been > on my mind for a long time, including the problem if a watchdog should > or should not stay or become enabled during early boot. All those are > system properties which should be addressed generically, and there > should be a means to express those properties in devicetree. > > Problem goes back into the old back-and-forth of what can be in devicetree > or not. Sorting that out always takes a long time and a substantial amount > of effort. Unfortunately, I don't have that time (writing the code would > probably be trivial in comparison). I once promised myself to propose this stupid idea, so here it is: How about creating a new concept called CT (for Config Tree), that would reuse the DT syntax and tree representation and add system config information to the appropriate devices (something like an overlay you'll put on top of your DT). This way nobody could ever complain about config information being stored in the DT, and people needing system config (like the one described here) could put them in this CT. CT files would be stored in files with a .cts or .ctsi extension, ... I'm stopping here, I think you got my point. Joke apart, I've had the same kind of discussion quite often lately. While I understand DT guys concern to control which property should go into the DT which ones should not, some system config are better described next to the device they are attached to rather than in the cmdline. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 19:43 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-20 19:43 UTC (permalink / raw) To: linux-arm-kernel On Fri, 20 Feb 2015 08:28:55 -0800 Guenter Roeck <linux@roeck-us.net> wrote: > On Fri, Feb 20, 2015 at 08:06:23AM -0600, Rob Herring wrote: > > On Thu, Feb 19, 2015 at 12:14 AM, Timo Kokkonen > > <timo.kokkonen@offcode.fi> wrote: > > > Hi, > > > [...] > > > What I am proposing here is a way to solve this without hacking. I was told > > > to think also a way to defer starting the watchdog for a given timeout so > > > that user space would have more time to wake up, which sounded like a good > > > idea. And this obviously needs to be implemented so that the watchdog is > > > guaranteed to reset the device should there be a crash of any kind that > > > prevents the watchdog daemon from starting up. There are a lot of details > > > that need to be taken care of properly and therefore watchdog core can't do > > > much about it, which is why I thought there is no much point trying to do it > > > in watchdog core. > > > > Deferring would assume that the watchdog is not already enabled. > > > > Putting in how long the kernel should service the watchdog in DT is > > like putting soft or hard lockup detection times into DT. These are > > kernel settings. If you need to change this, you should update your > > kernel or kernel settings, not the DT. > > > The time to userspace handover may differ from HW variant to HW variant. > Some may load faster, some may load slower. > > Similar, the runtime watchdog timeout may be different from system > to system. On a system with faster CPU, and/or one with faster io, > one may want (or need) a faster watchdog timeout. I assumed that > was accepted and understood when the timeout-sec property was > introduced a long time ago, but maybe not. > > Yes, the problem should be resolved in a generic way. This has been > on my mind for a long time, including the problem if a watchdog should > or should not stay or become enabled during early boot. All those are > system properties which should be addressed generically, and there > should be a means to express those properties in devicetree. > > Problem goes back into the old back-and-forth of what can be in devicetree > or not. Sorting that out always takes a long time and a substantial amount > of effort. Unfortunately, I don't have that time (writing the code would > probably be trivial in comparison). I once promised myself to propose this stupid idea, so here it is: How about creating a new concept called CT (for Config Tree), that would reuse the DT syntax and tree representation and add system config information to the appropriate devices (something like an overlay you'll put on top of your DT). This way nobody could ever complain about config information being stored in the DT, and people needing system config (like the one described here) could put them in this CT. CT files would be stored in files with a .cts or .ctsi extension, ... I'm stopping here, I think you got my point. Joke apart, I've had the same kind of discussion quite often lately. While I understand DT guys concern to control which property should go into the DT which ones should not, some system config are better described next to the device they are attached to rather than in the cmdline. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-20 19:43 ` Boris Brezillon @ 2015-02-20 20:04 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-20 20:04 UTC (permalink / raw) To: Boris Brezillon Cc: Rob Herring, Timo Kokkonen, Alexandre Belloni, Nicolas Ferre, linux-watchdog, linux-arm-kernel On Fri, Feb 20, 2015 at 08:43:58PM +0100, Boris Brezillon wrote: > On Fri, 20 Feb 2015 08:28:55 -0800 > Guenter Roeck <linux@roeck-us.net> wrote: > > > On Fri, Feb 20, 2015 at 08:06:23AM -0600, Rob Herring wrote: > > > On Thu, Feb 19, 2015 at 12:14 AM, Timo Kokkonen > > > <timo.kokkonen@offcode.fi> wrote: > > > > Hi, > > > > > > [...] > > > > > What I am proposing here is a way to solve this without hacking. I was told > > > > to think also a way to defer starting the watchdog for a given timeout so > > > > that user space would have more time to wake up, which sounded like a good > > > > idea. And this obviously needs to be implemented so that the watchdog is > > > > guaranteed to reset the device should there be a crash of any kind that > > > > prevents the watchdog daemon from starting up. There are a lot of details > > > > that need to be taken care of properly and therefore watchdog core can't do > > > > much about it, which is why I thought there is no much point trying to do it > > > > in watchdog core. > > > > > > Deferring would assume that the watchdog is not already enabled. > > > > > > Putting in how long the kernel should service the watchdog in DT is > > > like putting soft or hard lockup detection times into DT. These are > > > kernel settings. If you need to change this, you should update your > > > kernel or kernel settings, not the DT. > > > > > The time to userspace handover may differ from HW variant to HW variant. > > Some may load faster, some may load slower. > > > > Similar, the runtime watchdog timeout may be different from system > > to system. On a system with faster CPU, and/or one with faster io, > > one may want (or need) a faster watchdog timeout. I assumed that > > was accepted and understood when the timeout-sec property was > > introduced a long time ago, but maybe not. > > > > Yes, the problem should be resolved in a generic way. This has been > > on my mind for a long time, including the problem if a watchdog should > > or should not stay or become enabled during early boot. All those are > > system properties which should be addressed generically, and there > > should be a means to express those properties in devicetree. > > > > Problem goes back into the old back-and-forth of what can be in devicetree > > or not. Sorting that out always takes a long time and a substantial amount > > of effort. Unfortunately, I don't have that time (writing the code would > > probably be trivial in comparison). > > I once promised myself to propose this stupid idea, so here it is: > How about creating a new concept called CT (for Config Tree), that > would reuse the DT syntax and tree representation and add system config > information to the appropriate devices (something like an overlay > you'll put on top of your DT). > We actually use that approach at work - essentially a system configuration using dt syntax. It even uses the dt compiler to create dtb files, only the dtb files are kept as part of the application software. Problem here though is that we are not talking about configuration, but about system properties. Secondary problem is that those system properties can be abused, and "it can be abused, let's reject it" is always easy. This is made more complicated by the fact that very few people are willing or even able to go through the exercise of clearly distinguishing system configuration vs. system properties when proposing new dt properties, especially since this can be a very tricky slope and may require 90% communication skills and 10% engineering skills (use the term 'configuration' once and you are out). Not really sure how to solve that problem, or if it is even possible to solve it. > Joke apart, I've had the same kind of discussion quite often lately. > While I understand DT guys concern to control which property should go > into the DT which ones should not, some system config are better > described next to the device they are attached to rather than in the > cmdline. > I think we are very much in agreement here. Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 20:04 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-20 20:04 UTC (permalink / raw) To: linux-arm-kernel On Fri, Feb 20, 2015 at 08:43:58PM +0100, Boris Brezillon wrote: > On Fri, 20 Feb 2015 08:28:55 -0800 > Guenter Roeck <linux@roeck-us.net> wrote: > > > On Fri, Feb 20, 2015 at 08:06:23AM -0600, Rob Herring wrote: > > > On Thu, Feb 19, 2015 at 12:14 AM, Timo Kokkonen > > > <timo.kokkonen@offcode.fi> wrote: > > > > Hi, > > > > > > [...] > > > > > What I am proposing here is a way to solve this without hacking. I was told > > > > to think also a way to defer starting the watchdog for a given timeout so > > > > that user space would have more time to wake up, which sounded like a good > > > > idea. And this obviously needs to be implemented so that the watchdog is > > > > guaranteed to reset the device should there be a crash of any kind that > > > > prevents the watchdog daemon from starting up. There are a lot of details > > > > that need to be taken care of properly and therefore watchdog core can't do > > > > much about it, which is why I thought there is no much point trying to do it > > > > in watchdog core. > > > > > > Deferring would assume that the watchdog is not already enabled. > > > > > > Putting in how long the kernel should service the watchdog in DT is > > > like putting soft or hard lockup detection times into DT. These are > > > kernel settings. If you need to change this, you should update your > > > kernel or kernel settings, not the DT. > > > > > The time to userspace handover may differ from HW variant to HW variant. > > Some may load faster, some may load slower. > > > > Similar, the runtime watchdog timeout may be different from system > > to system. On a system with faster CPU, and/or one with faster io, > > one may want (or need) a faster watchdog timeout. I assumed that > > was accepted and understood when the timeout-sec property was > > introduced a long time ago, but maybe not. > > > > Yes, the problem should be resolved in a generic way. This has been > > on my mind for a long time, including the problem if a watchdog should > > or should not stay or become enabled during early boot. All those are > > system properties which should be addressed generically, and there > > should be a means to express those properties in devicetree. > > > > Problem goes back into the old back-and-forth of what can be in devicetree > > or not. Sorting that out always takes a long time and a substantial amount > > of effort. Unfortunately, I don't have that time (writing the code would > > probably be trivial in comparison). > > I once promised myself to propose this stupid idea, so here it is: > How about creating a new concept called CT (for Config Tree), that > would reuse the DT syntax and tree representation and add system config > information to the appropriate devices (something like an overlay > you'll put on top of your DT). > We actually use that approach at work - essentially a system configuration using dt syntax. It even uses the dt compiler to create dtb files, only the dtb files are kept as part of the application software. Problem here though is that we are not talking about configuration, but about system properties. Secondary problem is that those system properties can be abused, and "it can be abused, let's reject it" is always easy. This is made more complicated by the fact that very few people are willing or even able to go through the exercise of clearly distinguishing system configuration vs. system properties when proposing new dt properties, especially since this can be a very tricky slope and may require 90% communication skills and 10% engineering skills (use the term 'configuration' once and you are out). Not really sure how to solve that problem, or if it is even possible to solve it. > Joke apart, I've had the same kind of discussion quite often lately. > While I understand DT guys concern to control which property should go > into the DT which ones should not, some system config are better > described next to the device they are attached to rather than in the > cmdline. > I think we are very much in agreement here. Thanks, Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-18 12:57 ` Timo Kokkonen @ 2015-02-20 7:48 ` Jean-Christophe PLAGNIOL-VILLARD -1 siblings, 0 replies; 110+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-02-20 7:48 UTC (permalink / raw) To: Timo Kokkonen Cc: Jean-Christophe PLAGNIOL-VILLARD, boris.brezillon, linux-arm-kernel, linux-watchdog, Nicolas FERRE, alexandre.belloni > On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "early-timeout-sec" which will let the kernel timer to ping the > watchdog HW only as long as the specified timeout permits. The default > is still to use kernel timer, but more strict behavior can be enabled > via the device tree property. > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > --- > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- This should not be handled by the driver but the kernel in a generic way Best Regards, J. > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt > index 7e3686c..32647cf 100644 > --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt > +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt > @@ -4,9 +4,16 @@ using these definitions. > > Optional properties: > - timeout-sec: Contains the watchdog timeout in seconds. > +- early-timeout-sec: If present, specifies a timeout value in seconds > + that the driver keeps on ticking the watchdog HW on behalf of user > + space. Once this timeout expires watchdog is left to expire in > + timeout-sec seconds. If this propery is set to zero, watchdog is > + started (or left running) so that a reset occurs in timeout-sec > + since the watchdog was started. > > Example: > > watchdog { > timeout-sec = <60>; > + early-timeout-sec = <120>; > }; > diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c > index 6df9405..1b40bfa 100644 > --- a/drivers/watchdog/at91sam9_wdt.c > +++ b/drivers/watchdog/at91sam9_wdt.c > @@ -89,6 +89,8 @@ struct at91wdt { > u32 mr_mask; > unsigned long heartbeat; /* WDT heartbeat in jiffies */ > bool nowayout; > + /* Timeout in jiffies for stopping the early timer */ > + unsigned long early_timer; > unsigned int irq; > }; > > @@ -122,7 +124,8 @@ static void at91_ping(unsigned long data) > { > struct at91wdt *wdt = (struct at91wdt *)data; > if (time_before(jiffies, wdt->next_heartbeat) || > - !watchdog_active(&wdt->wdd)) { > + (time_before(jiffies, wdt->early_timer) && > + !watchdog_active(&wdt->wdd))) { > at91_wdt_reset(wdt); > mod_timer(&wdt->timer, jiffies + wdt->heartbeat); > } else { > @@ -316,6 +319,10 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) > > wdt->mr |= max | ((max - min) << 16); > > + if (!of_property_read_u32_index(np, "early-timeout-sec", 0, > + (u32 *)&wdt->early_timer)) > + wdt->early_timer = wdt->early_timer * HZ + jiffies; > + > return 0; > } > #else > -- > 2.1.0 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 7:48 ` Jean-Christophe PLAGNIOL-VILLARD 0 siblings, 0 replies; 110+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-02-20 7:48 UTC (permalink / raw) To: linux-arm-kernel > On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > By default the driver will start a kernel timer which keeps on kicking > the watchdog HW until user space has opened the watchdog > device. Usually this is desirable as the watchdog HW is running by > default and the user space may not have any watchdog daemon running at > all. > > However, on production systems it may be mandatory that also early > crashes and lockups will lead to a watchdog reset, even if they happen > before the user space has opened the watchdog device. > > To resolve the issue, add a new device tree property > "early-timeout-sec" which will let the kernel timer to ping the > watchdog HW only as long as the specified timeout permits. The default > is still to use kernel timer, but more strict behavior can be enabled > via the device tree property. > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > --- > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- This should not be handled by the driver but the kernel in a generic way Best Regards, J. > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt > index 7e3686c..32647cf 100644 > --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt > +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt > @@ -4,9 +4,16 @@ using these definitions. > > Optional properties: > - timeout-sec: Contains the watchdog timeout in seconds. > +- early-timeout-sec: If present, specifies a timeout value in seconds > + that the driver keeps on ticking the watchdog HW on behalf of user > + space. Once this timeout expires watchdog is left to expire in > + timeout-sec seconds. If this propery is set to zero, watchdog is > + started (or left running) so that a reset occurs in timeout-sec > + since the watchdog was started. > > Example: > > watchdog { > timeout-sec = <60>; > + early-timeout-sec = <120>; > }; > diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c > index 6df9405..1b40bfa 100644 > --- a/drivers/watchdog/at91sam9_wdt.c > +++ b/drivers/watchdog/at91sam9_wdt.c > @@ -89,6 +89,8 @@ struct at91wdt { > u32 mr_mask; > unsigned long heartbeat; /* WDT heartbeat in jiffies */ > bool nowayout; > + /* Timeout in jiffies for stopping the early timer */ > + unsigned long early_timer; > unsigned int irq; > }; > > @@ -122,7 +124,8 @@ static void at91_ping(unsigned long data) > { > struct at91wdt *wdt = (struct at91wdt *)data; > if (time_before(jiffies, wdt->next_heartbeat) || > - !watchdog_active(&wdt->wdd)) { > + (time_before(jiffies, wdt->early_timer) && > + !watchdog_active(&wdt->wdd))) { > at91_wdt_reset(wdt); > mod_timer(&wdt->timer, jiffies + wdt->heartbeat); > } else { > @@ -316,6 +319,10 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) > > wdt->mr |= max | ((max - min) << 16); > > + if (!of_property_read_u32_index(np, "early-timeout-sec", 0, > + (u32 *)&wdt->early_timer)) > + wdt->early_timer = wdt->early_timer * HZ + jiffies; > + > return 0; > } > #else > -- > 2.1.0 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-20 7:48 ` Jean-Christophe PLAGNIOL-VILLARD @ 2015-02-20 7:51 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-20 7:51 UTC (permalink / raw) To: Jean-Christophe PLAGNIOL-VILLARD Cc: Timo Kokkonen, linux-arm-kernel, linux-watchdog, Nicolas FERRE, alexandre.belloni Hi Jean-Christophe, On Fri, 20 Feb 2015 15:48:22 +0800 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > > > On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > > > By default the driver will start a kernel timer which keeps on kicking > > the watchdog HW until user space has opened the watchdog > > device. Usually this is desirable as the watchdog HW is running by > > default and the user space may not have any watchdog daemon running at > > all. > > > > However, on production systems it may be mandatory that also early > > crashes and lockups will lead to a watchdog reset, even if they happen > > before the user space has opened the watchdog device. > > > > To resolve the issue, add a new device tree property > > "early-timeout-sec" which will let the kernel timer to ping the > > watchdog HW only as long as the specified timeout permits. The default > > is still to use kernel timer, but more strict behavior can be enabled > > via the device tree property. > > > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > > --- > > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > > This should not be handled by the driver but the kernel in a generic way Could you detail a bit more what you have in mind ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 7:51 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-20 7:51 UTC (permalink / raw) To: linux-arm-kernel Hi Jean-Christophe, On Fri, 20 Feb 2015 15:48:22 +0800 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > > > On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > > > By default the driver will start a kernel timer which keeps on kicking > > the watchdog HW until user space has opened the watchdog > > device. Usually this is desirable as the watchdog HW is running by > > default and the user space may not have any watchdog daemon running at > > all. > > > > However, on production systems it may be mandatory that also early > > crashes and lockups will lead to a watchdog reset, even if they happen > > before the user space has opened the watchdog device. > > > > To resolve the issue, add a new device tree property > > "early-timeout-sec" which will let the kernel timer to ping the > > watchdog HW only as long as the specified timeout permits. The default > > is still to use kernel timer, but more strict behavior can be enabled > > via the device tree property. > > > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > > --- > > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > > This should not be handled by the driver but the kernel in a generic way Could you detail a bit more what you have in mind ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-20 7:51 ` Boris Brezillon @ 2015-02-20 16:33 ` Jean-Christophe PLAGNIOL-VILLARD -1 siblings, 0 replies; 110+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-02-20 16:33 UTC (permalink / raw) To: Boris Brezillon Cc: Jean-Christophe PLAGNIOL-VILLARD, Nicolas FERRE, alexandre.belloni, Timo Kokkonen, linux-watchdog, linux-arm-kernel > On Feb 20, 2015, at 3:51 PM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > Hi Jean-Christophe, > > On Fri, 20 Feb 2015 15:48:22 +0800 > Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > >> >>> On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: >>> >>> By default the driver will start a kernel timer which keeps on kicking >>> the watchdog HW until user space has opened the watchdog >>> device. Usually this is desirable as the watchdog HW is running by >>> default and the user space may not have any watchdog daemon running at >>> all. >>> >>> However, on production systems it may be mandatory that also early >>> crashes and lockups will lead to a watchdog reset, even if they happen >>> before the user space has opened the watchdog device. >>> >>> To resolve the issue, add a new device tree property >>> "early-timeout-sec" which will let the kernel timer to ping the >>> watchdog HW only as long as the specified timeout permits. The default >>> is still to use kernel timer, but more strict behavior can be enabled >>> via the device tree property. >>> >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>> --- >>> Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ >>> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- >> >> This should not be handled by the driver but the kernel in a generic way > > Could you detail a bit more what you have in mind ? move this timeout on the linux thread that keep alive the watchdog not in the driver Best Regards, J. > > Best Regards, > > Boris > > -- > Boris Brezillon, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 16:33 ` Jean-Christophe PLAGNIOL-VILLARD 0 siblings, 0 replies; 110+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-02-20 16:33 UTC (permalink / raw) To: linux-arm-kernel > On Feb 20, 2015, at 3:51 PM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > Hi Jean-Christophe, > > On Fri, 20 Feb 2015 15:48:22 +0800 > Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > >> >>> On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: >>> >>> By default the driver will start a kernel timer which keeps on kicking >>> the watchdog HW until user space has opened the watchdog >>> device. Usually this is desirable as the watchdog HW is running by >>> default and the user space may not have any watchdog daemon running at >>> all. >>> >>> However, on production systems it may be mandatory that also early >>> crashes and lockups will lead to a watchdog reset, even if they happen >>> before the user space has opened the watchdog device. >>> >>> To resolve the issue, add a new device tree property >>> "early-timeout-sec" which will let the kernel timer to ping the >>> watchdog HW only as long as the specified timeout permits. The default >>> is still to use kernel timer, but more strict behavior can be enabled >>> via the device tree property. >>> >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >>> --- >>> Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ >>> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- >> >> This should not be handled by the driver but the kernel in a generic way > > Could you detail a bit more what you have in mind ? move this timeout on the linux thread that keep alive the watchdog not in the driver Best Regards, J. > > Best Regards, > > Boris > > -- > Boris Brezillon, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-20 16:33 ` Jean-Christophe PLAGNIOL-VILLARD @ 2015-02-20 17:16 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-20 17:16 UTC (permalink / raw) To: Jean-Christophe PLAGNIOL-VILLARD Cc: Nicolas FERRE, alexandre.belloni, Timo Kokkonen, linux-watchdog, linux-arm-kernel Hi Jean-Christophe, On Sat, 21 Feb 2015 00:33:17 +0800 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > > > On Feb 20, 2015, at 3:51 PM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > > Hi Jean-Christophe, > > > > On Fri, 20 Feb 2015 15:48:22 +0800 > > Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > > > >> > >>> On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >>> > >>> By default the driver will start a kernel timer which keeps on kicking > >>> the watchdog HW until user space has opened the watchdog > >>> device. Usually this is desirable as the watchdog HW is running by > >>> default and the user space may not have any watchdog daemon running at > >>> all. > >>> > >>> However, on production systems it may be mandatory that also early > >>> crashes and lockups will lead to a watchdog reset, even if they happen > >>> before the user space has opened the watchdog device. > >>> > >>> To resolve the issue, add a new device tree property > >>> "early-timeout-sec" which will let the kernel timer to ping the > >>> watchdog HW only as long as the specified timeout permits. The default > >>> is still to use kernel timer, but more strict behavior can be enabled > >>> via the device tree property. > >>> > >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > >>> --- > >>> Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > >>> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > >> > >> This should not be handled by the driver but the kernel in a generic way > > > > Could you detail a bit more what you have in mind ? > > move this timeout on the linux thread that keep alive the watchdog not in the driver AFAIK there's no such thing (if there is, could you point me to the source file where this thread is defined ?), and each driver are registering their own timer (if they need one). If you're suggesting to add such common logic to watchdog core, why don't you propose something ? Timo's need is quite generic, but nobody seemed to bother with that before. Moreover, using an at91 specific implementation does not prevent migrating to a more generic implementation when it's available. Actually, it's rather difficult to design a generic infrastructure until you have dealt with several devices requiring the same feature, and that's obviously not the case here. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 17:16 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-20 17:16 UTC (permalink / raw) To: linux-arm-kernel Hi Jean-Christophe, On Sat, 21 Feb 2015 00:33:17 +0800 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > > > On Feb 20, 2015, at 3:51 PM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > > Hi Jean-Christophe, > > > > On Fri, 20 Feb 2015 15:48:22 +0800 > > Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > > > >> > >>> On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >>> > >>> By default the driver will start a kernel timer which keeps on kicking > >>> the watchdog HW until user space has opened the watchdog > >>> device. Usually this is desirable as the watchdog HW is running by > >>> default and the user space may not have any watchdog daemon running at > >>> all. > >>> > >>> However, on production systems it may be mandatory that also early > >>> crashes and lockups will lead to a watchdog reset, even if they happen > >>> before the user space has opened the watchdog device. > >>> > >>> To resolve the issue, add a new device tree property > >>> "early-timeout-sec" which will let the kernel timer to ping the > >>> watchdog HW only as long as the specified timeout permits. The default > >>> is still to use kernel timer, but more strict behavior can be enabled > >>> via the device tree property. > >>> > >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > >>> --- > >>> Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > >>> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > >> > >> This should not be handled by the driver but the kernel in a generic way > > > > Could you detail a bit more what you have in mind ? > > move this timeout on the linux thread that keep alive the watchdog not in the driver AFAIK there's no such thing (if there is, could you point me to the source file where this thread is defined ?), and each driver are registering their own timer (if they need one). If you're suggesting to add such common logic to watchdog core, why don't you propose something ? Timo's need is quite generic, but nobody seemed to bother with that before. Moreover, using an at91 specific implementation does not prevent migrating to a more generic implementation when it's available. Actually, it's rather difficult to design a generic infrastructure until you have dealt with several devices requiring the same feature, and that's obviously not the case here. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-20 17:16 ` Boris Brezillon @ 2015-02-20 18:06 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-20 18:06 UTC (permalink / raw) To: Boris Brezillon Cc: Jean-Christophe PLAGNIOL-VILLARD, Nicolas FERRE, alexandre.belloni, Timo Kokkonen, linux-watchdog, linux-arm-kernel On Fri, Feb 20, 2015 at 06:16:40PM +0100, Boris Brezillon wrote: > Hi Jean-Christophe, > > On Sat, 21 Feb 2015 00:33:17 +0800 > Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > > > > > > On Feb 20, 2015, at 3:51 PM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > > > > Hi Jean-Christophe, > > > > > > On Fri, 20 Feb 2015 15:48:22 +0800 > > > Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > > > > > >> > > >>> On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > >>> > > >>> By default the driver will start a kernel timer which keeps on kicking > > >>> the watchdog HW until user space has opened the watchdog > > >>> device. Usually this is desirable as the watchdog HW is running by > > >>> default and the user space may not have any watchdog daemon running at > > >>> all. > > >>> > > >>> However, on production systems it may be mandatory that also early > > >>> crashes and lockups will lead to a watchdog reset, even if they happen > > >>> before the user space has opened the watchdog device. > > >>> > > >>> To resolve the issue, add a new device tree property > > >>> "early-timeout-sec" which will let the kernel timer to ping the > > >>> watchdog HW only as long as the specified timeout permits. The default > > >>> is still to use kernel timer, but more strict behavior can be enabled > > >>> via the device tree property. > > >>> > > >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > > >>> --- > > >>> Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > > >>> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > > >> > > >> This should not be handled by the driver but the kernel in a generic way > > > > > > Could you detail a bit more what you have in mind ? > > > > move this timeout on the linux thread that keep alive the watchdog not in the driver > > AFAIK there's no such thing (if there is, could you point me to the > source file where this thread is defined ?), and each driver are > registering their own timer (if they need one). > If you're suggesting to add such common logic to watchdog core, why > don't you propose something ? > > Timo's need is quite generic, but nobody seemed to bother with that > before. The problem has been discussed before. There are even some patches, but they were too specific and limited in scope for my liking. As I said in my other reply, to move forward we would need someone who has the time and energy to get an agreement with the DT folks about an acceptable means to express the properties needed for a specific hardware, and to actually implement the necessary code. > Moreover, using an at91 specific implementation does not prevent > migrating to a more generic implementation when it's available. > Actually, it's rather difficult to design a generic infrastructure until > you have dealt with several devices requiring the same feature, and > that's obviously not the case here. > Absolutely agree. If we can not even get a property like the one suggested here accepted, it is completely pointless to even think about a more generic solution that would work for all watchdog drivers. Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 18:06 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-20 18:06 UTC (permalink / raw) To: linux-arm-kernel On Fri, Feb 20, 2015 at 06:16:40PM +0100, Boris Brezillon wrote: > Hi Jean-Christophe, > > On Sat, 21 Feb 2015 00:33:17 +0800 > Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > > > > > > On Feb 20, 2015, at 3:51 PM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > > > > Hi Jean-Christophe, > > > > > > On Fri, 20 Feb 2015 15:48:22 +0800 > > > Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > > > > > >> > > >>> On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > >>> > > >>> By default the driver will start a kernel timer which keeps on kicking > > >>> the watchdog HW until user space has opened the watchdog > > >>> device. Usually this is desirable as the watchdog HW is running by > > >>> default and the user space may not have any watchdog daemon running at > > >>> all. > > >>> > > >>> However, on production systems it may be mandatory that also early > > >>> crashes and lockups will lead to a watchdog reset, even if they happen > > >>> before the user space has opened the watchdog device. > > >>> > > >>> To resolve the issue, add a new device tree property > > >>> "early-timeout-sec" which will let the kernel timer to ping the > > >>> watchdog HW only as long as the specified timeout permits. The default > > >>> is still to use kernel timer, but more strict behavior can be enabled > > >>> via the device tree property. > > >>> > > >>> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > > >>> --- > > >>> Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > > >>> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > > >> > > >> This should not be handled by the driver but the kernel in a generic way > > > > > > Could you detail a bit more what you have in mind ? > > > > move this timeout on the linux thread that keep alive the watchdog not in the driver > > AFAIK there's no such thing (if there is, could you point me to the > source file where this thread is defined ?), and each driver are > registering their own timer (if they need one). > If you're suggesting to add such common logic to watchdog core, why > don't you propose something ? > > Timo's need is quite generic, but nobody seemed to bother with that > before. The problem has been discussed before. There are even some patches, but they were too specific and limited in scope for my liking. As I said in my other reply, to move forward we would need someone who has the time and energy to get an agreement with the DT folks about an acceptable means to express the properties needed for a specific hardware, and to actually implement the necessary code. > Moreover, using an at91 specific implementation does not prevent > migrating to a more generic implementation when it's available. > Actually, it's rather difficult to design a generic infrastructure until > you have dealt with several devices requiring the same feature, and > that's obviously not the case here. > Absolutely agree. If we can not even get a property like the one suggested here accepted, it is completely pointless to even think about a more generic solution that would work for all watchdog drivers. Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-20 18:06 ` Guenter Roeck @ 2015-02-23 7:29 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-23 7:29 UTC (permalink / raw) To: Guenter Roeck, Boris Brezillon Cc: Jean-Christophe PLAGNIOL-VILLARD, Nicolas FERRE, alexandre.belloni, linux-watchdog, linux-arm-kernel Hi, On 20.02.2015 20:06, Guenter Roeck wrote: > On Fri, Feb 20, 2015 at 06:16:40PM +0100, Boris Brezillon wrote: >> Hi Jean-Christophe, >> >> On Sat, 21 Feb 2015 00:33:17 +0800 >> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: >> >> >> Timo's need is quite generic, but nobody seemed to bother with that >> before. > > The problem has been discussed before. There are even some patches, > but they were too specific and limited in scope for my liking. > > As I said in my other reply, to move forward we would need > someone who has the time and energy to get an agreement with the > DT folks about an acceptable means to express the properties needed > for a specific hardware, and to actually implement the necessary code. > >> Moreover, using an at91 specific implementation does not prevent >> migrating to a more generic implementation when it's available. >> Actually, it's rather difficult to design a generic infrastructure until >> you have dealt with several devices requiring the same feature, and >> that's obviously not the case here. >> > Absolutely agree. If we can not even get a property like the one suggested > here accepted, it is completely pointless to even think about a more > generic solution that would work for all watchdog drivers. > I'm not really sure that I understand what we are really arguing here, but seems that this is not getting any forward unless we get in touch with the DT people who get to decide whether this kind of property belongs to device tree or not. Who are these people anyway? Which list should I write an email to get in touch with them? Why are we not CC'ing them already? Anyway, the way I tried to express it in the v4 patch set, we have a generic device tree property that does not try to imply any sort of implementation or HW details. The description in watchdog.txt tries to state the purpose of the property clearly so that other driver writers could make other drivers to support it correctly. And then there is at91 specific implementation because that's the only watchdog hardware currently on my desk that I can easily test it with. I can't think of how I could make this more generic, not without making more changes to the way drivers initialize itself with the watchdog core. And that would require changing a lot of drivers, at least if we intend to make it work so that the watchdog core takes care of this instead of the driver. It's a nice idea but I think it's overly complex given the amount of functionality there needs to be in different drivers and the diversity between drivers. To me there is nothing wrong with having this done also via a kernel configuration option. We could simply have CONFIG_WATCHDOG_EARLY_TIMEOUT_SEC option that works exactly the same way as the proposed device tree property. To make it clear only some drivers support this option, we could let each driver select an enabler config option CONFIG_WATCHDOG_HAS_DEFERRABLE_EARLY_RESET or such that is used to hide the config option unless we are building a watchdog that supports the given option. Or something like that. But that would be less flexible, as if we want to run the same kernel binary on different arm boards we can't make these values per board any more. The use case I am dealing with doesn't care about this, but I was thinking someone else might care. Which is why I thought it should be run time configurable via device tree instead of a compile time option. But now that I have mentioned arm boards, I noticed we are talking about generic behaviour and there are also watchdogs running on architectures where device trees are not supported. That said, it might be better to make it compile time configurable now and add other configuration options later. Any thoughts about that? Thanks, -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-23 7:29 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-23 7:29 UTC (permalink / raw) To: linux-arm-kernel Hi, On 20.02.2015 20:06, Guenter Roeck wrote: > On Fri, Feb 20, 2015 at 06:16:40PM +0100, Boris Brezillon wrote: >> Hi Jean-Christophe, >> >> On Sat, 21 Feb 2015 00:33:17 +0800 >> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: >> >> >> Timo's need is quite generic, but nobody seemed to bother with that >> before. > > The problem has been discussed before. There are even some patches, > but they were too specific and limited in scope for my liking. > > As I said in my other reply, to move forward we would need > someone who has the time and energy to get an agreement with the > DT folks about an acceptable means to express the properties needed > for a specific hardware, and to actually implement the necessary code. > >> Moreover, using an at91 specific implementation does not prevent >> migrating to a more generic implementation when it's available. >> Actually, it's rather difficult to design a generic infrastructure until >> you have dealt with several devices requiring the same feature, and >> that's obviously not the case here. >> > Absolutely agree. If we can not even get a property like the one suggested > here accepted, it is completely pointless to even think about a more > generic solution that would work for all watchdog drivers. > I'm not really sure that I understand what we are really arguing here, but seems that this is not getting any forward unless we get in touch with the DT people who get to decide whether this kind of property belongs to device tree or not. Who are these people anyway? Which list should I write an email to get in touch with them? Why are we not CC'ing them already? Anyway, the way I tried to express it in the v4 patch set, we have a generic device tree property that does not try to imply any sort of implementation or HW details. The description in watchdog.txt tries to state the purpose of the property clearly so that other driver writers could make other drivers to support it correctly. And then there is at91 specific implementation because that's the only watchdog hardware currently on my desk that I can easily test it with. I can't think of how I could make this more generic, not without making more changes to the way drivers initialize itself with the watchdog core. And that would require changing a lot of drivers, at least if we intend to make it work so that the watchdog core takes care of this instead of the driver. It's a nice idea but I think it's overly complex given the amount of functionality there needs to be in different drivers and the diversity between drivers. To me there is nothing wrong with having this done also via a kernel configuration option. We could simply have CONFIG_WATCHDOG_EARLY_TIMEOUT_SEC option that works exactly the same way as the proposed device tree property. To make it clear only some drivers support this option, we could let each driver select an enabler config option CONFIG_WATCHDOG_HAS_DEFERRABLE_EARLY_RESET or such that is used to hide the config option unless we are building a watchdog that supports the given option. Or something like that. But that would be less flexible, as if we want to run the same kernel binary on different arm boards we can't make these values per board any more. The use case I am dealing with doesn't care about this, but I was thinking someone else might care. Which is why I thought it should be run time configurable via device tree instead of a compile time option. But now that I have mentioned arm boards, I noticed we are talking about generic behaviour and there are also watchdogs running on architectures where device trees are not supported. That said, it might be better to make it compile time configurable now and add other configuration options later. Any thoughts about that? Thanks, -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-23 7:29 ` Timo Kokkonen @ 2015-02-23 8:51 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-23 8:51 UTC (permalink / raw) To: Timo Kokkonen Cc: Guenter Roeck, Jean-Christophe PLAGNIOL-VILLARD, Nicolas FERRE, alexandre.belloni, linux-watchdog, linux-arm-kernel, Rob Herring Hi Timo, On Mon, 23 Feb 2015 09:29:41 +0200 Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > Hi, > > On 20.02.2015 20:06, Guenter Roeck wrote: > > On Fri, Feb 20, 2015 at 06:16:40PM +0100, Boris Brezillon wrote: > >> Hi Jean-Christophe, > >> > >> On Sat, 21 Feb 2015 00:33:17 +0800 > >> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > >> > >> > >> Timo's need is quite generic, but nobody seemed to bother with that > >> before. > > > > The problem has been discussed before. There are even some patches, > > but they were too specific and limited in scope for my liking. > > > > As I said in my other reply, to move forward we would need > > someone who has the time and energy to get an agreement with the > > DT folks about an acceptable means to express the properties needed > > for a specific hardware, and to actually implement the necessary code. > > > >> Moreover, using an at91 specific implementation does not prevent > >> migrating to a more generic implementation when it's available. > >> Actually, it's rather difficult to design a generic infrastructure until > >> you have dealt with several devices requiring the same feature, and > >> that's obviously not the case here. > >> > > Absolutely agree. If we can not even get a property like the one suggested > > here accepted, it is completely pointless to even think about a more > > generic solution that would work for all watchdog drivers. > > > > I'm not really sure that I understand what we are really arguing here, > but seems that this is not getting any forward unless we get in touch > with the DT people who get to decide whether this kind of property > belongs to device tree or not. Who are these people anyway? Which list > should I write an email to get in touch with them? Why are we not CC'ing > them already? I thought they were in the recipient list, but they are not. If you want to be sure to include all the relevant maintainers and MLs you can use scripts/get_maintainer.pl, this would have given you the DT maintainers and DT ML. BTW, the discussion has already started (Rob is a DT maintainer) ;-). > > Anyway, the way I tried to express it in the v4 patch set, we have a > generic device tree property that does not try to imply any sort of > implementation or HW details. The description in watchdog.txt tries to > state the purpose of the property clearly so that other driver writers > could make other drivers to support it correctly. And then there is at91 > specific implementation because that's the only watchdog hardware > currently on my desk that I can easily test it with. The debate here is not whether the property is generic enough or not, but whether it is hardware or software related. DTs are supposed to describe HW and not the use you make of it (HW configuration), the problem is: sometime you have to describe that to get your hardware to work properly. > > I can't think of how I could make this more generic, not without making > more changes to the way drivers initialize itself with the watchdog > core. And that would require changing a lot of drivers, at least if we > intend to make it work so that the watchdog core takes care of this > instead of the driver. It's a nice idea but I think it's overly complex > given the amount of functionality there needs to be in different drivers > and the diversity between drivers. > > To me there is nothing wrong with having this done also via a kernel > configuration option. We could simply have > CONFIG_WATCHDOG_EARLY_TIMEOUT_SEC option that works exactly the same way > as the proposed device tree property. To make it clear only some drivers > support this option, we could let each driver select an enabler config > option CONFIG_WATCHDOG_HAS_DEFERRABLE_EARLY_RESET or such that is used > to hide the config option unless we are building a watchdog that > supports the given option. Or something like that. But that would be > less flexible, as if we want to run the same kernel binary on different > arm boards we can't make these values per board any more. The use case I > am dealing with doesn't care about this, but I was thinking someone else > might care. Which is why I thought it should be run time configurable > via device tree instead of a compile time option. IMHO, a viable alternative to the early-timeout-sec property would be a module parameter passed through the kernel cmdline. But as I said, attaching such parameters to the appropriate watchdog device (say you have several watchdogs in your system) is not as easy as using the DT representation. Is early-timeout-sec generic enough to be global to the watchdog framework ? > > But now that I have mentioned arm boards, I noticed we are talking about > generic behaviour and there are also watchdogs running on architectures > where device trees are not supported. That said, it might be better to > make it compile time configurable now and add other configuration > options later. As long as the early_timeout_sec is part of the generic watchdog struct, your driver shouldn't care where the value comes from (pdata, DT, ACPI, ...), this is why making DT parsing code part of the core is a better approach IMO. > > Any thoughts about that? As I said, the Kconfig option does not seem the right approach to me, using a module parameter would be more appropriate IMO. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-23 8:51 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-23 8:51 UTC (permalink / raw) To: linux-arm-kernel Hi Timo, On Mon, 23 Feb 2015 09:29:41 +0200 Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > Hi, > > On 20.02.2015 20:06, Guenter Roeck wrote: > > On Fri, Feb 20, 2015 at 06:16:40PM +0100, Boris Brezillon wrote: > >> Hi Jean-Christophe, > >> > >> On Sat, 21 Feb 2015 00:33:17 +0800 > >> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: > >> > >> > >> Timo's need is quite generic, but nobody seemed to bother with that > >> before. > > > > The problem has been discussed before. There are even some patches, > > but they were too specific and limited in scope for my liking. > > > > As I said in my other reply, to move forward we would need > > someone who has the time and energy to get an agreement with the > > DT folks about an acceptable means to express the properties needed > > for a specific hardware, and to actually implement the necessary code. > > > >> Moreover, using an at91 specific implementation does not prevent > >> migrating to a more generic implementation when it's available. > >> Actually, it's rather difficult to design a generic infrastructure until > >> you have dealt with several devices requiring the same feature, and > >> that's obviously not the case here. > >> > > Absolutely agree. If we can not even get a property like the one suggested > > here accepted, it is completely pointless to even think about a more > > generic solution that would work for all watchdog drivers. > > > > I'm not really sure that I understand what we are really arguing here, > but seems that this is not getting any forward unless we get in touch > with the DT people who get to decide whether this kind of property > belongs to device tree or not. Who are these people anyway? Which list > should I write an email to get in touch with them? Why are we not CC'ing > them already? I thought they were in the recipient list, but they are not. If you want to be sure to include all the relevant maintainers and MLs you can use scripts/get_maintainer.pl, this would have given you the DT maintainers and DT ML. BTW, the discussion has already started (Rob is a DT maintainer) ;-). > > Anyway, the way I tried to express it in the v4 patch set, we have a > generic device tree property that does not try to imply any sort of > implementation or HW details. The description in watchdog.txt tries to > state the purpose of the property clearly so that other driver writers > could make other drivers to support it correctly. And then there is at91 > specific implementation because that's the only watchdog hardware > currently on my desk that I can easily test it with. The debate here is not whether the property is generic enough or not, but whether it is hardware or software related. DTs are supposed to describe HW and not the use you make of it (HW configuration), the problem is: sometime you have to describe that to get your hardware to work properly. > > I can't think of how I could make this more generic, not without making > more changes to the way drivers initialize itself with the watchdog > core. And that would require changing a lot of drivers, at least if we > intend to make it work so that the watchdog core takes care of this > instead of the driver. It's a nice idea but I think it's overly complex > given the amount of functionality there needs to be in different drivers > and the diversity between drivers. > > To me there is nothing wrong with having this done also via a kernel > configuration option. We could simply have > CONFIG_WATCHDOG_EARLY_TIMEOUT_SEC option that works exactly the same way > as the proposed device tree property. To make it clear only some drivers > support this option, we could let each driver select an enabler config > option CONFIG_WATCHDOG_HAS_DEFERRABLE_EARLY_RESET or such that is used > to hide the config option unless we are building a watchdog that > supports the given option. Or something like that. But that would be > less flexible, as if we want to run the same kernel binary on different > arm boards we can't make these values per board any more. The use case I > am dealing with doesn't care about this, but I was thinking someone else > might care. Which is why I thought it should be run time configurable > via device tree instead of a compile time option. IMHO, a viable alternative to the early-timeout-sec property would be a module parameter passed through the kernel cmdline. But as I said, attaching such parameters to the appropriate watchdog device (say you have several watchdogs in your system) is not as easy as using the DT representation. Is early-timeout-sec generic enough to be global to the watchdog framework ? > > But now that I have mentioned arm boards, I noticed we are talking about > generic behaviour and there are also watchdogs running on architectures > where device trees are not supported. That said, it might be better to > make it compile time configurable now and add other configuration > options later. As long as the early_timeout_sec is part of the generic watchdog struct, your driver shouldn't care where the value comes from (pdata, DT, ACPI, ...), this is why making DT parsing code part of the core is a better approach IMO. > > Any thoughts about that? As I said, the Kconfig option does not seem the right approach to me, using a module parameter would be more appropriate IMO. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-23 8:51 ` Boris Brezillon @ 2015-02-23 9:11 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-23 9:11 UTC (permalink / raw) To: Boris Brezillon Cc: Guenter Roeck, Jean-Christophe PLAGNIOL-VILLARD, Nicolas FERRE, alexandre.belloni, linux-watchdog, linux-arm-kernel, Rob Herring On 23.02.2015 10:51, Boris Brezillon wrote: > Hi Timo, > > On Mon, 23 Feb 2015 09:29:41 +0200 > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >> Hi, >> >> On 20.02.2015 20:06, Guenter Roeck wrote: >>> On Fri, Feb 20, 2015 at 06:16:40PM +0100, Boris Brezillon wrote: >>>> Hi Jean-Christophe, >>>> >>>> On Sat, 21 Feb 2015 00:33:17 +0800 >>>> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: >>>> >>>> >>>> Timo's need is quite generic, but nobody seemed to bother with that >>>> before. >>> >>> The problem has been discussed before. There are even some patches, >>> but they were too specific and limited in scope for my liking. >>> >>> As I said in my other reply, to move forward we would need >>> someone who has the time and energy to get an agreement with the >>> DT folks about an acceptable means to express the properties needed >>> for a specific hardware, and to actually implement the necessary code. >>> >>>> Moreover, using an at91 specific implementation does not prevent >>>> migrating to a more generic implementation when it's available. >>>> Actually, it's rather difficult to design a generic infrastructure until >>>> you have dealt with several devices requiring the same feature, and >>>> that's obviously not the case here. >>>> >>> Absolutely agree. If we can not even get a property like the one suggested >>> here accepted, it is completely pointless to even think about a more >>> generic solution that would work for all watchdog drivers. >>> >> >> I'm not really sure that I understand what we are really arguing here, >> but seems that this is not getting any forward unless we get in touch >> with the DT people who get to decide whether this kind of property >> belongs to device tree or not. Who are these people anyway? Which list >> should I write an email to get in touch with them? Why are we not CC'ing >> them already? > > I thought they were in the recipient list, but they are not. > If you want to be sure to include all the relevant maintainers and MLs > you can use scripts/get_maintainer.pl, this would have given you the DT > maintainers and DT ML. > > BTW, the discussion has already started (Rob is a DT maintainer) ;-). > Right, indeed. Good. :) >> >> Anyway, the way I tried to express it in the v4 patch set, we have a >> generic device tree property that does not try to imply any sort of >> implementation or HW details. The description in watchdog.txt tries to >> state the purpose of the property clearly so that other driver writers >> could make other drivers to support it correctly. And then there is at91 >> specific implementation because that's the only watchdog hardware >> currently on my desk that I can easily test it with. > > The debate here is not whether the property is generic enough or not, > but whether it is hardware or software related. > DTs are supposed to describe HW and not the use you make of it (HW > configuration), the problem is: sometime you have to describe that to > get your hardware to work properly. > >> >> I can't think of how I could make this more generic, not without making >> more changes to the way drivers initialize itself with the watchdog >> core. And that would require changing a lot of drivers, at least if we >> intend to make it work so that the watchdog core takes care of this >> instead of the driver. It's a nice idea but I think it's overly complex >> given the amount of functionality there needs to be in different drivers >> and the diversity between drivers. >> >> To me there is nothing wrong with having this done also via a kernel >> configuration option. We could simply have >> CONFIG_WATCHDOG_EARLY_TIMEOUT_SEC option that works exactly the same way >> as the proposed device tree property. To make it clear only some drivers >> support this option, we could let each driver select an enabler config >> option CONFIG_WATCHDOG_HAS_DEFERRABLE_EARLY_RESET or such that is used >> to hide the config option unless we are building a watchdog that >> supports the given option. Or something like that. But that would be >> less flexible, as if we want to run the same kernel binary on different >> arm boards we can't make these values per board any more. The use case I >> am dealing with doesn't care about this, but I was thinking someone else >> might care. Which is why I thought it should be run time configurable >> via device tree instead of a compile time option. > > IMHO, a viable alternative to the early-timeout-sec property would be a > module parameter passed through the kernel cmdline. > But as I said, attaching such parameters to the appropriate watchdog > device (say you have several watchdogs in your system) is not as easy as > using the DT representation. > > Is early-timeout-sec generic enough to be global to the watchdog > framework ? > If we have multiple watchdogs running, each of the watchdog might have different meaning, so it may not be enough to have one global watchdog property that is global to all watchdogs. We'd need someone to comment who has multiple watchdogs.. >> >> But now that I have mentioned arm boards, I noticed we are talking about >> generic behaviour and there are also watchdogs running on architectures >> where device trees are not supported. That said, it might be better to >> make it compile time configurable now and add other configuration >> options later. > > As long as the early_timeout_sec is part of the generic watchdog > struct, your driver shouldn't care where the value comes from (pdata, > DT, ACPI, ...), this is why making DT parsing code part of the core is > a better approach IMO. > >> >> Any thoughts about that? > > As I said, the Kconfig option does not seem the right approach to > me, using a module parameter would be more appropriate IMO. > After all, we do have already watchdog_init_timeout function that parses the watchdog timeout argument from either device tree or from command line. How about if we expanded that interface? Maybe have a more generic watchdog_init_parmas() or something that parses the generic watchdog arguments, either from command line, device tree or ACPI or something. The device driver could replace call from watchdog_init_timeout() to watchdog_init_params() once it is ready to support other generic parameters, such as early-timeout-sec. Then the watchdog driver could do the right thing about whether watchdog should be left running or stopped and how long time should be given. Alternatively, we could also let the watchdog core know a little more about the actual watchdog hardware, such as whether the HW is stoppable, whether it needs manual pinging by the kernel until user space has taken over. Or maybe we can just extend the timeout values until the user space has first opened it and then shorten the timeout automatically so that it doesn't take that long for the device to reset after a crash. Or some other behaviour that is common to many users. Suggestions are welcome. Anyway, that is something that needs to be done to make watchdog core take more control over more of the generic watchdog behaviour. It just needs to be done so that we don't need to convert all drivers at once. Thanks, -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-23 9:11 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-23 9:11 UTC (permalink / raw) To: linux-arm-kernel On 23.02.2015 10:51, Boris Brezillon wrote: > Hi Timo, > > On Mon, 23 Feb 2015 09:29:41 +0200 > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >> Hi, >> >> On 20.02.2015 20:06, Guenter Roeck wrote: >>> On Fri, Feb 20, 2015 at 06:16:40PM +0100, Boris Brezillon wrote: >>>> Hi Jean-Christophe, >>>> >>>> On Sat, 21 Feb 2015 00:33:17 +0800 >>>> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote: >>>> >>>> >>>> Timo's need is quite generic, but nobody seemed to bother with that >>>> before. >>> >>> The problem has been discussed before. There are even some patches, >>> but they were too specific and limited in scope for my liking. >>> >>> As I said in my other reply, to move forward we would need >>> someone who has the time and energy to get an agreement with the >>> DT folks about an acceptable means to express the properties needed >>> for a specific hardware, and to actually implement the necessary code. >>> >>>> Moreover, using an at91 specific implementation does not prevent >>>> migrating to a more generic implementation when it's available. >>>> Actually, it's rather difficult to design a generic infrastructure until >>>> you have dealt with several devices requiring the same feature, and >>>> that's obviously not the case here. >>>> >>> Absolutely agree. If we can not even get a property like the one suggested >>> here accepted, it is completely pointless to even think about a more >>> generic solution that would work for all watchdog drivers. >>> >> >> I'm not really sure that I understand what we are really arguing here, >> but seems that this is not getting any forward unless we get in touch >> with the DT people who get to decide whether this kind of property >> belongs to device tree or not. Who are these people anyway? Which list >> should I write an email to get in touch with them? Why are we not CC'ing >> them already? > > I thought they were in the recipient list, but they are not. > If you want to be sure to include all the relevant maintainers and MLs > you can use scripts/get_maintainer.pl, this would have given you the DT > maintainers and DT ML. > > BTW, the discussion has already started (Rob is a DT maintainer) ;-). > Right, indeed. Good. :) >> >> Anyway, the way I tried to express it in the v4 patch set, we have a >> generic device tree property that does not try to imply any sort of >> implementation or HW details. The description in watchdog.txt tries to >> state the purpose of the property clearly so that other driver writers >> could make other drivers to support it correctly. And then there is at91 >> specific implementation because that's the only watchdog hardware >> currently on my desk that I can easily test it with. > > The debate here is not whether the property is generic enough or not, > but whether it is hardware or software related. > DTs are supposed to describe HW and not the use you make of it (HW > configuration), the problem is: sometime you have to describe that to > get your hardware to work properly. > >> >> I can't think of how I could make this more generic, not without making >> more changes to the way drivers initialize itself with the watchdog >> core. And that would require changing a lot of drivers, at least if we >> intend to make it work so that the watchdog core takes care of this >> instead of the driver. It's a nice idea but I think it's overly complex >> given the amount of functionality there needs to be in different drivers >> and the diversity between drivers. >> >> To me there is nothing wrong with having this done also via a kernel >> configuration option. We could simply have >> CONFIG_WATCHDOG_EARLY_TIMEOUT_SEC option that works exactly the same way >> as the proposed device tree property. To make it clear only some drivers >> support this option, we could let each driver select an enabler config >> option CONFIG_WATCHDOG_HAS_DEFERRABLE_EARLY_RESET or such that is used >> to hide the config option unless we are building a watchdog that >> supports the given option. Or something like that. But that would be >> less flexible, as if we want to run the same kernel binary on different >> arm boards we can't make these values per board any more. The use case I >> am dealing with doesn't care about this, but I was thinking someone else >> might care. Which is why I thought it should be run time configurable >> via device tree instead of a compile time option. > > IMHO, a viable alternative to the early-timeout-sec property would be a > module parameter passed through the kernel cmdline. > But as I said, attaching such parameters to the appropriate watchdog > device (say you have several watchdogs in your system) is not as easy as > using the DT representation. > > Is early-timeout-sec generic enough to be global to the watchdog > framework ? > If we have multiple watchdogs running, each of the watchdog might have different meaning, so it may not be enough to have one global watchdog property that is global to all watchdogs. We'd need someone to comment who has multiple watchdogs.. >> >> But now that I have mentioned arm boards, I noticed we are talking about >> generic behaviour and there are also watchdogs running on architectures >> where device trees are not supported. That said, it might be better to >> make it compile time configurable now and add other configuration >> options later. > > As long as the early_timeout_sec is part of the generic watchdog > struct, your driver shouldn't care where the value comes from (pdata, > DT, ACPI, ...), this is why making DT parsing code part of the core is > a better approach IMO. > >> >> Any thoughts about that? > > As I said, the Kconfig option does not seem the right approach to > me, using a module parameter would be more appropriate IMO. > After all, we do have already watchdog_init_timeout function that parses the watchdog timeout argument from either device tree or from command line. How about if we expanded that interface? Maybe have a more generic watchdog_init_parmas() or something that parses the generic watchdog arguments, either from command line, device tree or ACPI or something. The device driver could replace call from watchdog_init_timeout() to watchdog_init_params() once it is ready to support other generic parameters, such as early-timeout-sec. Then the watchdog driver could do the right thing about whether watchdog should be left running or stopped and how long time should be given. Alternatively, we could also let the watchdog core know a little more about the actual watchdog hardware, such as whether the HW is stoppable, whether it needs manual pinging by the kernel until user space has taken over. Or maybe we can just extend the timeout values until the user space has first opened it and then shorten the timeout automatically so that it doesn't take that long for the device to reset after a crash. Or some other behaviour that is common to many users. Suggestions are welcome. Anyway, that is something that needs to be done to make watchdog core take more control over more of the generic watchdog behaviour. It just needs to be done so that we don't need to convert all drivers at once. Thanks, -Timo ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-23 9:11 ` Timo Kokkonen @ 2015-02-23 16:19 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-23 16:19 UTC (permalink / raw) To: Timo Kokkonen Cc: Boris Brezillon, Jean-Christophe PLAGNIOL-VILLARD, Nicolas FERRE, alexandre.belloni, linux-watchdog, linux-arm-kernel, Rob Herring On Mon, Feb 23, 2015 at 11:11:38AM +0200, Timo Kokkonen wrote: [ ... ] > > After all, we do have already watchdog_init_timeout function that parses the > watchdog timeout argument from either device tree or from command line. How > about if we expanded that interface? Maybe have a more generic > watchdog_init_parmas() or something that parses the generic watchdog > arguments, either from command line, device tree or ACPI or something. The > device driver could replace call from watchdog_init_timeout() to > watchdog_init_params() once it is ready to support other generic parameters, > such as early-timeout-sec. Then the watchdog driver could do the right thing > about whether watchdog should be left running or stopped and how long time > should be given. > Good idea. > Alternatively, we could also let the watchdog core know a little more about > the actual watchdog hardware, such as whether the HW is stoppable, whether > it needs manual pinging by the kernel until user space has taken over. Or Yes, all that will be needed. But, still, the stop-gap is that we'll need to get buyin from the DT folks for the necessary properties. I have had the outline for the necessary watchdog core implementation in my mind for a long time, but I just don't have the time (nor the patience, quite frankly) to get DT buyin. > maybe we can just extend the timeout values until the user space has first > opened it and then shorten the timeout automatically so that it doesn't take > that long for the device to reset after a crash. Or some other behaviour > that is common to many users. Suggestions are welcome. > > Anyway, that is something that needs to be done to make watchdog core take > more control over more of the generic watchdog behaviour. It just needs to > be done so that we don't need to convert all drivers at once. > Correct. It should not be that difficult do do that if designed properly. Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-23 16:19 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-23 16:19 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 23, 2015 at 11:11:38AM +0200, Timo Kokkonen wrote: [ ... ] > > After all, we do have already watchdog_init_timeout function that parses the > watchdog timeout argument from either device tree or from command line. How > about if we expanded that interface? Maybe have a more generic > watchdog_init_parmas() or something that parses the generic watchdog > arguments, either from command line, device tree or ACPI or something. The > device driver could replace call from watchdog_init_timeout() to > watchdog_init_params() once it is ready to support other generic parameters, > such as early-timeout-sec. Then the watchdog driver could do the right thing > about whether watchdog should be left running or stopped and how long time > should be given. > Good idea. > Alternatively, we could also let the watchdog core know a little more about > the actual watchdog hardware, such as whether the HW is stoppable, whether > it needs manual pinging by the kernel until user space has taken over. Or Yes, all that will be needed. But, still, the stop-gap is that we'll need to get buyin from the DT folks for the necessary properties. I have had the outline for the necessary watchdog core implementation in my mind for a long time, but I just don't have the time (nor the patience, quite frankly) to get DT buyin. > maybe we can just extend the timeout values until the user space has first > opened it and then shorten the timeout automatically so that it doesn't take > that long for the device to reset after a crash. Or some other behaviour > that is common to many users. Suggestions are welcome. > > Anyway, that is something that needs to be done to make watchdog core take > more control over more of the generic watchdog behaviour. It just needs to > be done so that we don't need to convert all drivers at once. > Correct. It should not be that difficult do do that if designed properly. Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-23 16:19 ` Guenter Roeck @ 2015-02-23 17:10 ` Rob Herring -1 siblings, 0 replies; 110+ messages in thread From: Rob Herring @ 2015-02-23 17:10 UTC (permalink / raw) To: Guenter Roeck Cc: Timo Kokkonen, Boris Brezillon, Jean-Christophe PLAGNIOL-VILLARD, Nicolas FERRE, Alexandre Belloni, linux-watchdog, linux-arm-kernel On Mon, Feb 23, 2015 at 10:19 AM, Guenter Roeck <linux@roeck-us.net> wrote: > On Mon, Feb 23, 2015 at 11:11:38AM +0200, Timo Kokkonen wrote: > [ ... ] > >> >> After all, we do have already watchdog_init_timeout function that parses the >> watchdog timeout argument from either device tree or from command line. How >> about if we expanded that interface? Maybe have a more generic >> watchdog_init_parmas() or something that parses the generic watchdog >> arguments, either from command line, device tree or ACPI or something. The >> device driver could replace call from watchdog_init_timeout() to >> watchdog_init_params() once it is ready to support other generic parameters, >> such as early-timeout-sec. Then the watchdog driver could do the right thing >> about whether watchdog should be left running or stopped and how long time >> should be given. >> > Good idea. > >> Alternatively, we could also let the watchdog core know a little more about >> the actual watchdog hardware, such as whether the HW is stoppable, whether >> it needs manual pinging by the kernel until user space has taken over. Or Whether the h/w is stoppable or not is certainly a reasonable DT property. The maximum h/w timeout would be too (although that may just be a property of counter size and clock rate). > Yes, all that will be needed. But, still, the stop-gap is that we'll need to > get buyin from the DT folks for the necessary properties. I have had the > outline for the necessary watchdog core implementation in my mind for a long > time, but I just don't have the time (nor the patience, quite frankly) > to get DT buyin. Defining wdog core functionality and behavior has little to do with DT and you don't need buy in. Presumably you care about non-DT platforms as well. Moving more of the intelligence to the core would be a good thing and for the most part should be independent of DT. Rob >> maybe we can just extend the timeout values until the user space has first >> opened it and then shorten the timeout automatically so that it doesn't take >> that long for the device to reset after a crash. Or some other behaviour >> that is common to many users. Suggestions are welcome. >> >> Anyway, that is something that needs to be done to make watchdog core take >> more control over more of the generic watchdog behaviour. It just needs to >> be done so that we don't need to convert all drivers at once. >> > Correct. It should not be that difficult do do that if designed properly. > > Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-23 17:10 ` Rob Herring 0 siblings, 0 replies; 110+ messages in thread From: Rob Herring @ 2015-02-23 17:10 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 23, 2015 at 10:19 AM, Guenter Roeck <linux@roeck-us.net> wrote: > On Mon, Feb 23, 2015 at 11:11:38AM +0200, Timo Kokkonen wrote: > [ ... ] > >> >> After all, we do have already watchdog_init_timeout function that parses the >> watchdog timeout argument from either device tree or from command line. How >> about if we expanded that interface? Maybe have a more generic >> watchdog_init_parmas() or something that parses the generic watchdog >> arguments, either from command line, device tree or ACPI or something. The >> device driver could replace call from watchdog_init_timeout() to >> watchdog_init_params() once it is ready to support other generic parameters, >> such as early-timeout-sec. Then the watchdog driver could do the right thing >> about whether watchdog should be left running or stopped and how long time >> should be given. >> > Good idea. > >> Alternatively, we could also let the watchdog core know a little more about >> the actual watchdog hardware, such as whether the HW is stoppable, whether >> it needs manual pinging by the kernel until user space has taken over. Or Whether the h/w is stoppable or not is certainly a reasonable DT property. The maximum h/w timeout would be too (although that may just be a property of counter size and clock rate). > Yes, all that will be needed. But, still, the stop-gap is that we'll need to > get buyin from the DT folks for the necessary properties. I have had the > outline for the necessary watchdog core implementation in my mind for a long > time, but I just don't have the time (nor the patience, quite frankly) > to get DT buyin. Defining wdog core functionality and behavior has little to do with DT and you don't need buy in. Presumably you care about non-DT platforms as well. Moving more of the intelligence to the core would be a good thing and for the most part should be independent of DT. Rob >> maybe we can just extend the timeout values until the user space has first >> opened it and then shorten the timeout automatically so that it doesn't take >> that long for the device to reset after a crash. Or some other behaviour >> that is common to many users. Suggestions are welcome. >> >> Anyway, that is something that needs to be done to make watchdog core take >> more control over more of the generic watchdog behaviour. It just needs to >> be done so that we don't need to convert all drivers at once. >> > Correct. It should not be that difficult do do that if designed properly. > > Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-23 17:10 ` Rob Herring @ 2015-02-23 17:43 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-23 17:43 UTC (permalink / raw) To: Rob Herring Cc: Timo Kokkonen, Boris Brezillon, Jean-Christophe PLAGNIOL-VILLARD, Nicolas FERRE, Alexandre Belloni, linux-watchdog, linux-arm-kernel On Mon, Feb 23, 2015 at 11:10:13AM -0600, Rob Herring wrote: > On Mon, Feb 23, 2015 at 10:19 AM, Guenter Roeck <linux@roeck-us.net> wrote: > > On Mon, Feb 23, 2015 at 11:11:38AM +0200, Timo Kokkonen wrote: > > [ ... ] > > > >> > >> After all, we do have already watchdog_init_timeout function that parses the > >> watchdog timeout argument from either device tree or from command line. How > >> about if we expanded that interface? Maybe have a more generic > >> watchdog_init_parmas() or something that parses the generic watchdog > >> arguments, either from command line, device tree or ACPI or something. The > >> device driver could replace call from watchdog_init_timeout() to > >> watchdog_init_params() once it is ready to support other generic parameters, > >> such as early-timeout-sec. Then the watchdog driver could do the right thing > >> about whether watchdog should be left running or stopped and how long time > >> should be given. > >> > > Good idea. > > > >> Alternatively, we could also let the watchdog core know a little more about > >> the actual watchdog hardware, such as whether the HW is stoppable, whether > >> it needs manual pinging by the kernel until user space has taken over. Or > > Whether the h/w is stoppable or not is certainly a reasonable DT > property. The maximum h/w timeout would be too (although that may just > be a property of counter size and clock rate). > > > Yes, all that will be needed. But, still, the stop-gap is that we'll need to > > get buyin from the DT folks for the necessary properties. I have had the > > outline for the necessary watchdog core implementation in my mind for a long > > time, but I just don't have the time (nor the patience, quite frankly) > > to get DT buyin. > > Defining wdog core functionality and behavior has little to do with DT > and you don't need buy in. Presumably you care about non-DT platforms > as well. Moving more of the intelligence to the core would be a good > thing and for the most part should be independent of DT. > Even so, if we can not express the HW with DT as needed, we would end up having to work around DT limitations (like using module parameters on top of DT). I just don't have the time to do that. Maybe someone else does. As mentioned earlier, I'll be happy to review and as much as possible test patches. Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-23 17:43 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-23 17:43 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 23, 2015 at 11:10:13AM -0600, Rob Herring wrote: > On Mon, Feb 23, 2015 at 10:19 AM, Guenter Roeck <linux@roeck-us.net> wrote: > > On Mon, Feb 23, 2015 at 11:11:38AM +0200, Timo Kokkonen wrote: > > [ ... ] > > > >> > >> After all, we do have already watchdog_init_timeout function that parses the > >> watchdog timeout argument from either device tree or from command line. How > >> about if we expanded that interface? Maybe have a more generic > >> watchdog_init_parmas() or something that parses the generic watchdog > >> arguments, either from command line, device tree or ACPI or something. The > >> device driver could replace call from watchdog_init_timeout() to > >> watchdog_init_params() once it is ready to support other generic parameters, > >> such as early-timeout-sec. Then the watchdog driver could do the right thing > >> about whether watchdog should be left running or stopped and how long time > >> should be given. > >> > > Good idea. > > > >> Alternatively, we could also let the watchdog core know a little more about > >> the actual watchdog hardware, such as whether the HW is stoppable, whether > >> it needs manual pinging by the kernel until user space has taken over. Or > > Whether the h/w is stoppable or not is certainly a reasonable DT > property. The maximum h/w timeout would be too (although that may just > be a property of counter size and clock rate). > > > Yes, all that will be needed. But, still, the stop-gap is that we'll need to > > get buyin from the DT folks for the necessary properties. I have had the > > outline for the necessary watchdog core implementation in my mind for a long > > time, but I just don't have the time (nor the patience, quite frankly) > > to get DT buyin. > > Defining wdog core functionality and behavior has little to do with DT > and you don't need buy in. Presumably you care about non-DT platforms > as well. Moving more of the intelligence to the core would be a good > thing and for the most part should be independent of DT. > Even so, if we can not express the HW with DT as needed, we would end up having to work around DT limitations (like using module parameters on top of DT). I just don't have the time to do that. Maybe someone else does. As mentioned earlier, I'll be happy to review and as much as possible test patches. Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-20 7:48 ` Jean-Christophe PLAGNIOL-VILLARD @ 2015-02-20 8:00 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-20 8:00 UTC (permalink / raw) To: Jean-Christophe PLAGNIOL-VILLARD Cc: boris.brezillon, linux-arm-kernel, linux-watchdog, Nicolas FERRE, alexandre.belloni Hi, On 20.02.2015 09:48, Jean-Christophe PLAGNIOL-VILLARD wrote: > >> On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: >> >> By default the driver will start a kernel timer which keeps on kicking >> the watchdog HW until user space has opened the watchdog >> device. Usually this is desirable as the watchdog HW is running by >> default and the user space may not have any watchdog daemon running at >> all. >> >> However, on production systems it may be mandatory that also early >> crashes and lockups will lead to a watchdog reset, even if they happen >> before the user space has opened the watchdog device. >> >> To resolve the issue, add a new device tree property >> "early-timeout-sec" which will let the kernel timer to ping the >> watchdog HW only as long as the specified timeout permits. The default >> is still to use kernel timer, but more strict behavior can be enabled >> via the device tree property. >> >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >> --- >> Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ >> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > > This should not be handled by the driver but the kernel in a generic way > Any idea how to do that? The generic watchdog code doesn't really know anything about how the actual HW works. Eg. it can't know whether the watchdog is already running or not, does it need to be started or should we just change the expiration timeout or what. The best the core can do about this is to parse the timeout value off the device tree and give that to the driver. And even that requires that the driver asks the core to do that, because the driver needs to know how to configure the HW properly before exiting probe. This is why I thought it is quite pointless trying to do anything about it in the watchdog core. We could add more generic of parser in the core and change the core API and all drivers, but I don't really see what we would accomplish with that. Each driver that wants to support this needs to change, because all drivers currently try to stop watchdog on their probe function. This is not right if we are about to catch a crash that might happen in the kernel right after the watchdog HW has been stopped. Of course, I might be missing something, please elaborate if you had some plan in your mind. Thanks, -Timo >> 2 files changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt >> index 7e3686c..32647cf 100644 >> --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt >> +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt >> @@ -4,9 +4,16 @@ using these definitions. >> >> Optional properties: >> - timeout-sec: Contains the watchdog timeout in seconds. >> +- early-timeout-sec: If present, specifies a timeout value in seconds >> + that the driver keeps on ticking the watchdog HW on behalf of user >> + space. Once this timeout expires watchdog is left to expire in >> + timeout-sec seconds. If this propery is set to zero, watchdog is >> + started (or left running) so that a reset occurs in timeout-sec >> + since the watchdog was started. >> >> Example: >> >> watchdog { >> timeout-sec = <60>; >> + early-timeout-sec = <120>; >> }; >> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c >> index 6df9405..1b40bfa 100644 >> --- a/drivers/watchdog/at91sam9_wdt.c >> +++ b/drivers/watchdog/at91sam9_wdt.c >> @@ -89,6 +89,8 @@ struct at91wdt { >> u32 mr_mask; >> unsigned long heartbeat; /* WDT heartbeat in jiffies */ >> bool nowayout; >> + /* Timeout in jiffies for stopping the early timer */ >> + unsigned long early_timer; >> unsigned int irq; >> }; >> >> @@ -122,7 +124,8 @@ static void at91_ping(unsigned long data) >> { >> struct at91wdt *wdt = (struct at91wdt *)data; >> if (time_before(jiffies, wdt->next_heartbeat) || >> - !watchdog_active(&wdt->wdd)) { >> + (time_before(jiffies, wdt->early_timer) && >> + !watchdog_active(&wdt->wdd))) { >> at91_wdt_reset(wdt); >> mod_timer(&wdt->timer, jiffies + wdt->heartbeat); >> } else { >> @@ -316,6 +319,10 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) >> >> wdt->mr |= max | ((max - min) << 16); >> >> + if (!of_property_read_u32_index(np, "early-timeout-sec", 0, >> + (u32 *)&wdt->early_timer)) >> + wdt->early_timer = wdt->early_timer * HZ + jiffies; >> + >> return 0; >> } >> #else >> -- >> 2.1.0 >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 8:00 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-20 8:00 UTC (permalink / raw) To: linux-arm-kernel Hi, On 20.02.2015 09:48, Jean-Christophe PLAGNIOL-VILLARD wrote: > >> On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: >> >> By default the driver will start a kernel timer which keeps on kicking >> the watchdog HW until user space has opened the watchdog >> device. Usually this is desirable as the watchdog HW is running by >> default and the user space may not have any watchdog daemon running at >> all. >> >> However, on production systems it may be mandatory that also early >> crashes and lockups will lead to a watchdog reset, even if they happen >> before the user space has opened the watchdog device. >> >> To resolve the issue, add a new device tree property >> "early-timeout-sec" which will let the kernel timer to ping the >> watchdog HW only as long as the specified timeout permits. The default >> is still to use kernel timer, but more strict behavior can be enabled >> via the device tree property. >> >> Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> >> --- >> Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ >> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > > This should not be handled by the driver but the kernel in a generic way > Any idea how to do that? The generic watchdog code doesn't really know anything about how the actual HW works. Eg. it can't know whether the watchdog is already running or not, does it need to be started or should we just change the expiration timeout or what. The best the core can do about this is to parse the timeout value off the device tree and give that to the driver. And even that requires that the driver asks the core to do that, because the driver needs to know how to configure the HW properly before exiting probe. This is why I thought it is quite pointless trying to do anything about it in the watchdog core. We could add more generic of parser in the core and change the core API and all drivers, but I don't really see what we would accomplish with that. Each driver that wants to support this needs to change, because all drivers currently try to stop watchdog on their probe function. This is not right if we are about to catch a crash that might happen in the kernel right after the watchdog HW has been stopped. Of course, I might be missing something, please elaborate if you had some plan in your mind. Thanks, -Timo >> 2 files changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.txt b/Documentation/devicetree/bindings/watchdog/watchdog.txt >> index 7e3686c..32647cf 100644 >> --- a/Documentation/devicetree/bindings/watchdog/watchdog.txt >> +++ b/Documentation/devicetree/bindings/watchdog/watchdog.txt >> @@ -4,9 +4,16 @@ using these definitions. >> >> Optional properties: >> - timeout-sec: Contains the watchdog timeout in seconds. >> +- early-timeout-sec: If present, specifies a timeout value in seconds >> + that the driver keeps on ticking the watchdog HW on behalf of user >> + space. Once this timeout expires watchdog is left to expire in >> + timeout-sec seconds. If this propery is set to zero, watchdog is >> + started (or left running) so that a reset occurs in timeout-sec >> + since the watchdog was started. >> >> Example: >> >> watchdog { >> timeout-sec = <60>; >> + early-timeout-sec = <120>; >> }; >> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c >> index 6df9405..1b40bfa 100644 >> --- a/drivers/watchdog/at91sam9_wdt.c >> +++ b/drivers/watchdog/at91sam9_wdt.c >> @@ -89,6 +89,8 @@ struct at91wdt { >> u32 mr_mask; >> unsigned long heartbeat; /* WDT heartbeat in jiffies */ >> bool nowayout; >> + /* Timeout in jiffies for stopping the early timer */ >> + unsigned long early_timer; >> unsigned int irq; >> }; >> >> @@ -122,7 +124,8 @@ static void at91_ping(unsigned long data) >> { >> struct at91wdt *wdt = (struct at91wdt *)data; >> if (time_before(jiffies, wdt->next_heartbeat) || >> - !watchdog_active(&wdt->wdd)) { >> + (time_before(jiffies, wdt->early_timer) && >> + !watchdog_active(&wdt->wdd))) { >> at91_wdt_reset(wdt); >> mod_timer(&wdt->timer, jiffies + wdt->heartbeat); >> } else { >> @@ -316,6 +319,10 @@ static int of_at91wdt_init(struct device_node *np, struct at91wdt *wdt) >> >> wdt->mr |= max | ((max - min) << 16); >> >> + if (!of_property_read_u32_index(np, "early-timeout-sec", 0, >> + (u32 *)&wdt->early_timer)) >> + wdt->early_timer = wdt->early_timer * HZ + jiffies; >> + >> return 0; >> } >> #else >> -- >> 2.1.0 >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel at lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot 2015-02-20 7:48 ` Jean-Christophe PLAGNIOL-VILLARD @ 2015-02-20 16:09 ` Guenter Roeck -1 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-20 16:09 UTC (permalink / raw) To: Jean-Christophe PLAGNIOL-VILLARD Cc: Timo Kokkonen, boris.brezillon, linux-arm-kernel, linux-watchdog, Nicolas FERRE, alexandre.belloni On Fri, Feb 20, 2015 at 03:48:22PM +0800, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > > > By default the driver will start a kernel timer which keeps on kicking > > the watchdog HW until user space has opened the watchdog > > device. Usually this is desirable as the watchdog HW is running by > > default and the user space may not have any watchdog daemon running at > > all. > > > > However, on production systems it may be mandatory that also early > > crashes and lockups will lead to a watchdog reset, even if they happen > > before the user space has opened the watchdog device. > > > > To resolve the issue, add a new device tree property > > "early-timeout-sec" which will let the kernel timer to ping the > > watchdog HW only as long as the specified timeout permits. The default > > is still to use kernel timer, but more strict behavior can be enabled > > via the device tree property. > > > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > > --- > > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > > This should not be handled by the driver but the kernel in a generic way > Sure, and it has been in the back of my mind for a couple of years. Care to submit a set of patches to implement it ? Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot @ 2015-02-20 16:09 ` Guenter Roeck 0 siblings, 0 replies; 110+ messages in thread From: Guenter Roeck @ 2015-02-20 16:09 UTC (permalink / raw) To: linux-arm-kernel On Fri, Feb 20, 2015 at 03:48:22PM +0800, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > On Feb 18, 2015, at 8:57 PM, Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > > > > By default the driver will start a kernel timer which keeps on kicking > > the watchdog HW until user space has opened the watchdog > > device. Usually this is desirable as the watchdog HW is running by > > default and the user space may not have any watchdog daemon running at > > all. > > > > However, on production systems it may be mandatory that also early > > crashes and lockups will lead to a watchdog reset, even if they happen > > before the user space has opened the watchdog device. > > > > To resolve the issue, add a new device tree property > > "early-timeout-sec" which will let the kernel timer to ping the > > watchdog HW only as long as the specified timeout permits. The default > > is still to use kernel timer, but more strict behavior can be enabled > > via the device tree property. > > > > Signed-off-by: Timo Kokkonen <timo.kokkonen@offcode.fi> > > --- > > Documentation/devicetree/bindings/watchdog/watchdog.txt | 7 +++++++ > > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > > This should not be handled by the driver but the kernel in a generic way > Sure, and it has been in the back of my mind for a couple of years. Care to submit a set of patches to implement it ? Guenter ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCHv3 0/2] watchdog: Introduce "early-timeout-sec" property 2015-02-18 12:57 ` Timo Kokkonen @ 2015-02-18 13:16 ` Boris Brezillon -1 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-18 13:16 UTC (permalink / raw) To: Timo Kokkonen Cc: linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni Hi Timo, Could you send new versions of this in their own thread (not in reply to previous versions), and increment the version in patch 1 and 2 ? Could you also summarize what has changed between each versions in this cover letter ? Best Regards, Boris On Wed, 18 Feb 2015 14:57:20 +0200 Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > Currently we have no means to adjust the watchdog behavior on early > start up before user space has opened the device. The generic behavior > among the watchdog drivers is to not start the watchdog at all (or > disable it, if possible, or in case at91sam9_wdt, start a kernel timer > that keeps on pinging the watchdog on behalf of user space until a > watchdog daemon opens it). This unfortunately opens a time window > between starting the driver and starting the user space watchdog > daemon where a crash of the kernel or user space might prevent the > watchdog from ever resetting the device at all. This is obviously bad > on production systems. > > Introduce a new device tree property that, when set, changes the > watchdog driver behavior in such way that there no longer is any > window where crash is not caught by the watchdog. > > This is the third version of this patch. Previous versions of the > patch were using an atmel specific property name. This patch uses a > generic name instead as the functionality itself has nothing atmel > related. I am also introducing watchdog.txt for describing the generic > watchdog device tree bindings as there was no such file before. > > Timo Kokkonen (2): > devicetree: Document generic watchdog properties > at91sam9_wdt: Allow watchdog to reset device at early boot > > .../devicetree/bindings/watchdog/watchdog.txt | 19 +++++++++++++++++++ > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > 2 files changed, 27 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/watchdog/watchdog.txt > -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCHv3 0/2] watchdog: Introduce "early-timeout-sec" property @ 2015-02-18 13:16 ` Boris Brezillon 0 siblings, 0 replies; 110+ messages in thread From: Boris Brezillon @ 2015-02-18 13:16 UTC (permalink / raw) To: linux-arm-kernel Hi Timo, Could you send new versions of this in their own thread (not in reply to previous versions), and increment the version in patch 1 and 2 ? Could you also summarize what has changed between each versions in this cover letter ? Best Regards, Boris On Wed, 18 Feb 2015 14:57:20 +0200 Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > Currently we have no means to adjust the watchdog behavior on early > start up before user space has opened the device. The generic behavior > among the watchdog drivers is to not start the watchdog at all (or > disable it, if possible, or in case at91sam9_wdt, start a kernel timer > that keeps on pinging the watchdog on behalf of user space until a > watchdog daemon opens it). This unfortunately opens a time window > between starting the driver and starting the user space watchdog > daemon where a crash of the kernel or user space might prevent the > watchdog from ever resetting the device at all. This is obviously bad > on production systems. > > Introduce a new device tree property that, when set, changes the > watchdog driver behavior in such way that there no longer is any > window where crash is not caught by the watchdog. > > This is the third version of this patch. Previous versions of the > patch were using an atmel specific property name. This patch uses a > generic name instead as the functionality itself has nothing atmel > related. I am also introducing watchdog.txt for describing the generic > watchdog device tree bindings as there was no such file before. > > Timo Kokkonen (2): > devicetree: Document generic watchdog properties > at91sam9_wdt: Allow watchdog to reset device at early boot > > .../devicetree/bindings/watchdog/watchdog.txt | 19 +++++++++++++++++++ > drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- > 2 files changed, 27 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/watchdog/watchdog.txt > -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: [PATCHv3 0/2] watchdog: Introduce "early-timeout-sec" property 2015-02-18 13:16 ` Boris Brezillon @ 2015-02-18 13:51 ` Timo Kokkonen -1 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-18 13:51 UTC (permalink / raw) To: Boris Brezillon Cc: linux-arm-kernel, linux-watchdog, nicolas.ferre, alexandre.belloni Hi Boris, Thanks for your comments. I will resend tomorrow! -Timo On 18.02.2015 15:16, Boris Brezillon wrote: > Hi Timo, > > Could you send new versions of this in their own thread (not in reply > to previous versions), and increment the version in patch 1 and 2 ? > > Could you also summarize what has changed between each versions in this > cover letter ? > > Best Regards, > > Boris > > On Wed, 18 Feb 2015 14:57:20 +0200 > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >> Currently we have no means to adjust the watchdog behavior on early >> start up before user space has opened the device. The generic behavior >> among the watchdog drivers is to not start the watchdog at all (or >> disable it, if possible, or in case at91sam9_wdt, start a kernel timer >> that keeps on pinging the watchdog on behalf of user space until a >> watchdog daemon opens it). This unfortunately opens a time window >> between starting the driver and starting the user space watchdog >> daemon where a crash of the kernel or user space might prevent the >> watchdog from ever resetting the device at all. This is obviously bad >> on production systems. >> >> Introduce a new device tree property that, when set, changes the >> watchdog driver behavior in such way that there no longer is any >> window where crash is not caught by the watchdog. >> >> This is the third version of this patch. Previous versions of the >> patch were using an atmel specific property name. This patch uses a >> generic name instead as the functionality itself has nothing atmel >> related. I am also introducing watchdog.txt for describing the generic >> watchdog device tree bindings as there was no such file before. >> >> Timo Kokkonen (2): >> devicetree: Document generic watchdog properties >> at91sam9_wdt: Allow watchdog to reset device at early boot >> >> .../devicetree/bindings/watchdog/watchdog.txt | 19 +++++++++++++++++++ >> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- >> 2 files changed, 27 insertions(+), 1 deletion(-) >> create mode 100644 Documentation/devicetree/bindings/watchdog/watchdog.txt >> > > > ^ permalink raw reply [flat|nested] 110+ messages in thread
* [PATCHv3 0/2] watchdog: Introduce "early-timeout-sec" property @ 2015-02-18 13:51 ` Timo Kokkonen 0 siblings, 0 replies; 110+ messages in thread From: Timo Kokkonen @ 2015-02-18 13:51 UTC (permalink / raw) To: linux-arm-kernel Hi Boris, Thanks for your comments. I will resend tomorrow! -Timo On 18.02.2015 15:16, Boris Brezillon wrote: > Hi Timo, > > Could you send new versions of this in their own thread (not in reply > to previous versions), and increment the version in patch 1 and 2 ? > > Could you also summarize what has changed between each versions in this > cover letter ? > > Best Regards, > > Boris > > On Wed, 18 Feb 2015 14:57:20 +0200 > Timo Kokkonen <timo.kokkonen@offcode.fi> wrote: > >> Currently we have no means to adjust the watchdog behavior on early >> start up before user space has opened the device. The generic behavior >> among the watchdog drivers is to not start the watchdog at all (or >> disable it, if possible, or in case at91sam9_wdt, start a kernel timer >> that keeps on pinging the watchdog on behalf of user space until a >> watchdog daemon opens it). This unfortunately opens a time window >> between starting the driver and starting the user space watchdog >> daemon where a crash of the kernel or user space might prevent the >> watchdog from ever resetting the device at all. This is obviously bad >> on production systems. >> >> Introduce a new device tree property that, when set, changes the >> watchdog driver behavior in such way that there no longer is any >> window where crash is not caught by the watchdog. >> >> This is the third version of this patch. Previous versions of the >> patch were using an atmel specific property name. This patch uses a >> generic name instead as the functionality itself has nothing atmel >> related. I am also introducing watchdog.txt for describing the generic >> watchdog device tree bindings as there was no such file before. >> >> Timo Kokkonen (2): >> devicetree: Document generic watchdog properties >> at91sam9_wdt: Allow watchdog to reset device at early boot >> >> .../devicetree/bindings/watchdog/watchdog.txt | 19 +++++++++++++++++++ >> drivers/watchdog/at91sam9_wdt.c | 9 ++++++++- >> 2 files changed, 27 insertions(+), 1 deletion(-) >> create mode 100644 Documentation/devicetree/bindings/watchdog/watchdog.txt >> > > > ^ permalink raw reply [flat|nested] 110+ messages in thread
end of thread, other threads:[~2015-02-23 17:43 UTC | newest] Thread overview: 110+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-10-23 10:40 [PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot Timo Kokkonen 2014-10-23 10:40 ` Timo Kokkonen 2014-11-12 8:20 ` Timo Kokkonen 2014-11-12 8:20 ` Timo Kokkonen 2014-11-13 9:12 ` Nicolas Ferre 2014-11-13 9:12 ` Nicolas Ferre 2014-11-14 8:40 ` Timo Kokkonen 2014-11-14 8:40 ` Timo Kokkonen 2014-11-21 12:23 ` Timo Kokkonen 2014-11-21 12:23 ` Timo Kokkonen 2014-11-27 6:53 ` Timo Kokkonen 2014-11-27 6:53 ` Timo Kokkonen 2014-11-27 9:22 ` Nicolas Ferre 2014-11-27 9:22 ` Nicolas Ferre 2014-11-27 17:23 ` Guenter Roeck 2014-11-27 17:23 ` Guenter Roeck 2014-11-27 19:06 ` Boris Brezillon 2014-11-27 19:06 ` Boris Brezillon 2014-11-27 19:31 ` Guenter Roeck 2014-11-27 19:31 ` Guenter Roeck 2014-11-28 0:30 ` Alexandre Belloni 2014-11-28 0:30 ` Alexandre Belloni 2014-11-28 6:40 ` Timo Kokkonen 2014-11-28 6:40 ` Timo Kokkonen 2014-11-27 19:00 ` Boris Brezillon 2014-11-27 19:00 ` Boris Brezillon 2014-11-28 6:42 ` Timo Kokkonen 2014-11-28 6:42 ` Timo Kokkonen 2014-12-05 12:57 ` Timo Kokkonen 2014-12-05 12:57 ` Timo Kokkonen 2014-12-05 14:12 ` Boris Brezillon 2014-12-05 14:12 ` Boris Brezillon 2014-12-05 18:42 ` Timo Kokkonen 2014-12-05 18:42 ` Timo Kokkonen 2014-12-05 19:02 ` Guenter Roeck 2014-12-05 19:02 ` Guenter Roeck 2014-12-05 20:32 ` Timo Kokkonen 2014-12-05 20:32 ` Timo Kokkonen 2014-12-05 21:39 ` Guenter Roeck 2014-12-05 21:39 ` Guenter Roeck 2014-12-06 10:11 ` Timo Kokkonen 2014-12-06 10:11 ` Timo Kokkonen 2015-01-13 14:53 ` Guenter Roeck 2015-01-13 14:53 ` Guenter Roeck 2015-01-14 6:09 ` Timo Kokkonen 2015-01-14 6:09 ` Timo Kokkonen 2015-02-18 12:57 ` [PATCHv3 0/2] watchdog: Introduce "early-timeout-sec" property Timo Kokkonen 2015-02-18 12:57 ` Timo Kokkonen 2015-02-18 12:57 ` [PATCH 1/2] devicetree: Document generic watchdog properties Timo Kokkonen 2015-02-18 12:57 ` Timo Kokkonen 2015-02-18 12:57 ` [PATCH 2/2] at91sam9_wdt: Allow watchdog to reset device at early boot Timo Kokkonen 2015-02-18 12:57 ` Timo Kokkonen 2015-02-18 13:21 ` Boris Brezillon 2015-02-18 13:21 ` Boris Brezillon 2015-02-18 13:59 ` Guenter Roeck 2015-02-18 13:59 ` Guenter Roeck 2015-02-18 14:17 ` Boris Brezillon 2015-02-18 14:17 ` Boris Brezillon 2015-02-18 14:50 ` Guenter Roeck 2015-02-18 14:50 ` Guenter Roeck 2015-02-18 16:00 ` Alexandre Belloni 2015-02-18 16:00 ` Alexandre Belloni 2015-02-18 17:50 ` Guenter Roeck 2015-02-18 17:50 ` Guenter Roeck 2015-02-18 20:21 ` Boris Brezillon 2015-02-18 20:21 ` Boris Brezillon 2015-02-19 6:02 ` Timo Kokkonen 2015-02-19 6:02 ` Timo Kokkonen 2015-02-18 21:11 ` Rob Herring 2015-02-18 21:11 ` Rob Herring 2015-02-19 6:14 ` Timo Kokkonen 2015-02-19 6:14 ` Timo Kokkonen 2015-02-20 14:06 ` Rob Herring 2015-02-20 14:06 ` Rob Herring 2015-02-20 16:28 ` Guenter Roeck 2015-02-20 16:28 ` Guenter Roeck 2015-02-20 19:43 ` Boris Brezillon 2015-02-20 19:43 ` Boris Brezillon 2015-02-20 20:04 ` Guenter Roeck 2015-02-20 20:04 ` Guenter Roeck 2015-02-20 7:48 ` Jean-Christophe PLAGNIOL-VILLARD 2015-02-20 7:48 ` Jean-Christophe PLAGNIOL-VILLARD 2015-02-20 7:51 ` Boris Brezillon 2015-02-20 7:51 ` Boris Brezillon 2015-02-20 16:33 ` Jean-Christophe PLAGNIOL-VILLARD 2015-02-20 16:33 ` Jean-Christophe PLAGNIOL-VILLARD 2015-02-20 17:16 ` Boris Brezillon 2015-02-20 17:16 ` Boris Brezillon 2015-02-20 18:06 ` Guenter Roeck 2015-02-20 18:06 ` Guenter Roeck 2015-02-23 7:29 ` Timo Kokkonen 2015-02-23 7:29 ` Timo Kokkonen 2015-02-23 8:51 ` Boris Brezillon 2015-02-23 8:51 ` Boris Brezillon 2015-02-23 9:11 ` Timo Kokkonen 2015-02-23 9:11 ` Timo Kokkonen 2015-02-23 16:19 ` Guenter Roeck 2015-02-23 16:19 ` Guenter Roeck 2015-02-23 17:10 ` Rob Herring 2015-02-23 17:10 ` Rob Herring 2015-02-23 17:43 ` Guenter Roeck 2015-02-23 17:43 ` Guenter Roeck 2015-02-20 8:00 ` Timo Kokkonen 2015-02-20 8:00 ` Timo Kokkonen 2015-02-20 16:09 ` Guenter Roeck 2015-02-20 16:09 ` Guenter Roeck 2015-02-18 13:16 ` [PATCHv3 0/2] watchdog: Introduce "early-timeout-sec" property Boris Brezillon 2015-02-18 13:16 ` Boris Brezillon 2015-02-18 13:51 ` Timo Kokkonen 2015-02-18 13:51 ` Timo Kokkonen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.