All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yong Wu <yong.wu@mediatek.com>
To: Evan Green <evgreen@chromium.org>
Cc: Joerg Roedel <joro@8bytes.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Tomasz Figa <tfiga@google.com>, Will Deacon <will.deacon@arm.com>,
	linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	iommu@lists.linux-foundation.org, Arnd Bergmann <arnd@arndb.de>,
	yingjoe.chen@mediatek.com, youlin.pei@mediatek.com,
	Nicolas Boichat <drinkcat@chromium.org>
Subject: Re: [PATCH 02/13] driver core: Remove the link if there is no driver with AUTO flag
Date: Wed, 27 Feb 2019 22:33:20 +0800	[thread overview]
Message-ID: <1551278000.17917.50.camel@mhfsdcap03> (raw)
In-Reply-To: <CAE=gft7mWs1jc+KQQcPuuhcmxpFRnRBTt35+uC3F20N6R554bQ@mail.gmail.com>

On Mon, 2019-02-25 at 15:53 -0800, Evan Green wrote:
> On Mon, Dec 31, 2018 at 8:52 PM Yong Wu <yong.wu@mediatek.com> wrote:
> >
> > DL_FLAG_AUTOREMOVE_CONSUMER/SUPPLIER means "Remove the link
> > automatically on consumer/supplier driver unbind", that means we should
> > remove whole the device_link when there is no this driver no matter what
> > the ref_count of the link is.
> >
> > CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > The ref_count of our device_link normally is over 1. When the consumer
> > device driver is removed, whole the device_link should be removed.
> > Thus, I add this patch.
> > ---
> 
> I will admit to reading about device links for the first time while
> reviewing this patch, but I don't really get this. Why use a kref at
> all if we're just going to ignore its value? For instance, I see that
> if you call device_link_add() with the same supplier and consumer, it
> uses the kref to return the same link. That machinery is broken with
> your change. Although I don't see any uses of it, you might also
> expect a supplier or consumer could do a kref_get() on the link it got
> back from device_link_add(), and have a reasonable expectation that
> the link wouldn't be freed out from under it. This would also be
> broken.
> 
> Can you explain why your device_links normally have a reference count
> >1, 

I use device link between the smi-larb device and the iommu-consumer
device. Take a example, smi-larb1 have 4 VDEC ports. From 4/13 in this
patchset, we use device_link to link the VDEC device and the smi-larb1
device in the function(mtk_iommu_config). since there are 4 ports, it
will call device_link_add 4 times.

>
> and why those additional references can't be cleaned up in an
> orderly fashion?

If the iommu-consume device(like VDEC above) is removed, It should enter
device_links_driver_cleanup which only ref_put one time. I guess whole
the link should be removed at that time.

> 
> (To be honest, I don't really understand the case for the AUTOREMOVE
> flags at all. Is there some case where the party that set up the link
> can't tear it down? Or is this a way to devm_ify the link, where devm
> itself doesn't work because the links themselves stall out that
> mechanism?)

WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu@mediatek.com>
To: Evan Green <evgreen@chromium.org>
Cc: youlin.pei@mediatek.com,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Nicolas Boichat <drinkcat@chromium.org>,
	Arnd Bergmann <arnd@arndb.de>,
	srv_heupstream@mediatek.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will.deacon@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Tomasz Figa <tfiga@google.com>,
	iommu@lists.linux-foundation.org,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	yingjoe.chen@mediatek.com, Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 02/13] driver core: Remove the link if there is no driver with AUTO flag
Date: Wed, 27 Feb 2019 22:33:20 +0800	[thread overview]
Message-ID: <1551278000.17917.50.camel@mhfsdcap03> (raw)
In-Reply-To: <CAE=gft7mWs1jc+KQQcPuuhcmxpFRnRBTt35+uC3F20N6R554bQ@mail.gmail.com>

