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

Matthias Brugger mbrugger at suse.com
Mon May 26 07:06:52 PDT 2025



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 at suse.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?

Regards,
Matthias

> So patches 6 and 1 are in common between Florian and Greg, while patch 1
> is in common between everyone in the pool.
> 
> If I uniquely assign the patches in common to one of you, the others
> won't be able to compile their own branch because they will be missing
> the dependent patch.
> 
> If, on the other hand, I duplicate common patches to each of you to
> make the kernel compile for veryone, you should remember that there
> will be conflicts due to duplicated patches among different trees
> down the merge path.
> 
> Any advice about how to proceed is appreciated.
> 
> Many thanks,
> Andrea
> 
>>
>> Florian




More information about the linux-arm-kernel mailing list