linux-kernel - Re: [PATCH 06/10] PCI: qcom: Add support for SC8280XP

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:   Mon, 4 Jul 2022 16:10:43 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Johan Hovold <johan+linaro@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Stanimir Varbanov <svarbanov@...sol.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-pci@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/10] PCI: qcom: Add support for SC8280XP

On Fri, Jul 01, 2022 at 12:29:09PM -0600, Rob Herring wrote:
> On Wed, Jun 29, 2022 at 04:09:56PM +0200, Johan Hovold wrote:
> > The SC8280XP platform has seven PCIe controllers: two used with USB4,
> > two 4-lane, two 2-lane and one 1-lane.
> > 
> > Add a new "qcom,pcie-sc8280xp" compatible string and reuse the 1.9.0
> > ops.
> > 
> > Note that the SC8280XP controllers need two or three interconnect
> > clocks to be enabled. Model these as optional clocks to avoid encoding
> > devicetree data in the PCIe driver.
> 
> Shouldn't the interconnect binding handle these? Probably, bus clocks 
> have to be the biggest single reason why clocks are such a mess in terms 
> of 'the same' block having different clocks.

I fully agree, but I ended up following the current scheme of letting
the driver manage these, partly as I lack documentation for the
interconnect. 

Note that two interconnect clocks were recently included in the SM8450
binding:

	https://lore.kernel.org/all/YcIwcUzYCq1v4Kfs@robh.at.kernel.org/

and that the generically sounding clock names chosen make it tempting to
repurpose them:

	https://lore.kernel.org/all/1656691899-21315-4-git-send-email-quic_krichai@quicinc.com/

which seems like another step backwards.

For MSM8996, it looks like this was instead handled by never disabling
the interconnect clocks: 

	https://lore.kernel.org/all/20171207105922.31986-1-srinivas.kandagatla@linaro.org/

Johan