linux-kernel - Re: [PATCH v6 00/10] Add support for RaspberryPi RP1 PCI device using a DT overlay

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: <CAMEGJJ2FB-wwyOtjjCmPJ-vUDpZaV-8MMXxV13qXnKxYSzt9pw@mail.gmail.com>
Date: Thu, 13 Feb 2025 17:29:47 +0000
From: Phil Elwell <phil@...pberrypi.com>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>, Andrea della Porta <andrea.porta@...e.com>, Arnd Bergmann <arnd@...db.de>, 
	"maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" <bcm-kernel-feedback-list@...adcom.com>, bhelgaas@...gle.com, brgl@...ev.pl, 
	Catalin Marinas <catalin.marinas@....com>, Conor Dooley <conor+dt@...nel.org>, derek.kiernan@....com, 
	devicetree@...r.kernel.org, dragan.cvetic@....com, 
	Florian Fainelli <florian.fainelli@...adcom.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, krzk+dt@...nel.org, kw@...ux.com, 
	Linus Walleij <linus.walleij@...aro.org>, 
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, linux-clk@...r.kernel.org, 
	linux-gpio@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, 
	"open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS" <linux-pci@...r.kernel.org>, 
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" <linux-rpi-kernel@...ts.infradead.org>, lpieralisi@...nel.org, 
	luca.ceresoli@...tlin.com, manivannan.sadhasivam@...aro.org, 
	masahiroy@...nel.org, Michael Turquette <mturquette@...libre.com>, 
	Rob Herring <robh@...nel.org>, saravanak@...gle.com, Stephen Boyd <sboyd@...nel.org>, 
	thomas.petazzoni@...tlin.com, Stefan Wahren <wahrenst@....net>, 
	Will Deacon <will@...nel.org>, Dave Stevenson <dave.stevenson@...pberrypi.com>
Subject: Re: [PATCH v6 00/10] Add support for RaspberryPi RP1 PCI device using
 a DT overlay

Hervé,

On Thu, 13 Feb 2025 at 17:07, Herve Codina <herve.codina@...tlin.com> wrote:
>
> On Thu, 13 Feb 2025 16:30:44 +0000
> Phil Elwell <phil@...pberrypi.com> wrote:
>
> > Hi Andrew,
> >
> > On Thu, 13 Feb 2025 at 16:27, Andrew Lunn <andrew@...n.ch> wrote:
> > >
> > > On Thu, Feb 13, 2025 at 05:14:35PM +0100, Herve Codina wrote:
> > > > Hi Phil,
> > > >
> > > > On Thu, 13 Feb 2025 15:18:45 +0000
> > > > Phil Elwell <phil@...pberrypi.com> 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?
> > >
> > > Where is this button or fan? On a pluggable board? Isn't that what
> > > overlays are for, and they are stackable. So when you probe the
> > > pluggable board via its eeprom etc, you find the overlay and load it?
> >
> > In the Raspberry Pi ecosystem it would be the firmware that applies
> > the overlay, and it can't do that if the resources the overlay refers
> > to are not yet present in the dtb.
>
> What do you mean by the 'the resources are not yet present in the dtb' ?

Consider the fan connector on the Pi 5 PCB. It is wired to GPIO 45 on
RP1. In our current Pi 5 dtb there is an instance of pwm-fan whose
"pwms" property links to rp1_pwm node, which declares a PWM block on
RP1. Similarly, the camera and display ports make use of I2C
interfaces on RP1. The camera and display overlays, applied by the
firmware, have references to those interfaces.

If RP1 is not present in the dtb then neither of those scenarios -
board features and overlays applied the firmware - will work because
the necessary nodes and symbols are not present until the kernel has
started running, at which point dtb has been handed over.

> Also what you call the 'firmware' is the bootloader ? the kernel ?
> Can you tell me who is the 'firmware' what is the mecanisme it uses to
> load the overlay.

In the case of the Pi 5, the firmware is an EEPROM image containing
code run by the VPU embedded processor. It can load overlays using the
same mechanisms it uses to load the kernel - SD/EMMC, NVME, USB, TFTP,
etc. The same problem would exist for U-boot. Even though RP1 has a
standard XHCI controller, U-boot wouldn't be able to detect it and
make use of it, say to load a kernel from a USB stick, because it
isn't declared in the DTB.

Phil