Message-ID: <CAMuHMdXsrDLRLbPdHaHT-+Z8BxMGUSuA5fUCPvKwtbjrWDZD2A@mail.gmail.com>
Date: Mon, 15 Dec 2025 13:36:57 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Jean Delvare <jdelvare@...e.de>
Cc: Dave Stevenson <dave.stevenson@...pberrypi.com>, Marek Vasut <marex@...x.de>, 
	Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, 
	LKML <linux-kernel@...r.kernel.org>, Marek Vasut <marek.vasut@...lbox.org>
Subject: Re: [PATCH] regulator: Let raspberrypi drivers depend on ARM

Hi Jean,

Thanks for your patch, which is now commit 01313661b248c5ba
("regulator: Let raspberrypi drivers depend on ARM") in v6.19-rc1.

On Thu, 30 Oct 2025 at 13:33, Jean Delvare <jdelvare@...e.de> wrote:
> On Thu, 2025-10-30 at 11:09 +0000, Dave Stevenson wrote:
> > On Mon, 27 Oct 2025 at 12:22, Jean Delvare <jdelvare@...e.de> wrote:
> > > The Raspberry Pi drivers aren't useful on other architectures, so
> > > only offer them on ARM and ARM64, except for build testing purposes.
> > >
> > > Signed-off-by: Jean Delvare <jdelvare@...e.de>
> > > ---
> > > Marek, Dave, would you be OK with that change?
> >
> > These regulator drivers are for a MIPI DSI display, so they can work
> > with any platform that has a DSI interface. Currently that is mainly
> > ARM/ARM64 SoC, but there's nothing stopping RISC-V or x86 having a DSI
> > interface.
> >
> > Checking and [1] says the Intel Alder Lake 12th gen processors support
> > DSI, although presumably that would also then need ACPI support in the
> > driver.
> > [2] says the OrangePi RV2 is a RISC-V board with DSI interface, and
> > there is at least basic support for the board in mainline, although
> > not obviously the DSI block.
> >
> > Personally I see little point in reducing the scope to just ARM/ARM64
> > as it may well need to be extended again.
>
> I personally see no problem with extending the scope as new hardware is
> released. I think it's much better than building drivers on
> architectures where they aren't needed.
>
> > What's your reasoning for
> > saying they aren't useful on other architectures?
>
> My reasoning was that the config symbol names have RASPBERRYPI, and
> their labels start with "Raspberry Pi". So I concluded that these
> drivers were only useful on Raspberry Pi.

The names reflect the branding of these devices.  They do not mean
that these are drivers for components on actual Raspberry Pi SBCs with
Broadcom ARM/ARM64 SoCs.  The same is true for the various "Raspberry
Pi camera modules", which work with anything that has CSI.

> If the use of these drivers is not restricted to Raspberry Pi hardware,
> then I agree that binding these options to a specific architecture
> isn't right. But then these config options should be renamed and
> relabeled to properly describe what interfaces and devices they
> actually relate to.

Looking at the users of "raspberrypi,7inch-touchscreen-panel-regulator"
and "raspberrypi,touchscreen-panel-regulator-v2":

    $ git grep -l "raspberrypi,.*touchscreen-panel-regulator" -- "*dts*"
    arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x-rpidsi.dtso
    arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x-rpidsi.dtso
    arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx-rpidsi.dtso
    arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-rpi-display-2.dtsi

I see nothing Raspberry Pi SBC-specific in the microcontroller interface
these are regulator drivers for.   With the right DTS glue, these panels
can be made to work on anything that has a DSI interface.  In fact
none of the upstream users listed above are related to Raspberry
Pi SBCs.

> As a side note, I'm surprised that these options get to be selected
> independently from the touchscreen driver for the same hardware.
> Presumably driving the regulator is only meaningful if the touchscreen
> driver is also built and loaded?

Only one of the DTS users above describe the touchscreen?

> To give you some context, the problem I am trying to address is that
> with every new kernel version, all distribution kernel maintainers out
> there need to make decisions on which drivers to include on every
> supported architecture. Limiting drivers to their intended
> architecture(s) makes this process faster and less error-prone. Which
> in turn avoids wasting resources later on building, and backporting
> security fixes to, drivers which aren't actually used.

Usually I am the first to add a platform dependency on a symbol that
can be used only on a single platform ;-)  But in this case, I think
they should be enabled on all architectures that can have DSI (and I2C,
which is implied by DSI, IIRC).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists