linux-kernel - Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller

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:   Tue, 22 Nov 2016 18:23:16 +0100
From:   Gregory CLEMENT <gregory.clement@...e-electrons.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Ziji Hu <huziji@...vell.com>, Ulf Hansson <ulf.hansson@...aro.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        <linux-mmc@...r.kernel.org>, Jason Cooper <jason@...edaemon.net>,
        Andrew Lunn <andrew@...n.ch>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        <devicetree@...r.kernel.org>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        "Jack\(SH\) Zhu" <jmzhu@...vell.com>, Jimmy Xu <zmxu@...vell.com>,
        Jisheng Zhang <jszhang@...vell.com>,
        Nadav Haklai <nadavh@...vell.com>, Ryan Gao <ygao@...vell.com>,
        Doug Jones <dougj@...vell.com>,
        Shiwu Zhang <zhangshw@...vell.com>,
        Victor Gu <xigu@...vell.com>,
        "Wei\(SOCP\) Liu" <liuw@...vell.com>,
        Wilson Ding <dingwei@...vell.com>,
        Xueping Liu <xpliu@...vell.com>,
        Hilbert Zhang <zzhang@...vell.com>,
        Keji Zhang <keji@...vell.com>,
        Liuliu Zhao <zhaoliul@...vell.com>,
        Peng Zhu <zhupeng@...vell.com>, Yu Cao <yucao@...vell.com>,
        Romain Perier <romain.perier@...e-electrons.com>,
        Yehuda Yitschak <yehuday@...vell.com>,
        Marcin Wojtas <mw@...ihalf.com>,
        Hanna Hawa <hannah@...vell.com>,
        Kostya Porotchkin <kostap@...vell.com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller

Hi Rob,
 
 On jeu., nov. 10 2016, Ziji Hu <huziji@...vell.com> wrote:

[...]

>>> +
>>> +- reg:
>>> +  * For "marvell,xenon-sdhci", one register area for Xenon IP.
>>> +
>>> +  * For "marvell,armada-3700-sdhci", two register areas.
>>> +    The first one for Xenon IP register. The second one for the Armada 3700 SOC
>>> +    PHY PAD Voltage Control register.
>>> +    Please follow the examples with compatible "marvell,armada-3700-sdhci"
>>> +    in below.
>>> +    Please also check property marvell,pad-type in below.
>>> +
>>> +Optional Properties:
>>> +- marvell,xenon-slotno:
>> 
>> Multiple slots should be represented as child nodes IMO. I think some 
>> other bindings already do this.
>> 
>
> 	All the slots are entirely independent.
> 	I prefer to consider it as multiple independent SDHCs placed in
> 	a single IP, instead of that a IP contains multiple child slots.

It was indeed what I tried to show in my answer for the 1st version:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461860.html

Maybe you missed it.

You also mentioned other bindings using child nodes, but for this one
we have one controller with only one set of register with multiple slots
(Atmel is an example). Here each slot have it own set of register.

Actually giving the fact that each slot is controlled by a different set
of register I wonder why the hardware can't also deduce the slot number
from the address register. For me it looks like an hardware bug but we
have to deal with it.

Do you still think we needchild node here?

>
> 	It is unlike the implementation which put multiple slots behind PCIe EP interface. sdhci-pci.c will handle each slot init one by one.
> 	If Xenon SDHC slots are represented as child nodes, there should also be a main entry in Xenon driver to init each child node one by one.
> 	In my very own opinion, it is inconvenient and unnecessary.


Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com