linux-kernel - Re: Raspberry Pi5 - RP1 driver

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: <73e05c77-6d53-4aae-95ac-415456ff0ae4@lunn.ch>
Date: Tue, 11 Jun 2024 22:12:44 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Stefan Wahren <wahrenst@....net>
Cc: Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Florian Fainelli <florian.fainelli@...adcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
	Dave Ertman <david.m.ertman@...el.com>,
	Lizhi Hou <lizhi.hou@....com>, clement.leger@...tlin.com,
	Jeremy Linton <jeremy.linton@....com>
Subject: Re: Raspberry Pi5 - RP1 driver - RFC

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@bootlin.com/

ACPI and DT should not be considered mutually exclusive.

     Andrew