linux-kernel - Re: [PATCH v9 -next 08/12] arm64: dts: bcm2712: Add external clock for RP1 chipset on Rpi5

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: <aDYthG54Wz3khQ88@apocalypse>
Date: Tue, 27 May 2025 23:24:20 +0200
From: Andrea della Porta <andrea.porta@...e.com>
To: Florian Fainelli <florian.fainelli@...adcom.com>
Cc: Matthias Brugger <mbrugger@...e.com>,
	Andrea della Porta <andrea.porta@...e.com>,
	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>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczynski <kw@...ux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Bartosz Golaszewski <brgl@...ev.pl>,
	Derek Kiernan <derek.kiernan@....com>,
	Dragan Cvetic <dragan.cvetic@....com>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Saravana Kannan <saravanak@...gle.com>, linux-clk@...r.kernel.org,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-gpio@...r.kernel.org, Masahiro Yamada <masahiroy@...nel.org>,
	Stefan Wahren <wahrenst@....net>,
	Herve Codina <herve.codina@...tlin.com>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	Andrew Lunn <andrew@...n.ch>, Phil Elwell <phil@...pberrypi.com>,
	Dave Stevenson <dave.stevenson@...pberrypi.com>,
	kernel-list@...pberrypi.com
Subject: Re: [PATCH v9 -next 08/12] arm64: dts: bcm2712: Add external clock
 for RP1 chipset on Rpi5

Hi Florian,

On 09:18 Tue 27 May     , Florian Fainelli wrote:
> On 5/26/25 07:06, Matthias Brugger wrote:
> > 
> > 
> > On 12/05/2025 18:42, Andrea della Porta wrote:
> > > Hi Florian,
> > > 
> > > On 15:02 Mon 12 May     , Florian Fainelli wrote:
> > > > On May 7, 2025 5:01:05 PM GMT+02:00, Andrea della Porta
> > > > <andrea.porta@...e.com> wrote:
> > > > > Hi Florian, to accept the patches, what would work best for you?
> > > > > 
> > > > > 1) Send only the relevant updated patches (maybe as an entirely new
> > > > > patchset with
> > > > >    only those specific patches)
> > > > 
> > > > Only the updated patches work for me. I don't think there is
> > > > that much coupling between the DT changes and the non-DT changes
> > > > (other than without DT entries nothing is activated)
> > > 
> > > It's a little bit more involved than that:
> > > 
> > > - Patch 7 (misc driver) depends on 6 (RP1 common dts) which in turn
> > >    depends on 1 (clock binding header). Should be taken by Greg.
> > 
> > Greg gave an Acked-by so I think Florian is good to take that patch.
> > Which leaves us to the clock patches (driver + dt-bindings).
> > 
> > > 
> > > - Patch 9 and 10 (board dts) depends on 6 (RP1 common dts) which again
> > >    depends on 1 (clock binding header). Should be taken by Florian.
> > > 
> > > - Patch 4 (clock driver) depends on 1 (clock binding header) and
> > >    should be taken by Stephen.
> > > 
> > 
> > Steven reviewed the patches (driver + dt-binding) so he is waiting for a
> > new version which addresses the review. He offered to either take them
> > and provide a branch that Florian can merge into his branch or provide a
> > Acked-by tag.
> > 
> > @Florian what would you prefer?
> 
> I am fine either way, it's definitively simpler if I can take all of the
> patches in the respective Broadcom ARM SoC branches, but pulling a branch
> from another maintainer's tree works just as well.
> 
> Andrea, sorry to ask you this, can you post a v10 and we aim to get that
> version applied?

No problem, just to avoid any confusion I'll summarize what-goes-where with
respect to branches in your repo broadcom/stblinux, so I can adapt each patch
to the relevant branch:

- dt-binding/DTS (patch 1,2,3,6,8,9,10) -> devicetree/next
- defconfig (patch 11,12) -> defconfig/next
- drivers (patch 4,5,7) -> drivers/next or soc/next?

Also, should I split any patches that have MAINTAINERS changes so you can apply
them to your maintainers/next branch? Those are patches 4,5,6,7.

Many thanks,
Andrea

> Thanks!
> -- 
> Florian