The MediaTek UFS host driver's probe function allows using a
ti,syscon-reset as a reset, without going through the appropriate
abstractions, or by documenting this in the binding at all.

Remove this, it's downstream code and does not belong here.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/ufs/host/ufs-mediatek.c | 32 +++-----------------------------
 1 file changed, 3 insertions(+), 29 deletions(-)

diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index 3282b2d2d498..5f08fbbaa447 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -2383,38 +2383,12 @@ MODULE_DEVICE_TABLE(of, ufs_mtk_of_match);
 static int ufs_mtk_probe(struct platform_device *pdev)
 {
 	int err;
-	struct device *dev = &pdev->dev, *phy_dev = NULL;
-	struct device_node *reset_node, *phy_node = NULL;
-	struct platform_device *reset_pdev, *phy_pdev = NULL;
-	struct device_link *link;
 	struct ufs_hba *hba;
+	struct platform_device *phy_pdev = NULL;
+	struct device *dev = &pdev->dev;
+	struct device_node *phy_node = NULL;
 	struct ufs_mtk_host *host;
 
-	reset_node = of_find_compatible_node(NULL, NULL,
-					     "ti,syscon-reset");
-	if (!reset_node) {
-		dev_notice(dev, "find ti,syscon-reset fail\n");
-		goto skip_reset;
-	}
-	reset_pdev = of_find_device_by_node(reset_node);
-	if (!reset_pdev) {
-		dev_notice(dev, "find reset_pdev fail\n");
-		goto skip_reset;
-	}
-	link = device_link_add(dev, &reset_pdev->dev,
-		DL_FLAG_AUTOPROBE_CONSUMER);
-	put_device(&reset_pdev->dev);
-	if (!link) {
-		dev_notice(dev, "add reset device_link fail\n");
-		goto skip_reset;
-	}
-	/* supplier is not probed */
-	if (link->status == DL_STATE_DORMANT) {
-		err = -EPROBE_DEFER;
-		goto out;
-	}
-
-skip_reset:
 	/* find phy node */
 	phy_node = of_parse_phandle(dev->of_node, "phys", 0);
 

-- 
2.53.0

On Wed, 2026-03-04 at 15:53 +0100, Nicolas Frattaroli wrote:
> @@ -2383,38 +2383,12 @@ MODULE_DEVICE_TABLE(of, ufs_mtk_of_match);
>  static int ufs_mtk_probe(struct platform_device *pdev)
>  {
>  	int err;
> -	struct device *dev = &pdev->dev, *phy_dev = NULL;
> 

Will there be a build error if phy_dev is removed?
Please make sure that each patch can build successfully, one by one.

Thanks
Peter

On Thursday, 5 March 2026 10:14:47 Central European Standard Time Peter Wang (王信友) wrote:
> On Wed, 2026-03-04 at 15:53 +0100, Nicolas Frattaroli wrote:
> > @@ -2383,38 +2383,12 @@ MODULE_DEVICE_TABLE(of, ufs_mtk_of_match);
> >  static int ufs_mtk_probe(struct platform_device *pdev)
> >  {
> >  	int err;
> > -	struct device *dev = &pdev->dev, *phy_dev = NULL;
> > 
> 
> Will there be a build error if phy_dev is removed?
> Please make sure that each patch can build successfully, one by one.
> 
> Thanks
> Peter
> 
> 
> 
> 

Yes, these are the kinds of mistakes that happen when you ask someone
to pick apart patches for your downstream convenience.

I'll hand dealing with any further fixups and variable naming concerns
you have over to Angelo, as I can't be bothered to deal with you
anymore.

On Thu, 2026-03-05 at 10:57 +0100, Nicolas Frattaroli wrote:
> 
> Yes, these are the kinds of mistakes that happen when you ask someone
> to pick apart patches for your downstream convenience.
> 
> I'll hand dealing with any further fixups and variable naming
> concerns
> you have over to Angelo, as I can't be bothered to deal with you
> anymore.
> 

I thought ensuring that every patch builds successfully
was a basic requirement.

On Friday, 6 March 2026 06:39:22 Central European Standard Time Peter Wang (王信友) wrote:
> On Thu, 2026-03-05 at 10:57 +0100, Nicolas Frattaroli wrote:
> > 
> > Yes, these are the kinds of mistakes that happen when you ask someone
> > to pick apart patches for your downstream convenience.
> > 
> > I'll hand dealing with any further fixups and variable naming
> > concerns
> > you have over to Angelo, as I can't be bothered to deal with you
> > anymore.
> > 
> 
> I thought ensuring that every patch builds successfully
> was a basic requirement.
> 
> 

And I thought putting bindings through bindings review was a basic
requirement, but apparently not for you when you can subvert the
kernel's review process and push your downstream crap into mainline
willy-nilly.