All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yong Wu <yong.wu@mediatek.com>
To: Stephen Boyd <swboyd@chromium.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Douglas Anderson <dianders@chromium.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>,
	<freedreno@lists.freedesktop.org>,
	"Joerg Roedel" <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Rob Clark" <robdclark@gmail.com>,
	Russell King <rmk+kernel@arm.linux.org.uk>,
	Saravana Kannan <saravanak@google.com>
Subject: Re: [PATCH v6 25/35] iommu/mediatek: Migrate to aggregate driver
Date: Thu, 10 Feb 2022 19:03:35 +0800	[thread overview]
Message-ID: <7c517b787d1dd768372d0141f5078e3089e883cb.camel@mediatek.com> (raw)
In-Reply-To: <20220127200141.1295328-26-swboyd@chromium.org>

On Thu, 2022-01-27 at 12:01 -0800, Stephen Boyd wrote:
> Use an aggregate driver instead of component ops so that we can get
> proper driver probe ordering of the aggregate device with respect to
> all
> the component devices that make up the aggregate device.
> 
> Cc: Yong Wu <yong.wu@mediatek.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Will Deacon <will@kernel.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Saravana Kannan <saravanak@google.com>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>

+ Krzysztof

The memory/mtk-smi.c is expected to get Ack from Krzysztof.

Tested-by: Yong Wu <yong.wu@mediatek.com>

> ---
>  drivers/iommu/mtk_iommu.c    | 14 +++++++++-----
>  drivers/iommu/mtk_iommu.h    |  6 ++++--
>  drivers/iommu/mtk_iommu_v1.c | 14 +++++++++-----
>  drivers/memory/mtk-smi.c     | 10 ++++------
>  4 files changed, 26 insertions(+), 18 deletions(-)

[...]

> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index e201e5976f34..0910fe109f53 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -175,6 +175,8 @@ mtk_smi_larb_bind(struct device *dev, struct
> device *master, void *data)
>  			larb->larbid = i;
>  			larb->mmu = &larb_mmu[i].mmu;
>  			larb->bank = larb_mmu[i].bank;
> +
> +			pm_runtime_enable(dev);
>  			return 0;
>  		}
>  	}
> @@ -450,15 +452,11 @@ static int mtk_smi_larb_probe(struct
> platform_device *pdev)
>  	if (ret < 0)
>  		return ret;
>  
> -	pm_runtime_enable(dev);
>  	platform_set_drvdata(pdev, larb);
>  	ret = component_add(dev, &mtk_smi_larb_component_ops);
> -	if (ret)
> -		goto err_pm_disable;
> -	return 0;
> +	if (!ret)
> +		return 0;
>  
> -err_pm_disable:
> -	pm_runtime_disable(dev);
>  	device_link_remove(dev, larb->smi_common_dev);

Here is right. But at a glance code here, I was confused why it always
call device_link_remove here. If we have v7, Could you help keep the
original format? something like below. This may be helpful when we add
new error flow in future.

        if (ret)
              goto dev_link_remove;
        return ret;

dev_link_remove:
        device_link_remove(dev, larb->smi_common_dev);

Thanks.     

>  	return ret;
>  }


WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu@mediatek.com>
To: Stephen Boyd <swboyd@chromium.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Douglas Anderson <dianders@chromium.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: freedreno@lists.freedesktop.org,
	Saravana Kannan <saravanak@google.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-arm-msm@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Russell King <rmk+kernel@arm.linux.org.uk>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH v6 25/35] iommu/mediatek: Migrate to aggregate driver
Date: Thu, 10 Feb 2022 19:03:35 +0800	[thread overview]
Message-ID: <7c517b787d1dd768372d0141f5078e3089e883cb.camel@mediatek.com> (raw)
In-Reply-To: <20220127200141.1295328-26-swboyd@chromium.org>

On Thu, 2022-01-27 at 12:01 -0800, Stephen Boyd wrote:
> Use an aggregate driver instead of component ops so that we can get
> proper driver probe ordering of the aggregate device with respect to
> all
> the component devices that make up the aggregate device.
> 
> Cc: Yong Wu <yong.wu@mediatek.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Will Deacon <will@kernel.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Saravana Kannan <saravanak@google.com>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>

+ Krzysztof

The memory/mtk-smi.c is expected to get Ack from Krzysztof.

Tested-by: Yong Wu <yong.wu@mediatek.com>

> ---
>  drivers/iommu/mtk_iommu.c    | 14 +++++++++-----
>  drivers/iommu/mtk_iommu.h    |  6 ++++--
>  drivers/iommu/mtk_iommu_v1.c | 14 +++++++++-----
>  drivers/memory/mtk-smi.c     | 10 ++++------
>  4 files changed, 26 insertions(+), 18 deletions(-)

[...]

> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index e201e5976f34..0910fe109f53 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -175,6 +175,8 @@ mtk_smi_larb_bind(struct device *dev, struct
> device *master, void *data)
>  			larb->larbid = i;
>  			larb->mmu = &larb_mmu[i].mmu;
>  			larb->bank = larb_mmu[i].bank;
> +
> +			pm_runtime_enable(dev);
>  			return 0;
>  		}
>  	}
> @@ -450,15 +452,11 @@ static int mtk_smi_larb_probe(struct
> platform_device *pdev)
>  	if (ret < 0)
>  		return ret;
>  
> -	pm_runtime_enable(dev);
>  	platform_set_drvdata(pdev, larb);
>  	ret = component_add(dev, &mtk_smi_larb_component_ops);
> -	if (ret)
> -		goto err_pm_disable;
> -	return 0;
> +	if (!ret)
> +		return 0;
>  
> -err_pm_disable:
> -	pm_runtime_disable(dev);
>  	device_link_remove(dev, larb->smi_common_dev);

Here is right. But at a glance code here, I was confused why it always
call device_link_remove here. If we have v7, Could you help keep the
original format? something like below. This may be helpful when we add
new error flow in future.

        if (ret)
              goto dev_link_remove;
        return ret;

dev_link_remove:
        device_link_remove(dev, larb->smi_common_dev);

Thanks.     

>  	return ret;
>  }


  reply	other threads:[~2022-02-10 11:03 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-27 20:01 [PATCH v6 00/35] component: Make into an aggregate bus Stephen Boyd
2022-01-27 20:01 ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 01/35] component: Replace most references to 'master' with 'aggregate device' Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-31 13:48   ` Greg Kroah-Hartman
2022-01-31 13:48     ` Greg Kroah-Hartman
2022-01-27 20:01 ` [PATCH v6 02/35] component: Introduce the aggregate bus_type Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-31 13:48   ` Greg Kroah-Hartman
2022-01-31 13:48     ` Greg Kroah-Hartman
2022-01-31 15:15     ` Daniel Vetter
2022-01-31 15:15       ` Daniel Vetter
2022-01-31 15:32       ` Laurent Pinchart
2022-01-31 15:32         ` Laurent Pinchart
2022-01-31 16:34       ` Greg Kroah-Hartman
2022-01-31 16:34         ` Greg Kroah-Hartman
2022-02-08 12:53         ` Daniel Vetter
2022-02-08 12:53           ` Daniel Vetter
2022-02-11  2:04           ` Stephen Boyd
2022-02-11  2:04             ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 03/35] component: Add aggregate_device_parent() for driver use Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 04/35] component: Add {bind,unbind}_component() ops that take aggregate device Stephen Boyd
2022-01-27 20:01   ` [PATCH v6 04/35] component: Add {bind, unbind}_component() " Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 05/35] drm/of: Add a drm_of_aggregate_probe() API Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 06/35] drm/msm: Migrate to aggregate driver Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 07/35] drm/komeda: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 08/35] drm/arm/hdlcd: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 09/35] drm/malidp: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 10/35] drm/armada: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 11/35] drm/etnaviv: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 12/35] drm/kirin: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 13/35] drm/exynos: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 14/35] drm/imx: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 15/35] drm/ingenic: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 16/35] drm/mcde: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 17/35] drm/mediatek: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 18/35] drm/meson: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 19/35] drm/omap: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 20/35] drm/rockchip: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 21/35] drm/sti: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 22/35] drm/sun4i: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 23/35] drm/tilcdc: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 24/35] drm/vc4: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 25/35] iommu/mediatek: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-02-10 11:03   ` Yong Wu [this message]
2022-02-10 11:03     ` Yong Wu
2022-02-15 17:35     ` Krzysztof Kozlowski
2022-02-15 17:35       ` Krzysztof Kozlowski
2022-01-27 20:01 ` [PATCH v6 26/35] mei: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 27/35] power: supply: ab8500: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 28/35] fbdev: omap2: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 29/35] sound: hdac: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-31  8:18   ` Takashi Iwai
2022-01-31  8:18     ` Takashi Iwai
2022-01-27 20:01 ` [PATCH v6 30/35] ASoC: codecs: wcd938x: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 31/35] drm/sprd: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 32/35] usb: typec: port-mapper: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 33/35] ALSA: hda/realtek: " Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-28 15:31   ` Stefan Binding
2022-01-28 15:31     ` Stefan Binding
2022-01-27 20:01 ` [PATCH v6 34/35] component: Get rid of drm_of_component_probe() Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd
2022-01-27 20:01 ` [PATCH v6 35/35] component: Remove component_master_ops and friends Stephen Boyd
2022-01-27 20:01   ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7c517b787d1dd768372d0141f5078e3089e883cb.camel@mediatek.com \
    --to=yong.wu@mediatek.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=joro@8bytes.org \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=robdclark@gmail.com \
    --cc=saravanak@google.com \
    --cc=swboyd@chromium.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.