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@suse.de>
---
Marek, Dave, would you be OK with that change?

 drivers/regulator/Kconfig |    2 ++
 1 file changed, 2 insertions(+)

--- linux-6.17.orig/drivers/regulator/Kconfig
+++ linux-6.17/drivers/regulator/Kconfig
@@ -1144,6 +1144,7 @@ config REGULATOR_RAA215300
 
 config REGULATOR_RASPBERRYPI_TOUCHSCREEN_ATTINY
 	tristate "Raspberry Pi 7-inch touchscreen panel ATTINY regulator"
+	depends on ARM || ARM64 || COMPILE_TEST
 	depends on BACKLIGHT_CLASS_DEVICE
 	depends on I2C
 	depends on OF_GPIO
@@ -1155,6 +1156,7 @@ config REGULATOR_RASPBERRYPI_TOUCHSCREEN
 
 config REGULATOR_RASPBERRYPI_TOUCHSCREEN_V2
 	tristate "Raspberry Pi 7-inch touchscreen panel V2 regulator"
+	depends on ARM || ARM64 || COMPILE_TEST
 	depends on GPIOLIB
 	depends on I2C && OF
 	select GPIO_REGMAP


-- 
Jean Delvare
SUSE L3 Support

Hi Jean

Sorry I was out of the office for a few days.

On Mon, 27 Oct 2025 at 12:22, Jean Delvare <jdelvare@suse.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@suse.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. What's your reasoning for
saying they aren't useful on other architectures?

  Dave

[1] https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/010/mipi-dsi/
[2] http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_RV2

>  drivers/regulator/Kconfig |    2 ++
>  1 file changed, 2 insertions(+)
>
> --- linux-6.17.orig/drivers/regulator/Kconfig
> +++ linux-6.17/drivers/regulator/Kconfig
> @@ -1144,6 +1144,7 @@ config REGULATOR_RAA215300
>
>  config REGULATOR_RASPBERRYPI_TOUCHSCREEN_ATTINY
>         tristate "Raspberry Pi 7-inch touchscreen panel ATTINY regulator"
> +       depends on ARM || ARM64 || COMPILE_TEST
>         depends on BACKLIGHT_CLASS_DEVICE
>         depends on I2C
>         depends on OF_GPIO
> @@ -1155,6 +1156,7 @@ config REGULATOR_RASPBERRYPI_TOUCHSCREEN
>
>  config REGULATOR_RASPBERRYPI_TOUCHSCREEN_V2
>         tristate "Raspberry Pi 7-inch touchscreen panel V2 regulator"
> +       depends on ARM || ARM64 || COMPILE_TEST
>         depends on GPIOLIB
>         depends on I2C && OF
>         select GPIO_REGMAP
>
>
> --
> Jean Delvare
> SUSE L3 Support

Hi Dave,

On Thu, 2025-10-30 at 11:09 +0000, Dave Stevenson wrote:
> Sorry I was out of the office for a few days.
> 
> On Mon, 27 Oct 2025 at 12:22, Jean Delvare <jdelvare@suse.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@suse.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.

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.

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?

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.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

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@suse.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@suse.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@suse.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@linux-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

On Mon, 27 Oct 2025 13:22:19 +0100, Jean Delvare wrote:
> The Raspberry Pi drivers aren't useful on other architectures, so
> only offer them on ARM and ARM64, except for build testing purposes.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: Let raspberrypi drivers depend on ARM
      commit: 01313661b248c5ba586acae09bff57077dbec0a5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark