* Re: [PATCH v7 21/23] scsi: ufs: mediatek: Remove ret local from link_startup_notify
From: Peter Wang (王信友) @ 2026-02-25 10:36 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-21-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> Remove the "ret" local variable from ufs_mtk_link_startup_notify, as
> it's pointless; in all cases it is assigned, it is returned right
> after
> without being read first.
>
> Rework the code to just return directly, and get rid of the default
> branch while at it.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 20/23] scsi: ufs: mediatek: Back up idle timer in per-instance struct
From: Peter Wang (王信友) @ 2026-02-25 10:35 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-20-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> @@ -187,6 +187,7 @@ struct ufs_mtk_host {
> u16 ref_clk_gating_wait_us;
> u32 ip_ver;
> bool legacy_ip_ver;
> + u32 hibernate_idle_timer;
The name hibernate_idle_timer is somewhat confusing in
terms of its intended use. I would suggest using
backup_ahit or saved_ahit instead.
Thanks
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 19/23] scsi: ufs: mediatek: Rework hardware version reading
From: Peter Wang (王信友) @ 2026-02-25 10:34 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-19-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> Split assignment to the host struct out from the read function, and
> utilise bitfield helpers to simplify the code. Also move the debug
> print
> out of the legacy version helper, which means it no longer has to
> take a
> struct ufs_hba as an input, and can be rewritten as a pure function.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 18/23] scsi: ufs: mediatek: Don't acquire dvfsrc-vcore twice
From: Peter Wang (王信友) @ 2026-02-25 10:34 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-18-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> @@ -519,15 +519,13 @@ static void ufs_mtk_boost_crypt(struct ufs_hba
> *hba, bool boost)
> {
> struct ufs_mtk_host *host = ufshcd_get_variant(hba);
> struct ufs_mtk_crypt_cfg *cfg;
> - struct regulator *reg;
> int volt, ret;
>
> - if (!ufs_mtk_is_boost_crypt_enabled(hba))
> + if (!ufs_mtk_is_boost_crypt_enabled(hba) || !host-
> >reg_vcore)
> return;
If host->reg_vcore is NULL,
should ufs_mtk_is_boost_crypt_enabled be false?
So we don’t need to check both, right?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 17/23] scsi: ufs: mediatek: Rework ufs_mtk_wait_idle_state
From: Peter Wang (王信友) @ 2026-02-25 10:32 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-17-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> While ufs_mtk_wait_idle state has some code smells for me (the
> VS_HCE_BASE early exit seems racey at best), it can still benefit
> from
> some general cleanup to make the code flow less convoluted.
>
> Use the iopoll helpers, for one, and specifically the one that sleeps
> and does not busy delay, as it's being done for up to 5ms.
>
> The register read is split out to a helper function that branches
> between new and old style flow.
>
> Every called uses the same 5ms timeout value, so there is no point in
> making this a parameter. Just assume a 5ms timeout in the function.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Hi Nicolas,
The logic is quite different.
Previously, the check was:
If (sm >= VS_HIB_ENTER) and (sm <= VS_HIB_EXIT), then wait for sm to
reach VS_HCE_BASE.
If not ((val < VS_HIB_ENTER) and (val > VS_HIB_EXIT)), then exit the
loop directly.
Now, the logic is:
If sm == VS_HCE_BASE, return 0.
If (sm >= VS_HIB_ENTER) and (sm <= VS_HIB_EXIT), then wait for sm to
transition to any other state and exit the poll.
Thanks
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 0/9] net: stmmac: qcom-ethqos: further serdes reorganisation
From: Russell King (Oracle) @ 2026-02-25 9:02 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <aZ66OT9scKipRRu2@shell.armlinux.org.uk>
Note: only 8 patches in this series, not 9 as the subject line says,
as the set_clk_tx_rate() patch became part of the first series.
On Wed, Feb 25, 2026 at 09:00:41AM +0000, Russell King (Oracle) wrote:
> This is part 2 of the qcom-ethqos series, part 1 has now been merged.
>
> This part of the series focuses on the generic PHY driver, but these
> changes have dependencies on the ethernet driver, hence why
> it will need to go via net-next. Furthermore, subsequent changes
> depend on these patches.
>
> The underlying ideas here are:
>
> - get rid of the driver using phy_set_speed() with SPEED_1000 and
> SPEED_2500 which makes no sense for an ethernet SerDes due to the
> PCS 8B10B data encoding, which inflates the data rate at the SerDes
> compared to the MAC. This is replaced with phy_set_mode_ext().
> - allow phy_power_on() / phy_set_mode*() to be called in any order.
>
> Mohd has tested this series, but it would be great to get acks/reviews
> from the generic PHY maintainers.
>
> .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 31 +++--------
> drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 62 +++++++++++++++++-----
> 2 files changed, 57 insertions(+), 36 deletions(-)
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH net-next 7/8] phy: qcom-sgmii-eth: relax order of .power_on() vs .set_mode*()
From: Russell King (Oracle) @ 2026-02-25 9:02 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-arm-msm, linux-phy, Mohd Ayaan Anwar, Neil Armstrong,
Vinod Koul
In-Reply-To: <aZ66OT9scKipRRu2@shell.armlinux.org.uk>
Allow any order of the .power_on() and .set_mode*() methods as per the
recent discussion. This means phy_power_on() with this SerDes will now
restore the previous setup without requiring a subsequent
phy_set_mode*() call.
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
index 6332ff291fdf..f48faa2929a6 100644
--- a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
+++ b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
@@ -271,8 +271,17 @@ static int qcom_dwmac_sgmii_phy_calibrate(struct phy *phy)
static int qcom_dwmac_sgmii_phy_power_on(struct phy *phy)
{
struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
+ int ret;
+
+ ret = clk_prepare_enable(data->refclk);
+ if (ret < 0)
+ return ret;
- return clk_prepare_enable(data->refclk);
+ ret = qcom_dwmac_sgmii_phy_calibrate(phy);
+ if (ret < 0)
+ clk_disable_unprepare(data->refclk);
+
+ return ret;
}
static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)
@@ -318,6 +327,9 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
if (submode != data->interface)
data->interface = submode;
+ if (phy->power_count == 0)
+ return 0;
+
return qcom_dwmac_sgmii_phy_calibrate(phy);
}
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next 6/8] phy: qcom-sgmii-eth: remove qcom_dwmac_sgmii_phy_interface()
From: Russell King (Oracle) @ 2026-02-25 9:02 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-arm-msm, linux-phy, Mohd Ayaan Anwar, Neil Armstrong,
Vinod Koul
In-Reply-To: <aZ66OT9scKipRRu2@shell.armlinux.org.uk>
Now that qcom_dwmac_sgmii_phy_interface() only serves to validate the
passed interface mode, combine it with qcom_dwmac_sgmii_phy_validate(),
and use qcom_dwmac_sgmii_phy_validate() to validate the mode in
qcom_dwmac_sgmii_phy_set_mode().
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 27 +++++++++--------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
index 58ff15601206..6332ff291fdf 100644
--- a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
+++ b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
@@ -290,7 +290,9 @@ static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)
return 0;
}
-static int qcom_dwmac_sgmii_phy_interface(enum phy_mode mode, int submode)
+static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
+ int submode,
+ union phy_configure_opts *opts)
{
if (mode != PHY_MODE_ETHERNET)
return -EINVAL;
@@ -298,7 +300,7 @@ static int qcom_dwmac_sgmii_phy_interface(enum phy_mode mode, int submode)
if (submode == PHY_INTERFACE_MODE_SGMII ||
submode == PHY_INTERFACE_MODE_1000BASEX ||
submode == PHY_INTERFACE_MODE_2500BASEX)
- return submode;
+ return 0;
return -EINVAL;
}
@@ -307,27 +309,18 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
int submode)
{
struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
- int interface;
+ int ret;
- interface = qcom_dwmac_sgmii_phy_interface(mode, submode);
- if (interface < 0)
- return interface;
+ ret = qcom_dwmac_sgmii_phy_validate(phy, mode, submode, NULL);
+ if (ret)
+ return ret;
- if (interface != data->interface)
- data->interface = interface;
+ if (submode != data->interface)
+ data->interface = submode;
return qcom_dwmac_sgmii_phy_calibrate(phy);
}
-static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
- int submode,
- union phy_configure_opts *opts)
-{
- int ret = qcom_dwmac_sgmii_phy_interface(mode, submode);
-
- return ret < 0 ? ret : 0;
-}
-
static const struct phy_ops qcom_dwmac_sgmii_phy_ops = {
.power_on = qcom_dwmac_sgmii_phy_power_on,
.power_off = qcom_dwmac_sgmii_phy_power_off,
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next 5/8] phy: qcom-sgmii-eth: use PHY interface mode for SerDes settings
From: Russell King (Oracle) @ 2026-02-25 9:02 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-arm-msm, linux-phy, Mohd Ayaan Anwar, Neil Armstrong,
Vinod Koul
In-Reply-To: <aZ66OT9scKipRRu2@shell.armlinux.org.uk>
As established in the previous commit, using SPEED_1000 and SPEED_2500
does not make sense for a SerDes due to the PCS encoding that is used
over the SerDes link, which inflates the data rate at the SerDes. Thus,
the use of these constants in a SerDes driver is incorrect.
Since qcom-sgmii-eth no longer implements phy_set_speed(), but instead
uses the PHY interface mode passed via the .set_mode() method, convert
the driver to use the PHY interface mode internally to decide whether
to configure the SerDes for 1.25Gbps or 3.125Gbps mode.
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 41 ++++++++++++-----------
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
index dcfdb7d0e8ea..58ff15601206 100644
--- a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
+++ b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
@@ -29,7 +29,7 @@
struct qcom_dwmac_sgmii_phy_data {
struct regmap *regmap;
struct clk *refclk;
- int speed;
+ phy_interface_t interface;
};
static void qcom_dwmac_sgmii_phy_init_1g(struct regmap *regmap)
@@ -223,15 +223,18 @@ static int qcom_dwmac_sgmii_phy_calibrate(struct phy *phy)
struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
struct device *dev = phy->dev.parent;
- switch (data->speed) {
- case SPEED_10:
- case SPEED_100:
- case SPEED_1000:
+ switch (data->interface) {
+ case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
+ /* 1.25Gbps mode */
qcom_dwmac_sgmii_phy_init_1g(data->regmap);
break;
- case SPEED_2500:
+ case PHY_INTERFACE_MODE_2500BASEX:
+ /* 3.125Gbps mode */
qcom_dwmac_sgmii_phy_init_2p5g(data->regmap);
break;
+ default:
+ return -EINVAL;
}
if (qcom_dwmac_sgmii_phy_poll_status(data->regmap,
@@ -287,17 +290,15 @@ static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)
return 0;
}
-static int qcom_dwmac_sgmii_phy_speed(enum phy_mode mode, int submode)
+static int qcom_dwmac_sgmii_phy_interface(enum phy_mode mode, int submode)
{
if (mode != PHY_MODE_ETHERNET)
return -EINVAL;
if (submode == PHY_INTERFACE_MODE_SGMII ||
- submode == PHY_INTERFACE_MODE_1000BASEX)
- return SPEED_1000;
-
- if (submode == PHY_INTERFACE_MODE_2500BASEX)
- return SPEED_2500;
+ submode == PHY_INTERFACE_MODE_1000BASEX ||
+ submode == PHY_INTERFACE_MODE_2500BASEX)
+ return submode;
return -EINVAL;
}
@@ -306,14 +307,14 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
int submode)
{
struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
- int speed;
+ int interface;
- speed = qcom_dwmac_sgmii_phy_speed(mode, submode);
- if (speed < 0)
- return speed;
+ interface = qcom_dwmac_sgmii_phy_interface(mode, submode);
+ if (interface < 0)
+ return interface;
- if (speed != data->speed)
- data->speed = speed;
+ if (interface != data->interface)
+ data->interface = interface;
return qcom_dwmac_sgmii_phy_calibrate(phy);
}
@@ -322,7 +323,7 @@ static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
int submode,
union phy_configure_opts *opts)
{
- int ret = qcom_dwmac_sgmii_phy_speed(mode, submode);
+ int ret = qcom_dwmac_sgmii_phy_interface(mode, submode);
return ret < 0 ? ret : 0;
}
@@ -356,7 +357,7 @@ static int qcom_dwmac_sgmii_phy_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
- data->speed = SPEED_10;
+ data->interface = PHY_INTERFACE_MODE_SGMII;
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next 4/8] phy: qcom-sgmii-eth: remove .set_speed() implementation
From: Russell King (Oracle) @ 2026-02-25 9:02 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-arm-msm, linux-phy, Mohd Ayaan Anwar, Neil Armstrong,
Vinod Koul
In-Reply-To: <aZ66OT9scKipRRu2@shell.armlinux.org.uk>
Now that the qcom-ethqos driver has migrated to use phy_set_mode_ext()
rather than phy_set_speed() to configure the SerDes, the support for
phy_set_speed() is now obsolete. Remove support for this method.
Using the MAC speed for the SerDes is never correct due to the PCS
encoding. For SGMII and 2500BASE-X, the PCS uses 8B10B encoding, and
so:
MAC rate * PCS output bits / PCS input bits = SerDes rate
1000M * 10 / 8 = 1250M
2500M * 10 / 8 = 3125M
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
index 4ea3dce7719f..dcfdb7d0e8ea 100644
--- a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
+++ b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
@@ -318,16 +318,6 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
return qcom_dwmac_sgmii_phy_calibrate(phy);
}
-static int qcom_dwmac_sgmii_phy_set_speed(struct phy *phy, int speed)
-{
- struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
-
- if (speed != data->speed)
- data->speed = speed;
-
- return qcom_dwmac_sgmii_phy_calibrate(phy);
-}
-
static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
int submode,
union phy_configure_opts *opts)
@@ -341,7 +331,6 @@ static const struct phy_ops qcom_dwmac_sgmii_phy_ops = {
.power_on = qcom_dwmac_sgmii_phy_power_on,
.power_off = qcom_dwmac_sgmii_phy_power_off,
.set_mode = qcom_dwmac_sgmii_phy_set_mode,
- .set_speed = qcom_dwmac_sgmii_phy_set_speed,
.validate = qcom_dwmac_sgmii_phy_validate,
.calibrate = qcom_dwmac_sgmii_phy_calibrate,
.owner = THIS_MODULE,
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next 2/8] phy: qcom-sgmii-eth: add .set_mode() and .validate() methods
From: Russell King (Oracle) @ 2026-02-25 9:02 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-arm-msm, linux-phy, Mohd Ayaan Anwar, Neil Armstrong,
Vinod Koul
In-Reply-To: <aZ66OT9scKipRRu2@shell.armlinux.org.uk>
qcom-sgmii-eth is an Ethernet SerDes supporting only Ethernet mode
using SGMII, 1000BASE-X and 2500BASE-X.
Add an implementation of the .set_mode() method, which can be used
instead of or as well as the .set_speed() method. The Ethernet
interface modes mentioned above all have a fixed data rate, so
setting the mode is sufficient to fully specify the operating
parameters.
Add an implementation of the .validate() method, which will be
necessary to allow discovery of the SerDes capabilities for platform
independent SerDes support in the stmmac network driver.
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 43 +++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
index 5b1c82459c12..4ea3dce7719f 100644
--- a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
+++ b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
@@ -7,6 +7,7 @@
#include <linux/ethtool.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/phy.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
@@ -286,6 +287,37 @@ static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)
return 0;
}
+static int qcom_dwmac_sgmii_phy_speed(enum phy_mode mode, int submode)
+{
+ if (mode != PHY_MODE_ETHERNET)
+ return -EINVAL;
+
+ if (submode == PHY_INTERFACE_MODE_SGMII ||
+ submode == PHY_INTERFACE_MODE_1000BASEX)
+ return SPEED_1000;
+
+ if (submode == PHY_INTERFACE_MODE_2500BASEX)
+ return SPEED_2500;
+
+ return -EINVAL;
+}
+
+static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
+ int submode)
+{
+ struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
+ int speed;
+
+ speed = qcom_dwmac_sgmii_phy_speed(mode, submode);
+ if (speed < 0)
+ return speed;
+
+ if (speed != data->speed)
+ data->speed = speed;
+
+ return qcom_dwmac_sgmii_phy_calibrate(phy);
+}
+
static int qcom_dwmac_sgmii_phy_set_speed(struct phy *phy, int speed)
{
struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
@@ -296,10 +328,21 @@ static int qcom_dwmac_sgmii_phy_set_speed(struct phy *phy, int speed)
return qcom_dwmac_sgmii_phy_calibrate(phy);
}
+static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
+ int submode,
+ union phy_configure_opts *opts)
+{
+ int ret = qcom_dwmac_sgmii_phy_speed(mode, submode);
+
+ return ret < 0 ? ret : 0;
+}
+
static const struct phy_ops qcom_dwmac_sgmii_phy_ops = {
.power_on = qcom_dwmac_sgmii_phy_power_on,
.power_off = qcom_dwmac_sgmii_phy_power_off,
+ .set_mode = qcom_dwmac_sgmii_phy_set_mode,
.set_speed = qcom_dwmac_sgmii_phy_set_speed,
+ .validate = qcom_dwmac_sgmii_phy_validate,
.calibrate = qcom_dwmac_sgmii_phy_calibrate,
.owner = THIS_MODULE,
};
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next 0/9] net: stmmac: qcom-ethqos: further serdes reorganisation
From: Russell King (Oracle) @ 2026-02-25 9:00 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
This is part 2 of the qcom-ethqos series, part 1 has now been merged.
This part of the series focuses on the generic PHY driver, but these
changes have dependencies on the ethernet driver, hence why
it will need to go via net-next. Furthermore, subsequent changes
depend on these patches.
The underlying ideas here are:
- get rid of the driver using phy_set_speed() with SPEED_1000 and
SPEED_2500 which makes no sense for an ethernet SerDes due to the
PCS 8B10B data encoding, which inflates the data rate at the SerDes
compared to the MAC. This is replaced with phy_set_mode_ext().
- allow phy_power_on() / phy_set_mode*() to be called in any order.
Mohd has tested this series, but it would be great to get acks/reviews
from the generic PHY maintainers.
.../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 31 +++--------
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 62 +++++++++++++++++-----
2 files changed, 57 insertions(+), 36 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH V5 0/3] Add UFS support for x1e80100 SoC
From: Krzysztof Kozlowski @ 2026-02-25 8:58 UTC (permalink / raw)
To: Martin K. Petersen, Pradeep P V K
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, andersson,
konradybcio, taniya.das, dmitry.baryshkov, manivannan.sadhasivam,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
nitin.rawat
In-Reply-To: <yq1seaq6ifd.fsf@ca-mkp.ca.oracle.com>
On 24/02/2026 20:40, Martin K. Petersen wrote:
>
> Pradeep,
>
>> Add UFSPHY, UFSHC compatible binding names and UFS devicetree
>> enablement changes for Qualcomm x1e80100 SoC.
>
> Applied to 7.1/scsi-staging. Please validate conflict resolution in
> qcom,sc7180-ufshc.yaml, thanks!
NAK
You CANNOT take DTS patches. This is different subsysytem - look at the
subject prefix.
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 2/6] scsi: ufs: qcom,sc7180-ufshc: dt-bindings: Document the Milos UFS Controller
From: Krzysztof Kozlowski @ 2026-02-25 8:39 UTC (permalink / raw)
To: Luca Weiss, Martin K. Petersen
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Alim Akhtar, Avri Altman,
Bart Van Assche, Vinod Koul, Neil Armstrong, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Krzysztof Kozlowski
In-Reply-To: <DGNVDXQTH812.3MCVKWNCKR8B6@fairphone.com>
On 25/02/2026 08:38, Luca Weiss wrote:
> On Tue Feb 24, 2026 at 8:19 PM CET, Martin K. Petersen wrote:
>>
>> Luca,
>>
>>> I've added you to this email now since you seem to pick up most patches
>>> for these files. Could you take this one please to unblock Milos UFS
>>> dts?
>>
>> Applied #2, #5, and #6 to 7.1/scsi-staging, thanks!
>
> Hi Martin,
>
> Thanks for picking up the bindings!
>
> I'm surprised you picked up the dts as well (and modified the subject
> line), these patches should go via Bjorn's qcom tree.
>
> * scsi: qcom: milos: arm64: dts: Add UFS nodes
> * scsi: qcom: milos-fairphone-fp6: arm64: dts: Enable UFS
>
> I also see these in your staging branch as well:
>
> * scsi: qcom: hamoa: arm64: dts: Add UFS nodes for x1e80100 SoC
> * scsi: qcom: hamoa-iot-evk: arm64: dts: Enable UFS
Uh, what? First, renaming prefix is not correct for arm64 DTS patches,
but nevertheless these MUST NOT be merged into SCSI/UFS.
Never.
I will mark SCSI/UFS subsystem as one needing explicit patchset split.
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 v3 5/6] drm/mediatek: dsi: Add compatible for mt8167-dsi
From: Luca Leonardo Scorcia @ 2026-02-25 8:15 UTC (permalink / raw)
To: CK Hu (胡俊光)
Cc: linux-mediatek@lists.infradead.org, robh@kernel.org,
Chunfeng Yun (云春峰), tzimmermann@suse.de,
simona@ffwll.ch, mripard@kernel.org, AngeloGioacchino Del Regno,
linux-kernel@vger.kernel.org, maarten.lankhorst@linux.intel.com,
dri-devel@lists.freedesktop.org, chunkuang.hu@kernel.org,
vkoul@kernel.org, krzk+dt@kernel.org,
linux-phy@lists.infradead.org, p.zabel@pengutronix.de,
conor+dt@kernel.org, airlied@gmail.com,
linux-arm-kernel@lists.infradead.org, matthias.bgg@gmail.com,
neil.armstrong@linaro.org, devicetree@vger.kernel.org
In-Reply-To: <bc064717108de5ea1a8c98937bb03fd00794682c.camel@mediatek.com>
> > The mt8167 DSI controller is fully compatible with the one found in
> > mt2701. Device tree documentation is already present upstream.
>
> If mt8167 DSI is fully compatible with mt2701 DSI, I think the binding document and device tree should be modified.
> In device tree,
>
> compatible = "mediatek,mt8167-dsi", "mediatek,mt2701-dsi";
>
> And this patch is not necessary.
Hi, if I understand your review correctly that's what v2 [1] of this
patch did, but the change was rejected during review.
As far as I can see there is no win-win solution here. This tricky
situation derives from the fact that in last year's submissions the
change was only partially merged - the bindings went upstream while
the driver did not, and now we have to work around this. In v3 I tried
to address the issue by actually implementing what the binding
document says.
I'll be happy to resubmit v4 but I need to know what's the consensus here.
Thanks!
[1] https://patchwork.kernel.org/project/linux-mediatek/patch/ff920a7cc94f2b0c03d4bb55142030fded30d07c.1771258407.git.l.scorcia@gmail.com/
> >
> > Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index af4871de9e4c..ad10e86b161d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -1301,6 +1301,7 @@ static const struct mtk_dsi_driver_data mt8188_dsi_driver_data = {
> >
> > static const struct of_device_id mtk_dsi_of_match[] = {
> > { .compatible = "mediatek,mt2701-dsi", .data = &mt2701_dsi_driver_data },
> > + { .compatible = "mediatek,mt8167-dsi", .data = &mt2701_dsi_driver_data },
> > { .compatible = "mediatek,mt8173-dsi", .data = &mt8173_dsi_driver_data },
> > { .compatible = "mediatek,mt8183-dsi", .data = &mt8183_dsi_driver_data },
> > { .compatible = "mediatek,mt8186-dsi", .data = &mt8186_dsi_driver_data },
> > --
> > 2.43.0
> >
> >
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/3] phy: qcom: edp: Add eDP phy mode switch support
From: Yongxing Mou @ 2026-02-25 8:00 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <f7fed0cc-0c59-4a75-b045-a83df924113d@oss.qualcomm.com>
On 2/13/2026 7:06 PM, Konrad Dybcio wrote:
> On 2/10/26 11:29 AM, Yongxing Mou wrote:
>>
>>
>> On 2/6/2026 7:02 PM, Konrad Dybcio wrote:
>>> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>>>> Add DP/eDP switch support by splitting the PHY swing/pre-emphasis tables
>>>> into separate DP and eDP configurations. This allows the driver to select
>>>> the correct table based on the is_edp flag.
>>>>
>>>> Add a dedicated table for the SC7280/glymur platforms, as they are not
>>>> compatible with the others.
>>>>
>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> +static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
>>>> + { 0x0b, 0x11, 0x16, 0x1b },
>>>> + { 0x0b, 0x19, 0x1f, 0xff },
>>>> + { 0x18, 0x1f, 0xff, 0xff },
>>>> + { 0x1f, 0xff, 0xff, 0xff }
>>>> +};
>>>> +
>>>> +static const u8 edp_pre_emp_hbr2_hbr3_v3[4][4] = {
>>>> + { 0x0c, 0x15, 0x19, 0x1e },
>>>> + { 0x09, 0x14, 0x19, 0xff },
>>>> + { 0x0f, 0x14, 0xff, 0xff },
>>>> + { 0x0d, 0xff, 0xff, 0xff }
>>>> +};
>>>
>>> This is not quite in line with docs for kodiak. Now, if you have
>>> better/newer sequences than the HPG, I'm not objecting, but please
>>> cross-check
>>>
>>> the rest of this patch I think looks fine
>>>
>>> Konrad
>> Thanks for point that..
>>>> +static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
>>>> + { 0x0b, 0x11, 0x16, 0x1b },
>> here should be { 0x06, 0x11, 0x16, 0x1b }, arr[0][1]: 0x0b->0x06
>> does this looks fine? will check tables again..
>
> For kodiak I see:
>
> eDP HBR23 / low vdiff:
>
> swing
> 0x0b, 0x11, 0x17, 0x1c
> 0x10, 0x19, 0x1f
> 0x19, 0x1f
> 0x1f
>
> preemp
> 0x0c, 0x15, 0x19, 0x1e
> 0x08, 0x15, 0x19
> 0x0e, 0x14
> 0x0d
>
> (notice how that mostly differs by the lowest bit being (not)set vs
> your proposal)
>
> eDP HBR23 / high vdiff:
>
> swing
> 0x0a, 0x11, 0x17, 0x1f
> 0x0c, 0x14, 0x1d
> 0x15, 0x1f
> 0x17
>
> preemp
>
> 0x08, 0x11, 0x17, 0x1b
> 0x00, 0x0c, 0x13
> 0x05, 0x10,
> 0x00
>
> Konrad
Hi, this is different from what I saw. what i saw
from kodiak HPG:
eDP low vdiff (High HBR):
0x06, 0x11, 0x16, 0x1B
0x0B, 0x19, 0x1f
0x18, 0x1f
0x1f
preemp
0x0c, 0x15, 0x19, 0x1e
0x09, 0x14, 0x19
0x0f, 0x14
0x0d
eDP high vdiff (High HBR):
swing
0x0a, 0x11, 0x17, 0x1f
0x0c, 0x14, 0x1d
0x15, 0x1f
0x17
preemp
0x08, 0x11, 0x16, 0x1b
0x00, 0x0c, 0x13
0x05, 0x10,
0x00
The set of values you provided looks more like data from LeMans /
SC8280xp / glymur (low vidff). I’ll follow up by email later to confirm
whether this is due to us using different HPGs.
thanks.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] scsi: ufs: qcom,sc7180-ufshc: dt-bindings: Document the Milos UFS Controller
From: Luca Weiss @ 2026-02-25 7:38 UTC (permalink / raw)
To: Martin K. Petersen, Luca Weiss
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Alim Akhtar, Avri Altman,
Bart Van Assche, Vinod Koul, Neil Armstrong, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Krzysztof Kozlowski
In-Reply-To: <yq14in67xwd.fsf@ca-mkp.ca.oracle.com>
On Tue Feb 24, 2026 at 8:19 PM CET, Martin K. Petersen wrote:
>
> Luca,
>
>> I've added you to this email now since you seem to pick up most patches
>> for these files. Could you take this one please to unblock Milos UFS
>> dts?
>
> Applied #2, #5, and #6 to 7.1/scsi-staging, thanks!
Hi Martin,
Thanks for picking up the bindings!
I'm surprised you picked up the dts as well (and modified the subject
line), these patches should go via Bjorn's qcom tree.
* scsi: qcom: milos: arm64: dts: Add UFS nodes
* scsi: qcom: milos-fairphone-fp6: arm64: dts: Enable UFS
I also see these in your staging branch as well:
* scsi: qcom: hamoa: arm64: dts: Add UFS nodes for x1e80100 SoC
* scsi: qcom: hamoa-iot-evk: arm64: dts: Enable UFS
Regards
Luca
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/3] phy: qcom: edp: Add per-version LDO configuration callback
From: Yongxing Mou @ 2026-02-25 7:21 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong, Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <ece590b8-9a29-49f2-934b-6082f093290d@oss.qualcomm.com>
On 2/13/2026 7:14 PM, Konrad Dybcio wrote:
> On 2/12/26 10:04 AM, Yongxing Mou wrote:
>>
>>
>> On 2/6/2026 6:52 PM, Konrad Dybcio wrote:
>>> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>>>> Introduce the com_ldo_config callback to support per‑PHY LDO
>>>> configuration.
>>>>
>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> +static int qcom_edp_ldo_config_v4(const struct qcom_edp *edp)
>>>> +{
>>>> + const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
>>>> + u32 ldo_config;
>>>> +
>>>> + if (!edp->is_edp)
>>>> + ldo_config = 0x0;
>>>> + else if (dp_opts->link_rate <= 2700)
>>>> + ldo_config = 0xC1;
>>>
>>> lowercase hex, please
>>>
>>>> + else
>>>> + ldo_config = 0x81;
>>>> +
>>>> + writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
>>>> + writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
>>>
>>> tx1 should be dp_ops->lanes ? 2 : ldo_config : 0x00, in all cases,
>>> I believe
>>>
>>> Konrad
>> Hi, here i want to confirm again.. In the HPG main link brinup sequence, it not say write TX0/TX1 ldo_config based on the lane count. Only when we switch the lane mode, the LDO config will be updated according to the lane count. so here do we really need this condition?
>
> I don't believe these two cases are differentiated in your patch, unless
> you're trying to say that the hardware is smart enough to turn off the LDO
> for TX23 on its own as we switch modes, which I wouldn't bet it is and can't
> find confirmation for
>
> Konrad
Got it. will update next patch.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 10/23] scsi: ufs: mediatek: Handle misc host voltage regulators
From: Peter Wang (王信友) @ 2026-02-25 7:20 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260216-mt8196-ufs-v7-10-b5f2907c6da7@collabora.com>
On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> MediaTek SoCs handled by this driver contain a per-SoC specific set
> of
> miscellaneous supplies. These feed parts of the UFS controller
> silicon
> inside the SoC, as opposed to the UFS card.
>
> Add the necessary driver code to acquire these supplies using the
> regulator bulk API. They should be kept on during suspend, so enable
> them when acquiring.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 10/23] scsi: ufs: mediatek: Handle misc host voltage regulators
From: Peter Wang (王信友) @ 2026-02-25 7:19 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno,
Chaotian Jing (井朝天), conor+dt@kernel.org,
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, avri.altman@wdc.com, broonie@kernel.org,
martin.petersen@oracle.com
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <24445e6d-c308-4df2-8b3e-7ee8a8e3f2fe@collabora.com>
On Tue, 2026-02-24 at 13:41 +0100, AngeloGioacchino Del Regno wrote
>
>
> Because:
> 1. The UFS driver has to acquire the correct supplies regardless of
> them
> being on, guaranteeing both a readable power tree
> (sysfs/debugfs) and
> a correct hardware description in devicetree.
> 2. A future update might get those regulators disabled during deep
> sleep
>
> Regards,
> Angelo
>
Hi Nicolas,
Okay, providing correct supplies and hardware descriptions is welcome,
but I am afraid these regulators cannot be disabled even when entering
deep sleep.
Thanks
Peter
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 10/23] scsi: ufs: mediatek: Handle misc host voltage regulators
From: Peter Wang (王信友) @ 2026-02-25 7:18 UTC (permalink / raw)
To: broonie@kernel.org
Cc: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@hansenpartnership.com, kernel@collabora.com,
bvanassche@acm.org, AngeloGioacchino Del Regno,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
Chaotian Jing (井朝天), conor+dt@kernel.org,
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, linux-mediatek@lists.infradead.org,
krzk+dt@kernel.org, linux-phy@lists.infradead.org,
Louis-Alexis Eyraud, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, avri.altman@wdc.com,
martin.petersen@oracle.com
In-Reply-To: <3f4920b2-4697-4897-bdca-65c9f02909d8@sirena.org.uk>
On Tue, 2026-02-24 at 12:48 +0000, Mark Brown wrote:
> Drivers should request and enable any regulators they require, they
> should not rely on boards happening to enable a supply for them.
> Similarly the board should only impose constraints that come from the
> system design, it should not assume that drivers will continue to
> behave
> as they do.
Hi Mark,
Thank you for your detailed explanation.
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 6/6] gpu: drm: mediatek: ovl: add specific entry for mt8167
From: CK Hu (胡俊光) @ 2026-02-25 2:52 UTC (permalink / raw)
To: linux-mediatek@lists.infradead.org, l.scorcia@gmail.com
Cc: robh@kernel.org, Chunfeng Yun (云春峰),
simona@ffwll.ch, tzimmermann@suse.de, mripard@kernel.org,
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
maarten.lankhorst@linux.intel.com, conor+dt@kernel.org,
chunkuang.hu@kernel.org, vkoul@kernel.org, krzk+dt@kernel.org,
linux-phy@lists.infradead.org, p.zabel@pengutronix.de,
dri-devel@lists.freedesktop.org, airlied@gmail.com,
val@packett.cool, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <5f880f1334aa93184afee3e36132ca42628821fb.1771863641.git.l.scorcia@gmail.com>
title:
drm/mediatek: ovl: add specific entry for mt8167
After this modification,
Reviewed-by: CK Hu <ck.hu@mediatek.com>
On Mon, 2026-02-23 at 16:22 +0000, Luca Leonardo Scorcia wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>
>
> From: Val Packett <val@packett.cool>
>
> While this configuration is otherwise identical to mt8173, according
> to Android kernel sources, this SoC does need smi_id_en.
>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index e0236353d499..97a899e4bd99 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -671,6 +671,16 @@ static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> .num_formats = ARRAY_SIZE(mt8173_formats),
> };
>
> +static const struct mtk_disp_ovl_data mt8167_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 8,
> + .layer_nr = 4,
> + .fmt_rgb565_is_0 = true,
> + .smi_id_en = true,
> + .formats = mt8173_formats,
> + .num_formats = ARRAY_SIZE(mt8173_formats),
> +};
> +
> static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
> .addr = DISP_REG_OVL_ADDR_MT8173,
> .gmc_bits = 8,
> @@ -742,6 +752,8 @@ static const struct mtk_disp_ovl_data mt8195_ovl_driver_data = {
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-ovl",
> .data = &mt2701_ovl_driver_data},
> + { .compatible = "mediatek,mt8167-disp-ovl",
> + .data = &mt8167_ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = &mt8173_ovl_driver_data},
> { .compatible = "mediatek,mt8183-disp-ovl",
> --
> 2.43.0
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 5/6] drm/mediatek: dsi: Add compatible for mt8167-dsi
From: CK Hu (胡俊光) @ 2026-02-25 2:41 UTC (permalink / raw)
To: linux-mediatek@lists.infradead.org, l.scorcia@gmail.com
Cc: robh@kernel.org, Chunfeng Yun (云春峰),
tzimmermann@suse.de, simona@ffwll.ch, mripard@kernel.org,
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
maarten.lankhorst@linux.intel.com,
dri-devel@lists.freedesktop.org, chunkuang.hu@kernel.org,
vkoul@kernel.org, krzk+dt@kernel.org,
linux-phy@lists.infradead.org, p.zabel@pengutronix.de,
conor+dt@kernel.org, airlied@gmail.com,
linux-arm-kernel@lists.infradead.org, matthias.bgg@gmail.com,
neil.armstrong@linaro.org, devicetree@vger.kernel.org
In-Reply-To: <2fbf179c03c61f527e2583f9df4f97f6aaf3297a.1771863641.git.l.scorcia@gmail.com>
On Mon, 2026-02-23 at 16:22 +0000, Luca Leonardo Scorcia wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>
>
> The mt8167 DSI controller is fully compatible with the one found in
> mt2701. Device tree documentation is already present upstream.
If mt8167 DSI is fully compatible with mt2701 DSI, I think the binding document and device tree should be modified.
In device tree,
compatible = "mediatek,mt8167-dsi", "mediatek,mt2701-dsi";
And this patch is not necessary.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index af4871de9e4c..ad10e86b161d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1301,6 +1301,7 @@ static const struct mtk_dsi_driver_data mt8188_dsi_driver_data = {
>
> static const struct of_device_id mtk_dsi_of_match[] = {
> { .compatible = "mediatek,mt2701-dsi", .data = &mt2701_dsi_driver_data },
> + { .compatible = "mediatek,mt8167-dsi", .data = &mt2701_dsi_driver_data },
> { .compatible = "mediatek,mt8173-dsi", .data = &mt8173_dsi_driver_data },
> { .compatible = "mediatek,mt8183-dsi", .data = &mt8183_dsi_driver_data },
> { .compatible = "mediatek,mt8186-dsi", .data = &mt8186_dsi_driver_data },
> --
> 2.43.0
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 3/6] dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
From: CK Hu (胡俊光) @ 2026-02-25 2:27 UTC (permalink / raw)
To: linux-mediatek@lists.infradead.org, l.scorcia@gmail.com
Cc: robh@kernel.org, Chunfeng Yun (云春峰),
krzysztof.kozlowski@oss.qualcomm.com, simona@ffwll.ch,
tzimmermann@suse.de, mripard@kernel.org,
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
maarten.lankhorst@linux.intel.com, conor+dt@kernel.org,
chunkuang.hu@kernel.org, vkoul@kernel.org, krzk+dt@kernel.org,
linux-phy@lists.infradead.org, p.zabel@pengutronix.de,
dri-devel@lists.freedesktop.org, airlied@gmail.com,
linux-arm-kernel@lists.infradead.org, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, devicetree@vger.kernel.org
In-Reply-To: <92530e0a31eca1feb822f5c5fd4ac894937dd6c7.1771863641.git.l.scorcia@gmail.com>
On Mon, 2026-02-23 at 16:22 +0000, Luca Leonardo Scorcia wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>
>
> Add support for the MediaTek mt8167 SoC: the DSI PHY found
> in this chip is fully compatible with the one found in the mt2701 SoC.
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> index acdbce937b0a..c6d0bbdbe0e2 100644
> --- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> @@ -23,6 +23,7 @@ properties:
> - items:
> - enum:
> - mediatek,mt7623-mipi-tx
> + - mediatek,mt8167-mipi-tx
> - const: mediatek,mt2701-mipi-tx
> - items:
> - enum:
> --
> 2.43.0
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 2/6] dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
From: CK Hu (胡俊光) @ 2026-02-25 2:23 UTC (permalink / raw)
To: linux-mediatek@lists.infradead.org, l.scorcia@gmail.com
Cc: robh@kernel.org, Chunfeng Yun (云春峰),
krzysztof.kozlowski@oss.qualcomm.com, simona@ffwll.ch,
tzimmermann@suse.de, mripard@kernel.org,
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
maarten.lankhorst@linux.intel.com, conor+dt@kernel.org,
chunkuang.hu@kernel.org, vkoul@kernel.org, krzk+dt@kernel.org,
linux-phy@lists.infradead.org, p.zabel@pengutronix.de,
dri-devel@lists.freedesktop.org, airlied@gmail.com,
linux-arm-kernel@lists.infradead.org, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, devicetree@vger.kernel.org
In-Reply-To: <66eafae30f9fe00b469e79d385c1ddd24d209475.1771863641.git.l.scorcia@gmail.com>
On Mon, 2026-02-23 at 16:22 +0000, Luca Leonardo Scorcia wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>
>
> Add compatibles for various display-related blocks of MediaTek mt8167.
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 4 +++-
> .../devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 1 +
> .../devicetree/bindings/display/mediatek/mediatek,wdma.yaml | 4 +++-
> 7 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> index daf90ebb39bf..4bbea72b292a 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> @@ -33,6 +33,7 @@ properties:
> - enum:
> - mediatek,mt2712-disp-aal
> - mediatek,mt6795-disp-aal
> + - mediatek,mt8167-disp-aal
> - const: mediatek,mt8173-disp-aal
> - items:
> - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> index fca8e7bb0cbc..5c5068128d0c 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> @@ -25,7 +25,9 @@ properties:
> - mediatek,mt8183-disp-ccorr
> - mediatek,mt8192-disp-ccorr
> - items:
> - - const: mediatek,mt8365-disp-ccorr
> + - enum:
> + - mediatek,mt8167-disp-ccorr
> + - mediatek,mt8365-disp-ccorr
> - const: mediatek,mt8183-disp-ccorr
> - items:
> - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> index abaf27916d13..891c95be15b9 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> @@ -26,6 +26,7 @@ properties:
> - mediatek,mt8183-disp-dither
> - items:
> - enum:
> + - mediatek,mt8167-disp-dither
> - mediatek,mt8186-disp-dither
> - mediatek,mt8188-disp-dither
> - mediatek,mt8192-disp-dither
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
> index 48542dc7e784..ec1054bb06d4 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
> @@ -28,6 +28,7 @@ properties:
> - items:
> - enum:
> - mediatek,mt6795-disp-gamma
> + - mediatek,mt8167-disp-gamma
> - const: mediatek,mt8173-disp-gamma
> - items:
> - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
> index 4f110635afb6..679f731f0f15 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
> @@ -23,6 +23,7 @@ properties:
> oneOf:
> - enum:
> - mediatek,mt2701-disp-ovl
> + - mediatek,mt8167-disp-ovl
> - mediatek,mt8173-disp-ovl
> - mediatek,mt8183-disp-ovl
> - mediatek,mt8192-disp-ovl
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
> index 878f676b581f..cb187a95c11e 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
> @@ -36,6 +36,7 @@ properties:
> - enum:
> - mediatek,mt7623-disp-rdma
> - mediatek,mt2712-disp-rdma
> + - mediatek,mt8167-disp-rdma
> - const: mediatek,mt2701-disp-rdma
> - items:
> - enum:
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
> index a3a2b71a4523..816841a96133 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
> @@ -24,7 +24,9 @@ properties:
> - enum:
> - mediatek,mt8173-disp-wdma
> - items:
> - - const: mediatek,mt6795-disp-wdma
> + - enum:
> + - mediatek,mt6795-disp-wdma
> + - mediatek,mt8167-disp-wdma
> - const: mediatek,mt8173-disp-wdma
>
> reg:
> --
> 2.43.0
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
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