On Mon, 2019-02-25 at 15:53 -0800, Evan Green wrote:
> On Mon, Dec 31, 2018 at 8:52 PM Yong Wu <yong.wu@mediatek.com> wrote:
> >
> > DL_FLAG_AUTOREMOVE_CONSUMER/SUPPLIER means "Remove the link
> > automatically on consumer/supplier driver unbind", that means we should
> > remove whole the device_link when there is no this driver no matter what
> > the ref_count of the link is.
> >
> > CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > The ref_count of our device_link normally is over 1. When the consumer
> > device driver is removed, whole the device_link should be removed.
> > Thus, I add this patch.
> > ---
> 
> I will admit to reading about device links for the first time while
> reviewing this patch, but I don't really get this. Why use a kref at
> all if we're just going to ignore its value? For instance, I see that
> if you call device_link_add() with the same supplier and consumer, it
> uses the kref to return the same link. That machinery is broken with
> your change. Although I don't see any uses of it, you might also
> expect a supplier or consumer could do a kref_get() on the link it got
> back from device_link_add(), and have a reasonable expectation that
> the link wouldn't be freed out from under it. This would also be
> broken.
> 
> Can you explain why your device_links normally have a reference count
> >1, 

I use device link between the smi-larb device and the iommu-consumer
device. Take a example, smi-larb1 have 4 VDEC ports. From 4/13 in this
patchset, we use device_link to link the VDEC device and the smi-larb1
device in the function(mtk_iommu_config). since there are 4 ports, it
will call device_link_add 4 times.

>
> and why those additional references can't be cleaned up in an
> orderly fashion?

If the iommu-consume device(like VDEC above) is removed, It should enter
device_links_driver_cleanup which only ref_put one time. I guess whole
the link should be removed at that time.

> 
> (To be honest, I don't really understand the case for the AUTOREMOVE
> flags at all. Is there some case where the party that set up the link
> can't tear it down? Or is this a way to devm_ify the link, where devm
> itself doesn't work because the links themselves stall out that
> mechanism?)


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu@mediatek.com>
To: Evan Green <evgreen@chromium.org>
Cc: Joerg Roedel <joro@8bytes.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Tomasz Figa <tfiga@google.com>, Will Deacon <will.deacon@arm.com>,
	<linux-mediatek@lists.infradead.org>,
	<srv_heupstream@mediatek.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<iommu@lists.linux-foundation.org>, Arnd Bergmann <arnd@arndb.de>,
	<yingjoe.chen@mediatek.com>, <youlin.pei@mediatek.com>,
	Nicolas Boichat <drinkcat@chromium.org>
Subject: Re: [PATCH 02/13] driver core: Remove the link if there is no driver with AUTO flag
Date: Wed, 27 Feb 2019 22:33:20 +0800	[thread overview]
Message-ID: <1551278000.17917.50.camel@mhfsdcap03> (raw)
In-Reply-To: <CAE=gft7mWs1jc+KQQcPuuhcmxpFRnRBTt35+uC3F20N6R554bQ@mail.gmail.com>

On Mon, 2019-02-25 at 15:53 -0800, Evan Green wrote:
> On Mon, Dec 31, 2018 at 8:52 PM Yong Wu <yong.wu@mediatek.com> wrote:
> >
> > DL_FLAG_AUTOREMOVE_CONSUMER/SUPPLIER means "Remove the link
> > automatically on consumer/supplier driver unbind", that means we should
> > remove whole the device_link when there is no this driver no matter what
> > the ref_count of the link is.
> >
> > CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > The ref_count of our device_link normally is over 1. When the consumer
> > device driver is removed, whole the device_link should be removed.
> > Thus, I add this patch.
> > ---
> 
> I will admit to reading about device links for the first time while
> reviewing this patch, but I don't really get this. Why use a kref at
> all if we're just going to ignore its value? For instance, I see that
> if you call device_link_add() with the same supplier and consumer, it
> uses the kref to return the same link. That machinery is broken with
> your change. Although I don't see any uses of it, you might also
> expect a supplier or consumer could do a kref_get() on the link it got
> back from device_link_add(), and have a reasonable expectation that
> the link wouldn't be freed out from under it. This would also be
> broken.
> 
> Can you explain why your device_links normally have a reference count
> >1, 

I use device link between the smi-larb device and the iommu-consumer
device. Take a example, smi-larb1 have 4 VDEC ports. From 4/13 in this
patchset, we use device_link to link the VDEC device and the smi-larb1
device in the function(mtk_iommu_config). since there are 4 ports, it
will call device_link_add 4 times.

>
> and why those additional references can't be cleaned up in an
> orderly fashion?

