linux-kernel - Re: [PATCH v3 3/3] PCI: imx6: Add support for i.MX8MQ

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: <1545268969.22930.77.camel@impinj.com>
Date:   Thu, 20 Dec 2018 01:22:51 +0000
From:   Trent Piepho <tpiepho@...inj.com>
To:     "l.stach@...gutronix.de" <l.stach@...gutronix.de>,
        "andrew.smirnov@...il.com" <andrew.smirnov@...il.com>
CC:     "aisheng.dong@....com" <aisheng.dong@....com>,
        "hongxing.zhu@....com" <hongxing.zhu@....com>,
        "cphealy@...il.com" <cphealy@...il.com>,
        "linux-imx@....com" <linux-imx@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        "fabio.estevam@....com" <fabio.estevam@....com>,
        "robh@...nel.org" <robh@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "leonard.crestez@....com" <leonard.crestez@....com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH v3 3/3] PCI: imx6: Add support for i.MX8MQ

On Wed, 2018-12-19 at 16:47 -0800, Andrey Smirnov wrote:
> 
> > > This series initially added explicit offsets but I suggested a single
> > > "controller-id" because:
> > >   * There are multiple bit and byte offsets
> > >   * Other imx8 SOCs also have 2x pcie with other bit/byte offsets
> > > 
> > > Hiding this behind a compatible string and single "controller-id" seem
> > > preferable to elaborating register maps in dt bindings. It also makes
> > > upgrades simpler: if features are added which use other bits there is no
> > > need to describe them in DT and deal with compatibility headaches.
> > 
> > You already have an id for the controllers: the address. Use that if
> > you don't want to put the register offsets in DT.
> > 
> 
> Lucas, are you on board with this?

Does address here mean the address from the controller's reg property?

How do you map that address to the controller's index?  A giant table
of every soc so the soc type plus controller register address pair than
can be looked up in the driver?

I.e., on iMX8MQ the controller at 0x33800000 is controller 0 and so on
for every possible SoC address combination?

Not really a fan of that.

The situation here is that some registers for these controllers are
interleaved, right?  I.e., there's one register somewhere where bit 0
means enable controller 0 and bit 1 means enable controller 1 and so
on.

Isn't cell-index already the standard device tree property for this
kind of setup?

I know cell-index was historically also (ab)used in an attempt to
provide a fixed kernel device enumeration order, something now handled
better by chosen node aliases.