linux-kernel - Re: [PATCH v5 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs

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: <CAK8P3a0z_q-GNc-vSPbovu8yrEQyCGDccoDe16rycW+uOwO4Dw@mail.gmail.com>
Date:   Fri, 20 Oct 2017 11:15:55 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Li Wei <liwei213@...wei.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Wei Xu <xuwei5@...ilicon.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Vinayak Holikatti <vinholikatti@...il.com>,
        "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Kevin Hilman <khilman@...libre.com>,
        Gregory CLEMENT <gregory.clement@...e-electrons.com>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Riku Voipio <riku.voipio@...aro.org>,
        Thierry Reding <treding@...dia.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Eric Anholt <eric@...olt.net>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-scsi <linux-scsi@...r.kernel.org>,
        Guodong Xu <guodong.xu@...aro.org>, fengbaopeng@...ilicon.com,
        lihuan41@...ilicon.com, wangyupeng4@...ilicon.com
Subject: Re: [PATCH v5 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs

On Fri, Oct 20, 2017 at 10:52 AM, Li Wei <liwei213@...wei.com> wrote:
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> @@ -0,0 +1,46 @@
> +* Hisilicon Universal Flash Storage (UFS) Host Controller
> +
> +UFS nodes are defined to describe on-chip UFS hardware macro.
> +Each UFS Host Controller should have its own node.
> +
> +Required properties:
> +- compatible        : compatible list, contains one of the following -
> +                       "hisilicon,hi3660-ufs" for hisi ufs host controller
> +                        present on Hi3660 chipset.
> +- reg               : should contain UFS register address space & UFS SYS CTRL register address,
> +- interrupt-parent  : interrupt device
> +- interrupts        : interrupt number
> +- clocks               : List of phandle and clock specifier pairs
> +- clock-names       : List of clock input name strings sorted in the same
> +                     order as the clocks property. "clk_ref", "clk_phy" is optional
> +- resets            : reset node register, one reset the clk and the other reset the controller
> +- reset-names       : describe reset node register

I think I've asked about this before, but I think this should be done more
consistently with the other UFS bindings.

In particular, I wonder if what you describe as the "UFS SYS CTRL"
area corresponds to what Qualcomm have described as their PHY
implementation. It certainly seems to driver some of the properties
that would normally be associated with a PHY.

For the "clock-names" property, you specify "clk_ref", which I
assume is the same as what Qualcomm call "ref_clk". I'd
suggest you use the existing name and add that as the
default name in the ufshcd-pltfrm.txt binding document.

The "clk_phy" property appears to be related to the PHY, so
it might be better to have a separate phy node with either just
the clk, or with the clk plus the "UFS SYS CTRL" register area,
whichever matches your hardware better, and then use teh
"phys/phy-names" property to refer to that.

The reset handling you describe here (both resets and reset-gpios)
appears to be completely generic, so I'd suggest adding those to
ufshcd-pltfrm.txt instead of your own binding, to ensure that future
drivers use the same identifiers.


      Arnd