If the iommu-consume device(like VDEC above) is removed, It should enter
device_links_driver_cleanup which only ref_put one time. I guess whole
the link should be removed at that time.

> 
> (To be honest, I don't really understand the case for the AUTOREMOVE
> flags at all. Is there some case where the party that set up the link
> can't tear it down? Or is this a way to devm_ify the link, where devm
> itself doesn't work because the links themselves stall out that
> mechanism?)


  reply	other threads:[~2019-02-27 14:33 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-01  4:51 [PATCH 00/13] Clean up "mediatek,larb" after adding device_link Yong Wu
2019-01-01  4:51 ` Yong Wu
2019-01-01  4:51 ` Yong Wu
2019-01-01  4:51 ` [PATCH 07/13] media: mtk-mdp: Get rid of mtk_smi_larb_get/put Yong Wu
2019-01-01  4:51   ` Yong Wu
2019-01-01  4:51   ` Yong Wu
     [not found]   ` <1546318276-18993-8-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-02-25 23:55     ` Evan Green
2019-02-25 23:55       ` Evan Green
2019-02-25 23:55       ` Evan Green
     [not found] ` <1546318276-18993-1-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-01-01  4:51   ` [PATCH 01/13] dt-binding: mediatek: Get rid of mediatek, larb for multimedia HW Yong Wu
2019-01-01  4:51     ` [PATCH 01/13] dt-binding: mediatek: Get rid of mediatek,larb " Yong Wu
2019-01-01  4:51     ` [PATCH 01/13] dt-binding: mediatek: Get rid of mediatek, larb " Yong Wu
2019-01-11 14:58     ` [PATCH 01/13] dt-binding: mediatek: Get rid of mediatek,larb " Rob Herring
2019-01-11 14:58       ` Rob Herring
2019-01-11 14:58       ` [PATCH 01/13] dt-binding: mediatek: Get rid of mediatek, larb " Rob Herring
2019-02-25 23:54     ` [PATCH 01/13] dt-binding: mediatek: Get rid of mediatek,larb " Evan Green
2019-02-25 23:54       ` [PATCH 01/13] dt-binding: mediatek: Get rid of mediatek, larb " Evan Green
2019-01-01  4:51   ` [PATCH 02/13] driver core: Remove the link if there is no driver with AUTO flag Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-01-01  4:51     ` Yong Wu
     [not found]     ` <1546318276-18993-3-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-02-25 23:53       ` Evan Green
2019-02-25 23:53         ` Evan Green
2019-02-25 23:53         ` Evan Green
2019-02-27 14:33         ` Yong Wu [this message]
2019-02-27 14:33           ` Yong Wu
2019-02-27 14:33           ` Yong Wu
2019-03-05 19:03           ` Evan Green
2019-03-05 19:03             ` Evan Green
2019-03-12 14:21             ` Matthias Brugger
2019-03-12 14:21               ` Matthias Brugger
2019-03-12 23:17               ` Evan Green
2019-03-12 23:17                 ` Evan Green
2019-03-13  9:08                 ` Yong Wu
2019-03-13  9:08                   ` Yong Wu
2019-03-13  9:08                   ` Yong Wu
2019-01-01  4:51   ` [PATCH 03/13] iommu/mediatek: Add probe_defer for smi-larb Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-01-01  4:51     ` Yong Wu
     [not found]     ` <1546318276-18993-4-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-02-25 23:54       ` Evan Green
2019-02-25 23:54         ` Evan Green
2019-02-25 23:54         ` Evan Green
2019-02-27 14:33         ` Yong Wu
2019-02-27 14:33           ` Yong Wu
2019-02-27 14:33           ` Yong Wu
2019-03-05 19:02           ` Evan Green
2019-03-05 19:02             ` Evan Green
2019-01-01  4:51   ` [PATCH 04/13] iommu/mediatek: Add device_link between the consumer and the larb devices Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-02-25 23:54     ` Evan Green
2019-02-25 23:54       ` Evan Green
2019-02-27 14:34       ` Yong Wu
2019-02-27 14:34         ` Yong Wu
2019-02-27 14:34         ` Yong Wu
2019-02-27 19:30     ` Robin Murphy
2019-02-27 19:30       ` Robin Murphy
2019-03-13  9:11       ` Yong Wu
2019-03-13  9:11         ` Yong Wu
2019-03-13  9:11         ` Yong Wu
2019-01-01  4:51   ` [PATCH 05/13] memory: mtk-smi: Add device-link between smi-larb and smi-common Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-02-25 23:54     ` Evan Green
2019-02-25 23:54       ` Evan Green
2019-02-27 14:33       ` Yong Wu
2019-02-27 14:33         ` Yong Wu
2019-02-27 14:33         ` Yong Wu
2019-03-05 19:02         ` Evan Green
2019-03-05 19:02           ` Evan Green
2019-01-01  4:51   ` [PATCH 06/13] media: mtk-jpeg: Get rid of mtk_smi_larb_get/put Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-02-25 23:55     ` Evan Green
2019-02-25 23:55       ` Evan Green
2019-02-25 23:55       ` Evan Green
2019-01-01  4:51   ` [PATCH 08/13] media: mtk-vcodec: " Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-01-01  4:51     ` Yong Wu
     [not found]     ` <1546318276-18993-9-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-02-25 23:55       ` Evan Green
2019-02-25 23:55         ` Evan Green
2019-02-25 23:55         ` Evan Green
2019-01-01  4:51   ` [PATCH 09/13] drm/mediatek: " Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-02-25 23:55     ` Evan Green
2019-02-25 23:55       ` Evan Green
2019-02-25 23:55       ` Evan Green
2019-01-01  4:51   ` [PATCH 10/13] memory: mtk-smi: " Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-01-01  4:51     ` Yong Wu
     [not found]     ` <1546318276-18993-11-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-02-25 23:56       ` Evan Green
2019-02-25 23:56         ` Evan Green
2019-02-25 23:56         ` Evan Green
2019-01-01  4:51   ` [PATCH 11/13] iommu/mediatek: Use builtin_platform_driver Yong Wu
2019-01-01  4:51     ` Yong Wu
2019-01-01  4:51     ` Yong Wu
     [not found]     ` <1546318276-18993-12-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-02-25 23:56       ` Evan Green
2019-02-25 23:56         ` Evan Green
2019-02-25 23:56         ` Evan Green
2019-02-27 14:33         ` Yong Wu
2019-02-27 14:33           ` Yong Wu
2019-02-27 14:33           ` Yong Wu
2019-03-05 19:03           ` Evan Green
2019-03-05 19:03             ` Evan Green
2019-01-01  4:51   ` [PATCH 12/13] arm: dts: mediatek: Get rid of mediatek, larb for MM nodes Yong Wu
2019-01-01  4:51     ` [PATCH 12/13] arm: dts: mediatek: Get rid of mediatek,larb " Yong Wu
2019-01-01  4:51     ` [PATCH 12/13] arm: dts: mediatek: Get rid of mediatek, larb " Yong Wu
     [not found]     ` <1546318276-18993-13-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-02-25 23:56       ` Evan Green
2019-02-25 23:56         ` [PATCH 12/13] arm: dts: mediatek: Get rid of mediatek,larb " Evan Green
2019-02-25 23:56         ` [PATCH 12/13] arm: dts: mediatek: Get rid of mediatek, larb " Evan Green
2019-01-01  4:51   ` [PATCH 13/13] arm64: " Yong Wu
2019-01-01  4:51     ` [PATCH 13/13] arm64: dts: mediatek: Get rid of mediatek,larb " Yong Wu
2019-01-01  4:51     ` [PATCH 13/13] arm64: dts: mediatek: Get rid of mediatek, larb " Yong Wu
2019-02-25 23:56     ` Evan Green
2019-02-25 23:56       ` [PATCH 13/13] arm64: dts: mediatek: Get rid of mediatek,larb " Evan Green
2019-02-25 23:56       ` [PATCH 13/13] arm64: dts: mediatek: Get rid of mediatek, larb " Evan Green

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=1551278000.17917.50.camel@mhfsdcap03 \
    --to=yong.wu@mediatek.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=evgreen@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=tfiga@google.com \
    --cc=will.deacon@arm.com \
    --cc=yingjoe.chen@mediatek.com \
    --cc=youlin.pei@mediatek.com \
    /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.