linux-kernel - Re: [PATCH V3 3/3] mailbox: qcom-apcs: Add SM6125 compatible

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: <YNEiUMBqGAx1zLVX@yoga>
Date:   Mon, 21 Jun 2021 18:35:44 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Jassi Brar <jassisinghbrar@...il.com>,
        Martin Botka <martin.botka@...ainline.org>,
        ~postmarketos/upstreaming@...ts.sr.ht,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        jamipkettunen@...ainline.org, Andy Gross <agross@...nel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V3 3/3] mailbox: qcom-apcs: Add SM6125 compatible

On Mon 21 Jun 18:19 CDT 2021, Rob Herring wrote:

> On Mon, Jun 21, 2021 at 5:10 PM Jassi Brar <jassisinghbrar@...il.com> wrote:
> >
> > On Mon, Jun 21, 2021 at 2:46 PM Rob Herring <robh+dt@...nel.org> wrote:
> > >
> > > On Sun, Jun 20, 2021 at 10:03 PM Jassi Brar <jassisinghbrar@...il.com> wrote:
> > > >
> > > > On Sat, Jun 12, 2021 at 4:46 AM Martin Botka
> > > > <martin.botka@...ainline.org> wrote:
> > > > >
> > > > > This commit adds compatible for the SM6125 SoC
> > > > >
> > > > > Signed-off-by: Martin Botka <martin.botka@...ainline.org>
> > > > > ---
> > > > > Changes in V2:
> > > > > None
> > > > > Changes in V3:
> > > > > Change compatible to apcs-hmss-global
> > > > >  drivers/mailbox/qcom-apcs-ipc-mailbox.c | 5 +++++
> > > > >  1 file changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> > > > > index f25324d03842..f24c5ad8d658 100644
> > > > > --- a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> > > > > +++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> > > > > @@ -57,6 +57,10 @@ static const struct qcom_apcs_ipc_data sdm660_apcs_data = {
> > > > >         .offset = 8, .clk_name = NULL
> > > > >  };
> > > > >
> > > > > +static const struct qcom_apcs_ipc_data sm6125_apcs_data = {
> > > > > +       .offset = 8, .clk_name = NULL
> > > > > +};
> > > > > +
> > > > >  static const struct qcom_apcs_ipc_data apps_shared_apcs_data = {
> > > > >         .offset = 12, .clk_name = NULL
> > > > >  };
> > > > > @@ -166,6 +170,7 @@ static const struct of_device_id qcom_apcs_ipc_of_match[] = {
> > > > >         { .compatible = "qcom,sc8180x-apss-shared", .data = &apps_shared_apcs_data },
> > > > >         { .compatible = "qcom,sdm660-apcs-hmss-global", .data = &sdm660_apcs_data },
> > > > >         { .compatible = "qcom,sdm845-apss-shared", .data = &apps_shared_apcs_data },
> > > > > +       { .compatible = "qcom,sm6125-apcs-hmss-global", .data = &sm6125_apcs_data },
> > > > >         { .compatible = "qcom,sm8150-apss-shared", .data = &apps_shared_apcs_data },
> > > > >         { .compatible = "qcom,sdx55-apcs-gcc", .data = &sdx55_apcs_data },
> > > > >         {}
> > > > >
> > > > These all are basically different names for the same controller.
> > > > The 'offset' is a configuration parameter and the 'clock', when NULL,
> > > > is basically some "always-on" clock.
> > > > I am sure we wouldn't be doing it, if the controller was third-party.
> > >
> > > If newer implementations are 'the same', then they should have a
> > > fallback compatible to the existing one that is the same and no driver
> > > change is needed. If the differences are board or instance (within an
> > > SoC) specific, then a DT property would be appropriate.
> > >
> > The controllers (13 now) only differ by the 'offset' where the
> > registers are mapped. Clock-name is a pure s/w artifact.
> > So, maybe we could push all these in DT.
> 
> Why is 'reg' not used for the offset?
> 

The DT node and its "reg" describes the whole IP block.

The particular register that we care of has, as you can see, moved
around during the various platforms and some incarnations of this IP
block provides controls for CPU-related clocks as well.

We can certainly have the multiple compatible points to the same
apcs_data, but I'm not able to spot a reasonable "catch-all compatible"
given that I don't see any natural groupings.

> In any case, we can't really get rid of the first 13 instances though...
> 

Right, we have the problem that we have DTBs out there that relies on
these compatibles, but as Jassi requests we'd have to start describing
the internal register layout in DT - which this binding purposefully
avoids.

Regards,
Bjorn