Both ufs_mtk_vreg_fix_vcc and ufs_mtk_vreg_fix_vccqx look like they are
vendor kernel hacks to work around existing downstream device trees.
Mainline does not need or want them, so remove them.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/ufs/host/ufs-mediatek.c | 69 -----------------------------------------
 1 file changed, 69 deletions(-)

diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index cc6a3a4c9704..6385ebcc9142 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -1019,73 +1019,6 @@ static void ufs_mtk_init_clocks(struct ufs_hba *hba)
 	}
 }
 
-#define MAX_VCC_NAME 30
-static int ufs_mtk_vreg_fix_vcc(struct ufs_hba *hba)
-{
-	struct ufs_vreg_info *info = &hba->vreg_info;
-	struct device_node *np = hba->dev->of_node;
-	struct device *dev = hba->dev;
-	char vcc_name[MAX_VCC_NAME];
-	struct arm_smccc_res res;
-	int err, ver;
-
-	if (info->vcc)
-		return 0;
-
-	if (of_property_read_bool(np, "mediatek,ufs-vcc-by-num")) {
-		ufs_mtk_get_vcc_num(res);
-		if (res.a1 > UFS_VCC_NONE && res.a1 < UFS_VCC_MAX)
-			snprintf(vcc_name, MAX_VCC_NAME, "vcc-opt%lu", res.a1);
-		else
-			return -ENODEV;
-	} else if (of_property_read_bool(np, "mediatek,ufs-vcc-by-ver")) {
-		ver = (hba->dev_info.wspecversion & 0xF00) >> 8;
-		snprintf(vcc_name, MAX_VCC_NAME, "vcc-ufs%u", ver);
-	} else {
-		return 0;
-	}
-
-	err = ufshcd_populate_vreg(dev, vcc_name, &info->vcc, false);
-	if (err)
-		return err;
-
-	err = ufshcd_get_vreg(dev, info->vcc);
-	if (err)
-		return err;
-
-	err = regulator_enable(info->vcc->reg);
-	if (!err) {
-		info->vcc->enabled = true;
-		dev_info(dev, "%s: %s enabled\n", __func__, vcc_name);
-	}
-
-	return err;
-}
-
-static void ufs_mtk_vreg_fix_vccqx(struct ufs_hba *hba)
-{
-	struct ufs_vreg_info *info = &hba->vreg_info;
-	struct ufs_vreg **vreg_on, **vreg_off;
-
-	if (hba->dev_info.wspecversion >= 0x0300) {
-		vreg_on = &info->vccq;
-		vreg_off = &info->vccq2;
-	} else {
-		vreg_on = &info->vccq2;
-		vreg_off = &info->vccq;
-	}
-
-	if (*vreg_on)
-		(*vreg_on)->always_on = true;
-
-	if (*vreg_off) {
-		regulator_disable((*vreg_off)->reg);
-		devm_kfree(hba->dev, (*vreg_off)->name);
-		devm_kfree(hba->dev, *vreg_off);
-		*vreg_off = NULL;
-	}
-}
-
 static void ufs_mtk_setup_clk_gating(struct ufs_hba *hba)
 {
 	unsigned long flags;
@@ -2005,8 +1938,6 @@ static void ufs_mtk_fixup_dev_quirks(struct ufs_hba *hba)
 		hba->dev_quirks &= ~UFS_DEVICE_QUIRK_DELAY_BEFORE_LPM;
 	}
 
-	ufs_mtk_vreg_fix_vcc(hba);
-	ufs_mtk_vreg_fix_vccqx(hba);
 	ufs_mtk_fix_ahit(hba);
 	ufs_mtk_fix_clock_scaling(hba);
 }

-- 
2.52.0

On Thu, 2025-12-18 at 13:55 +0100, Nicolas Frattaroli wrote:
> 
> Both ufs_mtk_vreg_fix_vcc and ufs_mtk_vreg_fix_vccqx look like they
> are
> vendor kernel hacks to work around existing downstream device trees.
> Mainline does not need or want them, so remove them.
> 

