All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yong Wu <yong.wu@mediatek.com>
To: Evan Green <evgreen@chromium.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
	Joerg Roedel <joro@8bytes.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	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, 13 Mar 2019 17:08:23 +0800	[thread overview]
Message-ID: <1552468103.7433.11.camel@mhfsdcap03> (raw)
In-Reply-To: <CAE=gft47TODOqKUxCvd+kDKfGbkQC1OVBarb1MaU3KrptcXiNw@mail.gmail.com>

On Tue, 2019-03-12 at 16:17 -0700, Evan Green wrote:
> On Tue, Mar 12, 2019 at 7:21 AM Matthias Brugger <matthias.bgg@gmail.com> wrote:
> >
> >
> >
> > On 05/03/2019 20:03, Evan Green wrote:
> > > On Wed, Feb 27, 2019 at 6:33 AM Yong Wu <yong.wu@mediatek.com> wrote:
> > >>
> > >> 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.
> > >
> > > It seems like Robin had some suggestions about using
> > > mtk_iommu_add_device() rather than the attach_dev() to set the links
> > > up, and then track them for removal in the corresponding
> > > remove_device() callback. Then you wouldn't need this change, right?

Hi Evan,  sorry for reply you so late. I have not got time to try
this(Put it in the add_device), But I guess it works.
At that time the ref_cnt here should be 1, then this patch is
unnecessary.

> > >
> >
> > FYI, Evan the patch is queued for v5.1-rc1 as
> > 0fe6f7874d46 ("driver core: Remove the link if there is no driver with AUTO flag")
> >
> > So if you think there is something wrong with it, then please provide a fix or
> > raise awareness :)
> 
> Oh. Thanks for the heads-up Matthias. It's pretty weird that we have
> the kref there whose count we just completely ignore. I'll try to find
> some time to submit a patch.

Thanks very much if you improve this.

> -Evan

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, 13 Mar 2019 17:08:23 +0800	[thread overview]
Message-ID: <1552468103.7433.11.camel@mhfsdcap03> (raw)
In-Reply-To: <CAE=gft47TODOqKUxCvd+kDKfGbkQC1OVBarb1MaU3KrptcXiNw@mail.gmail.com>

On Tue, 2019-03-12 at 16:17 -0700, Evan Green wrote:
> On Tue, Mar 12, 2019 at 7:21 AM Matthias Brugger <matthias.bgg@gmail.com> wrote:
> >
> >
> >
> > On 05/03/2019 20:03, Evan Green wrote:
> > > On Wed, Feb 27, 2019 at 6:33 AM Yong Wu <yong.wu@mediatek.com> wrote:
> > >>
> > >> 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.
> > >
> > > It seems like Robin had some suggestions about using
> > > mtk_iommu_add_device() rather than the attach_dev() to set the links
> > > up, and then track them for removal in the corresponding
> > > remove_device() callback. Then you wouldn't need this change, right?

Hi Evan,  sorry for reply you so late. I have not got time to try
this(Put it in the add_device), But I guess it works.
At that time the ref_cnt here should be 1, then this patch is
unnecessary.

> > >
> >
> > FYI, Evan the patch is queued for v5.1-rc1 as
> > 0fe6f7874d46 ("driver core: Remove the link if there is no driver with AUTO flag")
> >
> > So if you think there is something wrong with it, then please provide a fix or
> > raise awareness :)
> 
> Oh. Thanks for the heads-up Matthias. It's pretty weird that we have
> the kref there whose count we just completely ignore. I'll try to find
> some time to submit a patch.

Thanks very much if you improve this.

> -Evan



_______________________________________________
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: Matthias Brugger <matthias.bgg@gmail.com>,
	Joerg Roedel <joro@8bytes.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"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, 13 Mar 2019 17:08:23 +0800	[thread overview]
Message-ID: <1552468103.7433.11.camel@mhfsdcap03> (raw)
In-Reply-To: <CAE=gft47TODOqKUxCvd+kDKfGbkQC1OVBarb1MaU3KrptcXiNw@mail.gmail.com>

On Tue, 2019-03-12 at 16:17 -0700, Evan Green wrote:
> On Tue, Mar 12, 2019 at 7:21 AM Matthias Brugger <matthias.bgg@gmail.com> wrote:
> >
> >
> >
> > On 05/03/2019 20:03, Evan Green wrote:
> > > On Wed, Feb 27, 2019 at 6:33 AM Yong Wu <yong.wu@mediatek.com> wrote:
> > >>
> > >> 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.
> > >
> > > It seems like Robin had some suggestions about using
> > > mtk_iommu_add_device() rather than the attach_dev() to set the links
> > > up, and then track them for removal in the corresponding
> > > remove_device() callback. Then you wouldn't need this change, right?

Hi Evan,  sorry for reply you so late. I have not got time to try
this(Put it in the add_device), But I guess it works.
At that time the ref_cnt here should be 1, then this patch is
unnecessary.

> > >
> >
> > FYI, Evan the patch is queued for v5.1-rc1 as
> > 0fe6f7874d46 ("driver core: Remove the link if there is no driver with AUTO flag")
> >
> > So if you think there is something wrong with it, then please provide a fix or
> > raise awareness :)
> 
> Oh. Thanks for the heads-up Matthias. It's pretty weird that we have
> the kref there whose count we just completely ignore. I'll try to find
> some time to submit a patch.

Thanks very much if you improve this.

> -Evan



  reply	other threads:[~2019-03-13  9:08 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
     [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
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 [this message]
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
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

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=1552468103.7433.11.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.