* 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
* Re: [PATCH v7 11/23] scsi: ufs: mediatek: Rework probe function
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: 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-11-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> Remove the ti,syscon-reset cruft, as it was never documented in the
> binding, and is not modelling the hardware correctly.
>
> Make PHY mandatory. All the compatibles supported by the binding make
> it
> mandatory.
>
> Entertain this driver's insistence on playing with the PHY's RPM, but
> at
> least fix the part where it doesn't increase the reference count,
> which
> would lead to use-after-free.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Could you separate this patch to "remove reset" and "reorganize PHY"?
The PHY reorganization can be merged with patch (13/23).
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-24 12:38 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:
> @@ -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?
Thanks
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v3 0/6] Add support for mt8167 display blocks
From: AngeloGioacchino Del Regno @ 2026-02-24 9:34 UTC (permalink / raw)
To: linux-mediatek, Luca Leonardo Scorcia
Cc: Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
On Mon, 23 Feb 2026 16:22:44 +0000, Luca Leonardo Scorcia wrote:
> This series adds support for the display blocks on MediaTek mt8167.
> Tested on Xiaomi Mi Smart Clock x04g.
>
> The first patch just does some reordering of dts nodes with no other
> changes as this makes later patches cleaner and easier to follow.
>
> v3:
> - Added mt8167-dsi compatible to driver instead of changing the binding;
> - Resolved patch formatting issues.
>
> [...]
Applied to v7.0-next/dts64, thanks!
[1/6] arm64: dts: mt8167: Reorder nodes according to mmio address
commit: d51b7191f2072e11259edd2bff88385891d0ae56
Cheers,
Angelo
--
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: apple: atc: Make atcphy_dwc3_reset_ops variable static
From: Janne Grunau @ 2026-02-24 7:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sven Peter, Neal Gompa, Vinod Koul, Neil Armstrong, Philipp Zabel,
asahi, linux-arm-kernel, linux-phy, linux-kernel, linux-arm-msm
In-Reply-To: <20260216110413.159994-4-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, Feb 16, 2026 at 12:04:14PM +0100, Krzysztof Kozlowski wrote:
> File-scope 'atcphy_dwc3_reset_ops' is not used outside of this unit, so
> make it static to silence sparse warning:
>
> atc.c:2026:32: warning: symbol 'atcphy_dwc3_reset_ops' was not declared. Should it be static?
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> drivers/phy/apple/atc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/apple/atc.c b/drivers/phy/apple/atc.c
> index dc867f368b68..32d97226e926 100644
> --- a/drivers/phy/apple/atc.c
> +++ b/drivers/phy/apple/atc.c
> @@ -2023,7 +2023,7 @@ static int atcphy_dwc3_reset_deassert(struct reset_controller_dev *rcdev, unsign
> return 0;
> }
>
> -const struct reset_control_ops atcphy_dwc3_reset_ops = {
> +static const struct reset_control_ops atcphy_dwc3_reset_ops = {
> .assert = atcphy_dwc3_reset_assert,
> .deassert = atcphy_dwc3_reset_deassert,
> };
Reviewed-by: Janne Grunau <j@jannau.net>
thanks
Janne
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/3] phy: qcom: qmp-usbc: Simplify check for non-NULL pointer
From: Dmitry Baryshkov @ 2026-02-24 7:47 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sven Peter, Janne Grunau, Neal Gompa, Vinod Koul, Neil Armstrong,
Philipp Zabel, asahi, linux-arm-kernel, linux-phy, linux-kernel,
linux-arm-msm
In-Reply-To: <20260216110413.159994-6-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, Feb 16, 2026 at 12:04:16PM +0100, Krzysztof Kozlowski wrote:
> Pointers should not use explicit '0' comparison, so just use standard
> evaluation as non-NULL:
>
> phy-qcom-qmp-usbc.c:1682:31: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
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 2/2] phy: qcom: qmp-pcie: Add vdda-refgen supplies for Glymur
From: Qiang Yu @ 2026-02-24 6:42 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <hi2znbyo5tunwi6du5ifxjci4xmjvfz5wrbikqs7yagpt2rhki@il4g5olkhkvw>
On Fri, Feb 13, 2026 at 07:48:23PM +0200, Dmitry Baryshkov wrote:
> On Wed, Feb 11, 2026 at 07:33:28PM -0800, Qiang Yu wrote:
> > On Mon, Feb 09, 2026 at 03:15:24PM +0200, Dmitry Baryshkov wrote:
> > > 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...
> > >
> > I will post dtsi patch after we get agreement on how to descibe refgen in
> > dt-bindings.
>
> Please include DT patches in future series, they help us understand your
> changes.
>
Okay, will include DT patches in future series.
- Qiang Yu
> >
> > - Qiang Yu
> > > >
> > > > 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
>
> --
> 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/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add vdda-refgen supply for Glymur
From: Qiang Yu @ 2026-02-24 6:41 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Krzysztof Kozlowski, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <hcslao22elcihjw56ltu4yo54lotheqpikzsrq6tia33di4fs4@2ygrbwhcfx2a>
On Fri, Feb 13, 2026 at 07:47:36PM +0200, Dmitry Baryshkov wrote:
> On Wed, Feb 11, 2026 at 07:32:23PM -0800, Qiang Yu wrote:
> > On Mon, Feb 09, 2026 at 09:06:23AM +0100, Krzysztof Kozlowski wrote:
> > > 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?
> >
> > Yeah, I know that dt-bindings should describe hardware, not software. But
> > what I meant to say is that the refgen is different from qref which is
> > controlled via TCSR registers and its LDOs are requested to vote in
> > tcsrcc driver. The refgen doesn't required register setting and it doesn't
> > have dedicated driver, so we vote its LDOs in phy driver. I will avoid
> > this statement in next version.
>
> I must admit, I could not find references to the refgen in any of Glymur
> PCIe-related HPGs.
We can find it on ipcatalog. On Glymur, there are 6 refgen instances:
u_cm_phy_refgen_0_west supplies to pcie3/4/6.
u_cm_phy_refgen_3_east supplies to pcie5.
This two refgen also supply to other modules like usb and qref which
is required by PCIe phy for stable reference clk.
In previous targets, refgen was often ignored because it shares LDOs with
phy or qref. We typically only vote for vdda-phy, vdda-pll, and vdda-qref
supplies. However, on Glymur, there are more instances and less LDO
sharing between phy/qref/refgen.
>
> >
> > >
> > > There is qcom,sc8280xp-refgen-regulator so why there cannot be
> > > qcom,x1e-refgen-regulator?
> >
> > I think we can and it seems better because the refgen for pcie phy also
> > supplies reference voltage to other modules like usb. But I checked the
> > qcom-refgen-regulator.c, it contains some register settings and there is
> > no LDOs voting. I'm not sure what does those register do, maybe Konrad
> > can provide some backgroud.
>
> Those regs provide voting for refgen, because on those platforms DSI
> block doesn't have a hardware vote for refgen.
>
Okay, for PCIe PHY, we don't need register settings for refgen.
- Qiang Yu
> > But on Glymur, we only need to vote LDOs. So
> > what if we use a fixed regulator in the device tree to represent refgen?
> > We could set refgen0p9 and refgen1p2 as its input supplies, then the PCIe
> > PHY would just need one refgen supply reference.
> >
> > - Qiang Yu
> > >
> > >
> > > > 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
> > >
>
> --
> 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] phy: core: fix potential UAF in of_phy_simple_xlate()
From: Dmitry Torokhov @ 2026-02-24 0:37 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: <20260223231500.zeffezslctqamhp7@skbuf>
Hi Vladimir,
On Tue, Feb 24, 2026 at 01:15:00AM +0200, Vladimir Oltean wrote:
> Hi Dmitry,
>
> On Fri, Feb 20, 2026 at 05:01:50PM -0800, Dmitry Torokhov wrote:
> > On Thu, Feb 19, 2026 at 04:11:37PM -0800, Dmitry Torokhov wrote:
> > > On Thu, Feb 19, 2026 at 03:57:11PM -0800, Dmitry Torokhov wrote:
> > > > The implementation put_device()s located device and then uses
> > > > container_of() on the pointer. The device may disappear by that time,
> > > > resulting in UAF.
> > > >
> > > > Fix the problem by keeping the reference to the framer device,
> > > > avoiding getting an extra reference to it in framer_get(), and making
> > > > sure to drop the reference in error path when we fail to get the module.
> > >
> > > Hmm, I was too rash. There are bunch of other xlate functions that need
> > > to be updated to take the reference.
> >
> > So I am convinced that xlate functions need to bump up the reference to
> > phy devices they return. The question is how to deal with the ones that
> > do not. I can either convert them in the same patch (the changes are
> > quite mechanical) or we can do the whole song and dance, introduce a
> > flag, set it up in converted xlate functions, have the core respect it,
> > and then remove it from xlates and from the core when it is all done.
> >
> > Please let me know.
>
> 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().
>
> 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...
>
> But first the problem. Too little has been said about the problem, and
> too much about the solution. We can't find a good solution if we don't
> call out the problem properly first.
>
> The phy_get() function follows a "lookup-then-get" approach for PHY
> providers, rather than "atomic-lookup-and-get".
>
> Namely, the phy_provider->of_xlate() caller, which is _of_phy_get(),
> returns a struct phy * with its underlying device reference count
> nominally at 1. All callers of _of_phy_get() do later call get_device()
> to bump this refcount for each PHY consumer, but it is "too late" in the
> sense that a window has been opened where the PHY provider driver can
> unbind, and the reference count of &phy->dev can drop to 0 and it can be
> freed.
Yes.
>
> Immediately after being created by phy_create(), the &phy->dev has a
> refcount of 1, and only the action of its provider driver (calling
> phy_destroy() directly or through devres, on driver unbind) can drop
> that refcount to 0. As long as the driver doesn't do that, the &phy->dev
> refcount is not in danger.
Right.
>
> Then the PHY is exposed to the outside world using of_phy_provider_register(),
> where the fact that the provider driver can concurrently unregister
> starts being a problem.
>
> Therefore, I would say that the problem is that consumers, aka phy_get()
> callers, can get a phy with a &phy->dev refcount that is not already bumped
> by the time they are handed over that PHY.
>
> Mechanically, PHY lookup happens under &phy_provider_mutex, and I
> believe it would be sufficient to call get_device() under this lock, in
> order for consumers to get PHYs with their reference bumped.
<skip the explanation and a patch>
Yes, given that there is 1:1 mapping between device and provider (not
phy instance but its parent) it looks like we can drop the reference and
then bump it up again as long as we hold that mutex.
>
> 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.
>
>
> 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.
>
>
> 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?)
>
> Sorry that this email is a bit long, it got a bit late writing it and I
> don't have a lot of energy left to trim it down.
> In summary I found 4 highly related problems:
> - use after free
> - misleading of_phy_simple_xlate() API pattern (not a functional issue)
> - zombie PHYs
> - premature release call
Thanks.
--
Dmitry
--
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-23 23:15 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: <aZkCyQ1oizPXplyU@google.com>
Hi Dmitry,
On Fri, Feb 20, 2026 at 05:01:50PM -0800, Dmitry Torokhov wrote:
> On Thu, Feb 19, 2026 at 04:11:37PM -0800, Dmitry Torokhov wrote:
> > On Thu, Feb 19, 2026 at 03:57:11PM -0800, Dmitry Torokhov wrote:
> > > The implementation put_device()s located device and then uses
> > > container_of() on the pointer. The device may disappear by that time,
> > > resulting in UAF.
> > >
> > > Fix the problem by keeping the reference to the framer device,
> > > avoiding getting an extra reference to it in framer_get(), and making
> > > sure to drop the reference in error path when we fail to get the module.
> >
> > Hmm, I was too rash. There are bunch of other xlate functions that need
> > to be updated to take the reference.
>
> So I am convinced that xlate functions need to bump up the reference to
> phy devices they return. The question is how to deal with the ones that
> do not. I can either convert them in the same patch (the changes are
> quite mechanical) or we can do the whole song and dance, introduce a
> flag, set it up in converted xlate functions, have the core respect it,
> and then remove it from xlates and from the core when it is all done.
>
> Please let me know.
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).
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.
But first the problem. Too little has been said about the problem, and
too much about the solution. We can't find a good solution if we don't
call out the problem properly first.
The phy_get() function follows a "lookup-then-get" approach for PHY
providers, rather than "atomic-lookup-and-get".
Namely, the phy_provider->of_xlate() caller, which is _of_phy_get(),
returns a struct phy * with its underlying device reference count
nominally at 1. All callers of _of_phy_get() do later call get_device()
to bump this refcount for each PHY consumer, but it is "too late" in the
sense that a window has been opened where the PHY provider driver can
unbind, and the reference count of &phy->dev can drop to 0 and it can be
freed.
Immediately after being created by phy_create(), the &phy->dev has a
refcount of 1, and only the action of its provider driver (calling
phy_destroy() directly or through devres, on driver unbind) can drop
that refcount to 0. As long as the driver doesn't do that, the &phy->dev
refcount is not in danger.
Then the PHY is exposed to the outside world using of_phy_provider_register(),
where the fact that the provider driver can concurrently unregister
starts being a problem.
Therefore, I would say that the problem is that consumers, aka phy_get()
callers, can get a phy with a &phy->dev refcount that is not already bumped
by the time they are handed over that PHY.
Mechanically, PHY lookup happens under &phy_provider_mutex, and I
believe it would be sufficient to call get_device() under this lock, in
order for consumers to get PHYs with their reference bumped.
Why?
Let's consider what a PHY provider does when unbinding. It runs the PHY
registration and creation processes in reverse, i.e.
- it calls of_phy_provider_unregister() directly or through devres
- it calls phy_destroy() directly or through devres
Since of_phy_provider_unregister() also acquires &phy_provider_mutex,
this acts like a synchronization barrier. There are 2 cases:
Consumer Provider
phy_get()
-> mutex_lock(&phy_provider_mutex)
-> get_device(&phy->dev) -> 2
-> mutex_unlock(&phy_provider_mutex)
of_phy_provider_unregister()
-> mutex_lock(&phy_provider_mutex)
-> removes phy from list
-> mutex_unlock(&phy_provider_mutex)
phy_destroy()
-> device_unregister(&phy->dev)
-> device_del(dev);
-> put_device(dev); // -> 1
and the consumer remains with a "zombie" PHY device (more later)
Or
Consumer Provider
phy_get()
of_phy_provider_unregister()
-> mutex_lock(&phy_provider_mutex)
-> removes phy from list
-> mutex_unlock(&phy_provider_mutex)
-> mutex_lock(&phy_provider_mutex)
-> doesn't find the PHY device!
It was unpublished even if not freed
-> mutex_unlock(&phy_provider_mutex)
phy_destroy()
-> device_unregister(&phy->dev)
-> device_del(dev);
-> put_device(dev); // -> 1
and the consumer won't be allowed to even find the PHY device in this case.
So this is why get_device() under phy_provider_mutex actually helps.
Now, it is much less important whether you push the get_device() to the
actual of_xlate() PHY vendor implementation or not. For simplicity sake,
I suggest you don't do that, but instead keep it in the core, to
preserve driver API semantics (patch not even compile-tested):
-- >8 --
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 21aaf2f76e53..c50e38f057a8 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -122,17 +122,19 @@ EXPORT_SYMBOL_GPL(phy_remove_lookup);
static struct phy *phy_find(struct device *dev, const char *con_id)
{
const char *dev_id = dev_name(dev);
- struct phy_lookup *p, *pl = NULL;
+ struct phy *phy = NULL;
+ struct phy_lookup *p;
mutex_lock(&phy_provider_mutex);
list_for_each_entry(p, &phys, node)
if (!strcmp(p->dev_id, dev_id) && !strcmp(p->con_id, con_id)) {
- pl = p;
+ phy = p->phy;
+ get_device(&phy->dev);
break;
}
mutex_unlock(&phy_provider_mutex);
- return pl ? pl->phy : ERR_PTR(-ENODEV);
+ return phy ? phy : ERR_PTR(-ENODEV);
}
static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
@@ -649,6 +651,7 @@ static struct phy *_of_phy_get(struct device_node *np, int index)
}
phy = phy_provider->of_xlate(phy_provider->dev, &args);
+ get_device(&phy->dev);
out_put_module:
module_put(phy_provider->owner);
@@ -682,10 +685,10 @@ struct phy *of_phy_get(struct device_node *np, const char *con_id)
if (IS_ERR(phy))
return phy;
- if (!try_module_get(phy->ops->owner))
+ if (!try_module_get(phy->ops->owner)) {
+ put_device(&phy->dev);
return ERR_PTR(-EPROBE_DEFER);
-
- get_device(&phy->dev);
+ }
return phy;
}
@@ -803,10 +806,10 @@ struct phy *phy_get(struct device *dev, const char *string)
if (IS_ERR(phy))
return phy;
- if (!try_module_get(phy->ops->owner))
+ if (!try_module_get(phy->ops->owner)) {
+ put_device(&phy->dev);
return ERR_PTR(-EPROBE_DEFER);
-
- get_device(&phy->dev);
+ }
link = device_link_add(dev, &phy->dev, DL_FLAG_STATELESS);
if (!link)
@@ -969,11 +972,10 @@ struct phy *devm_of_phy_get_by_index(struct device *dev, struct device_node *np,
if (!try_module_get(phy->ops->owner)) {
devres_free(ptr);
+ put_device(&phy->dev);
return ERR_PTR(-EPROBE_DEFER);
}
- get_device(&phy->dev);
-
*ptr = phy;
devres_add(dev, ptr);
-- >8 --
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.
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.
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.
Sorry that this email is a bit long, it got a bit late writing it and I
don't have a lot of energy left to trim it down.
In summary I found 4 highly related problems:
- use after free
- misleading of_phy_simple_xlate() API pattern (not a functional issue)
- zombie PHYs
- premature release call
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v3 5/6] drm/mediatek: dsi: Add compatible for mt8167-dsi
From: AngeloGioacchino Del Regno @ 2026-02-23 16:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <2fbf179c03c61f527e2583f9df4f97f6aaf3297a.1771863641.git.l.scorcia@gmail.com>
Il 23/02/26 17:22, Luca Leonardo Scorcia ha scritto:
> The mt8167 DSI controller is fully compatible with the one found in
> mt2701. Device tree documentation is already present upstream.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 6/6] gpu: drm: mediatek: ovl: add specific entry for mt8167
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Val Packett, Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
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 related
* [PATCH v3 5/6] drm/mediatek: dsi: Add compatible for mt8167-dsi
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Chun-Kuang Hu, Philipp Zabel,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
The mt8167 DSI controller is fully compatible with the one found in
mt2701. Device tree documentation is already present upstream.
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 related
* [PATCH v3 4/6] arm64: dts: mediatek: mt8167: Add DRM nodes
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, AngeloGioacchino Del Regno, Chun-Kuang Hu,
Philipp Zabel, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
Add all the DRM nodes required to get DSI to work on MT8167 SoC.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 317 +++++++++++++++++++++++
1 file changed, 317 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 27cf32d7ae35..32d3895baaa6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -16,6 +16,20 @@
/ {
compatible = "mediatek,mt8167";
+ aliases {
+ aal0 = &aal;
+ ccorr0 = &ccorr;
+ color0 = &color;
+ dither0 = &dither;
+ dsi0 = &dsi;
+ gamma0 = γ
+ ovl0 = &ovl0;
+ pwm0 = &disp_pwm;
+ rdma0 = &rdma0;
+ rdma1 = &rdma1;
+ wdma0 = &wdma;
+ };
+
soc {
topckgen: topckgen@10000000 {
compatible = "mediatek,mt8167-topckgen", "syscon";
@@ -120,10 +134,303 @@ iommu: m4u@10203000 {
#iommu-cells = <1>;
};
+ disp_pwm: pwm@1100f000 {
+ compatible = "mediatek,mt8167-disp-pwm", "mediatek,mt8173-disp-pwm";
+ reg = <0 0x1100f000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_PWM_26M>, <&mmsys CLK_MM_DISP_PWM_MM>;
+ clock-names = "main", "mm";
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt8167-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
#clock-cells = <1>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mmsys_main: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&ovl0_in>;
+ };
+
+ mmsys_ext: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&rdma1_in>;
+ };
+ };
+ };
+
+ ovl0: ovl0@14007000 {
+ compatible = "mediatek,mt8167-disp-ovl";
+ reg = <0 0x14007000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_OVL0>;
+ interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_LOW>;
+ iommus = <&iommu M4U_PORT_DISP_OVL0>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ovl0_in: endpoint {
+ remote-endpoint = <&mmsys_main>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ ovl0_out: endpoint {
+ remote-endpoint = <&color_in>;
+ };
+ };
+ };
+ };
+
+ rdma0: rdma0@14009000 {
+ compatible = "mediatek,mt8167-disp-rdma", "mediatek,mt2701-disp-rdma";
+ reg = <0 0x14009000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA0>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_LOW>;
+ iommus = <&iommu M4U_PORT_DISP_RDMA0>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ rdma0_in: endpoint {
+ remote-endpoint = <&dither_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ rdma0_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ };
+ };
+ };
+ };
+
+ rdma1: rdma1@1400a000 {
+ compatible = "mediatek,mt8167-disp-rdma", "mediatek,mt2701-disp-rdma";
+ reg = <0 0x1400a000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_LOW>;
+ iommus = <&iommu M4U_PORT_DISP_RDMA1>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ rdma1_in: endpoint {
+ remote-endpoint = <&mmsys_ext>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ rdma1_out: endpoint { };
+ };
+ };
+ };
+
+ wdma: wdma0@1400b000 {
+ compatible = "mediatek,mt8167-disp-wdma", "mediatek,mt8173-disp-wdma";
+ reg = <0 0x1400b000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_WDMA>;
+ interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_LOW>;
+ iommus = <&iommu M4U_PORT_DISP_WDMA0>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ };
+
+ color: color@1400c000 {
+ compatible = "mediatek,mt8167-disp-color";
+ reg = <0 0x1400c000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_COLOR>;
+ interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ color_in: endpoint {
+ remote-endpoint = <&ovl0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ color_out: endpoint {
+ remote-endpoint = <&ccorr_in>;
+ };
+ };
+ };
+ };
+
+ ccorr: ccorr@1400d000 {
+ compatible = "mediatek,mt8167-disp-ccorr", "mediatek,mt8183-disp-ccorr";
+ reg = <0 0x1400d000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_CCORR>;
+ interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ccorr_in: endpoint {
+ remote-endpoint = <&color_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ ccorr_out: endpoint {
+ remote-endpoint = <&aal_in>;
+ };
+ };
+ };
+ };
+
+ aal: aal@1400e000 {
+ compatible = "mediatek,mt8167-disp-aal", "mediatek,mt8173-disp-aal";
+ reg = <0 0x1400e000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_AAL>;
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ aal_in: endpoint {
+ remote-endpoint = <&ccorr_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ aal_out: endpoint {
+ remote-endpoint = <&gamma_in>;
+ };
+ };
+ };
+ };
+
+ gamma: gamma@1400f000 {
+ compatible = "mediatek,mt8167-disp-gamma", "mediatek,mt8173-disp-gamma";
+ reg = <0 0x1400f000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_GAMMA>;
+ interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ gamma_in: endpoint {
+ remote-endpoint = <&aal_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ gamma_out: endpoint {
+ remote-endpoint = <&dither_in>;
+ };
+ };
+ };
+ };
+
+ dither: dither@14010000 {
+ compatible = "mediatek,mt8167-disp-dither", "mediatek,mt8183-disp-dither";
+ reg = <0 0x14010000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_DITHER>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dither_in: endpoint {
+ remote-endpoint = <&gamma_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dither_out: endpoint {
+ remote-endpoint = <&rdma0_in>;
+ };
+ };
+ };
+ };
+
+ dsi: dsi@14012000 {
+ compatible = "mediatek,mt8167-dsi";
+ reg = <0 0x14012000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DSI_ENGINE>, <&mmsys CLK_MM_DSI_DIGITAL>,
+ <&mipi_tx>;
+ clock-names = "engine", "digital", "hs";
+ interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_LOW>;
+ phys = <&mipi_tx>;
+ phy-names = "dphy";
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ status = "disabled";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi_in: endpoint {
+ remote-endpoint = <&rdma0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi_out: endpoint { };
+ };
+ };
+ };
+
+ mutex: mutex@14015000 {
+ compatible = "mediatek,mt8167-disp-mutex";
+ reg = <0 0x14015000 0 0x1000>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
};
larb0: larb@14016000 {
@@ -145,6 +452,16 @@ smi_common: smi@14017000 {
power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
};
+ mipi_tx: dsi-phy@14018000 {
+ compatible = "mediatek,mt8167-mipi-tx", "mediatek,mt2701-mipi-tx";
+ reg = <0 0x14018000 0 0x90>;
+ clocks = <&topckgen CLK_TOP_MIPI_26M_DBG>;
+ clock-output-names = "mipi_tx0_pll";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
imgsys: syscon@15000000 {
compatible = "mediatek,mt8167-imgsys", "syscon";
reg = <0 0x15000000 0 0x1000>;
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 3/6] dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Krzysztof Kozlowski, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
dri-devel, devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
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.
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 related
* [PATCH v3 2/6] dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Krzysztof Kozlowski,
AngeloGioacchino Del Regno, Chun-Kuang Hu, Philipp Zabel,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
dri-devel, devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
Add compatibles for various display-related blocks of MediaTek mt8167.
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 related
* [PATCH v3 1/6] arm64: dts: mt8167: Reorder nodes according to mmio address
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, AngeloGioacchino Del Regno, Chun-Kuang Hu,
Philipp Zabel, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
In preparation for adding display nodes. No other changes.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 68 ++++++++++++------------
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 2374c0953057..27cf32d7ae35 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -29,12 +29,6 @@ infracfg: infracfg@10001000 {
#clock-cells = <1>;
};
- apmixedsys: apmixedsys@10018000 {
- compatible = "mediatek,mt8167-apmixedsys", "syscon";
- reg = <0 0x10018000 0 0x710>;
- #clock-cells = <1>;
- };
-
scpsys: syscon@10006000 {
compatible = "mediatek,mt8167-scpsys", "syscon", "simple-mfd";
reg = <0 0x10006000 0 0x1000>;
@@ -101,18 +95,6 @@ power-domain@MT8167_POWER_DOMAIN_CONN {
};
};
- imgsys: syscon@15000000 {
- compatible = "mediatek,mt8167-imgsys", "syscon";
- reg = <0 0x15000000 0 0x1000>;
- #clock-cells = <1>;
- };
-
- vdecsys: syscon@16000000 {
- compatible = "mediatek,mt8167-vdecsys", "syscon";
- reg = <0 0x16000000 0 0x1000>;
- #clock-cells = <1>;
- };
-
pio: pinctrl@1000b000 {
compatible = "mediatek,mt8167-pinctrl";
reg = <0 0x1000b000 0 0x1000>;
@@ -124,12 +106,36 @@ pio: pinctrl@1000b000 {
interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
};
+ apmixedsys: apmixedsys@10018000 {
+ compatible = "mediatek,mt8167-apmixedsys", "syscon";
+ reg = <0 0x10018000 0 0x710>;
+ #clock-cells = <1>;
+ };
+
+ iommu: m4u@10203000 {
+ compatible = "mediatek,mt8167-m4u";
+ reg = <0 0x10203000 0 0x1000>;
+ mediatek,larbs = <&larb0>, <&larb1>, <&larb2>;
+ interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_LOW>;
+ #iommu-cells = <1>;
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt8167-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
#clock-cells = <1>;
};
+ larb0: larb@14016000 {
+ compatible = "mediatek,mt8167-smi-larb";
+ reg = <0 0x14016000 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ clocks = <&mmsys CLK_MM_SMI_LARB0>,
+ <&mmsys CLK_MM_SMI_LARB0>;
+ clock-names = "apb", "smi";
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ };
+
smi_common: smi@14017000 {
compatible = "mediatek,mt8167-smi-common";
reg = <0 0x14017000 0 0x1000>;
@@ -139,14 +145,10 @@ smi_common: smi@14017000 {
power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
};
- larb0: larb@14016000 {
- compatible = "mediatek,mt8167-smi-larb";
- reg = <0 0x14016000 0 0x1000>;
- mediatek,smi = <&smi_common>;
- clocks = <&mmsys CLK_MM_SMI_LARB0>,
- <&mmsys CLK_MM_SMI_LARB0>;
- clock-names = "apb", "smi";
- power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ imgsys: syscon@15000000 {
+ compatible = "mediatek,mt8167-imgsys", "syscon";
+ reg = <0 0x15000000 0 0x1000>;
+ #clock-cells = <1>;
};
larb1: larb@15001000 {
@@ -159,6 +161,12 @@ larb1: larb@15001000 {
power-domains = <&spm MT8167_POWER_DOMAIN_ISP>;
};
+ vdecsys: syscon@16000000 {
+ compatible = "mediatek,mt8167-vdecsys", "syscon";
+ reg = <0 0x16000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
larb2: larb@16010000 {
compatible = "mediatek,mt8167-smi-larb";
reg = <0 0x16010000 0 0x1000>;
@@ -168,13 +176,5 @@ larb2: larb@16010000 {
clock-names = "apb", "smi";
power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
};
-
- iommu: m4u@10203000 {
- compatible = "mediatek,mt8167-m4u";
- reg = <0 0x10203000 0 0x1000>;
- mediatek,larbs = <&larb0>, <&larb1>, <&larb2>;
- interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_LOW>;
- #iommu-cells = <1>;
- };
};
};
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 0/6] Add support for mt8167 display blocks
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Chun-Kuang Hu, Philipp Zabel,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
This series adds support for the display blocks on MediaTek mt8167.
Tested on Xiaomi Mi Smart Clock x04g.
The first patch just does some reordering of dts nodes with no other
changes as this makes later patches cleaner and easier to follow.
v3:
- Added mt8167-dsi compatible to driver instead of changing the binding;
- Resolved patch formatting issues.
v2:
- Separate patch for mediatek,dsi-phy binding;
- Separate patch for mt8167-dsi binding;
- Simplified OF graph endpoints in mt8167.dtsi.
Luca Leonardo Scorcia (5):
arm64: dts: mt8167: Reorder nodes according to mmio address
dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
arm64: dts: mediatek: mt8167: Add DRM nodes
drm/mediatek: dsi: Add compatible for mt8167-dsi
Val Packett (1):
gpu: drm: mediatek: ovl: add specific entry for mt8167
.../display/mediatek/mediatek,aal.yaml | 1 +
.../display/mediatek/mediatek,ccorr.yaml | 4 +-
.../display/mediatek/mediatek,dither.yaml | 1 +
.../display/mediatek/mediatek,gamma.yaml | 1 +
.../display/mediatek/mediatek,ovl.yaml | 1 +
.../display/mediatek/mediatek,rdma.yaml | 1 +
.../display/mediatek/mediatek,wdma.yaml | 4 +-
.../bindings/phy/mediatek,dsi-phy.yaml | 1 +
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 381 ++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 12 +
drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
11 files changed, 374 insertions(+), 34 deletions(-)
--
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: move spacemit pcie driver to its subfolder
From: Yixun Lan @ 2026-02-23 14:38 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-phy, Neil Armstrong, Vladimir Oltean, Alex Elder, Ze Huang,
spacemit
In-Reply-To: <20260223064240.386617-1-vkoul@kernel.org>
Hi Vinod,
On 12:12 Mon 23 Feb , Vinod Koul wrote:
> Commit fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
> created spacemit subfolder with usb driver while commit 57e920b92724
> ("phy: spacemit: Introduce PCIe/combo PHY") added pcie driver in phy
> folder. Move latter into spacemit subfolder and rename file to
> phy-k1-pcie.c
>
Make sense, this looks better, thanks
Reviewed-by: Yixun Lan <dlan@kernel.org>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
> drivers/phy/Kconfig | 12 ------------
> drivers/phy/Makefile | 1 -
> drivers/phy/spacemit/Kconfig | 12 ++++++++++++
> drivers/phy/spacemit/Makefile | 1 +
> .../phy-k1-pcie.c} | 0
> 5 files changed, 13 insertions(+), 13 deletions(-)
> rename drivers/phy/{phy-spacemit-k1-pcie.c => spacemit/phy-k1-pcie.c} (100%)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 02467dfd4fb0..c0574e44f0a3 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -134,18 +134,6 @@ config PHY_NXP_PTN3222
> schemes. It supports all three USB 2.0 data rates: Low Speed, Full
> Speed and High Speed.
>
> -config PHY_SPACEMIT_K1_PCIE
> - tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
> - depends on ARCH_SPACEMIT || COMPILE_TEST
> - depends on COMMON_CLK
> - depends on HAS_IOMEM
> - depends on OF
> - select GENERIC_PHY
> - default ARCH_SPACEMIT
> - help
> - Enable support for the PCIe and USB 3 combo PHY and two
> - PCIe-only PHYs used in the SpacemiT K1 SoC.
> -
> source "drivers/phy/allwinner/Kconfig"
> source "drivers/phy/amlogic/Kconfig"
> source "drivers/phy/apple/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a648c2e02a83..2773d596e543 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -16,7 +16,6 @@ obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
> obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
> obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
> obj-$(CONFIG_PHY_NXP_PTN3222) += phy-nxp-ptn3222.o
> -obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE) += phy-spacemit-k1-pcie.o
> obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
> amlogic/ \
> apple/ \
> diff --git a/drivers/phy/spacemit/Kconfig b/drivers/phy/spacemit/Kconfig
> index 0136aee2e8a2..50b0005acf66 100644
> --- a/drivers/phy/spacemit/Kconfig
> +++ b/drivers/phy/spacemit/Kconfig
> @@ -2,6 +2,18 @@
> #
> # Phy drivers for SpacemiT platforms
> #
> +config PHY_SPACEMIT_K1_PCIE
> + tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
> + depends on ARCH_SPACEMIT || COMPILE_TEST
> + depends on COMMON_CLK
> + depends on HAS_IOMEM
> + depends on OF
> + select GENERIC_PHY
> + default ARCH_SPACEMIT
> + help
> + Enable support for the PCIe and USB 3 combo PHY and two
> + PCIe-only PHYs used in the SpacemiT K1 SoC.
> +
> config PHY_SPACEMIT_K1_USB2
> tristate "SpacemiT K1 USB 2.0 PHY support"
> depends on (ARCH_SPACEMIT || COMPILE_TEST) && OF
> diff --git a/drivers/phy/spacemit/Makefile b/drivers/phy/spacemit/Makefile
> index fec0b425a948..a821a21d6142 100644
> --- a/drivers/phy/spacemit/Makefile
> +++ b/drivers/phy/spacemit/Makefile
> @@ -1,2 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE) += phy-k1-pcie.o
> obj-$(CONFIG_PHY_SPACEMIT_K1_USB2) += phy-k1-usb2.o
> diff --git a/drivers/phy/phy-spacemit-k1-pcie.c b/drivers/phy/spacemit/phy-k1-pcie.c
> similarity index 100%
> rename from drivers/phy/phy-spacemit-k1-pcie.c
> rename to drivers/phy/spacemit/phy-k1-pcie.c
> --
> 2.43.0
>
>
--
Yixun Lan (dlan)
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/2] Add Axiado AX3000 eMMC Host Controller Support
From: Ulf Hansson @ 2026-02-23 14:12 UTC (permalink / raw)
To: Tzu-Hao Wei
Cc: SriNavmani A, Prasad Bolisetty, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Adrian Hunter,
Michal Simek, linux-phy, devicetree, linux-arm-kernel,
linux-kernel, linux-mmc, openbmc
In-Reply-To: <20260206-axiado-ax3000-add-emmc-host-driver-support-v3-0-ef83b09325be@axiado.com>
On Fri, 6 Feb 2026 at 09:23, Tzu-Hao Wei <twei@axiado.com> wrote:
>
> Axiado AX3000 SoC eMMC controller is based on Arasan eMMC controller.
>
> This series includes:
> 1. Add bindings for AX3000 SoC eMMC controller
> 2. Add arasan sdhci support for eMMC in Axiado AX3000
>
> For platform device tree change, we will send a different series of
> patches.
>
> It has been verified on AX3000 platform.
>
> ---
> Changes in v3:
> - Enable SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN quirk
> - Remove dependencies in b4
> - Link to v2: https://lore.kernel.org/r/20260109-axiado-ax3000-add-emmc-host-driver-support-v2-0-934f1a61f7c0@axiado.com
>
> Changes in v2:
> - Keep host controller changes in this patchset
> - Use pdata instead of mix compatible string
> - Fix coding style
> - Link to v1: https://lore.kernel.org/r/20251222-axiado-ax3000-add-emmc-host-driver-support-v1-0-5457d0ebcdb4@axiado.com
>
> Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
>
> ---
> SriNavmani A (2):
> dt-bindings: mmc: arasan,sdhci: Add Axiado AX3000 SoC
> mmc: sdhci-of-arasan: add support on Axiado AX3000 SoC
>
> Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml | 3 +++
> drivers/mmc/host/sdhci-of-arasan.c | 15 +++++++++++++++
> 2 files changed, 18 insertions(+)
> ---
> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
> change-id: 20251222-axiado-ax3000-add-emmc-host-driver-support-2cc84a8f889a
>
> Best regards,
> --
> Tzu-Hao Wei <twei@axiado.com>
>
Applied for next, thanks!
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] phy: mediatek: allow building T-PHY driver for MT7621 MIPS SoC
From: AngeloGioacchino Del Regno @ 2026-02-23 13:47 UTC (permalink / raw)
To: Shiji Yang, linux-phy
Cc: Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <OS7PR01MB136023DAF6E893E8110CEF777BC6BA@OS7PR01MB13602.jpnprd01.prod.outlook.com>
Il 19/02/26 13:53, Shiji Yang ha scritto:
> MT7621 also has compatible T-PHY which attached to the XHCI interface.
>
> Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
MT7621 seems to be a bit special among the mips/ralink platforms, so I agree.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Ulf Hansson @ 2026-02-23 13:44 UTC (permalink / raw)
To: Josua Mayer
Cc: Andreas Kemnade, Vladimir Oltean, Geert Uytterhoeven,
Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, 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: <203a36fb-6ac9-41f6-80ce-b137b9db4ad1@solid-run.com>
On Mon, 23 Feb 2026 at 13:44, Josua Mayer <josua@solid-run.com> wrote:
>
> Am 16.02.26 um 16:24 schrieb Andreas Kemnade:
> > On Mon, 16 Feb 2026 11:29:14 +0200
> > Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> >> Hi Josua,
> >>
> >> On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote:
> >>>>> In the future, when you have a series with cross-tree dependencies,
> >>>>> please try to think of it as individual mini-series for each tree's
> >>>>> 'next' branch, and specify clearly that you need stable tags (to be
> >>>>> pulled into other trees).
> >>> I don't really understand how I could split my series up to avoid this
> >>> issue.
> >>>
> >>> Due to the fact that one (and now two) drivers implemented local
> >>> mux helpers, to undo that an atomic change must be made tree-wide.
> >>>
> >>> Meanwhile it must be avoided that while the mux core helpers are being
> >>> tested / reviewed, that any tree adds another driver-local mux helper
> >>> like appears to have happened here.
> >>>
> >>> Note that my patch-set did go to linux-phy@lists.infradead.org list, too.
> >>>
> >>> The second challenge for this series was that mux framework is being
> >>> enabled only by drivers Kconfig "select" - and not possible by menuconfig.
> >>> This is e.g. responsible for being unable to test =m build with arm64
> >>> defconfig - and lead to it only being detected through kernel robot
> >>> x86_64 allmodconfig.
> >> To avoid this, a combination of developer due diligence + maintainer due
> >> diligence is probably required.
> >>
> >> From linux-phy perspective, there will be some automated build testing
> >> (which did not exist at the time of your submission). This would have
> >> caught the 'hidden' devm_mux_state_get_optional() call present only in
> >> linux-phy/next, when testing patch 2/7.
> Excellent!
> >>
> >> But, to work, the build automation needs to be able to apply the entire
> >> patch set on linux-phy/next. So expect some pushback if it doesn't
> >> (hence the recommendation to send a mini-series to linux-phy first, and
> >> request a stable tag).
> It would help immensely if there was a way to get the patches renaming
> driver-local conflicting helper-functions very early, before anything else.
>
> Would this sort of patch be acceptable in linux-next now, so it can make
> it into v7.0-rc1?
>
> If not then that mini-patchset would be the first one I shall submit after
> v7.0-rc1 is released.
>
> Then I can treat the actual implementation of the devm_mux_* helpers
> as a second standalone patch-set.
>
> And finally patching all drivers with local helpers to use the new global ones
> can be patch-set number 3.
>
> Any opinions on this?
>
> > I do not think that is at all the duty of the patch submitter. I think as
> > long as every dependencies and side effects are documented, it is IMHO up to the
> > maintainers to decide how it can be merged best. They know best whether there
> > is any danger of conflicts in their working tree because that is an area
> > where people are working on. Especially this patchset is around for months.
> >
> > In MFD where it is
> > more common practice to have cross-subsystem patchsets, once acks from
> > everyone are there, MFD Maintainer creates an immutable branch with a tag.
> > The maintainers of the affected subsystems pull it in.
> This seems like an option, if I can get the patch-set (or a partial one) ready early in the cycle.
I agree with this approach as it should provide less churns for all of
us. Especially since the changes to the consumer drivers here are few
and trivial.
I am willing to help with hosting the immutable branch (unless someone
else wants of course). Once all acks have been received for the
series, I can set it up. Then other subsystem maintainers can pull it
in if there is a need to avoid conflicts/build-errors.
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 v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Vladimir Oltean @ 2026-02-23 13:12 UTC (permalink / raw)
To: Josua Mayer
Cc: Andreas Kemnade, Geert Uytterhoeven, Marc Kleine-Budde,
Vincent Mailhol, Vinod Koul, Neil Armstrong, Peter Rosin,
Aaro Koskinen, 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: <203a36fb-6ac9-41f6-80ce-b137b9db4ad1@solid-run.com>
On Mon, Feb 23, 2026 at 12:43:48PM +0000, Josua Mayer wrote:
> It would help immensely if there was a way to get the patches renaming
> driver-local conflicting helper-functions very early, before anything else.
>
> Would this sort of patch be acceptable in linux-next now, so it can make
> it into v7.0-rc1?
>
> If not then that mini-patchset would be the first one I shall submit after
> v7.0-rc1 is released.
v7.0-rc1 was already tagged as commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f.
Additionally, patches are not accepted directly *in* linux-next. They
are accepted in subsystem trees (linux-phy, mmc, etc) which are then
integrated all together in linux-next.
>
> Then I can treat the actual implementation of the devm_mux_* helpers
> as a second standalone patch-set.
>
> And finally patching all drivers with local helpers to use the new global ones
> can be patch-set number 3.
>
> Any opinions on this?
From linux-phy perspective, I think in this particular case the following
would help:
- submit the patches at the beginning of the development cycle (i.e.
now) while the subsystem trees didn't diverge too much
- submit the patch series *in full* (to get build testing of the later
devm_mux_state_get_optional() introduction too, even if that is not
for linux-phy)
- keep all patches pertaining to linux-phy (the mini-patchset) together
and close to the beginning of the series, so they can be picked
without other dependencies
- be clear in the cover letter if you require a stable tag for the
linux-phy patches to be picked in other trees. You seem to be in the
best position to be aware of all dependencies.
I don't know what is the exact status with the MULTIPLEXER SUBSYSTEM
which is marked as Odd Fixes and doesn't have appear to have a subsystem
tree. I have no recommendation there.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: move spacemit pcie driver to its subfolder
From: Alex Elder @ 2026-02-23 13:00 UTC (permalink / raw)
To: Vinod Koul, linux-phy; +Cc: Neil Armstrong, Vladimir Oltean, Ze Huang, spacemit
In-Reply-To: <20260223064240.386617-1-vkoul@kernel.org>
On 2/23/26 12:42 AM, Vinod Koul wrote:
> Commit fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
> created spacemit subfolder with usb driver while commit 57e920b92724
> ("phy: spacemit: Introduce PCIe/combo PHY") added pcie driver in phy
> folder. Move latter into spacemit subfolder and rename file to
> phy-k1-pcie.c
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
Looks good. Thanks!
Reviewed-by: Alex Elder <elder@riscstar.com>
> ---
> drivers/phy/Kconfig | 12 ------------
> drivers/phy/Makefile | 1 -
> drivers/phy/spacemit/Kconfig | 12 ++++++++++++
> drivers/phy/spacemit/Makefile | 1 +
> .../phy-k1-pcie.c} | 0
> 5 files changed, 13 insertions(+), 13 deletions(-)
> rename drivers/phy/{phy-spacemit-k1-pcie.c => spacemit/phy-k1-pcie.c} (100%)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 02467dfd4fb0..c0574e44f0a3 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -134,18 +134,6 @@ config PHY_NXP_PTN3222
> schemes. It supports all three USB 2.0 data rates: Low Speed, Full
> Speed and High Speed.
>
> -config PHY_SPACEMIT_K1_PCIE
> - tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
> - depends on ARCH_SPACEMIT || COMPILE_TEST
> - depends on COMMON_CLK
> - depends on HAS_IOMEM
> - depends on OF
> - select GENERIC_PHY
> - default ARCH_SPACEMIT
> - help
> - Enable support for the PCIe and USB 3 combo PHY and two
> - PCIe-only PHYs used in the SpacemiT K1 SoC.
> -
> source "drivers/phy/allwinner/Kconfig"
> source "drivers/phy/amlogic/Kconfig"
> source "drivers/phy/apple/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a648c2e02a83..2773d596e543 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -16,7 +16,6 @@ obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
> obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
> obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
> obj-$(CONFIG_PHY_NXP_PTN3222) += phy-nxp-ptn3222.o
> -obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE) += phy-spacemit-k1-pcie.o
> obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
> amlogic/ \
> apple/ \
> diff --git a/drivers/phy/spacemit/Kconfig b/drivers/phy/spacemit/Kconfig
> index 0136aee2e8a2..50b0005acf66 100644
> --- a/drivers/phy/spacemit/Kconfig
> +++ b/drivers/phy/spacemit/Kconfig
> @@ -2,6 +2,18 @@
> #
> # Phy drivers for SpacemiT platforms
> #
> +config PHY_SPACEMIT_K1_PCIE
> + tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
> + depends on ARCH_SPACEMIT || COMPILE_TEST
> + depends on COMMON_CLK
> + depends on HAS_IOMEM
> + depends on OF
> + select GENERIC_PHY
> + default ARCH_SPACEMIT
> + help
> + Enable support for the PCIe and USB 3 combo PHY and two
> + PCIe-only PHYs used in the SpacemiT K1 SoC.
> +
> config PHY_SPACEMIT_K1_USB2
> tristate "SpacemiT K1 USB 2.0 PHY support"
> depends on (ARCH_SPACEMIT || COMPILE_TEST) && OF
> diff --git a/drivers/phy/spacemit/Makefile b/drivers/phy/spacemit/Makefile
> index fec0b425a948..a821a21d6142 100644
> --- a/drivers/phy/spacemit/Makefile
> +++ b/drivers/phy/spacemit/Makefile
> @@ -1,2 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE) += phy-k1-pcie.o
> obj-$(CONFIG_PHY_SPACEMIT_K1_USB2) += phy-k1-usb2.o
> diff --git a/drivers/phy/phy-spacemit-k1-pcie.c b/drivers/phy/spacemit/phy-k1-pcie.c
> similarity index 100%
> rename from drivers/phy/phy-spacemit-k1-pcie.c
> rename to drivers/phy/spacemit/phy-k1-pcie.c
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Josua Mayer @ 2026-02-23 12:43 UTC (permalink / raw)
To: Andreas Kemnade, Vladimir Oltean
Cc: Geert Uytterhoeven, Marc Kleine-Budde, Vincent Mailhol,
Vinod Koul, Neil Armstrong, Peter Rosin, Aaro Koskinen,
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: <20260216162406.0121dd91@kemnade.info>
Am 16.02.26 um 16:24 schrieb Andreas Kemnade:
> On Mon, 16 Feb 2026 11:29:14 +0200
> Vladimir Oltean <olteanv@gmail.com> wrote:
>
>> Hi Josua,
>>
>> On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote:
>>>>> In the future, when you have a series with cross-tree dependencies,
>>>>> please try to think of it as individual mini-series for each tree's
>>>>> 'next' branch, and specify clearly that you need stable tags (to be
>>>>> pulled into other trees).
>>> I don't really understand how I could split my series up to avoid this
>>> issue.
>>>
>>> Due to the fact that one (and now two) drivers implemented local
>>> mux helpers, to undo that an atomic change must be made tree-wide.
>>>
>>> Meanwhile it must be avoided that while the mux core helpers are being
>>> tested / reviewed, that any tree adds another driver-local mux helper
>>> like appears to have happened here.
>>>
>>> Note that my patch-set did go to linux-phy@lists.infradead.org list, too.
>>>
>>> The second challenge for this series was that mux framework is being
>>> enabled only by drivers Kconfig "select" - and not possible by menuconfig.
>>> This is e.g. responsible for being unable to test =m build with arm64
>>> defconfig - and lead to it only being detected through kernel robot
>>> x86_64 allmodconfig.
>> To avoid this, a combination of developer due diligence + maintainer due
>> diligence is probably required.
>>
>> From linux-phy perspective, there will be some automated build testing
>> (which did not exist at the time of your submission). This would have
>> caught the 'hidden' devm_mux_state_get_optional() call present only in
>> linux-phy/next, when testing patch 2/7.
Excellent!
>>
>> But, to work, the build automation needs to be able to apply the entire
>> patch set on linux-phy/next. So expect some pushback if it doesn't
>> (hence the recommendation to send a mini-series to linux-phy first, and
>> request a stable tag).
It would help immensely if there was a way to get the patches renaming
driver-local conflicting helper-functions very early, before anything else.
Would this sort of patch be acceptable in linux-next now, so it can make
it into v7.0-rc1?
If not then that mini-patchset would be the first one I shall submit after
v7.0-rc1 is released.
Then I can treat the actual implementation of the devm_mux_* helpers
as a second standalone patch-set.
And finally patching all drivers with local helpers to use the new global ones
can be patch-set number 3.
Any opinions on this?
> I do not think that is at all the duty of the patch submitter. I think as
> long as every dependencies and side effects are documented, it is IMHO up to the
> maintainers to decide how it can be merged best. They know best whether there
> is any danger of conflicts in their working tree because that is an area
> where people are working on. Especially this patchset is around for months.
>
> In MFD where it is
> more common practice to have cross-subsystem patchsets, once acks from
> everyone are there, MFD Maintainer creates an immutable branch with a tag.
> The maintainers of the affected subsystems pull it in.
This seems like an option, if I can get the patch-set (or a partial one) ready early in the cycle.
>
> Regards,
> Andreas
>
--
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