| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20151105222325.GA26159@roeck-us.net>
Date: Thu, 5 Nov 2015 14:23:25 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Akshay Bhat <akshay.bhat@...esys.com>
Cc: linux-watchdog@...r.kernel.org, robh+dt@...nel.org,
pawel.moll@....com, mark.rutland@....com,
ijc+devicetree@...lion.org.uk, galak@...eaurora.org, wim@...ana.be,
tharvey@...eworks.com, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, shawnguo@...nel.org,
kernel@...gutronix.de, linux@....linux.org.uk,
linux-arm-kernel@...ts.infradead.org, justin.waters@...esys.com,
l.stach@...gutronix.de, festevam@...il.com, sr@...x.de
Subject: Re: [PATCH v4 1/2] watchdog: imx2_wdt: add external reset support
via 'ext-reset-output' dt prop
On Thu, Nov 05, 2015 at 04:19:21PM -0500, Akshay Bhat wrote:
> From: Tim Harvey <tharvey@...eworks.com>
>
> The IMX6 watchdog supports assertion of a signal (WDOG_B) which
> can be pinmux'd to an external pin. This is typically used for boards that
> have PMIC's in control of the IMX6 power rails. In fact, failure to use
> such an external reset on boards with external PMIC's can result in various
> hangs due to the IMX6 not being fully reset [1] as well as the board failing
> to reset because its PMIC has not been reset to provide adequate voltage for
> the CPU when coming out of reset at 800Mhz.
>
> This uses a new device-tree property 'ext-reset-output' to indicate the
> board has such a reset and to cause the watchdog to be configured to assert
> WDOG_B instead of an internal reset both on a watchdog timeout and in
> system_restart.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html
>
> Cc: Lucas Stach <l.stach@...gutronix.de>
> Signed-off-by: Tim Harvey <tharvey@...eworks.com>
> ---
> .../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 ++
> drivers/watchdog/imx2_wdt.c | 20 ++++++++++++++++++--
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> index 8dab6fd..9b89b3a 100644
> --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> @@ -9,6 +9,8 @@ Optional property:
properties ?
> - big-endian: If present the watchdog device's registers are implemented
> in big endian mode, otherwise in native mode(same with CPU), for more
> detail please see: Documentation/devicetree/bindings/regmap/regmap.txt.
> +- ext-reset-output: If present the watchdog device is configured to assert its
Should that have a vendor prefix ? Also, not sure if "-output"
has any real value in the property name. "fsl,external-reset", maybe ?
> + external reset (WDOG_B) instead of issuing a software reset.
>
> Examples:
>
> diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> index 29ef719..84bfec4 100644
> --- a/drivers/watchdog/imx2_wdt.c
> +++ b/drivers/watchdog/imx2_wdt.c
> @@ -41,6 +41,8 @@
>
> #define IMX2_WDT_WCR 0x00 /* Control Register */
> #define IMX2_WDT_WCR_WT (0xFF << 8) /* -> Watchdog Timeout Field */
> +#define IMX2_WDT_WCR_WDA (1 << 5) /* -> External Reset WDOG_B */
> +#define IMX2_WDT_WCR_SRS (1 << 4) /* -> Software Reset Signal */
> #define IMX2_WDT_WCR_WRE (1 << 3) /* -> WDOG Reset Enable */
> #define IMX2_WDT_WCR_WDE (1 << 2) /* -> Watchdog Enable */
> #define IMX2_WDT_WCR_WDZST (1 << 0) /* -> Watchdog timer Suspend */
> @@ -65,6 +67,7 @@ struct imx2_wdt_device {
> struct timer_list timer; /* Pings the watchdog when closed */
> struct watchdog_device wdog;
> struct notifier_block restart_handler;
> + bool ext_reset;
> };
>
> static bool nowayout = WATCHDOG_NOWAYOUT;
> @@ -90,6 +93,13 @@ static int imx2_restart_handler(struct notifier_block *this, unsigned long mode,
> struct imx2_wdt_device *wdev = container_of(this,
> struct imx2_wdt_device,
> restart_handler);
> +
> + /* Use internal reset or external - not both */
> + if (wdev->ext_reset)
> + wcr_enable |= IMX2_WDT_WCR_SRS; /* do not assert int reset */
> + else
> + wcr_enable |= IMX2_WDT_WCR_WDA; /* do not assert ext-reset */
> +
> /* Assert SRS signal */
> regmap_write(wdev->regmap, IMX2_WDT_WCR, wcr_enable);
> /*
> @@ -119,8 +129,12 @@ static inline void imx2_wdt_setup(struct watchdog_device *wdog)
> val |= IMX2_WDT_WCR_WDZST;
> /* Strip the old watchdog Time-Out value */
> val &= ~IMX2_WDT_WCR_WT;
> - /* Generate reset if WDOG times out */
> - val &= ~IMX2_WDT_WCR_WRE;
> + /* Generate internal chip-level reset if WDOG times out */
> + if (!wdev->ext_reset)
> + val &= ~IMX2_WDT_WCR_WRE;
> + /* Or if external-reset assert WDOG_B reset only on time-out */
> + else
> + val |= IMX2_WDT_WCR_WRE;
I don't really understand what this means. Normally I would hope that a watchdog
only generates a reset if/when it times out.
> /* Keep Watchdog Disabled */
> val &= ~IMX2_WDT_WCR_WDE;
> /* Set the watchdog's Time-Out value */
> @@ -267,6 +281,8 @@ static int __init imx2_wdt_probe(struct platform_device *pdev)
> regmap_read(wdev->regmap, IMX2_WDT_WRSR, &val);
> wdog->bootstatus = val & IMX2_WDT_WRSR_TOUT ? WDIOF_CARDRESET : 0;
>
> + wdev->ext_reset = of_property_read_bool(pdev->dev.of_node,
> + "ext-reset-output");
> wdog->timeout = clamp_t(unsigned, timeout, 1, IMX2_WDT_MAX_TIME);
> if (wdog->timeout != timeout)
> dev_warn(&pdev->dev, "Initial timeout out of range! Clamped from %u to %u\n",
> --
> 2.6.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists