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: <VI1PR04MB553399573A1D360C62C17E61EEBF0@VI1PR04MB5533.eurprd04.prod.outlook.com>
Date:   Thu, 20 Dec 2018 13:49:38 +0000
From:   Leonard Crestez <leonard.crestez@....com>
To:     Trent Piepho <tpiepho@...inj.com>,
        "andrew.smirnov@...il.com" <andrew.smirnov@...il.com>,
        "robh@...nel.org" <robh@...nel.org>
CC:     "l.stach@...gutronix.de" <l.stach@...gutronix.de>,
        Aisheng Dong <aisheng.dong@....com>,
        Richard Zhu <hongxing.zhu@....com>,
        "cphealy@...il.com" <cphealy@...il.com>,
        dl-linux-imx <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 <fabio.estevam@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.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 12/20/2018 3:22 AM, Trent Piepho wrote:
> 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?

I guess you could have a constant for the address of the first 
controller and then substract. But hardcoding any sort of physical 
address feels wrong with DT.
> 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?

Look at how this cell-index property is documented in other bindings it 
seems to be an excellent fit: just rename controller-id to cell-index.