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

[Philipp Zabel]

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@xxxxxxxxxxxxxx> 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