* Re: [PATCH 3/3] phy: qcom: edp: Add eDP phy mode switch support
From: Yongxing Mou @ 2026-02-25 8:00 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <f7fed0cc-0c59-4a75-b045-a83df924113d@oss.qualcomm.com>
On 2/13/2026 7:06 PM, Konrad Dybcio wrote:
> On 2/10/26 11:29 AM, Yongxing Mou wrote:
>>
>>
>> On 2/6/2026 7:02 PM, Konrad Dybcio wrote:
>>> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>>>> Add DP/eDP switch support by splitting the PHY swing/pre-emphasis tables
>>>> into separate DP and eDP configurations. This allows the driver to select
>>>> the correct table based on the is_edp flag.
>>>>
>>>> Add a dedicated table for the SC7280/glymur platforms, as they are not
>>>> compatible with the others.
>>>>
>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> +static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
>>>> + { 0x0b, 0x11, 0x16, 0x1b },
>>>> + { 0x0b, 0x19, 0x1f, 0xff },
>>>> + { 0x18, 0x1f, 0xff, 0xff },
>>>> + { 0x1f, 0xff, 0xff, 0xff }
>>>> +};
>>>> +
>>>> +static const u8 edp_pre_emp_hbr2_hbr3_v3[4][4] = {
>>>> + { 0x0c, 0x15, 0x19, 0x1e },
>>>> + { 0x09, 0x14, 0x19, 0xff },
>>>> + { 0x0f, 0x14, 0xff, 0xff },
>>>> + { 0x0d, 0xff, 0xff, 0xff }
>>>> +};
>>>
>>> This is not quite in line with docs for kodiak. Now, if you have
>>> better/newer sequences than the HPG, I'm not objecting, but please
>>> cross-check
>>>
>>> the rest of this patch I think looks fine
>>>
>>> Konrad
>> Thanks for point that..
>>>> +static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
>>>> + { 0x0b, 0x11, 0x16, 0x1b },
>> here should be { 0x06, 0x11, 0x16, 0x1b }, arr[0][1]: 0x0b->0x06
>> does this looks fine? will check tables again..
>
> For kodiak I see:
>
> eDP HBR23 / low vdiff:
>
> swing
> 0x0b, 0x11, 0x17, 0x1c
> 0x10, 0x19, 0x1f
> 0x19, 0x1f
> 0x1f
>
> preemp
> 0x0c, 0x15, 0x19, 0x1e
> 0x08, 0x15, 0x19
> 0x0e, 0x14
> 0x0d
>
> (notice how that mostly differs by the lowest bit being (not)set vs
> your proposal)
>
> eDP HBR23 / high vdiff:
>
> swing
> 0x0a, 0x11, 0x17, 0x1f
> 0x0c, 0x14, 0x1d
> 0x15, 0x1f
> 0x17
>
> preemp
>
> 0x08, 0x11, 0x17, 0x1b
> 0x00, 0x0c, 0x13
> 0x05, 0x10,
> 0x00
>
> Konrad
Hi, this is different from what I saw. what i saw
from kodiak HPG:
eDP low vdiff (High HBR):
0x06, 0x11, 0x16, 0x1B
0x0B, 0x19, 0x1f
0x18, 0x1f
0x1f
preemp
0x0c, 0x15, 0x19, 0x1e
0x09, 0x14, 0x19
0x0f, 0x14
0x0d
eDP high vdiff (High HBR):
swing
0x0a, 0x11, 0x17, 0x1f
0x0c, 0x14, 0x1d
0x15, 0x1f
0x17
preemp
0x08, 0x11, 0x16, 0x1b
0x00, 0x0c, 0x13
0x05, 0x10,
0x00
The set of values you provided looks more like data from LeMans /
SC8280xp / glymur (low vidff). I’ll follow up by email later to confirm
whether this is due to us using different HPGs.
thanks.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] scsi: ufs: qcom,sc7180-ufshc: dt-bindings: Document the Milos UFS Controller
From: Luca Weiss @ 2026-02-25 7:38 UTC (permalink / raw)
To: Martin K. Petersen, Luca Weiss
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Alim Akhtar, Avri Altman,
Bart Van Assche, Vinod Koul, Neil Armstrong, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Krzysztof Kozlowski
In-Reply-To: <yq14in67xwd.fsf@ca-mkp.ca.oracle.com>
On Tue Feb 24, 2026 at 8:19 PM CET, Martin K. Petersen wrote:
>
> Luca,
>
>> I've added you to this email now since you seem to pick up most patches
>> for these files. Could you take this one please to unblock Milos UFS
>> dts?
>
> Applied #2, #5, and #6 to 7.1/scsi-staging, thanks!
Hi Martin,
Thanks for picking up the bindings!
I'm surprised you picked up the dts as well (and modified the subject
line), these patches should go via Bjorn's qcom tree.
* scsi: qcom: milos: arm64: dts: Add UFS nodes
* scsi: qcom: milos-fairphone-fp6: arm64: dts: Enable UFS
I also see these in your staging branch as well:
* scsi: qcom: hamoa: arm64: dts: Add UFS nodes for x1e80100 SoC
* scsi: qcom: hamoa-iot-evk: arm64: dts: Enable UFS
Regards
Luca
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/3] phy: qcom: edp: Add per-version LDO configuration callback
From: Yongxing Mou @ 2026-02-25 7:21 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong, Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <ece590b8-9a29-49f2-934b-6082f093290d@oss.qualcomm.com>
On 2/13/2026 7:14 PM, Konrad Dybcio wrote:
> On 2/12/26 10:04 AM, Yongxing Mou wrote:
>>
>>
>> On 2/6/2026 6:52 PM, Konrad Dybcio wrote:
>>> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>>>> Introduce the com_ldo_config callback to support per‑PHY LDO
>>>> configuration.
>>>>
>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> +static int qcom_edp_ldo_config_v4(const struct qcom_edp *edp)
>>>> +{
>>>> + const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
>>>> + u32 ldo_config;
>>>> +
>>>> + if (!edp->is_edp)
>>>> + ldo_config = 0x0;
>>>> + else if (dp_opts->link_rate <= 2700)
>>>> + ldo_config = 0xC1;
>>>
>>> lowercase hex, please
>>>
>>>> + else
>>>> + ldo_config = 0x81;
>>>> +
>>>> + writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
>>>> + writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
>>>
>>> tx1 should be dp_ops->lanes ? 2 : ldo_config : 0x00, in all cases,
>>> I believe
>>>
>>> Konrad
>> Hi, here i want to confirm again.. In the HPG main link brinup sequence, it not say write TX0/TX1 ldo_config based on the lane count. Only when we switch the lane mode, the LDO config will be updated according to the lane count. so here do we really need this condition?
>
> I don't believe these two cases are differentiated in your patch, unless
> you're trying to say that the hardware is smart enough to turn off the LDO
> for TX23 on its own as we switch modes, which I wouldn't bet it is and can't
> find confirmation for
>
> Konrad
Got it. will update next patch.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 10/23] scsi: ufs: mediatek: Handle misc host voltage regulators
From: Peter Wang (王信友) @ 2026-02-25 7:20 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-10-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> MediaTek SoCs handled by this driver contain a per-SoC specific set
> of
> miscellaneous supplies. These feed parts of the UFS controller
> silicon
> inside the SoC, as opposed to the UFS card.
>
> Add the necessary driver code to acquire these supplies using the
> regulator bulk API. They should be kept on during suspend, so enable
> them when acquiring.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 10/23] scsi: ufs: mediatek: Handle misc host voltage regulators
From: Peter Wang (王信友) @ 2026-02-25 7:19 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno,
Chaotian Jing (井朝天), conor+dt@kernel.org,
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, avri.altman@wdc.com, broonie@kernel.org,
martin.petersen@oracle.com
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <24445e6d-c308-4df2-8b3e-7ee8a8e3f2fe@collabora.com>
On Tue, 2026-02-24 at 13:41 +0100, AngeloGioacchino Del Regno wrote
>
>
> Because:
> 1. The UFS driver has to acquire the correct supplies regardless of
> them
> being on, guaranteeing both a readable power tree
> (sysfs/debugfs) and
> a correct hardware description in devicetree.
> 2. A future update might get those regulators disabled during deep
> sleep
>
> Regards,
> Angelo
>
Hi Nicolas,
Okay, providing correct supplies and hardware descriptions is welcome,
but I am afraid these regulators cannot be disabled even when entering
deep sleep.
Thanks
Peter
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 10/23] scsi: ufs: mediatek: Handle misc host voltage regulators
From: Peter Wang (王信友) @ 2026-02-25 7:18 UTC (permalink / raw)
To: broonie@kernel.org
Cc: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@hansenpartnership.com, kernel@collabora.com,
bvanassche@acm.org, AngeloGioacchino Del Regno,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
Chaotian Jing (井朝天), conor+dt@kernel.org,
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, linux-mediatek@lists.infradead.org,
krzk+dt@kernel.org, linux-phy@lists.infradead.org,
Louis-Alexis Eyraud, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, avri.altman@wdc.com,
martin.petersen@oracle.com
In-Reply-To: <3f4920b2-4697-4897-bdca-65c9f02909d8@sirena.org.uk>
On Tue, 2026-02-24 at 12:48 +0000, Mark Brown wrote:
> Drivers should request and enable any regulators they require, they
> should not rely on boards happening to enable a supply for them.
> Similarly the board should only impose constraints that come from the
> system design, it should not assume that drivers will continue to
> behave
> as they do.
Hi Mark,
Thank you for your detailed explanation.
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 6/6] gpu: drm: mediatek: ovl: add specific entry for mt8167
From: CK Hu (胡俊光) @ 2026-02-25 2:52 UTC (permalink / raw)
To: linux-mediatek@lists.infradead.org, l.scorcia@gmail.com
Cc: robh@kernel.org, Chunfeng Yun (云春峰),
simona@ffwll.ch, tzimmermann@suse.de, mripard@kernel.org,
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
maarten.lankhorst@linux.intel.com, conor+dt@kernel.org,
chunkuang.hu@kernel.org, vkoul@kernel.org, krzk+dt@kernel.org,
linux-phy@lists.infradead.org, p.zabel@pengutronix.de,
dri-devel@lists.freedesktop.org, airlied@gmail.com,
val@packett.cool, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <5f880f1334aa93184afee3e36132ca42628821fb.1771863641.git.l.scorcia@gmail.com>
title:
drm/mediatek: ovl: add specific entry for mt8167
After this modification,
Reviewed-by: CK Hu <ck.hu@mediatek.com>
On Mon, 2026-02-23 at 16:22 +0000, Luca Leonardo Scorcia wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>
>
> From: Val Packett <val@packett.cool>
>
> While this configuration is otherwise identical to mt8173, according
> to Android kernel sources, this SoC does need smi_id_en.
>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index e0236353d499..97a899e4bd99 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -671,6 +671,16 @@ static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> .num_formats = ARRAY_SIZE(mt8173_formats),
> };
>
> +static const struct mtk_disp_ovl_data mt8167_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 8,
> + .layer_nr = 4,
> + .fmt_rgb565_is_0 = true,
> + .smi_id_en = true,
> + .formats = mt8173_formats,
> + .num_formats = ARRAY_SIZE(mt8173_formats),
> +};
> +
> static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
> .addr = DISP_REG_OVL_ADDR_MT8173,
> .gmc_bits = 8,
> @@ -742,6 +752,8 @@ static const struct mtk_disp_ovl_data mt8195_ovl_driver_data = {
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-ovl",
> .data = &mt2701_ovl_driver_data},
> + { .compatible = "mediatek,mt8167-disp-ovl",
> + .data = &mt8167_ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = &mt8173_ovl_driver_data},
> { .compatible = "mediatek,mt8183-disp-ovl",
> --
> 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 v3 5/6] drm/mediatek: dsi: Add compatible for mt8167-dsi
From: CK Hu (胡俊光) @ 2026-02-25 2:41 UTC (permalink / raw)
To: linux-mediatek@lists.infradead.org, l.scorcia@gmail.com
Cc: robh@kernel.org, Chunfeng Yun (云春峰),
tzimmermann@suse.de, simona@ffwll.ch, mripard@kernel.org,
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
maarten.lankhorst@linux.intel.com,
dri-devel@lists.freedesktop.org, chunkuang.hu@kernel.org,
vkoul@kernel.org, krzk+dt@kernel.org,
linux-phy@lists.infradead.org, p.zabel@pengutronix.de,
conor+dt@kernel.org, airlied@gmail.com,
linux-arm-kernel@lists.infradead.org, matthias.bgg@gmail.com,
neil.armstrong@linaro.org, devicetree@vger.kernel.org
In-Reply-To: <2fbf179c03c61f527e2583f9df4f97f6aaf3297a.1771863641.git.l.scorcia@gmail.com>
On Mon, 2026-02-23 at 16:22 +0000, Luca Leonardo Scorcia wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>
>
> The mt8167 DSI controller is fully compatible with the one found in
> mt2701. Device tree documentation is already present upstream.
If mt8167 DSI is fully compatible with mt2701 DSI, I think the binding document and device tree should be modified.
In device tree,
compatible = "mediatek,mt8167-dsi", "mediatek,mt2701-dsi";
And this patch is not necessary.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index af4871de9e4c..ad10e86b161d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1301,6 +1301,7 @@ static const struct mtk_dsi_driver_data mt8188_dsi_driver_data = {
>
> static const struct of_device_id mtk_dsi_of_match[] = {
> { .compatible = "mediatek,mt2701-dsi", .data = &mt2701_dsi_driver_data },
> + { .compatible = "mediatek,mt8167-dsi", .data = &mt2701_dsi_driver_data },
> { .compatible = "mediatek,mt8173-dsi", .data = &mt8173_dsi_driver_data },
> { .compatible = "mediatek,mt8183-dsi", .data = &mt8183_dsi_driver_data },
> { .compatible = "mediatek,mt8186-dsi", .data = &mt8186_dsi_driver_data },
> --
> 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 v3 3/6] dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
From: CK Hu (胡俊光) @ 2026-02-25 2:27 UTC (permalink / raw)
To: linux-mediatek@lists.infradead.org, l.scorcia@gmail.com
Cc: robh@kernel.org, Chunfeng Yun (云春峰),
krzysztof.kozlowski@oss.qualcomm.com, simona@ffwll.ch,
tzimmermann@suse.de, mripard@kernel.org,
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
maarten.lankhorst@linux.intel.com, conor+dt@kernel.org,
chunkuang.hu@kernel.org, vkoul@kernel.org, krzk+dt@kernel.org,
linux-phy@lists.infradead.org, p.zabel@pengutronix.de,
dri-devel@lists.freedesktop.org, airlied@gmail.com,
linux-arm-kernel@lists.infradead.org, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, devicetree@vger.kernel.org
In-Reply-To: <92530e0a31eca1feb822f5c5fd4ac894937dd6c7.1771863641.git.l.scorcia@gmail.com>
On Mon, 2026-02-23 at 16:22 +0000, Luca Leonardo Scorcia wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>
>
> Add support for the MediaTek mt8167 SoC: the DSI PHY found
> in this chip is fully compatible with the one found in the mt2701 SoC.
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> index acdbce937b0a..c6d0bbdbe0e2 100644
> --- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> @@ -23,6 +23,7 @@ properties:
> - items:
> - enum:
> - mediatek,mt7623-mipi-tx
> + - mediatek,mt8167-mipi-tx
> - const: mediatek,mt2701-mipi-tx
> - items:
> - enum:
> --
> 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 v3 2/6] dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
From: CK Hu (胡俊光) @ 2026-02-25 2:23 UTC (permalink / raw)
To: linux-mediatek@lists.infradead.org, l.scorcia@gmail.com
Cc: robh@kernel.org, Chunfeng Yun (云春峰),
krzysztof.kozlowski@oss.qualcomm.com, simona@ffwll.ch,
tzimmermann@suse.de, mripard@kernel.org,
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
maarten.lankhorst@linux.intel.com, conor+dt@kernel.org,
chunkuang.hu@kernel.org, vkoul@kernel.org, krzk+dt@kernel.org,
linux-phy@lists.infradead.org, p.zabel@pengutronix.de,
dri-devel@lists.freedesktop.org, airlied@gmail.com,
linux-arm-kernel@lists.infradead.org, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, devicetree@vger.kernel.org
In-Reply-To: <66eafae30f9fe00b469e79d385c1ddd24d209475.1771863641.git.l.scorcia@gmail.com>
On Mon, 2026-02-23 at 16:22 +0000, Luca Leonardo Scorcia wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>
>
> Add compatibles for various display-related blocks of MediaTek mt8167.
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 4 +++-
> .../devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,wdma.yaml | 4 +++-
> 7 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> index daf90ebb39bf..4bbea72b292a 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> @@ -33,6 +33,7 @@ properties:
> - enum:
> - mediatek,mt2712-disp-aal
> - mediatek,mt6795-disp-aal
> + - mediatek,mt8167-disp-aal
> - const: mediatek,mt8173-disp-aal
> - items:
> - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> index fca8e7bb0cbc..5c5068128d0c 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> @@ -25,7 +25,9 @@ properties:
> - mediatek,mt8183-disp-ccorr
> - mediatek,mt8192-disp-ccorr
> - items:
> - - const: mediatek,mt8365-disp-ccorr
> + - enum:
> + - mediatek,mt8167-disp-ccorr
> + - mediatek,mt8365-disp-ccorr
> - const: mediatek,mt8183-disp-ccorr
> - items:
> - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> index abaf27916d13..891c95be15b9 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> @@ -26,6 +26,7 @@ properties:
> - mediatek,mt8183-disp-dither
> - items:
> - enum:
> + - mediatek,mt8167-disp-dither
> - mediatek,mt8186-disp-dither
> - mediatek,mt8188-disp-dither
> - mediatek,mt8192-disp-dither
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
> index 48542dc7e784..ec1054bb06d4 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
> @@ -28,6 +28,7 @@ properties:
> - items:
> - enum:
> - mediatek,mt6795-disp-gamma
> + - mediatek,mt8167-disp-gamma
> - const: mediatek,mt8173-disp-gamma
> - items:
> - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
> index 4f110635afb6..679f731f0f15 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
> @@ -23,6 +23,7 @@ properties:
> oneOf:
> - enum:
> - mediatek,mt2701-disp-ovl
> + - mediatek,mt8167-disp-ovl
> - mediatek,mt8173-disp-ovl
> - mediatek,mt8183-disp-ovl
> - mediatek,mt8192-disp-ovl
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
> index 878f676b581f..cb187a95c11e 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
> @@ -36,6 +36,7 @@ properties:
> - enum:
> - mediatek,mt7623-disp-rdma
> - mediatek,mt2712-disp-rdma
> + - mediatek,mt8167-disp-rdma
> - const: mediatek,mt2701-disp-rdma
> - items:
> - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
> index a3a2b71a4523..816841a96133 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
> @@ -24,7 +24,9 @@ properties:
> - enum:
> - mediatek,mt8173-disp-wdma
> - items:
> - - const: mediatek,mt6795-disp-wdma
> + - enum:
> + - mediatek,mt6795-disp-wdma
> + - mediatek,mt8167-disp-wdma
> - const: mediatek,mt8173-disp-wdma
>
> reg:
> --
> 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] phy: core: fix potential UAF in of_phy_simple_xlate()
From: Dmitry Torokhov @ 2026-02-24 20:38 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Kishon Vijay Abraham I, Neil Armstrong,
Rafael J. Wysocki, Geert Uytterhoeven, Johan Hovold,
Claudiu Beznea, Dr. David Alan Gilbert, Peter Griffin,
Dmitry Baryshkov, Krzysztof Kozlowski, Zijun Hu, linux-phy,
linux-kernel
In-Reply-To: <20260224154730.qqnomchkdpxnyf4x@skbuf>
On Tue, Feb 24, 2026 at 05:47:30PM +0200, Vladimir Oltean wrote:
> On Mon, Feb 23, 2026 at 04:37:39PM -0800, Dmitry Torokhov wrote:
> > > You have hit on a weak spot of the Generic PHY framework and I would
> > > like to encourage you to follow through with patches for this finding
> > > (although it won't be exactly trivial, I think it's doable with some
> > > determination).
> >
> > Thank you for the detailed response. I am not sure how much time I can
> > spend on phy rework as this change was an essentially a drive-by. I only
> > happen to look there because I want to remove
> > class_find_device_by_of_node() in favor of class_find_device_by_fwnode().
>
> OK, I believe you can still do that without any dependency.
Right, this is independent, I just happened to look at that function.
>
> > > On your direct question:
> > > It will impact downstream in subtle and unpleasant ways if you change
> > > the of_xlate() semantics w.r.t. reference counting, but the code will
> > > still compile just as before, i.e. when looking just at your downstream
> > > driver (what 99% of developers do) there will be no obvious way of
> > > knowing that something in the API has changed. I would avoid doing that.
> >
> > Hmm, I was not aware that we needed to take particular measures for
> > benefit of downstream trees...
>
> I think you're entirely missing the point.
>
> Obviously it benefits the maintainer/reviewer first and foremost. If you
> don't make the API change unmissable, drivers expecting the old convention
> will eventually creep their way into the mainline kernel. Why put avoidable
> pressure on reviewers watching out for things like this for years to come,
> when you can force downstream to notice and adapt (OR not make the
> change in the first place). Note that downstream means "API consumers
> invisible to you, the API changer", not only "hopelessly un-upstreamable
> drivers".
Well, this is whole "stable kernel API" argument. Rules of lifetime
around objects may change and the kernel needs to adapt. Anyway, this is
your subsystem so you get to decide.
>
> > > The patch above leaves a few loose ends.
> > >
> > > The most obvious is of_phy_simple_xlate(), which has that put_device()
> > > to balance out class_find_device_by_of_node() - which bumps the device
> > > refcount to 2. It "looks" wrong but it is consistent with vendor
> > > implementations of of_xlate(), which also provide a phy->dev refcount of 1.
> > > And as explained, the refcount never _actually_ drops to 0 with the
> > > above patch.
> > >
> > > I would actually address _only_ of_phy_simple_xlate(), for cosmetics sake.
> > > Instead of devm_of_phy_provider_register(..., of_phy_simple_xlate), I
> > > would offer a new helper, devm_of_phy_simple_provider_register(), which
> > > would internally use a callback that doesn't drop the refcount (say
> > > __of_phy_simple_xlate() for lack of imagination). I would convert vendor
> > > PHY drivers one by one to use this (it would be valid at any time to use
> > > either the old or the new method).
> > >
> > > You'd notice that most of the of_phy_simple_xlate() occurrences go away,
> > > except for freescale/phy-fsl-lynx-28g.c which calls this function
> > > directly from its own lynx_28g_xlate(). It will still have to keep
> > > calling it, and for refcount equalization purposes that weird
> > > put_device() will have to continue to exist. Just leave a comment as to
> > > why that is.
> >
> > I this case I would simply add a comment telling why the reference
> > should (and can) be dropped where it is being dropped in
> > of_phy_simple_xlate() and call it a day. There is not much benefit in
> > adding another helper.
>
> OK.
>
> > > But there are more important loose ends still.
> > >
> > > I mentioned that "zombie" device. We've solved the memory safety issue,
> > > but it's possible for consumers to hold onto a phy whose provider has
> > > disappeared. The refcount of &phy->dev hasn't dropped to 0, so
> > > technically it's a valid object, but from PHY API perspective, it's
> > > still possible to call phy_init(), phy_power_on() and friends on this
> > > PHY, and the Generic PHY core will be happy to further call into the
> > > phy->ops->init(), phy->ops->power_on() etc. But the driver has unbound,
> > > so it should really be left alone.
> > >
> > > If we fix the UAF but leave the zombie PHY problem, we've effectively
> > > done nothing but silence static analysis checkers, while the code path
> > > where the PHY provider unbinds effectively remains treated as poorly as
> > > before, just moving the crashes to a different place.
> > >
> > > I suspect what needs to be done here is to introduce a "bool dead" or
> > > similar, which is to be set from phy_destroy() and checked from every
> > > API call. The idea is that API functions on zombie PHYs should fail
> > > without calling into their driver. I **suppose** that
> > > try_module_get(phy->ops->owner) "tried" to avoid this situation, but
> > > it just protects against module removal, not against "echo device >
> > > /sys/bus/.../unbind". So it's absolutely incomplete and easily bypassable.
> >
> > I think this is a problem common to many kernel subsystems, where there
> > are devices that are vital for other devices to function, but are not
> > parents of said devices. Think about regulators or clocks and such.
> > In many such cases even validating at API level is not sufficient,
> > because if you enable a clock you typically keep it running at least for
> > a while, if not for entire duration of device being bound to a driver.
> > If that clock goes away the device will break even though you are not
> > calling any clock APIs at that particular time.
> >
> > We need some kind of revocation mechanism to signal consumers that
> > providers they rely upon are going away.
>
> Yeah, this gave me pause.
>
> When you unbind a Generic PHY you can kind of expect that the data path
> it affects to not work. But you'd sort of expect it to start working
> again when you rebind the PHY driver.
>
> That will not be the case, though.
>
> The problem, simply put, is that the struct phy that the consumer has
> will be different from the second struct phy that the provider registers
> when it rebinds. Using the stale struct phy, we cannot reach the phy_ops
> of the new provider.
>
> If we implement something similar to what Bartosz Golaszewski suggested
> here:
> https://lpc.events/event/17/contributions/1627/
There is also "revocable" from Tzung-Bi Shih.
>
> aka decouple the struct phy given to the consumer from the struct phy
> provided by the provider, and perform a PHY lookup during each
> phy_init() / phy_power_up() / etc etc operation;
>
> we are kinda able to:
> - match the consumer phy to the provider phy and forward the call to
> phy_ops, if the provider is present (or rebound)
> - return -ENODEV instead of calling into phy_ops, if the provider is not
> present
>
> But there's still one big gap.
>
> PHY consumers are driving the PHY through a state machine when they do
> phy_init -> phy_power_up() -> phy_set_mode() -> [ phy_configure()...].
> When the provider unbinds and then rebinds, that state is lost. But the
> consumer has no idea. It knows it is in a state where it called
> phy_power_up(), and next thing it knows, the power_count is 1 and it
> must call phy_power_down().
>
> The Generic PHY core cannot actually replay the entire state in a
> meaningful way so as to make the provider reprobing completely
> transparent (think of phy_calibrate() calls).
>
> So I guess we're looking at what Bartosz refers to as a notification
> side-channel that the PHY provider is going away.
>
> At least, for drivers that care in a meaningful way. For drivers that
> don't care about such complexity, there seems to be a simpler answer:
> device_link_add(DL_FLAG_AUTOREMOVE_CONSUMER).
Does DL_FLAG_AUTOREMOVE_CONSUMER result in forceful unbinding of the
consumer when provider goes away? And if it happens does it happen in
the right order?
>
> I can also answer why device links with "autoremove consumer" are not a
> universal answer. This is because the consumer itself may be a
> multi-port network switch (single device). If you unbind the Generic PHY
> driver (retimer, SerDes PHY) from port 3, you don't want ports 0, 1 and
> 2 to also disappear from the kernel. You need the more complex PHY
> provider disappearance notification which does something more localized
> (calls phylink_stop(), I don't know).
Aren't the ports represented as individual devices with their own state
and lifetime?
>
>
> I can say right off the bat that this is too complicated for me to even
> think about in more detail than that, at the moment. I would be quite
> happy if it's possible to unbind the PHY driver without the possibility
> to rebind it, as a first step.
Yes, this is something that is not phy specific and I think should be
solved at driver core (or at least driver core should provide subsystems
tools to solve this).
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH V5 0/3] Add UFS support for x1e80100 SoC
From: Martin K. Petersen @ 2026-02-24 19:40 UTC (permalink / raw)
To: Pradeep P V K
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, martin.petersen,
andersson, konradybcio, taniya.das, dmitry.baryshkov,
manivannan.sadhasivam, linux-arm-msm, linux-phy, devicetree,
linux-kernel, linux-scsi, nitin.rawat
In-Reply-To: <20260211132926.3716716-1-pradeep.pragallapati@oss.qualcomm.com>
Pradeep,
> Add UFSPHY, UFSHC compatible binding names and UFS devicetree
> enablement changes for Qualcomm x1e80100 SoC.
Applied to 7.1/scsi-staging. Please validate conflict resolution in
qcom,sc7180-ufshc.yaml, thanks!
--
Martin K. Petersen
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] scsi: ufs: qcom,sc7180-ufshc: dt-bindings: Document the Milos UFS Controller
From: Martin K. Petersen @ 2026-02-24 19:19 UTC (permalink / raw)
To: Luca Weiss
Cc: Martin K. Petersen, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Alim Akhtar,
Avri Altman, Bart Van Assche, Vinod Koul, Neil Armstrong,
Konrad Dybcio, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, linux-crypto, devicetree, linux-kernel, linux-scsi,
linux-phy, Krzysztof Kozlowski
In-Reply-To: <DGDW69W84LJ1.2GHM2WU31VANR@fairphone.com>
Luca,
> I've added you to this email now since you seem to pick up most patches
> for these files. Could you take this one please to unblock Milos UFS
> dts?
Applied #2, #5, and #6 to 7.1/scsi-staging, thanks!
--
Martin K. Petersen
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/4] phy: phy-can-transceiver: Convert to use device property API
From: Vladimir Oltean @ 2026-02-24 18:30 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-can, linux-phy, linux-kernel, Marc Kleine-Budde,
Vincent Mailhol, Vinod Koul, Neil Armstrong, Josua Mayer
In-Reply-To: <aZ3X2J1rBq1pMkae@smile.fi.intel.com>
On Tue, Feb 24, 2026 at 06:54:48PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 24, 2026 at 06:26:06PM +0200, Vladimir Oltean wrote:
> > On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote:
>
> ...
>
> > > - if (!of_property_present(dev->of_node, "mux-states"))
> > > + if (!device_property_present(dev, "mux-states"))
> >
> > There's an entire saga with this function - devm_mux_state_get_optional().
> > Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series.
> > Would you mind not touching this, to avoid complicating what is already
> > a complicated operation? It is going away anyway, and from what I can
> > see in Josua's last series, its implementation from drivers/mux/core.c
> > is already using device property APIs:
> > https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/
>
> Basically you ask me to postpone the series until that will be in. Since this
> file is a mess in terms of OF/fwnode API use in exchange I would like whoever
> is doing the other part to speed up a bit if possible.
>
> I prefer to see cleaner solution to be applied sooner and last in a long distance,
> that's why I see either mine first but soon, or that first but also soon should
> be in. Can we try to achieve that?
The idea is that Ulf already expressed the availability to take the phy-can-transceiver
patch through the mmc tree and provide back a tag to be pulled into linux-phy:
https://lore.kernel.org/linux-phy/CAPDyKFrtTaJ5fqqbGrE_K6SAdTZYUfp-BycGjtWs4SabwBysKA@mail.gmail.com/
If linux-phy takes your patch first, there will be a conflict when pulling the
stable branch, and it won't be so fun, plus we can't even build-test Josua's
submission on linux-phy, so that's obviously not great.
So yeah, I'm not requesting you to postpone the entire series, just not
touch devm_mux_state_get_optional() and don't let it appear in your
patch context.
Somebody will have to remove "#include <linux/of.h>" at the end of the
whole process, but that's minor.
> ...
>
> > > - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops);
> > > + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops);
> >
> > It is not obvious why you replaced dev->of_node with NULL here.
> > It doesn't appear correct. You seem to be breaking OF-based PHY lookups.
>
> It's the default. Yeah, I probably have to explain this in the commit message.
Ah, ok. Found the "phy->dev.of_node = node ?: dev->of_node;" assignment.
Sorry and noted, but please add it to the commit message too.
> Basically all devm_phy_create(dev, dev->of_node, ...) for clarity should be
> converted to that approach. Or even better, a new (agnostic) API should take
> default fwnode from the same device.
>
> phy = devm_phy_create_simple(dev, &..._phy_ops);
>
> // name was quickly chosen and may be not the best we can come up with
I agree in principle. PHY drivers shouldn't be given a function where
they routinely have to set one of the arguments to NULL, but a simpler
function without that argument.
But the phy-core.c doesn't support fwnode at all yet, it uses OF
throughout. I think it would be preferable to leave this change to
somebody who has business in that area.
(are you interested in PHYs with a fwnode for any particular reason, or
just because the API is more "generic" just in case?)
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 3/8] phy: Add driver for EyeQ5 Ethernet PHY wrapper
From: Théo Lebrun @ 2026-02-24 17:20 UTC (permalink / raw)
To: Vladimir Oltean, Théo Lebrun
Cc: Vladimir Kondratiev, Grégory Clement, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Kishon Vijay Abraham I, Michael Turquette, Stephen Boyd,
Philipp Zabel, Thomas Bogendoerfer, Neil Armstrong, linux-mips,
devicetree, linux-kernel, linux-phy, linux-clk, Benoît Monin,
Tawfik Bayouk, Thomas Petazzoni, Luca Ceresoli
In-Reply-To: <20260210193516.temrg46yozxma7xb@skbuf>
Hello Vladimir,
On Tue Feb 10, 2026 at 8:35 PM CET, Vladimir Oltean wrote:
> On Tue, Jan 27, 2026 at 06:09:31PM +0100, Théo Lebrun wrote:
>> +static int eq5_phy_init(struct phy *phy)
>> +{
>> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
>> + struct eq5_phy_private *priv = inst->priv;
>> + struct device *dev = priv->dev;
>> + u32 reg;
>> +
>> + dev_dbg(dev, "phy_init(inst=%td)\n", inst - priv->phys);
>
> Nitpick: can you please remove the debugging prints and maybe add some
> trace points to the PHY core if you feel strongly about having some
> introspection?
Ack!
>> +
>> + writel(0, inst->gp);
>> + writel(0, inst->sgmii);
>> +
>> + udelay(5);
>
> Could you please add a macro or comment hinting at the origin of the
> magic number 5 here? You could also place these 3 lines in a common
> helper, also called from eq5_phy_exit(), to avoid minor code
> duplication.
ACK, something named `eq5_phy_reinit()`.
I don't have precise explanation for the 5µs value; I only know it is
time to let the PHY settle before further register config writes.
Is this enough?
udelay(5); /* settling time */
>> +
>> + reg = readl(inst->gp) | EQ5_GP_TX_SWRST_DIS | EQ5_GP_TX_M_CLKE |
>
> When you write 0 to inst->gp and then read it back, do you expect to
> (a) get back 0 or
> (b) are some fields non-resetting?
>
> I see both as inconsistent, since if (a), you can remove the
> readl(inst->gp) and expect the same result. And if (b), it also
> shouldn't matter if you write zeroes a second time, if it was fine the
> first time?
>
> Shortly said, is readl(inst->gp) really needed?
Some fields are non-resetting (BIT 30).
Will drop. I was trying to play it safe for no good reason.
>
>> + EQ5_GP_SYS_SWRST_DIS | EQ5_GP_SYS_M_CLKE |
>> + FIELD_PREP(EQ5_GP_RGMII_DRV, 0x9);
>
> Quick sanity check on your proposal to use #phy-cells = <1>. This is not
> a request to change anything.
>
> What if you need to customize the RGMII drive strength (or some other
> setting, maybe SGMII polarity if that is available) per lane, for a
> particular board? How would you do that if each PHY does not have its
> own OF node?
I have no knowledge of what that 0x9 stands for, I didn't see the point
exposing it to devicetree. We could plan for the future and add a cell
or create subnodes, but here I kept it simple stupid. Is it OK?
>> + writel(reg, inst->gp);
>> +
>> + return 0;
>> +}
>> +
>> +static int eq5_phy_exit(struct phy *phy)
>> +{
>> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
>> + struct eq5_phy_private *priv = inst->priv;
>> + struct device *dev = priv->dev;
>> +
>> + dev_dbg(dev, "phy_exit(inst=%td)\n", inst - priv->phys);
>> +
>> + writel(0, inst->gp);
>> + writel(0, inst->sgmii);
>> + udelay(5);
>> +
>> + return 0;
>> +}
>> +
>> +static int eq5_phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
>> +{
>> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
>> + struct eq5_phy_private *priv = inst->priv;
>> + struct device *dev = priv->dev;
>> +
>> + dev_dbg(dev, "phy_set_mode(inst=%td, mode=%d, submode=%d)\n",
>> + inst - priv->phys, mode, submode);
>> +
>> + if (mode != PHY_MODE_ETHERNET)
>> + return -EOPNOTSUPP;
>> +
>> + if (!phy_interface_mode_is_rgmii(submode) &&
>> + submode != PHY_INTERFACE_MODE_SGMII)
>> + return -EOPNOTSUPP;
>
> Both PHYs are equal in capabilities, and support both RGMII and SGMII,
> correct? I see the driver is implemented as if they were, but it doesn't
> hurt to ask.
Datasheet indicates 0 can do SGMII/RGMII and 1 can do only RGMII.
Did you imply that the driver code should reject SGMII on PHY 1
if it ever gets asked for?
>> +
>> + inst->phy_interface = submode;
>
> Short story: don't rely on the phy_set_mode_ext() -> phy_power_on() order.
> Implement the driver so that it works the other way around too.
>
> Long story:
> https://lore.kernel.org/netdev/aXzFH09AeIRawCwU@shell.armlinux.org.uk/
I wouldn't mind, but what should phy_power_on() do if no submode has
been provided through phy_set_mode_ext() yet? Guess one? Fail?
Also our PHY will need to be reset to change its mode if we do
power_on() followed by set_mode(), which in practice is never something
we want. Maybe there is a flag to indicate that we require a submode to
power on?
Thanks for the extensive review Vladimir,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/4] phy: phy-can-transceiver: Convert to use device property API
From: Andy Shevchenko @ 2026-02-24 16:54 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-can, linux-phy, linux-kernel, Marc Kleine-Budde,
Vincent Mailhol, Vinod Koul, Neil Armstrong, Josua Mayer
In-Reply-To: <20260224162606.spnzzedvmvp2h7xd@skbuf>
On Tue, Feb 24, 2026 at 06:26:06PM +0200, Vladimir Oltean wrote:
> On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote:
...
> > - if (!of_property_present(dev->of_node, "mux-states"))
> > + if (!device_property_present(dev, "mux-states"))
>
> There's an entire saga with this function - devm_mux_state_get_optional().
> Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series.
> Would you mind not touching this, to avoid complicating what is already
> a complicated operation? It is going away anyway, and from what I can
> see in Josua's last series, its implementation from drivers/mux/core.c
> is already using device property APIs:
> https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/
Basically you ask me to postpone the series until that will be in. Since this
file is a mess in terms of OF/fwnode API use in exchange I would like whoever
is doing the other part to speed up a bit if possible.
I prefer to see cleaner solution to be applied sooner and last in a long distance,
that's why I see either mine first but soon, or that first but also soon should
be in. Can we try to achieve that?
...
> > - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops);
> > + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops);
>
> It is not obvious why you replaced dev->of_node with NULL here.
> It doesn't appear correct. You seem to be breaking OF-based PHY lookups.
It's the default. Yeah, I probably have to explain this in the commit message.
Basically all devm_phy_create(dev, dev->of_node, ...) for clarity should be
converted to that approach. Or even better, a new (agnostic) API should take
default fwnode from the same device.
phy = devm_phy_create_simple(dev, &..._phy_ops);
// name was quickly chosen and may be not the best we can come up with
...
Thanks for the review!
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/4] phy: phy-can-transceiver: Convert to use device property API
From: Vladimir Oltean @ 2026-02-24 16:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-can, linux-phy, linux-kernel, Marc Kleine-Budde,
Vincent Mailhol, Vinod Koul, Neil Armstrong, Josua Mayer
In-Reply-To: <20260219202910.2304440-2-andriy.shevchenko@linux.intel.com>
Hi Andy,
On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote:
> It seems the driver is half-moved to use device property APIs.
> Finish that by converting everything to use that.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/phy/phy-can-transceiver.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 330356706ad7..f2259af4af8a 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
> @@ -5,9 +5,9 @@
> * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
> *
> */
> -#include <linux/of.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/property.h>
> #include <linux/module.h>
> #include <linux/gpio.h>
> #include <linux/gpio/consumer.h>
> @@ -130,7 +130,7 @@ MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
> static inline struct mux_state *
> devm_mux_state_get_optional(struct device *dev, const char *mux_name)
> {
> - if (!of_property_present(dev->of_node, "mux-states"))
> + if (!device_property_present(dev, "mux-states"))
There's an entire saga with this function - devm_mux_state_get_optional().
Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series.
Would you mind not touching this, to avoid complicating what is already
a complicated operation? It is going away anyway, and from what I can
see in Josua's last series, its implementation from drivers/mux/core.c
is already using device property APIs:
https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/
> return NULL;
>
> return devm_mux_state_get(dev, mux_name);
> @@ -162,7 +162,6 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> struct can_transceiver_phy *can_transceiver_phy;
> struct can_transceiver_priv *priv;
> const struct can_transceiver_data *drvdata;
> - const struct of_device_id *match;
> struct phy *phy;
> struct gpio_desc *silent_gpio;
> struct gpio_desc *standby_gpio;
> @@ -171,8 +170,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> u32 max_bitrate = 0;
> int err, i, num_ch = 1;
>
> - match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
> - drvdata = match->data;
> + drvdata = device_get_match_data(dev);
> if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
> num_ch = 2;
>
> @@ -197,7 +195,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> can_transceiver_phy = &priv->can_transceiver_phy[i];
> can_transceiver_phy->priv = priv;
>
> - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops);
> + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops);
It is not obvious why you replaced dev->of_node with NULL here.
It doesn't appear correct. You seem to be breaking OF-based PHY lookups.
> if (IS_ERR(phy)) {
> dev_err(dev, "failed to create can transceiver phy\n");
> return PTR_ERR(phy);
> --
> 2.50.1
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: core: fix potential UAF in of_phy_simple_xlate()
From: Vladimir Oltean @ 2026-02-24 15:47 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Vinod Koul, Kishon Vijay Abraham I, Neil Armstrong,
Rafael J. Wysocki, Geert Uytterhoeven, Johan Hovold,
Claudiu Beznea, Dr. David Alan Gilbert, Peter Griffin,
Dmitry Baryshkov, Krzysztof Kozlowski, Zijun Hu, linux-phy,
linux-kernel
In-Reply-To: <aZzmU_oA6mVMsdQT@google.com>
On Mon, Feb 23, 2026 at 04:37:39PM -0800, Dmitry Torokhov wrote:
> > You have hit on a weak spot of the Generic PHY framework and I would
> > like to encourage you to follow through with patches for this finding
> > (although it won't be exactly trivial, I think it's doable with some
> > determination).
>
> Thank you for the detailed response. I am not sure how much time I can
> spend on phy rework as this change was an essentially a drive-by. I only
> happen to look there because I want to remove
> class_find_device_by_of_node() in favor of class_find_device_by_fwnode().
OK, I believe you can still do that without any dependency.
> > On your direct question:
> > It will impact downstream in subtle and unpleasant ways if you change
> > the of_xlate() semantics w.r.t. reference counting, but the code will
> > still compile just as before, i.e. when looking just at your downstream
> > driver (what 99% of developers do) there will be no obvious way of
> > knowing that something in the API has changed. I would avoid doing that.
>
> Hmm, I was not aware that we needed to take particular measures for
> benefit of downstream trees...
I think you're entirely missing the point.
Obviously it benefits the maintainer/reviewer first and foremost. If you
don't make the API change unmissable, drivers expecting the old convention
will eventually creep their way into the mainline kernel. Why put avoidable
pressure on reviewers watching out for things like this for years to come,
when you can force downstream to notice and adapt (OR not make the
change in the first place). Note that downstream means "API consumers
invisible to you, the API changer", not only "hopelessly un-upstreamable
drivers".
> > The patch above leaves a few loose ends.
> >
> > The most obvious is of_phy_simple_xlate(), which has that put_device()
> > to balance out class_find_device_by_of_node() - which bumps the device
> > refcount to 2. It "looks" wrong but it is consistent with vendor
> > implementations of of_xlate(), which also provide a phy->dev refcount of 1.
> > And as explained, the refcount never _actually_ drops to 0 with the
> > above patch.
> >
> > I would actually address _only_ of_phy_simple_xlate(), for cosmetics sake.
> > Instead of devm_of_phy_provider_register(..., of_phy_simple_xlate), I
> > would offer a new helper, devm_of_phy_simple_provider_register(), which
> > would internally use a callback that doesn't drop the refcount (say
> > __of_phy_simple_xlate() for lack of imagination). I would convert vendor
> > PHY drivers one by one to use this (it would be valid at any time to use
> > either the old or the new method).
> >
> > You'd notice that most of the of_phy_simple_xlate() occurrences go away,
> > except for freescale/phy-fsl-lynx-28g.c which calls this function
> > directly from its own lynx_28g_xlate(). It will still have to keep
> > calling it, and for refcount equalization purposes that weird
> > put_device() will have to continue to exist. Just leave a comment as to
> > why that is.
>
> I this case I would simply add a comment telling why the reference
> should (and can) be dropped where it is being dropped in
> of_phy_simple_xlate() and call it a day. There is not much benefit in
> adding another helper.
OK.
> > But there are more important loose ends still.
> >
> > I mentioned that "zombie" device. We've solved the memory safety issue,
> > but it's possible for consumers to hold onto a phy whose provider has
> > disappeared. The refcount of &phy->dev hasn't dropped to 0, so
> > technically it's a valid object, but from PHY API perspective, it's
> > still possible to call phy_init(), phy_power_on() and friends on this
> > PHY, and the Generic PHY core will be happy to further call into the
> > phy->ops->init(), phy->ops->power_on() etc. But the driver has unbound,
> > so it should really be left alone.
> >
> > If we fix the UAF but leave the zombie PHY problem, we've effectively
> > done nothing but silence static analysis checkers, while the code path
> > where the PHY provider unbinds effectively remains treated as poorly as
> > before, just moving the crashes to a different place.
> >
> > I suspect what needs to be done here is to introduce a "bool dead" or
> > similar, which is to be set from phy_destroy() and checked from every
> > API call. The idea is that API functions on zombie PHYs should fail
> > without calling into their driver. I **suppose** that
> > try_module_get(phy->ops->owner) "tried" to avoid this situation, but
> > it just protects against module removal, not against "echo device >
> > /sys/bus/.../unbind". So it's absolutely incomplete and easily bypassable.
>
> I think this is a problem common to many kernel subsystems, where there
> are devices that are vital for other devices to function, but are not
> parents of said devices. Think about regulators or clocks and such.
> In many such cases even validating at API level is not sufficient,
> because if you enable a clock you typically keep it running at least for
> a while, if not for entire duration of device being bound to a driver.
> If that clock goes away the device will break even though you are not
> calling any clock APIs at that particular time.
>
> We need some kind of revocation mechanism to signal consumers that
> providers they rely upon are going away.
Yeah, this gave me pause.
When you unbind a Generic PHY you can kind of expect that the data path
it affects to not work. But you'd sort of expect it to start working
again when you rebind the PHY driver.
That will not be the case, though.
The problem, simply put, is that the struct phy that the consumer has
will be different from the second struct phy that the provider registers
when it rebinds. Using the stale struct phy, we cannot reach the phy_ops
of the new provider.
If we implement something similar to what Bartosz Golaszewski suggested
here:
https://lpc.events/event/17/contributions/1627/
aka decouple the struct phy given to the consumer from the struct phy
provided by the provider, and perform a PHY lookup during each
phy_init() / phy_power_up() / etc etc operation;
we are kinda able to:
- match the consumer phy to the provider phy and forward the call to
phy_ops, if the provider is present (or rebound)
- return -ENODEV instead of calling into phy_ops, if the provider is not
present
But there's still one big gap.
PHY consumers are driving the PHY through a state machine when they do
phy_init -> phy_power_up() -> phy_set_mode() -> [ phy_configure()...].
When the provider unbinds and then rebinds, that state is lost. But the
consumer has no idea. It knows it is in a state where it called
phy_power_up(), and next thing it knows, the power_count is 1 and it
must call phy_power_down().
The Generic PHY core cannot actually replay the entire state in a
meaningful way so as to make the provider reprobing completely
transparent (think of phy_calibrate() calls).
So I guess we're looking at what Bartosz refers to as a notification
side-channel that the PHY provider is going away.
At least, for drivers that care in a meaningful way. For drivers that
don't care about such complexity, there seems to be a simpler answer:
device_link_add(DL_FLAG_AUTOREMOVE_CONSUMER).
I can also answer why device links with "autoremove consumer" are not a
universal answer. This is because the consumer itself may be a
multi-port network switch (single device). If you unbind the Generic PHY
driver (retimer, SerDes PHY) from port 3, you don't want ports 0, 1 and
2 to also disappear from the kernel. You need the more complex PHY
provider disappearance notification which does something more localized
(calls phylink_stop(), I don't know).
I can say right off the bat that this is too complicated for me to even
think about in more detail than that, at the moment. I would be quite
happy if it's possible to unbind the PHY driver without the possibility
to rebind it, as a first step.
> > Finally, I have identified one more loose end still.
> >
> > /**
> > * of_phy_put() - release the PHY
> > * @phy: the phy returned by of_phy_get()
> > *
> > * Releases a refcount the caller received from of_phy_get().
> > */
> > void of_phy_put(struct phy *phy)
> > {
> > if (!phy || IS_ERR(phy))
> > return;
> >
> > mutex_lock(&phy->mutex);
> > if (phy->ops->release)
> > phy->ops->release(phy);
> > mutex_unlock(&phy->mutex);
> >
> > module_put(phy->ops->owner);
> > put_device(&phy->dev);
> > }
> > EXPORT_SYMBOL_GPL(of_phy_put);
> >
> > This function is called by PHY consumers. A PHY provider can have
> > multiple consumers (example in the case of Ethernet: a QSGMII SerDes
> > lane has 4 MAC ports multiplexed onto it).
> >
> > If a single consumer calls of_phy_put() to release its reference to the
> > SerDes lane, the phy->ops->release() method makes absolutely no sense.
> > There are 3 remaining consumers with handles to the lane! But we aren't
> > even telling the PHY which consumer has disappeared! It has nothing
> > useful to do with this information.
> >
> > Looking at actual phy_ops implementations, what they want to know is
> > when _all_ consumers went away, not when individual consumers did.
> > So the phy->ops->release() call needs to be put somewhere which is
> > executed when all consumers disappear. If I were to guess, that would be
> > the phy_release() class callback, but this is completely untested.
>
> Shouldn't phy->ops->release() keep track of users and decide when to
> destroy the resources? The rest seem fine as they simply drop references
> (I assume each user of shared phy will bump up references as needed?)
AFAICS, the only instance is phy/ti/phy-am654-serdes.c: serdes_am654_release().
This undoes the effect of serdes_am654_xlate(), i.e. calls mux_control_deselect(phy->control).
The fact that phy_provider->of_xlate() has side effects on this
platform, rather than just return a struct phy * for a given struct
device_node * (as it's supposed to do), is "interesting".
I don't have extra info why the PHY maintainer didn't add extra phy_ops
for consumer_bind() and consumer_unbind() or something like that, to
make it clear that these calls are supposed to be _per consumer_.
Notice how the first of_xlate() call sets am654_phy->busy = true, and
second of_xlate() call is designed to fail due to am654_phy->busy.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 10/23] scsi: ufs: mediatek: Handle misc host voltage regulators
From: Mark Brown @ 2026-02-24 12:48 UTC (permalink / raw)
To: Peter Wang (王信友)
Cc: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <2c7c84a2df19624ba9f207fd3fee47a8bdd9d8dc.camel@mediatek.com>
[-- Attachment #1.1: Type: text/plain, Size: 711 bytes --]
On Tue, Feb 24, 2026 at 12:38:50PM +0000, Peter Wang (王信友) wrote:
> On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> > + if (data->num_reg_names) {
> > + ret = devm_regulator_bulk_get_enable(dev, data-
> > >num_reg_names,
> > + data-
> > >reg_names);
> If these regulators are only acquired and enabled once,
> why not just set regulator-always-on in the device tree?
Drivers should request and enable any regulators they require, they
should not rely on boards happening to enable a supply for them.
Similarly the board should only impose constraints that come from the
system design, it should not assume that drivers will continue to behave
as they do.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 16/23] scsi: ufs: mediatek: Clean up logging prints
From: Peter Wang (王信友) @ 2026-02-24 12:47 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-16-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> drivers/ufs/host/ufs-mediatek.c | 99 ++++++++++++++++++-------------
> ----------
> 1 file changed, 43 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-
> mediatek.c
> index ecf16e82a326..2b1f26b55782 100644
> --- a/drivers/ufs/host/ufs-mediatek.c
> +++ b/drivers/ufs/host/ufs-mediatek.c
> @@ -192,8 +192,8 @@ static void ufs_mtk_crypto_enable(struct ufs_hba
> *hba)
>
> ufs_mtk_crypto_ctrl(res, 1);
> if (res.a0) {
> - dev_info(hba->dev, "%s: crypto enable failed, err:
> %lu\n",
> - __func__, res.a0);
> + dev_err(hba->dev, "%s: crypto enable failed with
> error %lu, disabling\n",
> + __func__, res.a0);
> hba->caps &= ~UFSHCD_CAP_CRYPTO;
> }
> }
> @@ -542,40 +542,38 @@ static void ufs_mtk_boost_crypt(struct ufs_hba
> *hba, bool boost)
>
> ret = clk_prepare_enable(cfg->clk_crypt_mux);
> if (ret) {
> - dev_info(hba->dev, "clk_prepare_enable(): %d\n",
> - ret);
> + dev_err(hba->dev, "%s: Failed to enable
> clk_crypt_mux: %pe\n",
> + __func__, ERR_PTR(ret));
> return;
> }
>
> if (boost) {
> ret = regulator_set_voltage(reg, volt, INT_MAX);
> if (ret) {
> - dev_info(hba->dev,
> - "failed to set vcore to %d\n",
> volt);
> + dev_err(hba->dev, "%s: Failed to set vcore
> to %d: %pe\n",
> + __func__, volt, ERR_PTR(ret));
> goto out;
> }
>
> - ret = clk_set_parent(cfg->clk_crypt_mux,
> - cfg->clk_crypt_perf);
> + ret = clk_set_parent(cfg->clk_crypt_mux, cfg-
> >clk_crypt_perf);
> if (ret) {
> - dev_info(hba->dev,
> - "failed to set clk_crypt_perf\n");
> + dev_err(hba->dev, "%s: Failed to reparent
> clk_crypt_perf: %pe\n",
> + __func__, ERR_PTR(ret));
> regulator_set_voltage(reg, 0, INT_MAX);
> goto out;
> }
> } else {
> - ret = clk_set_parent(cfg->clk_crypt_mux,
> - cfg->clk_crypt_lp);
> + ret = clk_set_parent(cfg->clk_crypt_mux, cfg-
> >clk_crypt_lp);
> if (ret) {
> - dev_info(hba->dev,
> - "failed to set clk_crypt_lp\n");
> + dev_err(hba->dev, "%s: Failed to reparent
> clk_crypt_lp: %pe\n",
> + __func__, ERR_PTR(ret));
> goto out;
> }
>
> ret = regulator_set_voltage(reg, 0, INT_MAX);
> if (ret) {
> - dev_info(hba->dev,
> - "failed to set vcore to MIN\n");
> + dev_err(hba->dev, "%s: Failed to set vcore
> to minimum: %pe\n",
> + __func__, ERR_PTR(ret));
> }
> }
> out:
> @@ -763,10 +761,8 @@ static int ufs_mtk_setup_clocks(struct ufs_hba
> *hba, bool on,
> if (clk_pwr_off) {
> ufs_mtk_pwr_ctrl(hba, false);
> } else {
> - dev_warn(hba->dev, "Clock is not turned off,
> hba->ahit = 0x%x, AHIT = 0x%x\n",
> - hba->ahit,
> - ufshcd_readl(hba,
> -
> REG_AUTO_HIBERNATE_IDLE_TIMER));
> + dev_warn(hba->dev, "Clock isn't off, hba-
> >ahit = 0x%x, AHIT = 0x%x\n",
> + hba->ahit, ufshcd_readl(hba,
> REG_AUTO_HIBERNATE_IDLE_TIMER));
> }
> ufs_mtk_mcq_disable_irq(hba);
> } else if (on && status == POST_CHANGE) {
> @@ -810,11 +806,11 @@ static void ufs_mtk_mcq_set_irq_affinity(struct
> ufs_hba *hba, unsigned int cpu)
> _cpu = (cpu == 0) ? 3 : cpu;
> ret = irq_set_affinity(irq, cpumask_of(_cpu));
> if (ret) {
> - dev_err(hba->dev, "set irq %d affinity to CPU %d
> failed\n",
> + dev_err(hba->dev, "setting irq %d affinity to CPU %d
> failed\n",
> irq, _cpu);
> return;
> }
> - dev_info(hba->dev, "set irq %d affinity to CPU: %d\n", irq,
> _cpu);
> + dev_dbg(hba->dev, "set irq %d affinity to CPU %d\n", irq,
> _cpu);
>
Is it more appropriate to use dev_info for state changes or for setting
changes?
> }
>
> static bool ufs_mtk_is_legacy_chipset(struct ufs_hba *hba, u32
> hw_ip_ver)
> @@ -830,7 +826,8 @@ static bool ufs_mtk_is_legacy_chipset(struct
> ufs_hba *hba, u32 hw_ip_ver)
> default:
> break;
> }
> - dev_info(hba->dev, "legacy IP version - 0x%x, is legacy :
> %d", hw_ip_ver, is_legacy);
> + dev_dbg(hba->dev, "IP version 0x%x, legacy = %s", hw_ip_ver,
> + str_true_false(is_legacy));
>
> return is_legacy;
> }
> @@ -935,15 +932,12 @@ static void ufs_mtk_init_clocks(struct ufs_hba
> *hba)
> }
> }
>
> - list_for_each_entry(clki, head, list) {
> - dev_info(hba->dev, "clk \"%s\" present", clki-
> >name);
> - }
> + list_for_each_entry(clki, head, list)
> + dev_dbg(hba->dev, "clk \"%s\" present", clki->name);
>
> if (!ufs_mtk_is_clk_scale_ready(hba)) {
> hba->caps &= ~UFSHCD_CAP_CLK_SCALING;
> - dev_info(hba->dev,
> - "%s: Clk-scaling not ready. Feature
> disabled.",
> - __func__);
> + dev_info(hba->dev, "%s: Clock scaling unavailable",
> __func__);
> return;
> }
>
> @@ -953,8 +947,8 @@ static void ufs_mtk_init_clocks(struct ufs_hba
> *hba)
> */
> reg = devm_regulator_get_optional(dev, "dvfsrc-vcore");
> if (IS_ERR(reg)) {
> - dev_info(dev, "failed to get dvfsrc-vcore: %ld",
> - PTR_ERR(reg));
> + if (PTR_ERR(reg) != -ENODEV)
> + dev_err(dev, "Failed to get dvfsrc-vcore:
> %pe\n", reg);
> return;
> }
>
> @@ -968,12 +962,9 @@ static void ufs_mtk_init_clocks(struct ufs_hba
> *hba)
> host->mclk.vcore_volt = volt;
>
> /* If default boot is max gear, request vcore */
> - if (reg && volt && host->clk_scale_up) {
> - if (regulator_set_voltage(reg, volt, INT_MAX)) {
> - dev_info(hba->dev,
> - "Failed to set vcore to %d\n",
> volt);
> - }
> - }
> + if (reg && volt && host->clk_scale_up)
> + if (regulator_set_voltage(reg, volt, INT_MAX))
> + dev_err(hba->dev, "Failed to set vcore to
> %d\n", volt);
> }
>
> static void ufs_mtk_setup_clk_gating(struct ufs_hba *hba)
> @@ -1060,7 +1051,7 @@ static void ufs_mtk_init_mcq_irq(struct ufs_hba
> *hba)
> }
> host->mcq_intr_info[i].hba = hba;
> host->mcq_intr_info[i].irq = irq;
> - dev_info(hba->dev, "get platform mcq irq: %d, %d\n",
> i, irq);
> + dev_dbg(hba->dev, "get platform mcq irq: %d, %d\n",
> i, irq);
> }
>
> return;
> @@ -1307,10 +1298,8 @@ static int ufs_mtk_pre_pwr_change(struct
> ufs_hba *hba,
> host_params.desired_working_mode = UFS_PWM_MODE;
>
> ret = ufshcd_negotiate_pwr_params(&host_params,
> dev_max_params, dev_req_params);
> - if (ret) {
> - pr_info("%s: failed to determine capabilities\n",
> - __func__);
> - }
> + if (ret)
> + dev_warn(hba->dev, "%s: failed to determine
> capabilities\n", __func__);
>
> if (ufs_mtk_pmc_via_fastauto(hba, dev_req_params)) {
> ufs_mtk_adjust_sync_length(hba);
> @@ -1356,10 +1345,9 @@ static int ufs_mtk_pre_pwr_change(struct
> ufs_hba *hba,
> ret = ufshcd_uic_change_pwr_mode(hba,
> FASTAUTO_MODE << 4 |
> FASTAUTO_MODE);
>
> - if (ret) {
> - dev_err(hba->dev, "%s: HSG1B FASTAUTO failed
> ret=%d\n",
> - __func__, ret);
> - }
> + if (ret)
> + dev_err(hba->dev, "%s: HSG1B FASTAUTO
> failed: %pe\n",
> + __func__, ERR_PTR(ret));
> }
>
> /* if already configured to the requested pwr_mode, skip
> adapt */
> @@ -1409,7 +1397,7 @@ static int ufs_mtk_auto_hibern8_disable(struct
> ufs_hba *hba)
>
> out:
> if (ret) {
> - dev_warn(hba->dev, "exit h8 state fail, ret=%d\n",
> ret);
> + dev_err(hba->dev, "Failed to exit h8 state: %pe\n",
> ERR_PTR(ret));
>
> ufshcd_force_error_recovery(hba);
>
> @@ -1571,7 +1559,7 @@ static int ufs_mtk_device_reset(struct ufs_hba
> *hba)
> /* Some devices may need time to respond to rst_n */
> usleep_range(10000, 15000);
>
> - dev_info(hba->dev, "device reset done\n");
> + dev_dbg(hba->dev, "device reset done\n");
>
Is it more appropriate to use dev_info for state changes or for setting
changes?
Thanks
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 15/23] scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths
From: Peter Wang (王信友) @ 2026-02-24 12:43 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-15-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> Errors should be printed at the correct log level. Additionally, it
> looks like some "goto out"'s were omitted in the scale up case, which
> looks like a mistake, as the scale down branch of the code does use
> them.
>
> Rework the error messages to make them nicer and at the correct
> verbosity, and add the missing gotos.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 14/23] scsi: ufs: mediatek: Remove mediatek,ufs-broken-rtc property
From: Peter Wang (王信友) @ 2026-02-24 12:43 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-14-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-
> mediatek.c
> index 230e11533eac..424533538b90 100644
> --- a/drivers/ufs/host/ufs-mediatek.c
> +++ b/drivers/ufs/host/ufs-mediatek.c
> @@ -655,9 +655,6 @@ static void ufs_mtk_init_host_caps(struct ufs_hba
> *hba)
> if (of_property_read_bool(np, "mediatek,ufs-rtff-mtcmos"))
> host->caps |= UFS_MTK_CAP_RTFF_MTCMOS;
>
> - if (of_property_read_bool(np, "mediatek,ufs-broken-rtc"))
> - host->caps |= UFS_MTK_CAP_MCQ_BROKEN_RTC;
> -
> dev_info(hba->dev, "caps: 0x%x", host->caps);
> }
>
> @@ -1185,8 +1182,6 @@ static int ufs_mtk_init(struct ufs_hba *hba)
> hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL;
>
> hba->quirks |= UFSHCD_QUIRK_MCQ_BROKEN_INTR;
> - if (host->caps & UFS_MTK_CAP_MCQ_BROKEN_RTC)
> - hba->quirks |= UFSHCD_QUIRK_MCQ_BROKEN_RTC;
>
Maybe check the hardware version (host->ip_ver)
and set UFSHCD_QUIRK_MCQ_BROKEN_RTC instead of removing it?
Thanks
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 10/23] scsi: ufs: mediatek: Handle misc host voltage regulators
From: AngeloGioacchino Del Regno @ 2026-02-24 12:41 UTC (permalink / raw)
To: Peter Wang (王信友), chu.stanley@gmail.com,
robh@kernel.org, Chunfeng Yun (云春峰),
kishon@kernel.org, James.Bottomley@HansenPartnership.com,
bvanassche@acm.org, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <2c7c84a2df19624ba9f207fd3fee47a8bdd9d8dc.camel@mediatek.com>
Il 24/02/26 13:38, Peter Wang (王信友) ha scritto:
> On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
>> @@ -1188,8 +1190,21 @@ static int ufs_mtk_get_supplies(struct
>> ufs_mtk_host *host)
>> {
>> struct device *dev = host->hba->dev;
>> const struct ufs_mtk_soc_data *data =
>> of_device_get_match_data(dev);
>> + int ret;
>> +
>> + if (!data)
>> + return 0;
>> +
>> + if (data->num_reg_names) {
>> + ret = devm_regulator_bulk_get_enable(dev, data-
>>> num_reg_names,
>> + data-
>>> reg_names);
>
> Hi Nicolas,
>
> If these regulators are only acquired and enabled once,
> why not just set regulator-always-on in the device tree?
>
Because:
1. The UFS driver has to acquire the correct supplies regardless of them
being on, guaranteeing both a readable power tree (sysfs/debugfs) and
a correct hardware description in devicetree.
2. A future update might get those regulators disabled during deep sleep
Regards,
Angelo
> Thanks
> Peter
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 13/23] scsi: ufs: mediatek: Use the common PHY framework
From: Peter Wang (王信友) @ 2026-02-24 12:41 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-13-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> There is no need to reinvent the PHY framework, especially not its OF
> parsing.
>
> Change the code to simply use the PHY framework to acquire the
> device's
> PHY in the ufshcd init, so that it's device linked to the right
> device.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
Could you move the PHY reorganization patch (11/23) into this patch?
Thanks
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 12/23] scsi: ufs: mediatek: Remove vendor kernel quirks cruft
From: Peter Wang (王信友) @ 2026-02-24 12:40 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: krzysztof.kozlowski@oss.qualcomm.com, linux-scsi@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-12-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> Both ufs_mtk_vreg_fix_vcc and ufs_mtk_vreg_fix_vccqx look like they
> are
> vendor kernel hacks to work around existing downstream device trees.
> Mainline does not need or want them, so remove them.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Reviewed-by: Krzysztof Kozlowski
> <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
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