linux-kernel - Re: [PATCH v4 2/3] dt-bindings: reset: imx7: Document usage on i.MX8MQ SoCs

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] [day] [month] [year] [list]

Date:   Thu, 24 Jan 2019 10:11:56 +0100
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Andrey Smirnov <andrew.smirnov@...il.com>
Cc:     Lucas Stach <l.stach@...gutronix.de>,
        Leonard Crestez <leonard.crestez@....com>,
        Fabio Estevam <fabio.estevam@....com>,
        Chris Healy <cphealy@...il.com>,
        "A.s. Dong" <aisheng.dong@....com>,
        Richard Zhu <hongxing.zhu@....com>,
        dl-linux-imx <linux-imx@....com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 2/3] dt-bindings: reset: imx7: Document usage on
 i.MX8MQ SoCs

Hi Andrey,

On Wed, 2019-01-23 at 21:33 -0800, Andrey Smirnov wrote:
> On Wed, Jan 23, 2019 at 2:52 AM Philipp Zabel <p.zabel@...gutronix.de> wrote:
> > 
> > On Thu, 2019-01-17 at 14:38 -0800, Andrey Smirnov wrote:
> > [...]
> > > > To be honest, I don't like these two, I'm not convinced anymore that
> > > > they actually qualify as reset signals. To me it looks like this is
> > > > something that the PCIe glue code should handle via syscon like i.MX6.
> > > > Leonard, Lucas, what do you think?
> > > 
> > > OK, one thing to keep in mind about this is that those bits are
> > > already exposed for i.MX7D and I think (correct me if I am wrong)
> > > there's no going back there.
> > 
> > That's not a reason to repeat the same mistake for i.MX8QM, but at the
> > moment I'm still trying to figure out if it actually was a mistake.
> > 
> 
> It absolutely is. 

Ok, that was a sloppy expression. I'm glad you got my meaning anyway.
Of course it is a reason, but it's not a good one.

> Removing those resets will not meaningfully simplify
> maintenance burden for this driver (a one line change),

I'm less worried about the maintenance burden on this reset driver and
more about lying in the device tree description and possibly setting a
bad precedent.

> but it will cause additional code churn on PCI side of things.
> You may not agree with me that it is a _good_ reason to not to remove
> those resets, but it is a reason nonetheless.

Exactly. Code churn in one driver implementation should not stop us from
fixing device tree bindings (in a backwards compatible fashion).
Mind you, this is all under my assumption that the bits in question do
not control resets and should never have been described as resets in the
device tree.

regards
Philipp