Re: [PATCH] regulator: Let raspberrypi drivers depend on ARM

[Jean Delvare <jdelvare@suse.de>]

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