On Tue, Jun 11, 2024 at 09:05:24PM +0200, Stefan Wahren wrote: > Hi Andrea, > > i added Jeremy, because AFAIK he was deeply involved in ACPI > implementation of the RPi 4. > > Am 11.06.24 um 17:39 schrieb Andrea della Porta: > > Hi, > > I'm on the verge of reworking the RP1 driver from downstream in order for it to be > > in good shape for upstream inclusion. > > RP1 is an MFD chipset that acts as a south-bridge PCIe endpoint sporting a pletora > > of subdevices (i.e. Ethernet, USB host controller, I2C, PWM, etc.) whose registers > > are all reachable starting from an offset from the BAR address. > > The main point here is that while the RP1 as an endpoint itself is discoverable via > > usual PCI enumeraiton, the devices it contains are not discoverable and must be > > declared e.g. via the devicetree. This is an RFC about the correct approach to use > > in integrating the driver and registering the subdevices. > > > I cannot provide much input into the technical discussion, but i would > prefer an approach which works good with DT and ACPI. There is a small and slowly growing interest in using DT overlays on ACPI systems. It makes a lot of sense when you have an already working set of drivers based on DT, and then need to make them work on ACPI systems. The Microchip LAN996x is an ARM SoC with lots of peripherals and an Ethernet switch. There is a full DT description of it and drivers. However, it also has a PCIe interface which allows access to all the peripherals and the Ethernet switch. Bootlin are adding patches to allow any host with a PCIe bus use all the existing drivers and a DT overlay to glue it all together. https://patchwork.kernel.org/project/linux-pci/cover/20240527161450.326615-1-herve.codina@xxxxxxxxxxx/ ACPI and DT should not be considered mutually exclusive. Andrew
