linux-kernel - Re: [PATCH v2 01/16] dt-bindings: clock: at91: Split up per SoC partially

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: <20250217-shortwave-scoreless-38cb49fe5548@thorsis.com>
Date: Mon, 17 Feb 2025 10:47:48 +0100
From: Alexander Dahl <ada@...rsis.com>
To: Claudiu Beznea <claudiu.beznea@...on.dev>
Cc: Alexander Dahl <ada@...rsis.com>,
	Nicolas Ferre <nicolas.ferre@...rochip.com>,
	Ryan Wanner <ryan.wanner@...rochip.com>,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>
Subject: Re: [PATCH v2 01/16] dt-bindings: clock: at91: Split up per SoC
 partially

Hello Claudiu,

Am Mon, Feb 17, 2025 at 11:11:44AM +0200 schrieb Claudiu Beznea:
> Hi, Alexander,
> 
> On 10.02.2025 18:44, Alexander Dahl wrote:
> > Before adding even more new indexes creating more holes in the
> > clk at91 drivers pmc_data->chws arrays, split this up.
> > 
> > This is a partial split up only for SoCs affected by upcoming changes
> > and by that PMC_MAIN + x hack, others could follow by the same scheme.
> > 
> > Binding splitup was proposed for several reasons:
> > 
> > 1) keep the driver code simple, readable, and efficient
> > 2) avoid accidental array index duplication
> > 3) avoid memory waste by creating more and more unused array members.
> > 
> > Old values are kept to not break dts, and to maintain dt ABI.
> > 
> > Link: https://lore.kernel.org/linux-devicetree/20250207-jailbird-circus-bcc04ee90e05@thorsis.com/T/#u
> > Signed-off-by: Alexander Dahl <ada@...rsis.com>
> > ---
> > 
> > Notes:
> >     v2:
> >     - new patch, not present in v1
> > 
> >  .../dt-bindings/clock/microchip,sam9x60-pmc.h | 19 +++++++++++
> >  .../dt-bindings/clock/microchip,sam9x7-pmc.h  | 25 +++++++++++++++
> >  .../clock/microchip,sama7d65-pmc.h            | 32 +++++++++++++++++++
> >  .../dt-bindings/clock/microchip,sama7g5-pmc.h | 24 ++++++++++++++
> >  4 files changed, 100 insertions(+)
> >  create mode 100644 include/dt-bindings/clock/microchip,sam9x60-pmc.h
> >  create mode 100644 include/dt-bindings/clock/microchip,sam9x7-pmc.h
> >  create mode 100644 include/dt-bindings/clock/microchip,sama7d65-pmc.h
> >  create mode 100644 include/dt-bindings/clock/microchip,sama7g5-pmc.h
> > 
> 
> [ ...]
> 
> > diff --git a/include/dt-bindings/clock/microchip,sama7g5-pmc.h b/include/dt-bindings/clock/microchip,sama7g5-pmc.h
> > new file mode 100644
> > index 0000000000000..ad69ccdf9dc78
> > --- /dev/null
> > +++ b/include/dt-bindings/clock/microchip,sama7g5-pmc.h
> > @@ -0,0 +1,24 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
> > +/*
> > + * The constants defined in this header are being used in dts and in
> > + * at91 sama7g5 clock driver.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_CLOCK_MICROCHIP_SAMA7G5_PMC_H
> > +#define _DT_BINDINGS_CLOCK_MICROCHIP_SAMA7G5_PMC_H
> > +
> > +#include <dt-bindings/clock/at91.h>
> > +
> > +/* old from before bindings splitup */
> > +#define SAMA7G5_PMC_MCK0	PMC_MCK		/* 1 */
> > +#define SAMA7G5_PMC_UTMI	PMC_UTMI	/* 2 */
> > +#define SAMA7G5_PMC_MAIN	PMC_MAIN	/* 3 */
> > +#define SAMA7G5_PMC_CPUPLL	PMC_CPUPLL	/* 4 */
> > +#define SAMA7G5_PMC_SYSPLL	PMC_SYSPLL	/* 5 */
> > +
> > +#define SAMA7G5_PMC_AUDIOPMCPLL	PMC_AUDIOPMCPLL	/* 9 */
> > +#define SAMA7G5_PMC_AUDIOIOPLL	PMC_AUDIOIOPLL	/* 10 */
> > +
> > +#define SAMA7G5_PMC_MCK1	PMC_MCK1	/* 13 */
> > +
> > +#endif
> 
> I would have expected this to be something like:
> 
> #ifndef __DT_BINDINGS_CLOCK_MICROCHIP_SAMA7G5_PMC_H__
> #define __DT_BINDINGS_CLOCK_MICROCHIP_SAMA7G5_PMC_H__
> 
> /* Core clocks. */
> #define SAMA7G5_MCK0			1
> #define SAMA7G5_UTMI			2
> #define SAMA7G5_MAIN			3
> #define SAMA7G5_CPUPLL			4
> #define SAMA7G5_SYSPLL			5
> #define SAMA7G5_DDRPLL			6
> #define SAMA7G5_IMGPLL			7
> #define SAMA7G5_BAUDPLL			8

Okay no reference to the old header, but numbers.  Got that.

I'm not sure where you got the 7 and 8 from here, according to my
analysis, sama7g5 does not use those.

> 
> // ...
> 
> #define SAMA7G5_MCK1			13
> 
> #endif /* __DT_BINDINGS_CLOCK_MICROCHIP_SAMA7G5_PMC_H__ */
> 
> Same for the other affected SoCs.
> 
> The content of include/dt-bindings/clock/at91.h would be limited eventually
> only to the PMC clock types.

What does this mean?  The clocks split out are no PMC clocks?  Then
the old PMC_MAIN etc. definitions were named wrong?  All or only some
of them?  Or is this different between older and newer SoC variants of
the at91 family?

>From a quick glance in the SAM9X60 datasheet for example the clock
generator provides MD_SLCK, TD_SLCK, MAINCK, and PLL clocks, while the
PMC provides MCK, USB clocks, GCLK, PCK, and the peripheral clocks.

The chws array in drivers/clk/at91/sam9x60.c however gets main_rc_osc
(from clock generator), mainck (clock generator), pllack (clock
generator), upllck (clock generator, UTMI), but also mck (from PMC).

This creates the impression things are mixed up here.  I find all this
quite confusing to be honest.

> The other "#define PMC_*" defines will eventually go to SoC specific
> bindings. "#define AT91_PMC_*" seems to not belong here anyway and these
> would in the end removed, as well.

Okay, you seem to have an idea how this should look like in the long
run.  Are there any plans at Microchip or at91 clock maintainer side
to clean this up in the near future?

I would like to rather put my small changes for otpc on top of a clean
tree, instead of trying to clean up clock drivers and bindings for a
whole family of SoCs and boards, where I can test only one of them.
O:-)

Greets
Alex