* Re: [PATCH phy-next v2] phy: apple: apple: Use local variable for ioremap return value
From: Vladimir Oltean @ 2026-02-16 9:04 UTC (permalink / raw)
To: Janne Grunau
Cc: Sven Peter, Neal Gompa, Vinod Koul, Neil Armstrong, Philipp Zabel,
asahi, linux-phy, linux-kernel, linux-arm-kernel, Dan Carpenter
In-Reply-To: <20260215-phy-apple-resource-err-ptr-v2-1-e43c22453682@jannau.net>
On Sun, Feb 15, 2026 at 09:02:51AM +0100, Janne Grunau wrote:
> The indirection through the resources array is unnecessarily complicated
> and resuling in using IS_ERR() and PTR_ERR() on a valid address. A local
> variable for the devm_ioremap_resource() return value is both easier to
> read and matches expectations when reading code.
>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Closes: https://lore.kernel.org/asahi/aYXvX1bYOXtYCgfC@stanley.mountain/
> Suggested-by: Vladimir Oltean <olteanv@gmail.com>
> Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY")
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Changes in v2:
> - Use a local variable instead of the complex indirection with the
> resources array
> - Link to v1: https://lore.kernel.org/r/20260207-phy-apple-resource-err-ptr-v1-1-78735b07ed2d@jannau.net
> ---
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
I hope this can be picked up for the linux-phy PR.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/3] phy: k1-usb: add disconnect function support
From: Vladimir Oltean @ 2026-02-16 9:01 UTC (permalink / raw)
To: Yixun Lan
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang, Junzhong Pan, linux-phy, devicetree,
linux-riscv, spacemit, linux-kernel
In-Reply-To: <20260214-11-k3-usb2-phy-v2-2-6ed31e031ab4@kernel.org>
Hello Yixun,
On Sat, Feb 14, 2026 at 08:29:15PM +0800, Yixun Lan wrote:
> A disconnect status BIT of USB2 PHY need to be cleared, otherwise
> it will fail to work properly during next connection when devices
> connect to roothub directly.
>
> Fixes: fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
> Signed-off-by: Yixun Lan <dlan@kernel.org>
> ---
> drivers/phy/spacemit/phy-k1-usb2.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/phy/spacemit/phy-k1-usb2.c b/drivers/phy/spacemit/phy-k1-usb2.c
> index 342061380012..959bf79c7a72 100644
> --- a/drivers/phy/spacemit/phy-k1-usb2.c
> +++ b/drivers/phy/spacemit/phy-k1-usb2.c
> @@ -48,6 +48,9 @@
> #define PHY_CLK_HSTXP_EN BIT(3) /* clock hstxp enable */
> #define PHY_HSTXP_MODE BIT(4) /* 0: force en_txp to be 1; 1: no force */
>
> +#define PHY_K1_HS_HOST_DISC 0x40
> +#define PHY_K1_HS_HOST_DISC_CLR BIT(0)
> +
> #define PHY_PLL_DIV_CFG 0x98
> #define PHY_FDIV_FRACT_8_15 GENMASK(7, 0)
> #define PHY_FDIV_FRACT_16_19 GENMASK(11, 8)
> @@ -142,9 +145,20 @@ static int spacemit_usb2phy_exit(struct phy *phy)
> return 0;
> }
>
> +static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
> +{
> + struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
> +
> + regmap_update_bits(sphy->regmap_base, PHY_K1_HS_HOST_DISC,
> + PHY_K1_HS_HOST_DISC_CLR, PHY_K1_HS_HOST_DISC_CLR);
Please align function arguments to the open parenthesis.
Since we are in the merge window, it is likely that new features will
not be picked up at this stage.
But this seems to be a fix for existing SpacemiT K1 support, currently
in the linux-phy/next branch. The linux-phy pull request hasn't been
sent yet, so if you can resend just this patch and we can get an ACK for
it in time, perhaps it can be included for v7.0.
The K3 support should be resent after the merge window.
> +
> + return 0;
> +}
> +
> static const struct phy_ops spacemit_usb2phy_ops = {
> .init = spacemit_usb2phy_init,
> .exit = spacemit_usb2phy_exit,
> + .disconnect = spacemit_usb2phy_disconnect,
> .owner = THIS_MODULE,
> };
>
>
> --
> 2.52.0
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: hisilicon: Fix OF node reference leak
From: Vladimir Oltean @ 2026-02-16 8:43 UTC (permalink / raw)
To: Haotian Zhang; +Cc: vkoul, kishon, andriy.shevchenko, linux-phy, linux-kernel
In-Reply-To: <20251112062246.852-1-vulab@iscas.ac.cn>
Hello Haotian,
On Wed, Nov 12, 2025 at 02:22:46PM +0800, Haotian Zhang wrote:
> hi3670_pcie_get_resources_from_pcie() leaks an OF node reference
> obtained by of_get_child_by_name(). The reference is not released
> on any of the error paths or on successful return, causing a
> reference count leak.
>
> Fix this by declaring the device node with the __free(device_node)
> cleanup construct to ensure the reference is automatically released.
>
> Fixes: 73075011ffff ("phy: HiSilicon: Add driver for Kirin 970 PCIe PHY")
> Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
> ---
> drivers/phy/hisilicon/phy-hi3670-pcie.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/hisilicon/phy-hi3670-pcie.c b/drivers/phy/hisilicon/phy-hi3670-pcie.c
> index dbc7dcce682b..fc4f50aa31cd 100644
> --- a/drivers/phy/hisilicon/phy-hi3670-pcie.c
> +++ b/drivers/phy/hisilicon/phy-hi3670-pcie.c
> @@ -558,11 +558,10 @@ static int hi3670_pcie_noc_power(struct hi3670_pcie_phy *phy, bool enable)
>
> static int hi3670_pcie_get_resources_from_pcie(struct hi3670_pcie_phy *phy)
> {
> - struct device_node *pcie_port;
> struct device *dev = phy->dev;
> struct device *pcie_dev;
> -
> - pcie_port = of_get_child_by_name(dev->parent->of_node, "pcie");
> + struct device_node *pcie_port __free(device_node) =
> + of_get_child_by_name(dev->parent->of_node, "pcie");
> if (!pcie_port) {
> dev_err(dev, "no pcie node found in %s\n",
> dev->parent->of_node->full_name);
> --
> 2.50.1.windows.1
>
>
Sorry for the delay, and thank you for the patch.
Please do not complicate the solution more than necessary, and more
importantly, do not use cleanup.h infrastructure added in 2023 to fix a
bug from 2021 (will be difficult to backport).
In this case, it is sufficient to free the OF node after
bus_find_device_by_of_node():
pcie_port = of_get_child_by_name(dev->parent->of_node, "pcie");
if (!pcie_port) {
dev_err(dev, "no pcie node found in %s\n",
dev->parent->of_node->full_name);
return -ENODEV;
}
pcie_dev = bus_find_device_by_of_node(&platform_bus_type, pcie_port);
+ of_node_put(pcie_port);
if (!pcie_dev) {
dev_err(dev, "Didn't find pcie device\n");
return -ENODEV;
}
Note that there exists a second reference leak bug in the same function.
bus_find_device_by_of_node() requires put_device(pcie_dev) after it is
no longer needed.
Can you resubmit a patch set addressing both issues?
--
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-16 8:19 UTC (permalink / raw)
To: Geert Uytterhoeven, Vladimir Oltean
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang,
Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <CAMuHMdVOqovkugmCnR4FOfk8VkQyN_dmyKFzbsOSN0mPKQedeQ@mail.gmail.com>
Hi,
On 12/02/2026 18:53, Geert Uytterhoeven wrote:
> Hi Vladimir,
>
> On Thu, 12 Feb 2026 at 17:48, Vladimir Oltean <olteanv@gmail.com> wrote:
>> On Sun, Feb 08, 2026 at 05:38:56PM +0200, Josua Mayer wrote:
>>> Rename the temporary devm_mux_state_get_optional function to avoid
>>> conflict with upcoming implementation in multiplexer subsystem.
>>>
>>> Acked-by: Vinod Koul <vkoul@kernel.org>
>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>> 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.
>> Telling maintainers what is your expected
>> merge strategy helps avoid making mistakes.
>>
>> For example, if you did that in this set, you wouldn't have missed the
>> fact that in linux-phy/next, phy-can-transceiver is _not_ the only
>> occurrence of devm_mux_state_get_optional(). There's another one in
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c, and that should be also
>> handled in order for trees to not enter inconsistent states.
> To his defense, the one in drivers/phy/renesas/phy-rcar-gen3-usb2.c
> is a recent addition.
>
> So this is yet another case of "convert all current users" (i.e. those
> present in the typical subsystem base, typically *-rc1), with new
> users popping up in -next in parallel, which happens all the time...
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
From: Krzysztof Kozlowski @ 2026-02-16 7:33 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, 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,
AngeloGioacchino Del Regno, Jitao Shi, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <826d54c75cfd1b8e4713431a9426e89edade9eb2.1771144723.git.l.scorcia@gmail.com>
On Sun, Feb 15, 2026 at 08:53:54AM +0000, Luca Leonardo Scorcia wrote:
> Add compatibles for various display-related blocks of MediaTek mt8167.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 4 +++-
> .../bindings/display/mediatek/mediatek,dither.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 5 ++++-
> .../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 +++-
> Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
> 9 files changed, 16 insertions(+), 3 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 3/3] phy: k1-usb: k3: add USB2 PHY support
From: Yao Zi @ 2026-02-16 4:39 UTC (permalink / raw)
To: Yixun Lan, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel
In-Reply-To: <20260214-11-k3-usb2-phy-v2-3-6ed31e031ab4@kernel.org>
On Sat, Feb 14, 2026 at 08:29:16PM +0800, Yixun Lan wrote:
> Add USB2 PHY support for SpacemiT K3 SoC.
>
> Register layout of handling USB disconnect operation has been changed,
> So introducing a platform data to distinguish the different SoCs.
>
> Signed-off-by: Yixun Lan <dlan@kernel.org>
Reviewed-by: Yao Zi <me@ziyao.cc>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [REGRESSION] HDMI monitor not working on Radxa Rock 5B after phy rockchip samsung hdptx HDMI 2.1 FRL patchset
From: Cristian Ciocaltea @ 2026-02-16 1:18 UTC (permalink / raw)
To: dubito, Vinod Koul, Neil Armstrong, Heiko Stuebner, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, regressions
In-Reply-To: <1859c940219a4dbfdf0497afbf333e627ab0ba25.camel@online.de>
Hi Thomas,
On 2/14/26 12:00 AM, Thomas Niederprüm wrote:
> Hi Cristian,
>
>
> Am Freitag, dem 13.02.2026 um 00:04 +0200 schrieb Cristian Ciocaltea:
>> Hi Thomas,
>>
>> On 2/11/26 11:20 PM, Thomas Niederprüm wrote:
>>> Hi,
>>>
>>> I'm running a Radxa Rock 5B (rk3588) on a 10+ year old Samsung TV screen
>>> connected via HDMI. This worked flawlessly in 6.18.7 but does not work on
>>> linux-
>>> next. I bisected the problem and identified commit 3481fc04 to be the first
>>> bad
>>> commit. This points to the phy PLL clock rate calculation to be the problem
>>> in
>>> connection with my monitor. As it seems relevant, I attached the EDID of my
>>> monitor.
>>>
>>> I'm booting the kernel out of EDK2 after which efifb is correctly taking
>>> over
>>> the initialized display and I can see the initial kernel boot messages on
>>> the
>>> HDMI output. After the drm/kms in the kernel takes over the screen shortly
>>> turns
>>> black, changes resolution, and then correctly displays on 6.18.7. However,
>>> in
>>> linux-next the screen remains black after kms took over. I cannot see any
>>> obvious differences in the boot logs but I attached two boot logs, one for
>>> the
>>> working 6.18.7 kernel and one for the non-working linux-next kernel.
>>>
>>> When reverting 3481fc04..de5dba83 (i.e. the faulty commit and the ones that
>>> followed in the HDMI 2.1 FRL series) I can build a working kernel from
>>> linux-
>>> next.
>>>
>>> I don't know where to dig from here but I'm happy to run any test necessary
>>> to
>>> track down the problem.
>>
>> It'd be helpful if you could resend the logs after booting both kernels with
>> the
>> following params (requires CONFIG_DYNAMIC_DEBUG=y):
>>
>> rockchipdrm.dyndbg=+p dw_hdmi_qp.dyndbg=+p
>> phy_rockchip_samsung_hdptx.dyndbg=+p
>>
>> As well as running the command below before connecting your display/TV:
>>
>> $ echo 0x4 > /sys/module/drm/parameters/debug
>>
>> I've noticed you're forcing "video=HDMI-A-1:1920x1080M@60", which should be
>> anyway the preferred mode (according to the EDID).
>
> I dumped the kernel messages for a freshly built v6.19 and a linux-next image.
> For each kernel I booted with the suggested debug options and forcing the modes
> 1920x1080@60, 1920x1080@50, 1920x1080@30. The boot logs are attached. For v6.19
> all modes work. Running linux-next, 1920x1080@60 and 1920x1080@50 don't work but
> 1920x1080@30 works.
>
>> Did you try choosing a different one, e.g. 1920x1080@50 or 1920x1080@30 (they
>> are supported according to the listing in CTA-861 Extension Block). That's
>> more
>> a test to confirm the issue affects a particular modeline, or is more general.
>>
>
> As stated above, if I force 1920x1080@30 the screen turns on in linux-next.
> 1920x1080@60 and 1920x1080@50 don't work. This points to something specific to
> the modeline.
>
> By diff'ing the relevant part of the logs between kernels one can see that in
> the cases where the screen stays black the log lacks the following lines:
>
> rockchip-hdptx-phy fed60000.phy: rk_hdptx_ropll_tmds_cmn_config
> rate=185625000 mdiv=155 sdiv=4 sdm_en=1 k_sign=1 k=16 lc=62
> rockchip-hdptx-phy fed60000.phy: PHY clk ready
>
> So obviously the PHY clock never gets ready.
>
> I also attached the diffs I made.
Thanks for checking this out! The behavior is really unexpected and I'm still
unable to reproduce on my end, i.e. even tested with a Samsung TV, which is
almost as old as yours:
# Mine
Vendor & Product Identification:
Manufacturer: SAM
Model: 2685
Serial Number: 1 (0x00000001)
Made in: week 46 of 2012
# Yours
Vendor & Product Identification:
Manufacturer: SAM
Model: 1641
Serial Number: 1 (0x00000001)
Made in: week 47 of 2009
I added some more debug information, hence could you please apply commit [1] on
your next-20260213 kernel and share the logs after testing again the
1920x1080@50 and 1920x1080@30 modes?
[1] https://gitlab.collabora.com/cristicc/linux-next/-/commit/2ce4b1fb60fc601068abbe9131c05c4f09f1380c
Regards,
Cristian
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next v2] phy: apple: apple: Use local variable for ioremap return value
From: Sven Peter @ 2026-02-15 12:07 UTC (permalink / raw)
To: Janne Grunau, Neal Gompa, Vinod Koul, Neil Armstrong,
Philipp Zabel
Cc: asahi, linux-phy, linux-kernel, linux-arm-kernel, Dan Carpenter,
Vladimir Oltean
In-Reply-To: <20260215-phy-apple-resource-err-ptr-v2-1-e43c22453682@jannau.net>
On 15.02.26 09:02, Janne Grunau wrote:
> The indirection through the resources array is unnecessarily complicated
> and resuling in using IS_ERR() and PTR_ERR() on a valid address. A local
> variable for the devm_ioremap_resource() return value is both easier to
> read and matches expectations when reading code.
>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Closes: https://lore.kernel.org/asahi/aYXvX1bYOXtYCgfC@stanley.mountain/
> Suggested-by: Vladimir Oltean <olteanv@gmail.com>
> Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY")
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
Reviewed-by: Sven Peter <sven@kernel.org>
> Changes in v2:
> - Use a local variable instead of the complex indirection with the
> resources array
> - Link to v1: https://lore.kernel.org/r/20260207-phy-apple-resource-err-ptr-v1-1-78735b07ed2d@jannau.net
> ---
> drivers/phy/apple/atc.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/apple/atc.c b/drivers/phy/apple/atc.c
> index dc867f368b68748ea953e594ad998d7f965d8d1d..64d0c3dba1cbb95f867d338da706225ee0bf79f7 100644
> --- a/drivers/phy/apple/atc.c
> +++ b/drivers/phy/apple/atc.c
> @@ -2202,14 +2202,16 @@ static int atcphy_map_resources(struct platform_device *pdev, struct apple_atcph
> { "pipehandler", &atcphy->regs.pipehandler, NULL },
> };
> struct resource *res;
> + void __iomem *addr;
>
> for (int i = 0; i < ARRAY_SIZE(resources); i++) {
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, resources[i].name);
> - *resources[i].addr = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(resources[i].addr))
> - return dev_err_probe(atcphy->dev, PTR_ERR(resources[i].addr),
> + addr = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(addr))
> + return dev_err_probe(atcphy->dev, PTR_ERR(addr),
> "Unable to map %s regs", resources[i].name);
>
> + *resources[i].addr = addr;
This is much easier to understand. I missed return PTR_ERR(..) error in
the first version and introduced it originally due to the indirection as
well.
Best,
Sven
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 4/4] gpu: drm: mediatek: ovl: add specific entry for mt8167
From: Luca Leonardo Scorcia @ 2026-02-15 8:53 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Val Packett, 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, Jitao Shi, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771144723.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>
---
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 3/4] arm64: dts: mediatek: mt8167: Add DRM nodes
From: Luca Leonardo Scorcia @ 2026-02-15 8:53 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, Jitao Shi, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771144723.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>
---
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 386 +++++++++++++++++++++++
1 file changed, 386 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 27cf32d7ae35..c6306234e592 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,371 @@ 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 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ ovl0_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&mmsys_main>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ ovl0_out: endpoint@0 {
+ reg = <0>;
+ 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 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ rdma0_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&dither_out>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ rdma0_out: endpoint@0 {
+ reg = <0>;
+ 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 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ rdma1_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&mmsys_ext>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ rdma1_out: endpoint@0 {
+ reg = <0>;
+ };
+ };
+ };
+ };
+
+ 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 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ color_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&ovl0_out>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ color_out: endpoint@0 {
+ reg = <0>;
+ 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 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ ccorr_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&color_out>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ ccorr_out: endpoint@0 {
+ reg = <0>;
+ 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 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ aal_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&ccorr_out>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ aal_out: endpoint@0 {
+ reg = <0>;
+ 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 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ gamma_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&aal_out>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ gamma_out: endpoint@0 {
+ reg = <0>;
+ 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 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ dither_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&gamma_out>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ dither_out: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&rdma0_in>;
+ };
+ };
+ };
+ };
+
+ dsi: dsi@14012000 {
+ compatible = "mediatek,mt8167-dsi",
+ "mediatek,mt2701-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 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ dsi_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&rdma0_out>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ dsi_out: endpoint@0 {
+ reg = <0>;
+ };
+ };
+ };
+ };
+
+ 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 +520,17 @@ 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 2/4] dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
From: Luca Leonardo Scorcia @ 2026-02-15 8:53 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, 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,
AngeloGioacchino Del Regno, Jitao Shi, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771144723.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>
---
.../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
.../devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 4 +++-
.../bindings/display/mediatek/mediatek,dither.yaml | 1 +
.../devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 5 ++++-
.../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 +++-
Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
9 files changed, 16 insertions(+), 3 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,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
index 27ffbccc2a08..bcbde16648c0 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
@@ -25,11 +25,14 @@ properties:
- enum:
- mediatek,mt2701-dsi
- mediatek,mt7623-dsi
- - mediatek,mt8167-dsi
- mediatek,mt8173-dsi
- mediatek,mt8183-dsi
- mediatek,mt8186-dsi
- mediatek,mt8188-dsi
+ - items:
+ - enum:
+ - mediatek,mt8167-dsi
+ - const: mediatek,mt2701-dsi
- items:
- enum:
- mediatek,mt6795-dsi
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:
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 1/4] arm64: dts: mt8167: Reorder nodes according to mmio address
From: Luca Leonardo Scorcia @ 2026-02-15 8:53 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, 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,
AngeloGioacchino Del Regno, Jitao Shi, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771144723.git.l.scorcia@gmail.com>
In preparation for adding display nodes. No other changes.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.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 0/4] Add support for mt8167 display blocks
From: Luca Leonardo Scorcia @ 2026-02-15 8:53 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, 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,
AngeloGioacchino Del Regno, Jitao Shi, 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.
Luca Leonardo Scorcia (3):
arm64: dts: mt8167: Reorder nodes according to mmio address
dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
arm64: dts: mediatek: mt8167: Add DRM nodes
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,dsi.yaml | 5 +-
.../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 | 450 ++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 12 +
11 files changed, 446 insertions(+), 35 deletions(-)
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH phy-next v2] phy: apple: apple: Use local variable for ioremap return value
From: Janne Grunau @ 2026-02-15 8:02 UTC (permalink / raw)
To: Sven Peter, Neal Gompa, Vinod Koul, Neil Armstrong, Philipp Zabel
Cc: asahi, linux-phy, linux-kernel, linux-arm-kernel, Dan Carpenter,
Vladimir Oltean, Janne Grunau
The indirection through the resources array is unnecessarily complicated
and resuling in using IS_ERR() and PTR_ERR() on a valid address. A local
variable for the devm_ioremap_resource() return value is both easier to
read and matches expectations when reading code.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/asahi/aYXvX1bYOXtYCgfC@stanley.mountain/
Suggested-by: Vladimir Oltean <olteanv@gmail.com>
Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY")
Signed-off-by: Janne Grunau <j@jannau.net>
---
Changes in v2:
- Use a local variable instead of the complex indirection with the
resources array
- Link to v1: https://lore.kernel.org/r/20260207-phy-apple-resource-err-ptr-v1-1-78735b07ed2d@jannau.net
---
drivers/phy/apple/atc.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/apple/atc.c b/drivers/phy/apple/atc.c
index dc867f368b68748ea953e594ad998d7f965d8d1d..64d0c3dba1cbb95f867d338da706225ee0bf79f7 100644
--- a/drivers/phy/apple/atc.c
+++ b/drivers/phy/apple/atc.c
@@ -2202,14 +2202,16 @@ static int atcphy_map_resources(struct platform_device *pdev, struct apple_atcph
{ "pipehandler", &atcphy->regs.pipehandler, NULL },
};
struct resource *res;
+ void __iomem *addr;
for (int i = 0; i < ARRAY_SIZE(resources); i++) {
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, resources[i].name);
- *resources[i].addr = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(resources[i].addr))
- return dev_err_probe(atcphy->dev, PTR_ERR(resources[i].addr),
+ addr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(addr))
+ return dev_err_probe(atcphy->dev, PTR_ERR(addr),
"Unable to map %s regs", resources[i].name);
+ *resources[i].addr = addr;
if (resources[i].res)
*resources[i].res = res;
}
---
base-commit: dbeea86fecef7cf2b93aded4525d74f6277376ef
change-id: 20260207-phy-apple-resource-err-ptr-5923d1130465
Best regards,
--
Janne Grunau <j@jannau.net>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH phy-next] phy: apple: apple: Check the actual ioremap return value
From: Janne Grunau @ 2026-02-15 7:58 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Sven Peter, Neal Gompa, Vinod Koul, Neil Armstrong, Philipp Zabel,
asahi, linux-phy, linux-kernel, Dan Carpenter
In-Reply-To: <20260210204822.jr22el4rlyosin2q@skbuf>
Hej Vladimir,
On Tue, Feb 10, 2026 at 10:48:22PM +0200, Vladimir Oltean wrote:
> Hello Janne,
>
> On Sat, Feb 07, 2026 at 05:40:34PM +0100, Janne Grunau wrote:
> > The address where the devm_ioremap_resource() return value is stored is
> > always a valid pointer. Check the actual return value instead as that
> > that might be an error value.
> >
> > Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> > Closes: https://lore.kernel.org/asahi/aYXvX1bYOXtYCgfC@stanley.mountain/
> > Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY")
> > Signed-off-by: Janne Grunau <j@jannau.net>
> > ---
> > 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 dc867f368b68748ea953e594ad998d7f965d8d1d..c144e273a555a741b49adfccbe046df83d193e03 100644
> > --- a/drivers/phy/apple/atc.c
> > +++ b/drivers/phy/apple/atc.c
> > @@ -2206,7 +2206,7 @@ static int atcphy_map_resources(struct platform_device *pdev, struct apple_atcph
> > for (int i = 0; i < ARRAY_SIZE(resources); i++) {
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM, resources[i].name);
> > *resources[i].addr = devm_ioremap_resource(&pdev->dev, res);
> > - if (IS_ERR(resources[i].addr))
> > + if (IS_ERR(*resources[i].addr))
> > return dev_err_probe(atcphy->dev, PTR_ERR(resources[i].addr),
> > "Unable to map %s regs", resources[i].name);
>
> This does not seem correct - every call site that tests a pointer for
> IS_ERR() also decodes the error using PTR_ERR(). Whereas you are here
> creating the pattern "if (IS_ERR(*a)) return PTR_ERR(a)".
missed this.
> Proven practice seems to tell us that insisting to save the
> devm_ioremap_resource() return code directly in *resources[i].addr
> is too complex here.
>
> Would you consider creating a temporary "void __iomem *addr" local
> variable, and set "*resources[i].addr = addr" only once it's validated?
> This would make the code obviously correct upon review.
I agree. A local variable makes this easier to read. Thanks for spotting
this and the suggestion. I'll change that for v2.
Janne
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v4 0/3] dt-bindings: phy: Convert TI OMAP control and PIPE3 PHY to DT schema
From: Charan Pedumuru @ 2026-02-15 5:48 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros, linux-phy, devicetree, linux-kernel, linux-omap
In-Reply-To: <20260213190054.ezblztj3blmhtywr@skbuf>
On 14-02-2026 00:30, Vladimir Oltean wrote:
> Hi Charan,
>
> On Fri, Feb 13, 2026 at 10:06:16PM +0530, Charan Pedumuru wrote:
>> On 04-02-2026 21:14, Vinod Koul wrote:
>>>
>>> On Fri, 23 Jan 2026 15:39:01 +0000, Charan Pedumuru wrote:
>>>> This series converts the old text-based DeviceTree bindings for TI OMAP
>>>> Control PHY and TI PIPE3 PHY to modern JSON-schema (YAML) format.
>>>>
>>>>
>>>
>>> Applied, thanks!
>>>
>>> [2/3] dt-bindings: phy: ti,phy-usb3: convert to DT schema
>>> commit: 62c9ff8fc20d23c0dc36be1330734fdafb3e8585
>>> [3/3] dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
>>> commit: 7878306d182a1750583a325a29e5ccab9ce0235b
>>
>> Hi Vinod,
>>
>> You missed to apply the first patch which has DT node pattern changes
>> and now this dtb check fails in linux-next as these YAML patches use
>> the updated node pattern. I got a report of errors from kernel test
>> robot.
>
> If there was any request formulated to Vinod to pick up patch 1, then I
> also missed it while reading this series.
>
> Usually, dt-bindings patches are picked up by the subsystem maintainer
> while DTS patches are picked up by the platform maintainer. If you know
> that there is any dependency then it would greatly help if you could
> mention that upfront, or even specify how you expect the patches to be
> merged.
>
> In this case, I expect the warnings will get eventually resolved when
> Kevin picks up patch 1.
Yes.
>
> To avoid warnings from being introduced in the first place, you could
> have
> - requested all patches to be taken through a single tree (requires
> maintainer coordination with ACK from the other one, more complicated
> if the files touched are under heavy development)
> - requested a stable tag from the first maintainer, to be pulled in the
> second tree
> - send patch 1, wait for a merge window to pass, send patches 2-3
Sure, next time I will follow this procedure. Thanks.
--
Best Regards,
Charan.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 3/3] phy: k1-usb: k3: add USB2 PHY support
From: Yixun Lan @ 2026-02-14 12:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan
In-Reply-To: <20260214-11-k3-usb2-phy-v2-0-6ed31e031ab4@kernel.org>
Add USB2 PHY support for SpacemiT K3 SoC.
Register layout of handling USB disconnect operation has been changed,
So introducing a platform data to distinguish the different SoCs.
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
drivers/phy/spacemit/phy-k1-usb2.c | 34 +++++++++++++++++++++++++++++-----
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/spacemit/phy-k1-usb2.c b/drivers/phy/spacemit/phy-k1-usb2.c
index 959bf79c7a72..b4ba97481ddd 100644
--- a/drivers/phy/spacemit/phy-k1-usb2.c
+++ b/drivers/phy/spacemit/phy-k1-usb2.c
@@ -51,6 +51,9 @@
#define PHY_K1_HS_HOST_DISC 0x40
#define PHY_K1_HS_HOST_DISC_CLR BIT(0)
+#define PHY_K3_HS_HOST_DISC 0x20
+#define PHY_K3_HS_HOST_DISC_CLR BIT(8)
+
#define PHY_PLL_DIV_CFG 0x98
#define PHY_FDIV_FRACT_8_15 GENMASK(7, 0)
#define PHY_FDIV_FRACT_16_19 GENMASK(11, 8)
@@ -145,7 +148,7 @@ static int spacemit_usb2phy_exit(struct phy *phy)
return 0;
}
-static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
+static int spacemit_k1_usb2phy_disconnect(struct phy *phy, int port)
{
struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
@@ -155,10 +158,27 @@ static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
return 0;
}
-static const struct phy_ops spacemit_usb2phy_ops = {
+static int spacemit_k3_usb2phy_disconnect(struct phy *phy, int port)
+{
+ struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
+
+ regmap_update_bits(sphy->regmap_base, PHY_K3_HS_HOST_DISC,
+ PHY_K3_HS_HOST_DISC_CLR, PHY_K3_HS_HOST_DISC_CLR);
+
+ return 0;
+}
+
+static const struct phy_ops spacemit_k1_usb2phy_ops = {
.init = spacemit_usb2phy_init,
.exit = spacemit_usb2phy_exit,
- .disconnect = spacemit_usb2phy_disconnect,
+ .disconnect = spacemit_k1_usb2phy_disconnect,
+ .owner = THIS_MODULE,
+};
+
+static const struct phy_ops spacemit_k3_usb2phy_ops = {
+ .init = spacemit_usb2phy_init,
+ .exit = spacemit_usb2phy_exit,
+ .disconnect = spacemit_k3_usb2phy_disconnect,
.owner = THIS_MODULE,
};
@@ -167,12 +187,15 @@ static int spacemit_usb2phy_probe(struct platform_device *pdev)
struct phy_provider *phy_provider;
struct device *dev = &pdev->dev;
struct spacemit_usb2phy *sphy;
+ const struct phy_ops *ops;
void __iomem *base;
sphy = devm_kzalloc(dev, sizeof(*sphy), GFP_KERNEL);
if (!sphy)
return -ENOMEM;
+ ops = device_get_match_data(dev);
+
sphy->clk = devm_clk_get_prepared(&pdev->dev, NULL);
if (IS_ERR(sphy->clk))
return dev_err_probe(dev, PTR_ERR(sphy->clk), "Failed to get clock\n");
@@ -185,7 +208,7 @@ static int spacemit_usb2phy_probe(struct platform_device *pdev)
if (IS_ERR(sphy->regmap_base))
return dev_err_probe(dev, PTR_ERR(sphy->regmap_base), "Failed to init regmap\n");
- sphy->phy = devm_phy_create(dev, NULL, &spacemit_usb2phy_ops);
+ sphy->phy = devm_phy_create(dev, NULL, ops);
if (IS_ERR(sphy->phy))
return dev_err_probe(dev, PTR_ERR(sphy->phy), "Failed to create phy\n");
@@ -196,7 +219,8 @@ static int spacemit_usb2phy_probe(struct platform_device *pdev)
}
static const struct of_device_id spacemit_usb2phy_dt_match[] = {
- { .compatible = "spacemit,k1-usb2-phy", },
+ { .compatible = "spacemit,k1-usb2-phy", .data = &spacemit_k1_usb2phy_ops },
+ { .compatible = "spacemit,k3-usb2-phy", .data = &spacemit_k3_usb2phy_ops },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, spacemit_usb2phy_dt_match);
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 2/3] phy: k1-usb: add disconnect function support
From: Yixun Lan @ 2026-02-14 12:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan
In-Reply-To: <20260214-11-k3-usb2-phy-v2-0-6ed31e031ab4@kernel.org>
A disconnect status BIT of USB2 PHY need to be cleared, otherwise
it will fail to work properly during next connection when devices
connect to roothub directly.
Fixes: fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
drivers/phy/spacemit/phy-k1-usb2.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/phy/spacemit/phy-k1-usb2.c b/drivers/phy/spacemit/phy-k1-usb2.c
index 342061380012..959bf79c7a72 100644
--- a/drivers/phy/spacemit/phy-k1-usb2.c
+++ b/drivers/phy/spacemit/phy-k1-usb2.c
@@ -48,6 +48,9 @@
#define PHY_CLK_HSTXP_EN BIT(3) /* clock hstxp enable */
#define PHY_HSTXP_MODE BIT(4) /* 0: force en_txp to be 1; 1: no force */
+#define PHY_K1_HS_HOST_DISC 0x40
+#define PHY_K1_HS_HOST_DISC_CLR BIT(0)
+
#define PHY_PLL_DIV_CFG 0x98
#define PHY_FDIV_FRACT_8_15 GENMASK(7, 0)
#define PHY_FDIV_FRACT_16_19 GENMASK(11, 8)
@@ -142,9 +145,20 @@ static int spacemit_usb2phy_exit(struct phy *phy)
return 0;
}
+static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
+{
+ struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
+
+ regmap_update_bits(sphy->regmap_base, PHY_K1_HS_HOST_DISC,
+ PHY_K1_HS_HOST_DISC_CLR, PHY_K1_HS_HOST_DISC_CLR);
+
+ return 0;
+}
+
static const struct phy_ops spacemit_usb2phy_ops = {
.init = spacemit_usb2phy_init,
.exit = spacemit_usb2phy_exit,
+ .disconnect = spacemit_usb2phy_disconnect,
.owner = THIS_MODULE,
};
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: phy: spacemit: k3: add USB2 PHY support
From: Yixun Lan @ 2026-02-14 12:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Krzysztof Kozlowski
In-Reply-To: <20260214-11-k3-usb2-phy-v2-0-6ed31e031ab4@kernel.org>
Introduce a compatible string for the USB2 PHY in SpacemiT K3 SoC. The IP
of USB2 PHY mostly shares the same functionalities with K1 SoC, while has
some register layout changes.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
index 43eaca90d88c..18025e5f60d6 100644
--- a/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
@@ -4,14 +4,16 @@
$id: http://devicetree.org/schemas/phy/spacemit,usb2-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SpacemiT K1 SoC USB 2.0 PHY
+title: SpacemiT K1/K3 SoC USB 2.0 PHY
maintainers:
- Ze Huang <huang.ze@linux.dev>
properties:
compatible:
- const: spacemit,k1-usb2-phy
+ enum:
+ - spacemit,k1-usb2-phy
+ - spacemit,k3-usb2-phy
reg:
maxItems: 1
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/3] phy: spacemit: Add USB2 PHY support for K3 SoC
From: Yixun Lan @ 2026-02-14 12:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Krzysztof Kozlowski
The series trys to add USB2 PHY support for SpacemiT K3 SoC,
while patch [2/3] implement a disconnect function which is
needed during next connection.
No DTS part has been inclueded in this series, instead I plan
to submit while adding USB host support.
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
Changes in v2:
- collect ACK
- add Fixes tag
- implement separate phy_ops
- Link to v1: https://lore.kernel.org/r/20260212-11-k3-usb2-phy-v1-0-43578592405d@kernel.org
---
Yixun Lan (3):
dt-bindings: phy: spacemit: k3: add USB2 PHY support
phy: k1-usb: add disconnect function support
phy: k1-usb: k3: add USB2 PHY support
.../devicetree/bindings/phy/spacemit,usb2-phy.yaml | 6 ++-
drivers/phy/spacemit/phy-k1-usb2.c | 44 ++++++++++++++++++++--
2 files changed, 45 insertions(+), 5 deletions(-)
---
base-commit: dd39930f3d9c1d74a40b79d368e1f3d1555e919c
change-id: 20260124-11-k3-usb2-phy-c4630b990b1f
Best regards,
--
Yixun Lan <dlan@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/6] arm64: dts: qcom: milos: Add UFS nodes
From: Dmitry Baryshkov @ 2026-02-13 21:06 UTC (permalink / raw)
To: Abel Vesa
Cc: Luca Weiss, 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, Konrad Dybcio
In-Reply-To: <7zdyb2wnojudnrnomnx4aiwvni3e6i52kfioflb3gslztsizkw@ofvvkvrv5f3s>
On Tue, Jan 20, 2026 at 04:52:43PM +0200, Abel Vesa wrote:
> On 26-01-20 16:49:26, Abel Vesa wrote:
> > On 26-01-12 14:53:18, Luca Weiss wrote:
> > > Add the nodes for the UFS PHY and UFS host controller, along with the
> > > ICE used for UFS.
> > >
> > > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/milos.dtsi | 129 +++++++++++++++++++++++++++++++++++-
> > > 1 file changed, 126 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> > > index e1a51d43943f..7c8a84bfaee1 100644
> > > --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> > > @@ -1151,6 +1151,129 @@ aggre2_noc: interconnect@1700000 {
> > > qcom,bcm-voters = <&apps_bcm_voter>;
> > > };
> > >
> > > + ufs_mem_phy: phy@1d80000 {
> > > + compatible = "qcom,milos-qmp-ufs-phy";
> > > + reg = <0x0 0x01d80000 0x0 0x2000>;
> > > +
> > > + clocks = <&rpmhcc RPMH_CXO_CLK>,
> > > + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
> > > + <&tcsr TCSR_UFS_CLKREF_EN>;
> > > + clock-names = "ref",
> > > + "ref_aux",
> > > + "qref";
> > > +
> > > + resets = <&ufs_mem_hc 0>;
> > > + reset-names = "ufsphy";
> > > +
> > > + power-domains = <&gcc UFS_MEM_PHY_GDSC>;
> > > +
> > > + #clock-cells = <1>;
> > > + #phy-cells = <0>;
> > > +
> > > + status = "disabled";
> > > + };
> > > +
> > > + ufs_mem_hc: ufshc@1d84000 {
> > > + compatible = "qcom,milos-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
> > > + reg = <0x0 0x01d84000 0x0 0x3000>;
> > > +
> > > + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH 0>;
> > > +
> > > + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
> > > + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
> > > + <&gcc GCC_UFS_PHY_AHB_CLK>,
> > > + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
> > > + <&tcsr TCSR_UFS_PAD_CLKREF_EN>,
> >
> > Maybe I'm looking at the wrong documentation, but it doesn't seem to exist
> > such clock on Milos. It does exist on SM8650 though. So maybe the TCSR CC
> > driver is not really that much compatible between these two platforms.
> >
> > I take it that the UFS works. Maybe because the actual TCSR UFS clkref
> > is left enabled at boot?
>
> Oh, nevemind. I think I was looking at the wrong SoC.
Is that an r-b then? ;-)
--
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 v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Vladimir Oltean @ 2026-02-13 20:15 UTC (permalink / raw)
To: Loic Poulain
Cc: Johan Hovold, vkoul, kishon, linux-arm-msm, linux-phy,
dmitry.baryshkov, neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <CAFEp6-0rzkqc0ajN72q=mv3U-TT0JHMSPmnJD6ohKuLmbPz2-A@mail.gmail.com>
Hello Loic,
On Fri, Feb 13, 2026 at 04:04:43PM +0100, Loic Poulain wrote:
> On Fri, Feb 13, 2026 at 11:45 AM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Fri, Feb 13, 2026 at 10:45:32AM +0100, Loic Poulain wrote:
> > > On Fri, Feb 13, 2026 at 10:07 AM Johan Hovold <johan@kernel.org> wrote:
> > > >
> > > > On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> > > > > Enabling runtime PM before attaching the hsphy instance as driver data
> > > > > can lead to a NULL pointer dereference in runtime PM callbacks that
> > > > > expect valid driver data. There is a small window where the suspend
> > > > > callback may run after PM runtime enabling and before runtime forbid.
> > > >
> > > > So here too, the commit should reflect that this cannot really happen in
> > > > practice.
> > >
> > > This happened in practice in the qcom‑qusb2 PHY driver, with the same
> > > code flow.
> > > Bug: https://github.com/qualcomm-linux/qcom-deb-images/issues/208
> > > Patch: https://lore.kernel.org/linux-arm-msm/20251219085640.114473-1-loic.poulain@oss.qualcomm.com/
> >
> > Thanks for the link.
> >
> > > I know it may sound unlikely, but this crash has been reported
> > > several times during boot‑stress testing. I haven’t investigated
> > > deeply enough to determine whether it’s caused by an unfortunate
> > > preemption window or a racing CPU.
> >
> > But I'm literally asking for *what* would trigger the suspend in that
> > initial window between enable() and forbid() cause I don't see it.
>
> To be honest, I had not initially looked into the exact cause of the
> suspend trigger until now, but here is what is happening.
>
> The PHY is a supplier of the USB device. A USB device cannot be probed
> until all its suppliers are ready. As long as the PHY is not ready, the
> device core keeps retrying the probe, which fails with -EPROBE_DEFER.
>
> At some point the PHY probe finally runs, but the device core may still be
> attempting to probe the USB device concurrently.
>
> Inside __driver_probe_device(), we have:
>
> ret = really_probe(dev, drv);
> pm_request_idle(dev);
>
> if (dev->parent)
> pm_runtime_put(dev->parent);
>
> pm_runtime_put_suppliers(dev);
> return ret;
>
> This means that whenever a USB probe attempt completes, whether with an
> error or not, its suppliers are released via pm_runtime_put_suppliers().
> Releasing suppliers may in turn trigger a runtime suspend.
>
> In our case, since the PHY is a supplier of the USB device, the USB core
> keeps 'looping' in __driver_probe_device() returning -EPROBE_DEFER until
> the PHY becomes ready. As a result, pm_runtime_put_suppliers() may run
> concurrently with the PHY's probe function. If this happens after
> runtime PM has been enabled for the PHY, but before the driver has
> forbidden suspend or taken a PM reference, the PHY may end up being
> runtime-suspended 'unexpectedly'.
Please resend this patch with the commit message including this
explanation (note that your code snippet from __driver_probe_device() is
missing a relevant call to pm_runtime_get_suppliers()).
Also, please separate the devres change to its own patch. It is fixing a
different logical issue (missing pm_runtime_disable() causes device with
unbound driver to have non-zero dev->power.disable_depth; should warn on
driver re-probe).
Another comment upon reviewing this driver's runtime PM use (although
this is at most something that may result in a patch for "next"):
This driver uses hsphy->phy_initialized to make sure qcom_snps_hsphy_suspend()
isn't called unless qcom_snps_hsphy_init() was called.
Don't we achieve the same behaviour by replacing "hsphy->phy_initialized = true"
with pm_runtime_get_sync(dev) and "hsphy->phy_initialized = false" with
pm_runtime_put(dev)?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v4 0/3] dt-bindings: phy: Convert TI OMAP control and PIPE3 PHY to DT schema
From: Vladimir Oltean @ 2026-02-13 19:00 UTC (permalink / raw)
To: Charan Pedumuru
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros, linux-phy, devicetree, linux-kernel, linux-omap
In-Reply-To: <f60156a6-58af-4548-9dc3-71c71b822343@gmail.com>
Hi Charan,
On Fri, Feb 13, 2026 at 10:06:16PM +0530, Charan Pedumuru wrote:
> On 04-02-2026 21:14, Vinod Koul wrote:
> >
> > On Fri, 23 Jan 2026 15:39:01 +0000, Charan Pedumuru wrote:
> >> This series converts the old text-based DeviceTree bindings for TI OMAP
> >> Control PHY and TI PIPE3 PHY to modern JSON-schema (YAML) format.
> >>
> >>
> >
> > Applied, thanks!
> >
> > [2/3] dt-bindings: phy: ti,phy-usb3: convert to DT schema
> > commit: 62c9ff8fc20d23c0dc36be1330734fdafb3e8585
> > [3/3] dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
> > commit: 7878306d182a1750583a325a29e5ccab9ce0235b
>
> Hi Vinod,
>
> You missed to apply the first patch which has DT node pattern changes
> and now this dtb check fails in linux-next as these YAML patches use
> the updated node pattern. I got a report of errors from kernel test
> robot.
If there was any request formulated to Vinod to pick up patch 1, then I
also missed it while reading this series.
Usually, dt-bindings patches are picked up by the subsystem maintainer
while DTS patches are picked up by the platform maintainer. If you know
that there is any dependency then it would greatly help if you could
mention that upfront, or even specify how you expect the patches to be
merged.
In this case, I expect the warnings will get eventually resolved when
Kevin picks up patch 1.
To avoid warnings from being introduced in the first place, you could
have
- requested all patches to be taken through a single tree (requires
maintainer coordination with ACK from the other one, more complicated
if the files touched are under heavy development)
- requested a stable tag from the first maintainer, to be pulled in the
second tree
- send patch 1, wait for a merge window to pass, send patches 2-3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add vdda-refgen supplies for Glymur
From: Dmitry Baryshkov @ 2026-02-13 17:48 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <aY1KCLDDoQtLJ4F1@hu-qianyu-lv.qualcomm.com>
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.
>
> - 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: Dmitry Baryshkov @ 2026-02-13 17:47 UTC (permalink / raw)
To: Qiang Yu
Cc: Krzysztof Kozlowski, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <aY1Jx5J8x/OALk5M@hu-qianyu-lv.qualcomm.com>
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.
>
> >
> > 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.
> 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
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