linux-kernel - Re: [PATCH v5 2/5] dt-bindings: arm: msm: Convert kpss-acc driver Documentation to yaml

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:   Sat, 17 Sep 2022 16:45:21 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Christian Marangi <ansuelsmth@...il.com>
Cc:     Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Takashi Iwai <tiwai@...e.de>,
        Christian Brauner <brauner@...nel.org>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Marc Herbert <marc.herbert@...el.com>,
        James Smart <jsmart2021@...il.com>,
        Justin Tee <justin.tee@...adcom.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH v5 2/5] dt-bindings: arm: msm: Convert kpss-acc driver
 Documentation to yaml

On Sat, 17 Sept 2022 at 00:54, Christian Marangi <ansuelsmth@...il.com> wrote:
>
> On Fri, Sep 16, 2022 at 11:31:49PM +0300, Dmitry Baryshkov wrote:
> > On Fri, 16 Sept 2022 at 23:27, Christian Marangi <ansuelsmth@...il.com> wrote:
> > >
> > > On Fri, Sep 16, 2022 at 11:22:17PM +0300, Dmitry Baryshkov wrote:
> > > > On Fri, 16 Sept 2022 at 23:13, Christian Marangi <ansuelsmth@...il.com> wrote:
> > > > >
> > > > > On Fri, Sep 16, 2022 at 11:06:35PM +0300, Dmitry Baryshkov wrote:
> > > > > > On Fri, 16 Sept 2022 at 22:43, Christian Marangi <ansuelsmth@...il.com> wrote:
> > > > > > >
> > > > > > > On Fri, Sep 16, 2022 at 02:17:15PM -0500, Rob Herring wrote:
> > > > > > > > On Wed, Sep 14, 2022 at 04:22:53PM +0200, Christian Marangi wrote:
> > > > > > > > > Convert kpss-acc driver Documentation to yaml.
> > > > > > > > > The original Documentation was wrong all along. Fix it while we are
> > > > > > > > > converting it.
> > > > > > > > > The example was wrong as kpss-acc-v2 should only expose the regs but we
> > > > > > > > > don't have any driver that expose additional clocks. The kpss-acc driver
> > > > > > > > > is only specific to v1. For this exact reason, limit all the additional
> > > > > > > > > bindings (clocks, clock-names, clock-output-names and #clock-cells) to
> > > > > > > > > v1 and also flag that these bindings should NOT be used for v2.
> > > > > > > >
> > > > > > > > Odd that a clock controller has no clocks, but okay.
> > > > > > > >
> > > > > > >
> > > > > > > As said in the commit v2 is only used for regs. v2 it's only used in
> > > > > > > arch/arm/mach-qcom/platsmp.c to setup stuff cpu hotplug and bringup.
> > > > > > >
> > > > > > > Should we split the 2 driver? To me the acc naming seems to be just
> > > > > > > recycled for v2 and it's not really a clk controller.
> > > > > > >
> > > > > > > So keeping v2 in arm/msm/qcom,kpss-acc-v2.yaml and v1 moved to clock?
> > > > > >
> > > > > > I suspect that qcom,kpss-acc-v2 is misnamed as the "clock-controller".
> > > > > > According to msm-3.10, these regions are used by the Krait core
> > > > > > regulators.
> > > > > >
> > > > >
> > > > > Well we need to understand how to handle this... change the compatible
> > > > > it's a nono for sure. In platsmp.c they are used for cpu power control
> > > > > so could be that they are actually used to regulators. I would honestly
> > > > > move v1 to clock and leave v2 to arm/msm but I'm not cetain on what name
> > > > > to assign to the 2 yaml.
> > > > >
> > > > > What do you think?
> > > >
> > > > This is fine for me. If somebody gets better understanding of
> > > > underlying hardware and works on actually using these blocks, he will
> > > > update the bindings.
> > > >
> > > > My only suggestion would be to rename kpss-acc-v2 nodes to
> > > > 'power-controller@...ress' and document them so.
> > > >
> > >
> > > Ok so something like this?
> > >
> > >     power-controller@...88000 {
> > >       compatible = "qcom,kpss-acc-v2";
> > >       reg = <0xf9088000 0x1000>,
> > >             <0xf9008000 0x1000>;
> > >     };
> > >
> > > (and I will have to fix dtbs warning as they will be unmatched I think.)
> > > Yaml naming:
> > > qcom,kpss-acc-v1.yaml
> > > qcom,kpss-acc-v2.yaml
> > > Right?
> >
> > Sounds good to me.
> >
> > I'd even say clock/qcom,kpss-acc-v1.yaml and
> > arm/msm/qcom,kpss-acc-v2.yaml or maybe power/qcom,kpss-acc-v2.yaml
> >
>
> Wonder if the gcc driver should have the same tretement? It's also a
> clock-controller driver that doesn't use clock at all... Do you have
> some info about it?

As far as I understand, the kpss-gcc is a normal clock controller,
isn't it? It provides clocks to other devices.

-- 
With best wishes
Dmitry