From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B60102D5936 for ; Mon, 15 Dec 2025 12:37:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.217.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765802234; cv=none; b=T+97qa/lQf7uBqdn/mrZrBE4OfVjz6J/VvzZ8AjehrhlxMMRlACPO4oovzkV5eYuQF9KqIiNB81kkVBoCj1dF9sds8y/U0l8iApSTqwXPO/G0aXyukpAIRDIO7YemuRWhbDygpFVXg42x3SeVVuGCbA7T7ZLG53MNWU93XSwGoA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765802234; c=relaxed/simple; bh=cHUCr364lqLe5UGzYcz6PPV9a4w8Az0KH1BENuNCjRw=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=V1haqhwWgirCzcPlbB+b6jd1RHtLSMBjxUvltxuaAuzhBHupH1kpqVD5I26rHf/YLiSAs+F0jD5QueeBrt35Q1rF6O5cWG6lSfXhYChU7aDXfvMHF+T5Ou8yph5p2wZc7VbDN9zqG+J2FYeW03HHY+kwaM5QvAqvyL1j3qvInc0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.217.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-vs1-f44.google.com with SMTP id ada2fe7eead31-5dbddd71c46so1227314137.2 for ; Mon, 15 Dec 2025 04:37:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765802229; x=1766407029; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uJW8n+YjUn91WPb+zS/qX45Q02qfq62gJPUsbMG0DDE=; b=mePOnpO0Lxeit12LTOdN/yU52OL7iPtjfHrxBrxc2Qw7m1DsYRL8LEhk2AqTOvJwcE z/2ocPz9XBobyCTN82uShjSQJmHxzm3Gq1Fx4hoyi9Ka5v7nZDqIlbPlIbH9C6hGSPkS z1MZ4NTe8YUPsLJ053uKE27Pg4UOSBncljTkhURMDp4MKB0DY4p3WxxlH5OYlmnG3t5O UbKZWJJiwdfG+VwnrEiZ010e+x8aoItQsQ3YN0UC6VkwtChtFgSJTlWnlMV0Wox8qaa5 Da7EB1CFsF8mtTjuP4LnRyAzHg6ZZ+3FlEr7zjVOCdm3DUsR2Cpbem/FKcN5uS4wn8ie Btdw== X-Forwarded-Encrypted: i=1; AJvYcCVHr18Xq+RZzTQMkwHT6TM16b5s5YyUuAZ8oiqh1evng8VsyNJolSrSDFvEBMIH3JJno34Bu+UOft+ZbWM=@vger.kernel.org X-Gm-Message-State: AOJu0YyMbysZMg+/acnVjOHvxVkI1zPzCZICdvkQI4F8JtiplaIegyTK O3bi1xozgwa2yM5+/oXcNTdcm2j0xe5WLMiBtx56N6I2GO6zLRwv+n3AzOacwIrgaI0= X-Gm-Gg: AY/fxX6TAylyBhUKrsRwcCzD3drGKw1f28xuyxEVOL6XElhvc68mOwDuA2GRsJVQUnF TiBjD8fHenG5RAuNaHXpag+WEfTfjybpuZx0a14DjaQ+oDsWfr+Fdgv+xp+EebfgBe95pKVOne6 mb0sz5ihBiF5bg5yUNbZDmgnNVS9d1CFTrufJa1J3YSGzWiBEMX1sFX0h0jQSCWqAK+9N+ZAj+Q DQyCAr6k+7aSvztNsD6VxkquOMKb9miSE1OGVrlcFAokGk/jSDMyTxg3ITALXvEYCG2AJeB8EI0 GYj3ruI1qScKbJx5LBSRKDxHVw6rNqdOLXsvQQmYkkESt81RkhlwqI79oEAnkr5BfQ0rKZz03ht z9HIi0udBE78eLJbOkGeWxa/9WvJALj9BeSEg8FmeNsZQcSsGVExE4dK4xwLYi5EntM/0zX+Kjs B2a+0fLhL7D+CiSWNTZTvksUHwnUAiKfFQxxOVjO8HIsC8by8L X-Google-Smtp-Source: AGHT+IH+ORyc5UPQu2MSQfxpR95GwGU4MWMHD8M4ENUdHNSR8+bGQX3knVAI+4KkLqI0cvLXuIrspg== X-Received: by 2002:a05:6102:1627:b0:4e6:a338:a421 with SMTP id ada2fe7eead31-5e827696825mr2760730137.6.1765802229383; Mon, 15 Dec 2025 04:37:09 -0800 (PST) Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com. [209.85.222.48]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-5e7db28a71bsm5916794137.13.2025.12.15.04.37.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Dec 2025 04:37:09 -0800 (PST) Received: by mail-ua1-f48.google.com with SMTP id a1e0cc1a2514c-93723104137so876476241.3 for ; Mon, 15 Dec 2025 04:37:09 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWg5umRlk/TiGgjLFb1RVyxjxifQKUDSCfn29gueNT1rGPNBGuyVtcek+8hAbnd+pQZmjSGkgKyV2soMK0=@vger.kernel.org X-Received: by 2002:a05:6102:3747:b0:5db:f031:84d6 with SMTP id ada2fe7eead31-5e827803cbdmr3560382137.28.1765802228698; Mon, 15 Dec 2025 04:37:08 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251027132219.2f3274f0@endymion> <58bc4e17423beebee358baece311a46b5525b9b0.camel@suse.de> In-Reply-To: <58bc4e17423beebee358baece311a46b5525b9b0.camel@suse.de> From: Geert Uytterhoeven Date: Mon, 15 Dec 2025 13:36:57 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AQt7F2r5xiNO1ybuXScpNVeom2p7JnkOtTGP_QiI6tfimsv6xT37wTkzbZJy9v4 Message-ID: Subject: Re: [PATCH] regulator: Let raspberrypi drivers depend on ARM To: Jean Delvare Cc: Dave Stevenson , Marek Vasut , Liam Girdwood , Mark Brown , LKML , Marek Vasut Content-Type: text/plain; charset="UTF-8" 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 wrote: > On Thu, 2025-10-30 at 11:09 +0000, Dave Stevenson wrote: > > On Mon, 27 Oct 2025 at 12:22, 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. > > > > > > Signed-off-by: Jean Delvare > > > --- > > > 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