linux-kernel - Re: [PATCH v3 1/2] drivers/watchdog: Add optional ASPEED device tree properties

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170706143512.bmjv2gnoqp5ew4py@rob-hp-laptop>
Date:   Thu, 6 Jul 2017 09:35:12 -0500
From:   Rob Herring <robh@...nel.org>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Christopher Bostic <cbostic@...ux.vnet.ibm.com>, wim@...ana.be,
        mark.rutland@....com, joel@....id.au,
        linux-watchdog@...r.kernel.org, devicetree@...r.kernel.org,
        openbmc@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] drivers/watchdog: Add optional ASPEED device tree
 properties

On Thu, Jun 29, 2017 at 08:04:17AM -0700, Guenter Roeck wrote:
> On Thu, Jun 29, 2017 at 08:39:59AM -0500, Christopher Bostic wrote:
> > 
> > 
> > On 6/28/17 10:33 PM, Guenter Roeck wrote:
> > >On 06/28/2017 05:28 PM, Christopher Bostic wrote:
> > >>Describe device tree optional properties:
> > >>
> > >>   * aspeed,arm-reet - ARM CPU reset on signal
> > >>   * aspeed,no-soc-reset - SOC reset on signal
> > >>   * aspeed,no-sys-reset - System reset on signal
> > >>   * aspeed,interrupt - Interrupt CPU on signal
> > >>   * aspeed,external-signal - Generate external signal (WDT1 and WDT2
> > >>only)
> > >>   * aspeed,alt-boot - Boot from alternate block on signal
> > >>
> > >>Signed-off-by: Christopher Bostic <cbostic@...ux.vnet.ibm.com>
> > >>---
> > >>v3 - Invert soc and sys reset to 'no' to preserve backwards
> > >>      compatibility.  SOC and SYS reset will be set by default
> > >>      without any optional parameters set
> > >>v2 - Add 'aspeed,' prefix to all optional properties
> > >>    - Add arm-reset, soc-reset, interrupt, alt-boot properties
> > >>---
> > >>  .../devicetree/bindings/watchdog/aspeed-wdt.txt    | 24
> > >>++++++++++++++++++++++
> > >>  1 file changed, 24 insertions(+)
> > >>
> > >>diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> > >>b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> > >>index c5e74d7..6f18005 100644
> > >>--- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> > >>+++ b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> > >>@@ -8,9 +8,33 @@ Required properties:
> > >>   - reg: physical base address of the controller and length of memory
> > >>mapped
> > >>     region
> > >>  +Optional properties:
> > >>+   Signal behavior - Whenever a timeout occurs the watchdog can be
> > >>programmed
> > >>+   to generate/not generate 6 types of signals:
> > >>+
> > >>+ - aspeed,arm-reset:    If property is present then reset ARM CPU only.
> > >>+            If not specified no ARM CPU reset is done.
> > >>+
> > >>+ - aspeed,no-soc-reset: If property is present then do not reset SOC.
> > >>+            If not specified then SOC reset is done.
> > >>+
> > >>+ - aspeed,no-sys-reset: If property is present then do not reset
> > >>system.
> > >>+            Typcally used in tandem with 'aspeed-external-signal'
> > >
> > >Is this correct ? As I understand the datasheet, it could also used in
> > >tandem with
> > >aspeed,interrupt.
> > True, that should be documented.  Will add that.
> > >
> > >>+            If not specified then system reset is done.
> > >>+
> > >
> > >I'll leave it up to Rob to decide, but for my part I don't understand
> > >no-soc-reset.
> > As the aspeed watchdog driver exists prior to this change an SOC reset is
> > done by
> > default.   In order to preserve backwards compatibility a missing optional
> > property
> > should result in default behavior.  I however need to be able to specify
> > that SOC
> > reset be disabled in some way.  This goes back to our discussion about why
> > we'd
> > ever want to disable SYSTEM reset in the first place.  Same reasoning
> > applies for
> > SOC reset.
> > 
> > >I would instead use four properties.
> > >
> > >    aspeed,arm-reset
> > >    aspeed,soc-reset
> > Per my response above I think it should remain as aspeed,no-soc-reset due to
> > backwards compatibility requirements.
> 
> The same can be accomplished with "aspeed,no-reset", which would avoid the, in
> my opinion, awkward "no-{sys,soc}-reset" poperties.
> 
> > >    aspeed,sys-reset (which is the default)
> > Again as per our discussion yesterday I need some way to specify how system
> > reset is to  be done.  For backwards compatibility, a lack of parameter here
> > would
> > result in a system reset being configured.  Only way to indicate to the
> > driver
> > that no system reset is to be done is to indicate 'no' system reset in the
> > optional
> > parameter.
> 
> Or "aspeed,no-reset".
> 
> > >    aspeed,no-reset
> > This parameter seems ambiguous as we could be doing a 'no system reset'
> > or a 'no SOC reset' in theory.
> 
> {arm,soc,sys}-reset are mutually exclusive per datasheet, and there is a
> separate configuration bit which enables the reset in the first place.
> I don't see how that is ambiguous.
> 
> Anyway, I don't think we are making any progress here. Let's wait for
> guidance from Rob.

I tend to agree with Guenter.

Maybe using the form 'aspeed,reset-type = "cpu|soc|system"' would be 
more aligned to the type of reset being mutually exclusive. 

Rob