| Message ID | 38514415df9c174be49e72b88410d56c8de586c5.1745347417.git.andrea.porta@suse.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add support for RaspberryPi RP1 PCI device using a DT overlay | expand |
Hi Florian On 09:32 Wed 07 May , Florian Fainelli wrote: > > > On 5/6/2025 10:49 PM, Andrea della Porta wrote: > > Hi Florian, > > > > On 20:53 Tue 22 Apr , Andrea della Porta wrote: > > > The RP1 found on Raspberry Pi 5 board needs an external crystal at 50MHz. > > > Add clk_rp1_xosc node to provide that. > > > > > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > > > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> > > > > A gentle reminder for patches 8 through 12 of this series, which I guess > > would ideally be taken by you. Since the merge window is approaching, do > > you think it's feasible to iterate a second pull request to Arnd with my > > patches too? > > > > With respect to your devicetree/next branch, my patches have the following > > conflicts: > > > > PATCH 9: > > - arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts: &pcie1 and &pcie2 > > reference at the end, my patch was rebased on linux-next which has them > > while your devicetree branch has not. This is trivial to fix too. > > > > PATCH 9 and 10: > > - arch/arm64/boot/dts/broadcom/Makefile on your branch has a line recently > > added by Stefan's latest patch for RPi2. The fix is trivial. > > > > PATCH 11 and 12: > > - arch/arm64/configs/defconfig: just a couple of fuzz lines. > > > > Please let me know if I should resend those patches adjusted for your tree. > > Yes please resend them today or tomorrow so I can send them the following > day. Thanks Sorry, what's the best wasy to provide the updated patch 8 to 12 to you? 1) Resend the entire patchset (V10) with relevant patches updated 2) Send only updated patches 8 through 12 (maybe as an entirely new patchset with only those specific patches) 3) Asking you to pull teh relevant commit from my own git repo Many thanks, Andrea > -- > Florian >
On May 8, 2025 11:11:14 PM GMT+02:00, Andrea della Porta <andrea.porta@suse.com> wrote: >Hi Florian, > >On 19:10 Wed 07 May , Florian Fainelli wrote: >> >> >> On 5/7/2025 4:13 PM, 'Andrea della Porta' via BCM-KERNEL-FEEDBACK-LIST,PDL >> wrote: >> > Hi Florian >> > >> > On 09:32 Wed 07 May , Florian Fainelli wrote: >> > > >> > > >> > > On 5/6/2025 10:49 PM, Andrea della Porta wrote: >> > > > Hi Florian, >> > > > >> > > > On 20:53 Tue 22 Apr , Andrea della Porta wrote: >> > > > > The RP1 found on Raspberry Pi 5 board needs an external crystal at 50MHz. >> > > > > Add clk_rp1_xosc node to provide that. >> > > > > >> > > > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> >> > > > > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> >> > > > >> > > > A gentle reminder for patches 8 through 12 of this series, which I guess >> > > > would ideally be taken by you. Since the merge window is approaching, do >> > > > you think it's feasible to iterate a second pull request to Arnd with my >> > > > patches too? >> > > > >> > > > With respect to your devicetree/next branch, my patches have the following >> > > > conflicts: >> > > > >> > > > PATCH 9: >> > > > - arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts: &pcie1 and &pcie2 >> > > > reference at the end, my patch was rebased on linux-next which has them >> > > > while your devicetree branch has not. This is trivial to fix too. >> > > > >> > > > PATCH 9 and 10: >> > > > - arch/arm64/boot/dts/broadcom/Makefile on your branch has a line recently >> > > > added by Stefan's latest patch for RPi2. The fix is trivial. >> > > > >> > > > PATCH 11 and 12: >> > > > - arch/arm64/configs/defconfig: just a couple of fuzz lines. >> > > > >> > > > Please let me know if I should resend those patches adjusted for your tree. >> > > >> > > Yes please resend them today or tomorrow so I can send them the following >> > > day. Thanks >> > >> > Sorry, what's the best wasy to provide the updated patch 8 to 12 to you? >> > >> > 1) Resend the entire patchset (V10) with relevant patches updated >> > 2) Send only updated patches 8 through 12 (maybe as an entirely new patchset with >> > only those specific patches) >> >> Either of those two options would work. Maybe let's do option 2) in the >> interest of keeping the traffic low for people. > >Could you please take a look at this: > >https://lore.kernel.org/all/aBxtyvI3LUaM3P00@apocalypse/#t > >besides patches 8 through 12, would you like to take also binding patches + clock >driver (patches 1 to 4, if Linux Walleij is not willing to take patch 2 himself), >and maybe also misc driver and its dts (patches 6 and 7 unless Greg has different >ideas)? I know this is almost the entire patchset, but it's getting hard to escape >the dependency maze. >I'm open to any alternative solutions, more details in the link above. If I am taking the whole patchset I would need maintainers to provide the adequate tags. I would prefer to only take the DT changes, with an understanding that drivers wouldn't be active unless the relevant DT entries are present as well. I am out of the office until the end of this week, so there may be some delay (more than usual) with my responses. Florian
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@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. - 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. 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
diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts index 34470e3d7171..6ea3c102e0d6 100644 --- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts +++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts @@ -16,6 +16,13 @@ chosen: chosen { stdout-path = "serial10:115200n8"; }; + clk_rp1_xosc: clock-50000000 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-output-names = "rp1-xosc"; + clock-frequency = <50000000>; + }; + /* Will be filled by the bootloader */ memory@0 { device_type = "memory";