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

Date:   Wed, 23 Jan 2019 21:33:47 -0800
From:   Andrey Smirnov <andrew.smirnov@...il.com>
To:     Philipp Zabel <p.zabel@...gutronix.de>
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

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. Removing those resets will not meaningfully simplify
maintenance burden for this driver (a one line change), 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.

> > PCIe driver already has the code to use
> > those on i.MX7D and, due to high degree of similarity, i.MX8MQ
> > actually re-uses the same codepath (at least for
> > IMX8MQ_RESET_PCIE_CTRL_APPS_EN).
>
> We can always switch to i.MX6-like direct syscon/GPR manipulation and
> just drop the resets from DT.
> Since if this is done, it should be done for i.MX7 as well, I see no
> reason for this issue to hold up your i.MX8M changes.
>

Cool, thanks!

Thanks,
Andrey Smirnov