linux-kernel - Re: [PATCH 0/4] Refactor the PRCI driver to reduce the complexity

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>] [day] [month] [year] [list]

Message-ID: <CANXhq0qbjBpRPMP51cK9QsvQj-uvG_czPgLw+cjrWXhWEibcDw@mail.gmail.com>
Date:   Wed, 23 Feb 2022 15:33:24 +0800
From:   Zong Li <zong.li@...ive.com>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Palmer Dabbelt <palmer@...belt.com>,
        Michael Turquette <mturquette@...libre.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Lee Jones <lee.jones@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
        <devicetree@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] Refactor the PRCI driver to reduce the complexity

On Sat, Feb 19, 2022 at 6:23 AM Stephen Boyd <sboyd@...nel.org> wrote:
>
> Quoting Zong Li (2022-02-06 21:21:50)
> > On Sat, Feb 5, 2022 at 2:56 AM Palmer Dabbelt <palmer@...belt.com> wrote:
> > >
> > > On Wed, 19 Jan 2022 01:28:37 PST (-0800), zong.li@...ive.com wrote:
> > > > This patch set tries to improve the PRCI driver to reduce the
> > > > complexity, we remove the SoCs C files by putting putting all stuff in
> > > > each SoCs header file, and include these SoCs-specific header files in
> > > > core of PRCI. It can also avoid the W=1 kernel build warnings about
> > > > variable defined but not used [-Wunused-const-variable=], like 'commit
> > > > 487dc7bb6a0c ("clk: sifive:fu540-prci: Declare static const variable
> > > > 'prci_clk_fu540' where it's used")' does.
> > > >
> > > > This patch set also contains the dt-bindings and dts change, because
> > > > we change the macro name for fu540 and fu740 by adding the prefix
> > > > respectively.
> > > >
> > > > Thanks all for your review and suggestions.
> > > >
> > > > Zong Li (4):
> > > >   dt-bindings: change the macro name of prci in header files and example
> > > >   riscv: dts: Change the macro name of prci in each device node
> > > >   clk: sifive: Add SoCs prefix in each SoCs-dependent data
> > >
> > > IIUC these there aren't bisectable: the bindings change will break
> > > builds of the DTs and drivers.  I'm not sure what's generally the way to
> > > go with these, but I always try to avoid broken builds in the middle of
> > > patch sets.
> > >
> > > Aside from that this generally looks good to me, but the DT and clock
> > > folks are probably a better bet for a proper review here.  Happy to take
> > > this through the RISC-V tree, but IMO it's a better candidate for the
> > > clock tree so
> > >
> > > Acked-by: Palmer Dabbelt <palmer@...osinc.com> # aside from breaking bisect
> > >
> > > Thanks!
> > >
> >
> > Many thanks for your review and reminding, and yes, it seems a bit
> > hard there since the DT binding docs and includes need to be a
> > separate patch.
> >
>
> Why not add new defines with the same numbers in a different file? Then
> a cycle or two later the conflicting defines can be removed? The driver
> can include the new file with the new defines while the old defines can
> be changed in parallel?

Hi Stephon, many thanks for your tips. I'm afraid that I don't
completely understand, does it mean that I can create a new temporary
file to define these numbers for the driver, and add a patch to remove
this file in the same patch set. If I understand correctly, let me
prepare the next version for doing that. Thanks.