Hi Nicolas,

This is a flexible approach to implement one software supporting
multiple
hardware configurations. Because you cannot guarantee that your SOC
will 
always use UFS 2.0 or UFS 3.0, or that the PMIC you use will only have
one set.

Thanks
Peter

On 06/01/2026 14:25, Peter Wang (王信友) wrote:
> On Thu, 2025-12-18 at 13:55 +0100, Nicolas Frattaroli wrote:
>>
>> Both ufs_mtk_vreg_fix_vcc and ufs_mtk_vreg_fix_vccqx look like they
>> are
>> vendor kernel hacks to work around existing downstream device trees.
>> Mainline does not need or want them, so remove them.
>>
> 
> Hi Nicolas,
> 
> This is a flexible approach to implement one software supporting
> multiple
> hardware configurations. Because you cannot guarantee that your SOC
> will 

We do not store dead code for your vendor, downstream kernel. We already
discussed it months ago where you were pushing same agenda.

Stop with this downstream approach and understand that your downstream
absolutely does not matter and does not exist for us.

> always use UFS 2.0 or UFS 3.0, or that the PMIC you use will only have
> one set.
> 
> Thanks
> Peter
> 
> 


Best regards,
Krzysztof

On Tuesday, 6 January 2026 14:25:22 Central European Standard Time Peter Wang (王信友) wrote:
> On Thu, 2025-12-18 at 13:55 +0100, Nicolas Frattaroli wrote:
> > 
> > Both ufs_mtk_vreg_fix_vcc and ufs_mtk_vreg_fix_vccqx look like they
> > are
> > vendor kernel hacks to work around existing downstream device trees.
> > Mainline does not need or want them, so remove them.
> > 
> 
> Hi Nicolas,
> 
> This is a flexible approach to implement one software supporting
> multiple
> hardware configurations. Because you cannot guarantee that your SOC
> will 
> always use UFS 2.0 or UFS 3.0, or that the PMIC you use will only have
> one set.

By "one software supporting multiple hardware configurations", do you
mean one device tree? Because if so, I don't think that's a good idea.
Device tree is meant to describe non-enumerable hardware.

Even if you want to make it easier for your customers to ship one image
for several SKUs, there's better ways to do this than having drivers
fix up individual DT nodes. The platform firmware like u-boot can choose
a DT based on differences it can probe. E.g. on Radxa ROCK 5B/5B+ boards,
we have u-boot choose between the 5B and 5B+ DT based on whether LPDDR5
is present, as 5B does not have LPDDR5, so as long as u-boot is told it's
either a ROCK 5B or ROCK 5B+, it can figure out which one specifically based
on that. Similarly, for whichever boards this is for, there may be
differences that can be probed to disambiguate between several SKUs of the
board as long as it's known it must be at least one of those SKUs.

> 
> Thanks
> Peter
> 
> 
> 

On Thu, 2026-01-08 at 10:28 +0100, Nicolas Frattaroli wrote:
> By "one software supporting multiple hardware configurations", do you
> mean one device tree? Because if so, I don't think that's a good
> idea.

Yes.

> Device tree is meant to describe non-enumerable hardware.

I agree.

> 
> Even if you want to make it easier for your customers to ship one
> image
> for several SKUs, there's better ways to do this than having drivers
> fix up individual DT nodes. The platform firmware like u-boot can
> choose
> a DT based on differences it can probe. E.g. on Radxa ROCK 5B/5B+
> boards,
> we have u-boot choose between the 5B and 5B+ DT based on whether
> LPDDR5
> is present, as 5B does not have LPDDR5, so as long as u-boot is told
> it's
> either a ROCK 5B or ROCK 5B+, it can figure out which one
> specifically based
> on that. Similarly, for whichever boards this is for, there may be
> differences that can be probed to disambiguate between several SKUs
> of the
> board as long as it's known it must be at least one of those SKUs.



We will adopt this approach. Thank you for your suggestion.