linux-kernel - Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

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:   Thu, 19 Jan 2017 13:42:58 -0800
From:   Stephen Boyd <sboyd@...eaurora.org>
To:     Vivek Gautam <vivek.gautam@...eaurora.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Kishon Vijay Abraham I <kishon@...com>, robh+dt@...nel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        mark.rutland@....com, srinivas.kandagatla@...aro.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

On 01/19, Vivek Gautam wrote:
> 
> On 01/19/2017 06:10 AM, Stephen Boyd wrote:
> >>
> >Didn't we already move away from subnodes for lanes in an earlier
> >revision of these patches? I seem to recall we did that because
> >lanes are not devices and the whole "phy as a bus" concept not
> >making sense.
> 
> Yea, we started out without having any sub-nodes and we
> argued that we don't require them since the qmp device is
> represented by the qmp node itself.
> The lanes otoh are representative of gen_phys and related properties.
> 
> In the driver -
> "struct qmp_phy " represents the lanes and holds "struct phy",
> "struct qcom_qmp" represents the qmp block as a whole and holds
> "struct device"
> Does this make lanes qualify to be childs of qmp ?

Hmm... maybe I was recalling the DSI phy binding. I think there
are lanes there too but we decided to just have one node.

> 
> "phy as a bus" (just trying to understand here) -
> let's say a usb phy controller has one HSIC phy port and one USB2 phy port.
> So, should this phy controller be a bus providing two ports (and so
> we will have
> couple of child nodes to the phy controller) ?
> 

Typically in DT a subnode or collection of subnodes means there's
some sort of bus involved. Usually each node corresponds to a
struct device, and the parent node corresponds to the bus or
controller for the logical bus.

In this case (only PCIe though? not UFS or USB?) it seems like we
have multiple phys that share a common register space, but
otherwise they have their own register space and power
management. Would you have each PCIe controller point to a
different subnode for their associated phy? I'm trying to
understand the benefit of the subnodes if they aren't treated as
struct devices.

At the least, please get DT reviewers to ack the new binding
before rewriting the code.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project