* Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux
From: Peter Rosin @ 2026-02-09 13:16 UTC (permalink / raw)
To: Ulf Hansson, Josua Mayer
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Janusz Krzysztofik, Vignesh R, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, Yazan Shhady,
Jon Nettleton, Mikhail Anikin, linux-can, linux-phy, linux-kernel,
linux-omap, linux-i2c, linux-mmc, devicetree, linux-renesas-soc
In-Reply-To: <CAPDyKFpbpcg3ei51hEcG5FzJL7tK44PdBcMbxfOdON7ozxP2Xg@mail.gmail.com>
2026-02-09 at 10:57, Ulf Hansson wrote:
> I have already applied for v8 and it's going to be in my pull-request
> for v7.0 in a few hours.
>
> Please send incremental fixes on top instead of a new version of the
> series, then I can pick them as fixes for v7.0.
Hi!
Sorry for being late with this, but as the mux maintainer I'm not
fond of
028ec00381f5 ("mux: add help text for MULTIPLEXER config option"
and would not like to see it in rc1. Can you prevent that some way?
Cheers,
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add vdda-refgen supplies for Glymur
From: Dmitry Baryshkov @ 2026-02-09 13:15 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260208-refgen-v1-2-87ca84fd78b3@oss.qualcomm.com>
On Sun, Feb 08, 2026 at 08:49:40PM -0800, Qiang Yu wrote:
> The refgen providing reference voltage for PCIe QMP PHY on Glymur requires
> two power supplies independent from the PHY's core and qref rails. Add
> support for vdda-refgen0p9 and vdda-refgen1p2 supplies with a dedicated
> glymur_qmp_phy_vreg_l list.
>
> Update both Gen5x4 and Gen4x2 configurations to use the new supply list.
I'd ask for the DTSI patch too...
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option
From: Peter Rosin @ 2026-02-09 13:08 UTC (permalink / raw)
To: Josua Mayer, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
Neil Armstrong, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang
Cc: Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <9d7bda92-e520-466a-a0be-d01686af1d56@solid-run.com>
Hi!
2026-02-09 at 13:07, Josua Mayer wrote:
> On 09/02/2026 13:43, Peter Rosin wrote:
>> Hi!
>>
>> 2026-02-09 at 12:31, Josua Mayer wrote:
>>> Hi Peter,
>>>
>>> On 09/02/2026 13:10, Peter Rosin wrote:
>>>> Hi!
>>>>
>>>> 2026-02-08 at 16:38, Josua Mayer wrote:
>>>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>>>>> option thorugh the kernel configuration without explicit "select" driver
>>>>> dependencies.
>>>>>
>>>>> Select it by default when COMPILE_TEST is set for better coverage.
>>>>>
>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>>> ---
>>>>> drivers/mux/Kconfig | 9 ++++++++-
>>>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>>>> index c68132e38138..4f7c6bb86fc6 100644
>>>>> --- a/drivers/mux/Kconfig
>>>>> +++ b/drivers/mux/Kconfig
>>>>> @@ -4,7 +4,14 @@
>>>>> #
>>>>>
>>>>> config MULTIPLEXER
>>>>> - tristate
>>>>> + tristate "Generic Multiplexer Support"
>>>>> + default m if COMPILE_TEST
>>>>> + help
>>>>> + This framework is designed to abstract multiplexer handling for
>>>>> + devices via various GPIO-, MMIO/Regmap or specific multiplexer
>>>>> + controller chips.
>>>>> +
>>>>> + If unsure, say no.
>>>>>
>>>>> menu "Multiplexer drivers"
>>>>> depends on MULTIPLEXER
>>>>>
>>>> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
>>>> be selected when needed (and there are a dozen or so instances). The kbuild
>>>> docs has this on the subject:
>>>>
>>>> "In general use select only for non-visible symbols (no prompts
>>>> anywhere) and for symbols with no dependencies."
>>> The patch description didn't make the decision logic clear,
>>> and I plan to submit a standalone patch for this after v7.0-rc1.
>>>
>>> Basically existing drivers using mux core used "select" to enable it,
>>> even though the core can function standalone with device-tree.
>>>
>>> Some of these users (phy-can-transceiver) function perfectly
>>> perfectly fine without mux, and use it as an optional feature.
>>>
>>> Likely drivers only used "select" to avoid writing helper functions,
>>> prompt, kconfig description and stubs - which this patch-set added.
>>>
>>> So I will argue that some existing users relying on "select" was wrong,
>>> and that the mux framework is generally useful on its own.
>> When I wrote the mux sub-system it was very much intentional and by
>> design that drivers needing a mux should select MULTIPLEXER, and that
>> MULTIPLEXER should not be a visible symbol.
> Need is a strong word here, and doesn't address the optional case.
"Need" was the correct verb up until you needed the subsystem to be
optional. If you need the mux subsystem to be optional, you need to
do it in a way that does not introduce headaches.
>> You say that it could be useful to have it visible, which is all fine
>> I suppose. But, you fail to address that quote from the kbuild docs.
>> Why is it OK to have the preexisting drivers select a visible symbol,
>> when the kbuild documentation states that it should not be done that
>> way?
>
> It might have been okay for a transitional period.
What would be ok for a transitional period? Introducing potentially
problematic kbuild dependencies? I'd rather not...
> My original patch-set had already exploded due to the request to
> introduce general purpose devm_*_optional_* helpers,
> and the fact phy-can-transceiver already had a local version of the same.
>
> So perhaps if I will submit a patch-set changing to visible symbol,
> I shall also change the few drivers that are now using "select"?
I think it would be simpler to introduce some new visible symbol
that triggers select MULTIPLEXER, making it perfectly fine to
leave all the existing select MULTIPLEXER users as-is?
Cheers,
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/3] phy: qcom: edp: Correct and clean up eDP/DP combo PHY configuration values
From: Dmitry Baryshkov @ 2026-02-09 12:47 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel
In-Reply-To: <23930db0-730e-4f99-a661-262b15f1a8ac@oss.qualcomm.com>
On Mon, Feb 09, 2026 at 05:52:22PM +0800, Yongxing Mou wrote:
>
>
> On 2/7/2026 6:22 PM, Dmitry Baryshkov wrote:
> > On Thu, Feb 05, 2026 at 05:20:53PM +0800, Yongxing Mou wrote:
> > > According to the current HPG settings, most eDP/DP combo PHYs can reuse the
> > > same configuration values.
> > > DP mode：
> > > -sa8775p/sc7280/sc8280xp/x1e80100
> > > -glymur
> > > eDP mode(low vdiff):
> > > -glymur/sa8775p/sc8280xp/x1e80100
> > > -sc7280
> > > The current driver still keeps multiple versions of these tables and
> > > doesn't fully support every combo PHY mode. This patch removes the
> >
> > See Documentation/process/submitting-patches.rst, "This patch".
> >
> Sure. got it thanks, will remove "This patch".
> > > redundant configs and keeps only the sets we actually use, matching the
> > > platforms listed above.
> >
> > Should it be combined with the 3rd patch? There you sort out all the
> > tables, it makes more sense to review all programming together.
> >
> Hi, if this would help with your review work, I’m very happy to do it.
> My original intention was to do some cleanup in this patch—correct the table
> values so that more platforms can reuse the same table.
Fixed should come before cleanups (so that they can be backported to
stable kernels).
> From Konard’s comments, it seems that the HPG table may not be the most
> appropriate one either.
> Maybe shoud first determine what the correct table values should be.
Please follow the tables for each SKU separately (that's the 'fix'
part).
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/3] phy: qcom: edp: Correct and clean up eDP/DP combo PHY configuration values
From: Dmitry Baryshkov @ 2026-02-09 12:46 UTC (permalink / raw)
To: Yongxing Mou
Cc: Konrad Dybcio, Vinod Koul, Neil Armstrong, linux-arm-msm,
linux-phy, linux-kernel
In-Reply-To: <92556aa2-607f-4743-a480-19458836fffa@oss.qualcomm.com>
On Mon, Feb 09, 2026 at 05:00:03PM +0800, Yongxing Mou wrote:
>
>
> On 2/6/2026 6:47 PM, Konrad Dybcio wrote:
> > On 2/5/26 10:20 AM, Yongxing Mou wrote:
> > > According to the current HPG settings, most eDP/DP combo PHYs can reuse the
> > > same configuration values.
> >
> > Even across the various process nodes?
> >
> Emm,Currently, I have only checked the five platforms that already have eDP
> PHY driver support enabled. The results are the same as stated in the commit
> message: in DP mode and in eDP low‑vdiff mode, there are four platforms that
> can reuse the same settings. The HPG I used was the one I found on IPCAT.
> Regarding HRG, please move to next comment.
> > > DP mode：
> > > -sa8775p/sc7280/sc8280xp/x1e80100
> > > -glymur
> > > eDP mode(low vdiff):
> > > -glymur/sa8775p/sc8280xp/x1e80100
> > > -sc7280
> > > The current driver still keeps multiple versions of these tables and
> > > doesn't fully support every combo PHY mode. This patch removes the
> > > redundant configs and keeps only the sets we actually use, matching the
> > > platforms listed above.
> >
> > I see that e.g. eDP Low-Vdiff swing setting for RBR is:
> >
> Hi, do you mean emphasis settings, i don't see 0x11 0x12 in arr[0][1].
> > hamoa kodiak
> > arr[0][1] 0x11 0x12
> >
> > It may be that this changed later during tuning but it's not reflected
> > in the docs for kodiak
> Emm, if that, where can i get the correct value for tables.. In this patch,
> I’m indeed quite curious why the values before the modification differ from
> those in the HPG. I’m not sure about the reason. The HPG I used was taken
> directly from the current go/ipcat. Could you tell me where I can obtain the
> final table that should be used?
Use the HPG which matches the chip generation / codename.
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option
From: Josua Mayer @ 2026-02-09 12:07 UTC (permalink / raw)
To: Peter Rosin, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
Neil Armstrong, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang
Cc: Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <704210e0-2e53-09f6-9f8c-3ae0c4b8e0da@axentia.se>
On 09/02/2026 13:43, Peter Rosin wrote:
> Hi!
>
> 2026-02-09 at 12:31, Josua Mayer wrote:
>> Hi Peter,
>>
>> On 09/02/2026 13:10, Peter Rosin wrote:
>>> Hi!
>>>
>>> 2026-02-08 at 16:38, Josua Mayer wrote:
>>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>>>> option thorugh the kernel configuration without explicit "select" driver
>>>> dependencies.
>>>>
>>>> Select it by default when COMPILE_TEST is set for better coverage.
>>>>
>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>> ---
>>>> drivers/mux/Kconfig | 9 ++++++++-
>>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>>> index c68132e38138..4f7c6bb86fc6 100644
>>>> --- a/drivers/mux/Kconfig
>>>> +++ b/drivers/mux/Kconfig
>>>> @@ -4,7 +4,14 @@
>>>> #
>>>>
>>>> config MULTIPLEXER
>>>> - tristate
>>>> + tristate "Generic Multiplexer Support"
>>>> + default m if COMPILE_TEST
>>>> + help
>>>> + This framework is designed to abstract multiplexer handling for
>>>> + devices via various GPIO-, MMIO/Regmap or specific multiplexer
>>>> + controller chips.
>>>> +
>>>> + If unsure, say no.
>>>>
>>>> menu "Multiplexer drivers"
>>>> depends on MULTIPLEXER
>>>>
>>> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
>>> be selected when needed (and there are a dozen or so instances). The kbuild
>>> docs has this on the subject:
>>>
>>> "In general use select only for non-visible symbols (no prompts
>>> anywhere) and for symbols with no dependencies."
>> The patch description didn't make the decision logic clear,
>> and I plan to submit a standalone patch for this after v7.0-rc1.
>>
>> Basically existing drivers using mux core used "select" to enable it,
>> even though the core can function standalone with device-tree.
>>
>> Some of these users (phy-can-transceiver) function perfectly
>> perfectly fine without mux, and use it as an optional feature.
>>
>> Likely drivers only used "select" to avoid writing helper functions,
>> prompt, kconfig description and stubs - which this patch-set added.
>>
>> So I will argue that some existing users relying on "select" was wrong,
>> and that the mux framework is generally useful on its own.
> When I wrote the mux sub-system it was very much intentional and by
> design that drivers needing a mux should select MULTIPLEXER, and that
> MULTIPLEXER should not be a visible symbol.
Need is a strong word here, and doesn't address the optional case.
> You say that it could be useful to have it visible, which is all fine
> I suppose. But, you fail to address that quote from the kbuild docs.
> Why is it OK to have the preexisting drivers select a visible symbol,
> when the kbuild documentation states that it should not be done that
> way?
It might have been okay for a transitional period.
My original patch-set had already exploded due to the request to
introduce general purpose devm_*_optional_* helpers,
and the fact phy-can-transceiver already had a local version of the same.
So perhaps if I will submit a patch-set changing to visible symbol,
I shall also change the few drivers that are now using "select"?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option
From: Peter Rosin @ 2026-02-09 11:43 UTC (permalink / raw)
To: Josua Mayer, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
Neil Armstrong, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang
Cc: Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <fcef2798-1645-41fb-952e-daf3657bc231@solid-run.com>
Hi!
2026-02-09 at 12:31, Josua Mayer wrote:
> Hi Peter,
>
> On 09/02/2026 13:10, Peter Rosin wrote:
>> Hi!
>>
>> 2026-02-08 at 16:38, Josua Mayer wrote:
>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>>> option thorugh the kernel configuration without explicit "select" driver
>>> dependencies.
>>>
>>> Select it by default when COMPILE_TEST is set for better coverage.
>>>
>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>> ---
>>> drivers/mux/Kconfig | 9 ++++++++-
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>> index c68132e38138..4f7c6bb86fc6 100644
>>> --- a/drivers/mux/Kconfig
>>> +++ b/drivers/mux/Kconfig
>>> @@ -4,7 +4,14 @@
>>> #
>>>
>>> config MULTIPLEXER
>>> - tristate
>>> + tristate "Generic Multiplexer Support"
>>> + default m if COMPILE_TEST
>>> + help
>>> + This framework is designed to abstract multiplexer handling for
>>> + devices via various GPIO-, MMIO/Regmap or specific multiplexer
>>> + controller chips.
>>> +
>>> + If unsure, say no.
>>>
>>> menu "Multiplexer drivers"
>>> depends on MULTIPLEXER
>>>
>> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
>> be selected when needed (and there are a dozen or so instances). The kbuild
>> docs has this on the subject:
>>
>> "In general use select only for non-visible symbols (no prompts
>> anywhere) and for symbols with no dependencies."
> The patch description didn't make the decision logic clear,
> and I plan to submit a standalone patch for this after v7.0-rc1.
>
> Basically existing drivers using mux core used "select" to enable it,
> even though the core can function standalone with device-tree.
>
> Some of these users (phy-can-transceiver) function perfectly
> perfectly fine without mux, and use it as an optional feature.
>
> Likely drivers only used "select" to avoid writing helper functions,
> prompt, kconfig description and stubs - which this patch-set added.
>
> So I will argue that some existing users relying on "select" was wrong,
> and that the mux framework is generally useful on its own.
When I wrote the mux sub-system it was very much intentional and by
design that drivers needing a mux should select MULTIPLEXER, and that
MULTIPLEXER should not be a visible symbol.
You say that it could be useful to have it visible, which is all fine
I suppose. But, you fail to address that quote from the kbuild docs.
Why is it OK to have the preexisting drivers select a visible symbol,
when the kbuild documentation states that it should not be done that
way?
Cheers,
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option
From: Josua Mayer @ 2026-02-09 11:31 UTC (permalink / raw)
To: Peter Rosin, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
Neil Armstrong, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang
Cc: Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <bc5fbfc5-6f71-eeed-ad90-0c1b835e65ea@axentia.se>
Hi Peter,
On 09/02/2026 13:10, Peter Rosin wrote:
> Hi!
>
> 2026-02-08 at 16:38, Josua Mayer wrote:
>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>> option thorugh the kernel configuration without explicit "select" driver
>> dependencies.
>>
>> Select it by default when COMPILE_TEST is set for better coverage.
>>
>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>> ---
>> drivers/mux/Kconfig | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>> index c68132e38138..4f7c6bb86fc6 100644
>> --- a/drivers/mux/Kconfig
>> +++ b/drivers/mux/Kconfig
>> @@ -4,7 +4,14 @@
>> #
>>
>> config MULTIPLEXER
>> - tristate
>> + tristate "Generic Multiplexer Support"
>> + default m if COMPILE_TEST
>> + help
>> + This framework is designed to abstract multiplexer handling for
>> + devices via various GPIO-, MMIO/Regmap or specific multiplexer
>> + controller chips.
>> +
>> + If unsure, say no.
>>
>> menu "Multiplexer drivers"
>> depends on MULTIPLEXER
>>
> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
> be selected when needed (and there are a dozen or so instances). The kbuild
> docs has this on the subject:
>
> "In general use select only for non-visible symbols (no prompts
> anywhere) and for symbols with no dependencies."
The patch description didn't make the decision logic clear,
and I plan to submit a standalone patch for this after v7.0-rc1.
Basically existing drivers using mux core used "select" to enable it,
even though the core can function standalone with device-tree.
Some of these users (phy-can-transceiver) function perfectly
perfectly fine without mux, and use it as an optional feature.
Likely drivers only used "select" to avoid writing helper functions,
prompt, kconfig description and stubs - which this patch-set added.
So I will argue that some existing users relying on "select" was wrong,
and that the mux framework is generally useful on its own.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 3/7] mux: add help text for MULTIPLEXER config option
From: Geert Uytterhoeven @ 2026-02-09 11:03 UTC (permalink / raw)
To: Josua Mayer
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang,
Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <1a4288f2-ee5c-494f-9fbe-ea3a90a16014@solid-run.com>
Hi Josua,
On Mon, 9 Feb 2026 at 11:47, Josua Mayer <josua@solid-run.com> wrote:
> On 09/02/2026 12:17, Geert Uytterhoeven wrote:
> > On Mon, 9 Feb 2026 at 11:12, Josua Mayer <josua@solid-run.com> wrote:
> >> On 09/02/2026 10:06, Geert Uytterhoeven wrote:
> >>> On Sun, 8 Feb 2026 at 16:16, Josua Mayer <josua@solid-run.com> wrote:
> >>>> On 03/02/2026 15:01, Josua Mayer wrote:
> >>>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
> >>>>> option thorugh the kernel configuration without explicit "select" driver
> >>>>> dependencies.
> >>>>>
> >>>>> Select it by default when COMPILE_TEST is set for better coverage.
> >>>>>
> >>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
> >>>>> ---
> >>>>> drivers/mux/Kconfig | 8 +++++++-
> >>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> >>>>> index c68132e38138..e31c46820bdf 100644
> >>>>> --- a/drivers/mux/Kconfig
> >>>>> +++ b/drivers/mux/Kconfig
> >>>>> @@ -4,7 +4,13 @@
> >>>>> #
> >>>>>
> >>>>> config MULTIPLEXER
> >>>>> - tristate
> >>>>> + tristate "Generic Multiplexer Support" if COMPILE_TEST
> >>>> This didn't do what I thought it would.
> >>>> It was my intention to allow enabling this through menuconfig / .config.
> >>>>
> >>>> With the syntax above menuconfig shows:
> >>>>
> >>>> │ Symbol: MULTIPLEXER [=n]
> >>>> │ Type : tristate
> >>>> │ Defined at drivers/mux/Kconfig:6
> >>>> │ Prompt: Generic Multiplexer Support
> >>>> │ Visible if: COMPILE_TEST [=n]
> >>>>
> >>>> This means it cannot be selected.
> >>> Looks like you haven't enabled COMPILE_TEST first?
> >> Correct.
> >> But CONFIG_MULTIPLEXER should be visible always,
> >> not just when COMPILE_TEST is set.
> > Why should it always be visible? All users select it?
>
> This is not relevant for v7 now and can be handled later.
>
> It was discussed previously that drivers supporting optional muxes
> do not need to "select" MULTIPLEXER through Kconfig,
> E.g. the renesas sdhi driver.
>
> However other drivers are already selecting it even though the mux
> is optional, see e.g. phy-can-transceiver.
>
> In order to support muxes in renesas sdhi driver e.g., users must choose to
> enable both the renesas driver, and multiplexer subsystem via the
> configuration.
>
> The mux core standalone also supports a limited use-case without other
> driver
> interactions, setting idle-state e.g.:
>
> mux-controller {
> compatible = "gpio-mux";
> #mux-control-cells = <0>;
> mux-gpios = <&tca6416_u20 0 GPIO_ACTIVE_HIGH>;
> idle-state = <0>;
> };
>
> So it can be generally useful for a user to enable CONFIG_MULTIPLEXER.
Then please say so in the patch description.
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option
From: Peter Rosin @ 2026-02-09 11:10 UTC (permalink / raw)
To: Josua Mayer, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
Neil Armstrong, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang
Cc: Yazan Shhady, Jon Nettleton, Mikhail Anikin, linux-can, linux-phy,
linux-kernel, linux-omap, linux-i2c, linux-mmc, devicetree,
linux-renesas-soc
In-Reply-To: <20260208-rz-sdio-mux-v9-3-9a3be13c1280@solid-run.com>
Hi!
2026-02-08 at 16:38, Josua Mayer wrote:
> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
> option thorugh the kernel configuration without explicit "select" driver
> dependencies.
>
> Select it by default when COMPILE_TEST is set for better coverage.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> drivers/mux/Kconfig | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> index c68132e38138..4f7c6bb86fc6 100644
> --- a/drivers/mux/Kconfig
> +++ b/drivers/mux/Kconfig
> @@ -4,7 +4,14 @@
> #
>
> config MULTIPLEXER
> - tristate
> + tristate "Generic Multiplexer Support"
> + default m if COMPILE_TEST
> + help
> + This framework is designed to abstract multiplexer handling for
> + devices via various GPIO-, MMIO/Regmap or specific multiplexer
> + controller chips.
> +
> + If unsure, say no.
>
> menu "Multiplexer drivers"
> depends on MULTIPLEXER
>
I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
be selected when needed (and there are a dozen or so instances). The kbuild
docs has this on the subject:
"In general use select only for non-visible symbols (no prompts
anywhere) and for symbols with no dependencies."
Cheers,
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 3/7] mux: add help text for MULTIPLEXER config option
From: Josua Mayer @ 2026-02-09 10:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang,
Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <CAMuHMdVbi=2puhk84k+FCDXqkQ9jFsy0rsseQiFCF8i=KsR1OQ@mail.gmail.com>
On 09/02/2026 12:17, Geert Uytterhoeven wrote:
> Hi Josua,
>
> On Mon, 9 Feb 2026 at 11:12, Josua Mayer <josua@solid-run.com> wrote:
>> On 09/02/2026 10:06, Geert Uytterhoeven wrote:
>>> On Sun, 8 Feb 2026 at 16:16, Josua Mayer <josua@solid-run.com> wrote:
>>>> On 03/02/2026 15:01, Josua Mayer wrote:
>>>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>>>>> option thorugh the kernel configuration without explicit "select" driver
>>>>> dependencies.
>>>>>
>>>>> Select it by default when COMPILE_TEST is set for better coverage.
>>>>>
>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>>> ---
>>>>> drivers/mux/Kconfig | 8 +++++++-
>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>>>> index c68132e38138..e31c46820bdf 100644
>>>>> --- a/drivers/mux/Kconfig
>>>>> +++ b/drivers/mux/Kconfig
>>>>> @@ -4,7 +4,13 @@
>>>>> #
>>>>>
>>>>> config MULTIPLEXER
>>>>> - tristate
>>>>> + tristate "Generic Multiplexer Support" if COMPILE_TEST
>>>> This didn't do what I thought it would.
>>>> It was my intention to allow enabling this through menuconfig / .config.
>>>>
>>>> With the syntax above menuconfig shows:
>>>>
>>>> │ Symbol: MULTIPLEXER [=n]
>>>> │ Type : tristate
>>>> │ Defined at drivers/mux/Kconfig:6
>>>> │ Prompt: Generic Multiplexer Support
>>>> │ Visible if: COMPILE_TEST [=n]
>>>>
>>>> This means it cannot be selected.
>>> Looks like you haven't enabled COMPILE_TEST first?
>> Correct.
>> But CONFIG_MULTIPLEXER should be visible always,
>> not just when COMPILE_TEST is set.
> Why should it always be visible? All users select it?
This is not relevant for v7 now and can be handled later.
It was discussed previously that drivers supporting optional muxes
do not need to "select" MULTIPLEXER through Kconfig,
E.g. the renesas sdhi driver.
However other drivers are already selecting it even though the mux
is optional, see e.g. phy-can-transceiver.
In order to support muxes in renesas sdhi driver e.g., users must choose to
enable both the renesas driver, and multiplexer subsystem via the
configuration.
The mux core standalone also supports a limited use-case without other
driver
interactions, setting idle-state e.g.:
mux-controller {
compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&tca6416_u20 0 GPIO_ACTIVE_HIGH>;
idle-state = <0>;
};
So it can be generally useful for a user to enable CONFIG_MULTIPLEXER.
>
>>>> Instead I (think I) should use
>>>> default m if COMPILE_TEST
>>> No, merely enabling COMPILE_TEST must not enable additional
>>> functionality.
>>>
>>>> Since my patch-set broke x86_64 allmodconfig and failed merge into
>>>> linux-next,
>>>> this presents an opportunity to change the above as well with v9.
>>> Ulf has already applied this series to mmc/next.
>> What would be the process to fix the build error for x86_64 allmodconfig
>> now?
> Incremental patches, cfr. Ulf's response to [PATCH v9 0/7].
>
> 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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux
From: Josua Mayer @ 2026-02-09 10:21 UTC (permalink / raw)
To: Ulf Hansson
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, Yazan Shhady,
Jon Nettleton, Mikhail Anikin, linux-can@vger.kernel.org,
linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <CAPDyKFpbpcg3ei51hEcG5FzJL7tK44PdBcMbxfOdON7ozxP2Xg@mail.gmail.com>
On 09/02/2026 11:57, Ulf Hansson wrote:
> On Sun, 8 Feb 2026 at 16:39, Josua Mayer <josua@solid-run.com> wrote:
>> Some Renesas SoC based boards mux SD and eMMC on a single sdio
>> controller, exposing user control by dip switch and software control by
>> gpio.
>>
>> Purpose is to simplify development and provisioning by selecting boot
>> media at power-on, and again before starting linux.
>>
>> Add binding and driver support for linking a (gpio) mux to renesas sdio
>> controller.
>>
>> Introduce generic helper functions for getting managed and selected
>> mux-state objects, and switch i2c-omap and phy-can-transceiver drivers.
>>
>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>> ---
>> Changes in v9:
>> - compile-tested on x86 with MULTIPLEXER=m/y/unset.
>> - fixed Kconfig changes so that CONFIG_MULTIPLEXER can be selected.
>> through menuconfig / .config as intended.
>> - updated trailers
>> - document null return value for mux_control_get_optional.
>> - fix build error for CONFIG_MULTIPLEXER=m, found with x86_64
>> allmodconfig: replaced ifdef ... with if IS_ENABLED(...).
>> (Reported-by: Mark Brown <broonie@kernel.org>)
>> - Link to v8: https://lore.kernel.org/r/20260203-rz-sdio-mux-v8-0-024ea405863e@solid-run.com
> [...]
>
> I have already applied for v8 and it's going to be in my pull-request
> for v7.0 in a few hours.
>
> Please send incremental fixes on top instead of a new version of the
> series, then I can pick them as fixes for v7.0.
Okay, I'll send a minimal patch to fix the build error only in that case.
Thanks!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 3/7] mux: add help text for MULTIPLEXER config option
From: Geert Uytterhoeven @ 2026-02-09 10:17 UTC (permalink / raw)
To: Josua Mayer
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang,
Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <39f3891c-c05a-4e10-9ad4-ab3cbc6fa70e@solid-run.com>
Hi Josua,
On Mon, 9 Feb 2026 at 11:12, Josua Mayer <josua@solid-run.com> wrote:
> On 09/02/2026 10:06, Geert Uytterhoeven wrote:
> > On Sun, 8 Feb 2026 at 16:16, Josua Mayer <josua@solid-run.com> wrote:
> >> On 03/02/2026 15:01, Josua Mayer wrote:
> >>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
> >>> option thorugh the kernel configuration without explicit "select" driver
> >>> dependencies.
> >>>
> >>> Select it by default when COMPILE_TEST is set for better coverage.
> >>>
> >>> Signed-off-by: Josua Mayer <josua@solid-run.com>
> >>> ---
> >>> drivers/mux/Kconfig | 8 +++++++-
> >>> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> >>> index c68132e38138..e31c46820bdf 100644
> >>> --- a/drivers/mux/Kconfig
> >>> +++ b/drivers/mux/Kconfig
> >>> @@ -4,7 +4,13 @@
> >>> #
> >>>
> >>> config MULTIPLEXER
> >>> - tristate
> >>> + tristate "Generic Multiplexer Support" if COMPILE_TEST
> >> This didn't do what I thought it would.
> >> It was my intention to allow enabling this through menuconfig / .config.
> >>
> >> With the syntax above menuconfig shows:
> >>
> >> │ Symbol: MULTIPLEXER [=n]
> >> │ Type : tristate
> >> │ Defined at drivers/mux/Kconfig:6
> >> │ Prompt: Generic Multiplexer Support
> >> │ Visible if: COMPILE_TEST [=n]
> >>
> >> This means it cannot be selected.
> > Looks like you haven't enabled COMPILE_TEST first?
> Correct.
> But CONFIG_MULTIPLEXER should be visible always,
> not just when COMPILE_TEST is set.
Why should it always be visible? All users select it?
> >> Instead I (think I) should use
> >> default m if COMPILE_TEST
> > No, merely enabling COMPILE_TEST must not enable additional
> > functionality.
> >
> >> Since my patch-set broke x86_64 allmodconfig and failed merge into
> >> linux-next,
> >> this presents an opportunity to change the above as well with v9.
> > Ulf has already applied this series to mmc/next.
> What would be the process to fix the build error for x86_64 allmodconfig
> now?
Incremental patches, cfr. Ulf's response to [PATCH v9 0/7].
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 3/7] mux: add help text for MULTIPLEXER config option
From: Josua Mayer @ 2026-02-09 10:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang,
Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <CAMuHMdU01vwif4H6H-cYUfW0Y56fN6Anp9F4Ru7q3fveNqqoXA@mail.gmail.com>
On 09/02/2026 10:06, Geert Uytterhoeven wrote:
> Hi Josua,
>
> On Sun, 8 Feb 2026 at 16:16, Josua Mayer <josua@solid-run.com> wrote:
>> On 03/02/2026 15:01, Josua Mayer wrote:
>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>>> option thorugh the kernel configuration without explicit "select" driver
>>> dependencies.
>>>
>>> Select it by default when COMPILE_TEST is set for better coverage.
>>>
>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>> ---
>>> drivers/mux/Kconfig | 8 +++++++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>> index c68132e38138..e31c46820bdf 100644
>>> --- a/drivers/mux/Kconfig
>>> +++ b/drivers/mux/Kconfig
>>> @@ -4,7 +4,13 @@
>>> #
>>>
>>> config MULTIPLEXER
>>> - tristate
>>> + tristate "Generic Multiplexer Support" if COMPILE_TEST
>> This didn't do what I thought it would.
>> It was my intention to allow enabling this through menuconfig / .config.
>>
>> With the syntax above menuconfig shows:
>>
>> │ Symbol: MULTIPLEXER [=n]
>> │ Type : tristate
>> │ Defined at drivers/mux/Kconfig:6
>> │ Prompt: Generic Multiplexer Support
>> │ Visible if: COMPILE_TEST [=n]
>>
>> This means it cannot be selected.
> Looks like you haven't enabled COMPILE_TEST first?
Correct.
But CONFIG_MULTIPLEXER should be visible always,
not just when COMPILE_TEST is set.
>
>> Instead I (think I) should use
>> default m if COMPILE_TEST
> No, merely enabling COMPILE_TEST must not enable additional
> functionality.
>
>> Since my patch-set broke x86_64 allmodconfig and failed merge into
>> linux-next,
>> this presents an opportunity to change the above as well with v9.
> Ulf has already applied this series to mmc/next.
What would be the process to fix the build error for x86_64 allmodconfig
now?
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux
From: Ulf Hansson @ 2026-02-09 9:57 UTC (permalink / raw)
To: Josua Mayer
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, Yazan Shhady,
Jon Nettleton, Mikhail Anikin, linux-can, linux-phy, linux-kernel,
linux-omap, linux-i2c, linux-mmc, devicetree, linux-renesas-soc
In-Reply-To: <20260208-rz-sdio-mux-v9-0-9a3be13c1280@solid-run.com>
On Sun, 8 Feb 2026 at 16:39, Josua Mayer <josua@solid-run.com> wrote:
>
> Some Renesas SoC based boards mux SD and eMMC on a single sdio
> controller, exposing user control by dip switch and software control by
> gpio.
>
> Purpose is to simplify development and provisioning by selecting boot
> media at power-on, and again before starting linux.
>
> Add binding and driver support for linking a (gpio) mux to renesas sdio
> controller.
>
> Introduce generic helper functions for getting managed and selected
> mux-state objects, and switch i2c-omap and phy-can-transceiver drivers.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> Changes in v9:
> - compile-tested on x86 with MULTIPLEXER=m/y/unset.
> - fixed Kconfig changes so that CONFIG_MULTIPLEXER can be selected.
> through menuconfig / .config as intended.
> - updated trailers
> - document null return value for mux_control_get_optional.
> - fix build error for CONFIG_MULTIPLEXER=m, found with x86_64
> allmodconfig: replaced ifdef ... with if IS_ENABLED(...).
> (Reported-by: Mark Brown <broonie@kernel.org>)
> - Link to v8: https://lore.kernel.org/r/20260203-rz-sdio-mux-v8-0-024ea405863e@solid-run.com
[...]
I have already applied for v8 and it's going to be in my pull-request
for v7.0 in a few hours.
Please send incremental fixes on top instead of a new version of the
series, then I can pick them as fixes for v7.0.
Kind regards
Uffe
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/3] phy: qcom: edp: Correct and clean up eDP/DP combo PHY configuration values
From: Yongxing Mou @ 2026-02-09 9:52 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel
In-Reply-To: <57bwrceuqejzliljhrzj5wfumtr2q3dslgmjj3vd7masafi4k2@dskfnosor553>
On 2/7/2026 6:22 PM, Dmitry Baryshkov wrote:
> On Thu, Feb 05, 2026 at 05:20:53PM +0800, Yongxing Mou wrote:
>> According to the current HPG settings, most eDP/DP combo PHYs can reuse the
>> same configuration values.
>> DP mode：
>> -sa8775p/sc7280/sc8280xp/x1e80100
>> -glymur
>> eDP mode(low vdiff):
>> -glymur/sa8775p/sc8280xp/x1e80100
>> -sc7280
>> The current driver still keeps multiple versions of these tables and
>> doesn't fully support every combo PHY mode. This patch removes the
>
> See Documentation/process/submitting-patches.rst, "This patch".
>
Sure. got it thanks, will remove "This patch".
>> redundant configs and keeps only the sets we actually use, matching the
>> platforms listed above.
>
> Should it be combined with the 3rd patch? There you sort out all the
> tables, it makes more sense to review all programming together.
>
Hi, if this would help with your review work, I’m very happy to do it.
My original intention was to do some cleanup in this patch—correct the
table values so that more platforms can reuse the same table.
From Konard’s comments, it seems that the HPG table may not be the most
appropriate one either.
Maybe shoud first determine what the correct table values should be.
>>
>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>> ---
>> drivers/phy/qualcomm/phy-qcom-edp.c | 41 +++++++++----------------------------
>> 1 file changed, 10 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
>> index 13feab99feec..10cbb7d9a8a0 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
>> @@ -116,17 +116,17 @@ struct qcom_edp {
>> };
>>
>> static const u8 dp_swing_hbr_rbr[4][4] = {
>> - { 0x08, 0x0f, 0x16, 0x1f },
>> + { 0x07, 0x0f, 0x16, 0x1f },
>> { 0x11, 0x1e, 0x1f, 0xff },
>> { 0x16, 0x1f, 0xff, 0xff },
>> { 0x1f, 0xff, 0xff, 0xff }
>> };
>>
>> static const u8 dp_pre_emp_hbr_rbr[4][4] = {
>> - { 0x00, 0x0d, 0x14, 0x1a },
>> + { 0x00, 0x0e, 0x15, 0x1a },
>> { 0x00, 0x0e, 0x15, 0xff },
>> { 0x00, 0x0e, 0xff, 0xff },
>> - { 0x03, 0xff, 0xff, 0xff }
>> + { 0x04, 0xff, 0xff, 0xff }
>> };
>>
>> static const u8 dp_swing_hbr2_hbr3[4][4] = {
>> @@ -158,7 +158,7 @@ static const u8 edp_swing_hbr_rbr[4][4] = {
>> };
>>
>> static const u8 edp_pre_emp_hbr_rbr[4][4] = {
>> - { 0x05, 0x12, 0x17, 0x1d },
>> + { 0x05, 0x11, 0x17, 0x1d },
>> { 0x05, 0x11, 0x18, 0xff },
>> { 0x06, 0x11, 0xff, 0xff },
>> { 0x00, 0xff, 0xff, 0xff }
>> @@ -172,10 +172,10 @@ static const u8 edp_swing_hbr2_hbr3[4][4] = {
>> };
>>
>> static const u8 edp_pre_emp_hbr2_hbr3[4][4] = {
>> - { 0x08, 0x11, 0x17, 0x1b },
>> - { 0x00, 0x0c, 0x13, 0xff },
>> - { 0x05, 0x10, 0xff, 0xff },
>> - { 0x00, 0xff, 0xff, 0xff }
>> + { 0x0c, 0x15, 0x19, 0x1e },
>> + { 0x0b, 0x15, 0x19, 0xff },
>> + { 0x0e, 0x14, 0xff, 0xff },
>> + { 0x0d, 0xff, 0xff, 0xff }
>> };
>>
>> static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg = {
>> @@ -193,27 +193,6 @@ static const u8 edp_phy_vco_div_cfg_v4[4] = {
>> 0x01, 0x01, 0x02, 0x00,
>> };
>>
>> -static const u8 edp_pre_emp_hbr_rbr_v5[4][4] = {
>> - { 0x05, 0x11, 0x17, 0x1d },
>> - { 0x05, 0x11, 0x18, 0xff },
>> - { 0x06, 0x11, 0xff, 0xff },
>> - { 0x00, 0xff, 0xff, 0xff }
>> -};
>> -
>> -static const u8 edp_pre_emp_hbr2_hbr3_v5[4][4] = {
>> - { 0x0c, 0x15, 0x19, 0x1e },
>> - { 0x0b, 0x15, 0x19, 0xff },
>> - { 0x0e, 0x14, 0xff, 0xff },
>> - { 0x0d, 0xff, 0xff, 0xff }
>> -};
>> -
>> -static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg_v5 = {
>> - .swing_hbr_rbr = &edp_swing_hbr_rbr,
>> - .swing_hbr3_hbr2 = &edp_swing_hbr2_hbr3,
>> - .pre_emphasis_hbr_rbr = &edp_pre_emp_hbr_rbr_v5,
>> - .pre_emphasis_hbr3_hbr2 = &edp_pre_emp_hbr2_hbr3_v5,
>> -};
>> -
>> static const u8 edp_phy_aux_cfg_v5[DP_AUX_CFG_SIZE] = {
>> 0x00, 0x13, 0xa4, 0x00, 0x0a, 0x26, 0x0a, 0x03, 0x37, 0x03, 0x02, 0x02, 0x00,
>> };
>> @@ -564,7 +543,7 @@ static const struct qcom_edp_phy_cfg sa8775p_dp_phy_cfg = {
>> .is_edp = false,
>> .aux_cfg = edp_phy_aux_cfg_v5,
>> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
>> - .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v5,
>> + .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
>> .ver_ops = &qcom_edp_phy_ops_v4,
>> };
>>
>> @@ -944,7 +923,7 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v8 = {
>> static struct qcom_edp_phy_cfg glymur_phy_cfg = {
>> .aux_cfg = edp_phy_aux_cfg_v8,
>> .vco_div_cfg = edp_phy_vco_div_cfg_v8,
>> - .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v5,
>> + .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
>> .ver_ops = &qcom_edp_phy_ops_v8,
>> };
>>
>>
>> --
>> 2.43.0
>>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/3] phy: qcom: edp: Correct and clean up eDP/DP combo PHY configuration values
From: Yongxing Mou @ 2026-02-09 9:00 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <1b78ea12-84ba-467e-b541-1ffd2348f38c@oss.qualcomm.com>
On 2/6/2026 6:47 PM, Konrad Dybcio wrote:
> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>> According to the current HPG settings, most eDP/DP combo PHYs can reuse the
>> same configuration values.
>
> Even across the various process nodes?
>
Emm,Currently, I have only checked the five platforms that already have
eDP PHY driver support enabled. The results are the same as stated in
the commit message: in DP mode and in eDP low‑vdiff mode, there are four
platforms that can reuse the same settings. The HPG I used was the one I
found on IPCAT. Regarding HRG, please move to next comment.
>> DP mode：
>> -sa8775p/sc7280/sc8280xp/x1e80100
>> -glymur
>> eDP mode(low vdiff):
>> -glymur/sa8775p/sc8280xp/x1e80100
>> -sc7280
>> The current driver still keeps multiple versions of these tables and
>> doesn't fully support every combo PHY mode. This patch removes the
>> redundant configs and keeps only the sets we actually use, matching the
>> platforms listed above.
>
> I see that e.g. eDP Low-Vdiff swing setting for RBR is:
>
Hi, do you mean emphasis settings, i don't see 0x11 0x12 in arr[0][1].
> hamoa kodiak
> arr[0][1] 0x11 0x12
>
> It may be that this changed later during tuning but it's not reflected
> in the docs for kodiak
Emm, if that, where can i get the correct value for tables.. In this
patch, I’m indeed quite curious why the values before the modification
differ from those in the HPG. I’m not sure about the reason. The HPG I
used was taken directly from the current go/ipcat. Could you tell me
where I can obtain the final table that should be used?
>
> Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 3/7] mux: add help text for MULTIPLEXER config option
From: Geert Uytterhoeven @ 2026-02-09 8:06 UTC (permalink / raw)
To: Josua Mayer
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang,
Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <b7dcb374-b79c-4e9f-ac30-2f507127cfb3@solid-run.com>
Hi Josua,
On Sun, 8 Feb 2026 at 16:16, Josua Mayer <josua@solid-run.com> wrote:
> On 03/02/2026 15:01, Josua Mayer wrote:
> > Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
> > option thorugh the kernel configuration without explicit "select" driver
> > dependencies.
> >
> > Select it by default when COMPILE_TEST is set for better coverage.
> >
> > Signed-off-by: Josua Mayer <josua@solid-run.com>
> > ---
> > drivers/mux/Kconfig | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> > index c68132e38138..e31c46820bdf 100644
> > --- a/drivers/mux/Kconfig
> > +++ b/drivers/mux/Kconfig
> > @@ -4,7 +4,13 @@
> > #
> >
> > config MULTIPLEXER
> > - tristate
> > + tristate "Generic Multiplexer Support" if COMPILE_TEST
>
> This didn't do what I thought it would.
> It was my intention to allow enabling this through menuconfig / .config.
>
> With the syntax above menuconfig shows:
>
> │ Symbol: MULTIPLEXER [=n]
> │ Type : tristate
> │ Defined at drivers/mux/Kconfig:6
> │ Prompt: Generic Multiplexer Support
> │ Visible if: COMPILE_TEST [=n]
>
> This means it cannot be selected.
Looks like you haven't enabled COMPILE_TEST first?
> Instead I (think I) should use
> default m if COMPILE_TEST
No, merely enabling COMPILE_TEST must not enable additional
functionality.
> Since my patch-set broke x86_64 allmodconfig and failed merge into
> linux-next,
> this presents an opportunity to change the above as well with v9.
Ulf has already applied this series to mmc/next.
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option
From: Geert Uytterhoeven @ 2026-02-09 8:10 UTC (permalink / raw)
To: Josua Mayer
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang,
Yazan Shhady, Jon Nettleton, Mikhail Anikin, linux-can, linux-phy,
linux-kernel, linux-omap, linux-i2c, linux-mmc, devicetree,
linux-renesas-soc
In-Reply-To: <20260208-rz-sdio-mux-v9-3-9a3be13c1280@solid-run.com>
Hi Josua,
On Sun, 8 Feb 2026 at 16:39, Josua Mayer <josua@solid-run.com> wrote:
> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
> option thorugh the kernel configuration without explicit "select" driver
> dependencies.
>
> Select it by default when COMPILE_TEST is set for better coverage.
Merely enabling COMPILE_TEST must not enable additional functionality.
> Signed-off-by: Josua Mayer <josua@solid-run.com>
Nacked-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add vdda-refgen supply for Glymur
From: Krzysztof Kozlowski @ 2026-02-09 8:06 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260208-refgen-v1-1-87ca84fd78b3@oss.qualcomm.com>
On Sun, Feb 08, 2026 at 08:49:39PM -0800, Qiang Yu wrote:
> The PCIe QMP PHYs on Glymur require stable reference voltage provided by
> refgen. The refgen itself requires two separate power supplies:
> vdda-refgen0p9 and vdda-refgen1p2.
>
> Since there is no dedicated driver for REFGEN, add vdda-refgen0p9-supply
How does the driver matter for the bindings? If I add dedicated driver
for refgen, then I change the bindings?
There is qcom,sc8280xp-refgen-regulator so why there cannot be
qcom,x1e-refgen-regulator?
> and vdda-refgen1p2-supply properties to the PCIe PHY dt-bindings. Use
> conditional schema to restrict these properties to only Glymur PCIe QMP
> PHYs.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: spacemit: add regulator support to K1 USB2 PHY
From: Chukun Pan @ 2026-02-09 6:40 UTC (permalink / raw)
To: krzk
Cc: amadeus, broonie, conor+dt, devicetree, dlan, huang.ze, krzk+dt,
lgirdwood, linux-kernel, linux-phy, linux-riscv, neil.armstrong,
robh, spacemit, vkoul
In-Reply-To: <8c3835c4-3602-4cee-9631-0551b0341918@kernel.org>
Hi,
> Plus, if this was a vbus regulator it would not be called "phy"...
> Even more confusing.
Sorry, I didn't consider that this naming is confusing. Other
platforms, such as Rockchip's inno-usb2phy driver, use the
"phy-supply" property. I continued with this bad naming.
> Bindings are supposed to be complete regardless what driver does
> (or does not).
>
> You must list all supplies with proper names.
>
> If this regulator was missing, then what else?
(...)
> Please start describing in the bindings your complete hardware, not
> your drivers.
It appears Ze Huang described the vbus-supply property in
spacemit.k1-dwc3.yaml. So I should enable the regulator in
the dwc3-generic-plat driver. Sorry for the noise.
Thanks,
Chukun
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 2/2] phy: qcom: qmp-pcie: Add vdda-refgen supplies for Glymur
From: Qiang Yu @ 2026-02-09 4:49 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260208-refgen-v1-0-87ca84fd78b3@oss.qualcomm.com>
The refgen providing reference voltage for PCIe QMP PHY on Glymur requires
two power supplies independent from the PHY's core and qref rails. Add
support for vdda-refgen0p9 and vdda-refgen1p2 supplies with a dedicated
glymur_qmp_phy_vreg_l list.
Update both Gen5x4 and Gen4x2 configurations to use the new supply list.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index fed2fc9bb31108d51f88d34f3379c7744681f485..b24ed260f30a689b5668f38c1471c0ab2aced0cc 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -3382,6 +3382,10 @@ static const char * const sm8550_qmp_phy_vreg_l[] = {
"vdda-phy", "vdda-pll", "vdda-qref",
};
+static const char * const glymur_qmp_phy_vreg_l[] = {
+ "vdda-phy", "vdda-pll", "vdda-refgen0p9", "vdda-refgen1p2",
+};
+
/* list of resets */
static const char * const ipq8074_pciephy_reset_l[] = {
"phy", "common",
@@ -4623,8 +4627,8 @@ static const struct qmp_phy_cfg glymur_qmp_gen5x4_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
- .vreg_list = qmp_phy_vreg_l,
- .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+ .vreg_list = glymur_qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(glymur_qmp_phy_vreg_l),
.regs = pciephy_v8_50_regs_layout,
@@ -4639,8 +4643,8 @@ static const struct qmp_phy_cfg glymur_qmp_gen4x2_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
- .vreg_list = qmp_phy_vreg_l,
- .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+ .vreg_list = glymur_qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(glymur_qmp_phy_vreg_l),
.regs = pciephy_v8_regs_layout,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add vdda-refgen supply for Glymur
From: Qiang Yu @ 2026-02-09 4:49 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260208-refgen-v1-0-87ca84fd78b3@oss.qualcomm.com>
The PCIe QMP PHYs on Glymur require stable reference voltage provided by
refgen. The refgen itself requires two separate power supplies:
vdda-refgen0p9 and vdda-refgen1p2.
Since there is no dedicated driver for REFGEN, add vdda-refgen0p9-supply
and vdda-refgen1p2-supply properties to the PCIe PHY dt-bindings. Use
conditional schema to restrict these properties to only Glymur PCIe QMP
PHYs.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
.../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
index 82316aa5e15f2bde9c32c112876dd820f9450e94..5f60b472264d54b714538c869a095e620b0eba2d 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -90,6 +90,10 @@ properties:
vdda-qref-supply: true
+ vdda-refgen0p9-supply: true
+
+ vdda-refgen1p2-supply: true
+
qcom,4ln-config-sel:
description: PCIe 4-lane configuration
$ref: /schemas/types.yaml#/definitions/phandle-array
@@ -259,6 +263,22 @@ allOf:
"#clock-cells":
const: 0
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-qmp-gen4x2-pcie-phy
+ - qcom,glymur-qmp-gen5x4-pcie-phy
+ then:
+ properties:
+ vdda-refgen0p9-supply: true
+ vdda-refgen1p2-supply: true
+ else:
+ properties:
+ vdda-refgen0p9-supply: false
+ vdda-refgen1p2-supply: false
+
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 0/2] phy: qcom: qmp-pcie: Add vdda-refgen supply support for Glymur
From: Qiang Yu @ 2026-02-09 4:49 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
The PCIe QMP PHYs on Glymur require both refgen for stable reference
voltage and qref for stable reference clock. The refgen requires two power
supplies: vdda-refgen0p9 and vdda-refgen1p2.
Unlike qref, refgen doesn't require register configuration and has no
dedicated driver. Therefore, the PHY driver must vote for the regulators
that refgen requires.
While refgen may be a common component across different platforms, on
older platforms it typically shares regulators with PHY core or qref
supplies, making refgen supplies map not very clear. Glymur introduces
dedicated refgen supplies that require explicit management.
Hence, this series adds support for refgen power supplies specifically to
Glymur PCIe QMP PHY. If other platforms require these supplies, support
can be extended in the future.
This series creates a Glymur-specific supply list including the refgen
supplies and updates both Gen5x4 and Gen4x2 configurations to use it.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
Qiang Yu (2):
dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add vdda-refgen supply for Glymur
phy: qcom: qmp-pcie: Add vdda-refgen supplies for Glymur
.../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 20 ++++++++++++++++++++
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 12 ++++++++----
2 files changed, 28 insertions(+), 4 deletions(-)
---
base-commit: 8bb92fd7a04077925c8330f46a6ab44c80ca59f4
change-id: 20260202-refgen-f0a611d5c355
Best regards,
--
Qiang Yu <qiang.yu@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 7/7] mmc: host: renesas_sdhi_core: support selecting an optional mux
From: kernel test robot @ 2026-02-09 2:12 UTC (permalink / raw)
To: Josua Mayer, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
Neil Armstrong, Peter Rosin, Aaro Koskinen, Andreas Kemnade,
Kevin Hilman, Roger Quadros, Tony Lindgren, Janusz Krzysztofik,
Vignesh R, Andi Shyti, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: oe-kbuild-all, Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can, linux-phy, linux-kernel, linux-omap, linux-i2c,
linux-mmc, devicetree
In-Reply-To: <20260208-rz-sdio-mux-v9-7-9a3be13c1280@solid-run.com>
Hi Josua,
kernel test robot noticed the following build errors:
[auto build test ERROR on 8f0b4cce4481fb22653697cced8d0d04027cb1e8]
url: https://github.com/intel-lab-lkp/linux/commits/Josua-Mayer/phy-can-transceiver-rename-temporary-helper-function-to-avoid-conflict/20260208-234345
base: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
patch link: https://lore.kernel.org/r/20260208-rz-sdio-mux-v9-7-9a3be13c1280%40solid-run.com
patch subject: [PATCH v9 7/7] mmc: host: renesas_sdhi_core: support selecting an optional mux
config: s390-randconfig-r054-20260209 (https://download.01.org/0day-ci/archive/20260209/202602091037.wNIGJdbh-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260209/202602091037.wNIGJdbh-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602091037.wNIGJdbh-lkp@intel.com/
All errors (new ones prefixed by >>):
s390-linux-ld: drivers/mmc/host/renesas_sdhi_core.o: in function `renesas_sdhi_probe':
>> renesas_sdhi_core.c:(.text+0x1996): undefined reference to `devm_mux_state_get_optional_selected'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox