* [PATCH 3/3] phy: qcom: qmp-usbc: Simplify check for non-NULL pointer
From: Krzysztof Kozlowski @ 2026-02-16 11:04 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Vinod Koul, Neil Armstrong,
Philipp Zabel, asahi, linux-arm-kernel, linux-phy, linux-kernel,
linux-arm-msm
Cc: Krzysztof Kozlowski
In-Reply-To: <20260216110413.159994-4-krzysztof.kozlowski@oss.qualcomm.com>
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(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
index 14feb77789b3..c342479a3798 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
@@ -1679,7 +1679,7 @@ static int qmp_usbc_register_clocks(struct qmp_usbc *qmp, struct device_node *np
if (ret)
return ret;
- if (qmp->dp_serdes != 0) {
+ if (qmp->dp_serdes) {
ret = phy_dp_clks_register(qmp, np);
if (ret)
return ret;
@@ -1833,7 +1833,7 @@ static int qmp_usbc_parse_dt(struct qmp_usbc *qmp)
if (IS_ERR(base))
return PTR_ERR(base);
- if (offs->dp_serdes != 0) {
+ if (offs->dp_serdes) {
qmp->dp_serdes = base + offs->dp_serdes;
qmp->dp_tx = base + offs->dp_txa;
qmp->dp_tx2 = base + offs->dp_txb;
@@ -1982,7 +1982,7 @@ static int qmp_usbc_probe(struct platform_device *pdev)
phy_set_drvdata(qmp->usb_phy, qmp);
- if (qmp->dp_serdes != 0) {
+ if (qmp->dp_serdes) {
qmp->dp_phy = devm_phy_create(dev, np, &qmp_usbc_dp_phy_ops);
if (IS_ERR(qmp->dp_phy)) {
ret = PTR_ERR(qmp->dp_phy);
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 2/3] phy: marvell: mmp3-hsic: Avoid re-casting __iomem
From: Krzysztof Kozlowski @ 2026-02-16 11:04 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Vinod Koul, Neil Armstrong,
Philipp Zabel, asahi, linux-arm-kernel, linux-phy, linux-kernel,
linux-arm-msm
Cc: Krzysztof Kozlowski
In-Reply-To: <20260216110413.159994-4-krzysztof.kozlowski@oss.qualcomm.com>
__iomem annotated memory must be accessed via dedicated accessors, even
if actual code is correct (accessing the driver data in
mmp3_hsic_phy_init() brings back the __iomem cast), but dropping its
cast (with or without __force) when storing as driver data seems like
less readable code for any future changes. Instead, add a dedicated
wrapping structure just to hold the pointer without changing the __iomem
cast. This makes the code explicit, obvious and solves the sparse
warning:
phy-mmp3-hsic.c:58:31: warning: cast removes address space '__iomem' of expression
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/phy/marvell/phy-mmp3-hsic.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/phy/marvell/phy-mmp3-hsic.c b/drivers/phy/marvell/phy-mmp3-hsic.c
index 271f1a2258ef..72ab6da0ebc3 100644
--- a/drivers/phy/marvell/phy-mmp3-hsic.c
+++ b/drivers/phy/marvell/phy-mmp3-hsic.c
@@ -14,15 +14,19 @@
#define HSIC_ENABLE BIT(7)
#define PLL_BYPASS BIT(4)
+struct mmp3_hsic_data {
+ void __iomem *base;
+};
+
static int mmp3_hsic_phy_init(struct phy *phy)
{
- void __iomem *base = (void __iomem *)phy_get_drvdata(phy);
+ struct mmp3_hsic_data *mmp3 = phy_get_drvdata(phy);
u32 hsic_ctrl;
- hsic_ctrl = readl_relaxed(base + HSIC_CTRL);
+ hsic_ctrl = readl_relaxed(mmp3->base + HSIC_CTRL);
hsic_ctrl |= HSIC_ENABLE;
hsic_ctrl |= PLL_BYPASS;
- writel_relaxed(hsic_ctrl, base + HSIC_CTRL);
+ writel_relaxed(hsic_ctrl, mmp3->base + HSIC_CTRL);
return 0;
}
@@ -41,13 +45,17 @@ MODULE_DEVICE_TABLE(of, mmp3_hsic_phy_of_match);
static int mmp3_hsic_phy_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ struct mmp3_hsic_data *mmp3;
struct phy_provider *provider;
- void __iomem *base;
struct phy *phy;
- base = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
- if (IS_ERR(base))
- return PTR_ERR(base);
+ mmp3 = devm_kzalloc(dev, sizeof(*mmp3), GFP_KERNEL);
+ if (!mmp3)
+ return -ENOMEM;
+
+ mmp3->base = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
+ if (IS_ERR(mmp3->base))
+ return PTR_ERR(mmp3->base);
phy = devm_phy_create(dev, NULL, &mmp3_hsic_phy_ops);
if (IS_ERR(phy)) {
@@ -55,7 +63,7 @@ static int mmp3_hsic_phy_probe(struct platform_device *pdev)
return PTR_ERR(phy);
}
- phy_set_drvdata(phy, (void *)base);
+ phy_set_drvdata(phy, mmp3);
provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
if (IS_ERR(provider)) {
dev_err(dev, "failed to register PHY provider\n");
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 1/3] phy: apple: atc: Make atcphy_dwc3_reset_ops variable static
From: Krzysztof Kozlowski @ 2026-02-16 11:04 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Vinod Koul, Neil Armstrong,
Philipp Zabel, asahi, linux-arm-kernel, linux-phy, linux-kernel,
linux-arm-msm
Cc: Krzysztof Kozlowski
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,
};
--
2.51.0
--
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/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Johan Hovold @ 2026-02-16 10:47 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Loic Poulain, vkoul, kishon, linux-arm-msm, linux-phy,
dmitry.baryshkov, neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <20260213201550.vk5cosmoewokarlx@skbuf>
On Fri, Feb 13, 2026 at 10:15:50PM +0200, Vladimir Oltean wrote:
> 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)?
No, the device can still suspend before phy_init() is called.
What would work, and which should probably be preferred over adding
these phy_initialized flags, is to increment the pm usage counter before
enabling runtime pm and decrementing it after the PHY has been created.
Johan
--
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: Johan Hovold @ 2026-02-16 10:41 UTC (permalink / raw)
To: Loic Poulain
Cc: 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>
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:
> > 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'.
Thanks for tracking that down. That's an unexpected side effect of
fw_devlink adding runtime pm enabled links (which is the default
behaviour since late 2023).
Johan
--
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: Geert Uytterhoeven @ 2026-02-16 10:01 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Josua Mayer, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
Neil Armstrong, Peter Rosin, Aaro Koskinen, Andreas Kemnade,
Kevin Hilman, Roger Quadros, Tony Lindgren, Janusz Krzysztofik,
Vignesh R, Andi Shyti, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang, 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: <20260216092914.kmvl7aep7dantcsd@skbuf>
Hi Vladimir,
On Mon, 16 Feb 2026 at 10:29, Vladimir Oltean <olteanv@gmail.com> wrote:
> Then there is the fact that local definitions of devm_mux_state_get_optional()
> keep popping up, possibly in unrelated trees (not the case here). This seems
> to be a bad practice which should be discouraged during review if caught.
This was done on purpose, to (1) avoid having to make too many changes
to the file when a common helper would be introduced later, and (2) make
it easy to find all locations where a future common helper could be used.
The alternative is to use a completely different name (which is thus harder
to find), and having to fix up all the users of that name too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/6] arm64: dts: qcom: milos: Add UFS nodes
From: Abel Vesa @ 2026-02-16 10:05 UTC (permalink / raw)
To: Dmitry Baryshkov
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: <lvaxthcmqvjit4hnofqikxog3vi557elctiqc3nj3ere7rs47v@xcnwzrzc6koy>
On 26-02-13 23:06:51, Dmitry Baryshkov wrote:
> 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.
>
Sorry, my bad. Yes. There you go:
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Vladimir Oltean @ 2026-02-16 9:29 UTC (permalink / raw)
To: Josua Mayer
Cc: Geert Uytterhoeven, 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: <f9ede0d3-6a37-449c-b62b-a5c761ece097@solid-run.com>
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.
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).
These are the tools we have, we need to find a way to make them work somehow.
Then there is the fact that local definitions of devm_mux_state_get_optional()
keep popping up, possibly in unrelated trees (not the case here). This seems
to be a bad practice which should be discouraged during review if caught.
Otherwise, some 'retries' will be required from the developer until all
occurrences are removed.
Note that the upcoming linux-phy automated build testing does have an
x86_64 allmodconfig test too.
--
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: Andy Shevchenko @ 2026-02-16 9:11 UTC (permalink / raw)
To: Vladimir Oltean; +Cc: Haotian Zhang, vkoul, kishon, linux-phy, linux-kernel
In-Reply-To: <aZLe4-w0Jb50O63N@smile.fi.intel.com>
On Mon, Feb 16, 2026 at 11:09:59AM +0200, Andy Shevchenko wrote:
> On Mon, Feb 16, 2026 at 10:43:48AM +0200, Vladimir Oltean wrote:
> > On Wed, Nov 12, 2025 at 02:22:46PM +0800, Haotian Zhang wrote:
...
> > 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)
>
> Note, there is a pci_* wrapper for that.
Now I re-read this and found confusing comment, please, disregard this.
> > after it is no longer needed.
>
> Is it only a local variable? If so, it's probably okay to put it, but that
> action needs more investigations of the how the pcie_dev is being used.
> Also, it might be (but I don't think it is) a (double) put_device() call
> somewhere else. TL;DR: the summary of this investigation should be present
> in the commit message.
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: hisilicon: Fix OF node reference leak
From: Andy Shevchenko @ 2026-02-16 9:09 UTC (permalink / raw)
To: Vladimir Oltean; +Cc: Haotian Zhang, vkoul, kishon, linux-phy, linux-kernel
In-Reply-To: <20260216084348.e2ozdqy5unvfs7qe@skbuf>
On Mon, Feb 16, 2026 at 10:43:48AM +0200, Vladimir Oltean wrote:
> On Wed, Nov 12, 2025 at 02:22:46PM +0800, Haotian Zhang wrote:
...
> 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)
Note, there is a pci_* wrapper for that.
> after it is no longer needed.
Is it only a local variable? If so, it's probably okay to put it, but that
action needs more investigations of the how the pcie_dev is being used.
Also, it might be (but I don't think it is) a (double) put_device() call
somewhere else. TL;DR: the summary of this investigation should be present
in the commit message.
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 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
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