Hi Phil, On Thu, 13 Feb 2025 15:18:45 +0000 Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote: > Hi Andrea, > > The problem with this approach (loading an overlay from the RP1 PCIe > driver), and it's one that I have raised with you offline, is that > (unless anyone can prove otherwise) it becomes impossible to create a > Pi 5 DTS file which makes use of the RP1's resources. How do you > declare something as simple as a button wired to an RP1 GPIO, or fan > connected to a PWM output? The driver could be improved in a second step. For instance, it could load the dtbo from user-space using request_firmare() instead of loading the embedded dtbo. > > If this is the preferred route to upstream adoption, I would prefer it > if rp1.dtso could be split in two - an rp1.dtsi similar to what we > have downstream, and an rp1.dtso that #includes it. In this way we can > keep the patching and duplication to a minimum. Indeed, having a rp1.dtsi avoid duplication but how the rp1.dtso in the the kernel sources could include user customization (button, fan, ...) without being modified ? At least we have to '#include <my_rp1_customizations.dtsi>'. Requesting the dtbo from user-space allows to let the user to create its own dtso without the need to modify the one in kernel sources. Does it make sense ? Best regards, Hervé
