linux-kernel - Re: [PATCH 06/12] clk: sunxi=ng: add support for R329 CCUs

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

Date:   Tue, 12 Jul 2022 20:16:49 +0800
From:   Icenowy Zheng <uwu@...nowy.me>
To:     Samuel Holland <samuel@...lland.org>
Cc:     Rob Herring <robh+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Andre Przywara <andre.przywara@....com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/12] clk: sunxi=ng: add support for R329 CCUs

在 2022-07-12星期二的 19:57 +0800，Icenowy Zheng写道：
> 在 2022-04-23星期六的 21:12 -0500，Samuel Holland写道：
> > On 4/22/22 10:41 AM, icenowy@...look.com wrote:
> > > From: Icenowy Zheng <icenowy@...c.io>
> > > 
> > > Allwinner R329 has two CCUs, one in CPUX and another in PRCM.
> > > 
> > > Add support for them.
> > > 
> > > Signed-off-by: Icenowy Zheng <icenowy@...c.io>
> > 
> > There is a typo in your commit title. = should be -.
> > 
> > Thanks for updating the driver to use .fw_name and be loadable as a
> > module. All
> > of those changes look good.
> > 
> > There are still some missing clocks here compared to the BSP, and a
> > couple of
> > other minor issues. Please see my earlier review:
> > 
> > https://lore.kernel.org/linux-sunxi/99a74950-fdc0-ecfe-e5f0-ba4a7d8751f0@sholland.org/
> > 
> > So far it's been consistent that any settable bits in the CCU
> > registers actually
> > do something. So I would expect all of those bits to have an index
> > reserved in
> > the binding, even if we do not model them. I want to avoid having
> > to
> 
> Sorry but I don't think it proper to reserve unclear bits, because
> we're just allocating the numbers as a random sequence (in fact it's
> the sequence that it gets implemented).
> 
> Or consider a structural number scheme, in which a value can be
> uniquely predicted by its name?

Well by thinking a little further, I realized our current CCU DT
binding is just based on implementation details of sunxi-ng drivers
(for example, some intermediate clocks get a number too, just not
exposed to the DT binding header). This continues to prove that
reserving numbers is just needed at all, and the current way to make
CCU DT bindings might be totally wrong.

Maybe we should start to use reasonable slice numbers in the next CCU
driver?

> 
> > go back and
> > add gates to the binding out-of-order later, like we are doing for
> > H6.
> > 
> > Regards,
> > Samuel
> 
> 
>