All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yong Wu <yong.wu@mediatek.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Robin Murphy <Robin.Murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>,
	Thierry Reding <treding@nvidia.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Daniel Kurtz <djkurtz@google.com>, Tomasz Figa <tfiga@google.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Rob Herring <robh+dt@kernel.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"linux-mediatek@lists.infradead.org" 
	<linux-mediatek@lists.infradead.org>,
	Sasha Hauer <kernel@pengutronix.de>,
	"srv_heupstream@mediatek.com" <srv_heupstream@mediatek.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"pebolle@tiscali.nl" <pebolle@tiscali.nl>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"mitchelh@codeaurora.org" <mitchelh@codeaurora.org>,
	"cloud.chou@mediatek.com" <cloud.chou@mediatek.com>,
	"frederic.chen@mediatek.com" <frederic.chen@mediatek.com>
Subject: Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
Date: Tue, 28 Jul 2015 21:37:43 +0800	[thread overview]
Message-ID: <1438090663.25925.75.camel@mhfsdcap03> (raw)
In-Reply-To: <20150728110023.GH29209@arm.com>

On Tue, 2015-07-28 at 12:00 +0100, Will Deacon wrote:
> On Tue, Jul 28, 2015 at 06:08:14AM +0100, Yong Wu wrote:
> > On Mon, 2015-07-27 at 15:11 +0100, Will Deacon wrote:
> > > On Mon, Jul 27, 2015 at 03:05:38PM +0100, Robin Murphy wrote:
> > > > On 27/07/15 05:21, Yong Wu wrote:
> > > > >>>>> +       } else {        /* page or largepage */
> > > > >>>>> +               if (quirk & IO_PGTABLE_QUIRK_SHORT_MTK) {
> > > > >>>>> +                       if (large) { /* special Bit */
> > > > >>>>
> > > > >>>> This definitely needs a better comment! What exactly are you doing here
> > > > >>>> and what is that quirk all about?
> > > > >>>
> > > > >>> I use this quirk is for MTK Special Bit as we don't have the XN bit in
> > > > >>> pagetable.
> > > > >>
> > > > >> I'm still not really clear about what this is.
> > > > >
> > > > > There is some difference between the standard spec and MTK HW,
> > > > > Our hw don't implement some bits, like XN and AP.
> > > > > So I add a quirk for MTK special.
> > > > 
> > > > When you say it doesn't implement these bits, do you mean that having 
> > > > them set will lead to Bad Things happening in the hardware, or that it 
> > > > will simply ignore them and not enforce any of the protections they 
> > > > imply? The former case would definitely want clearly documenting 
> > > > somewhere, whereas for the latter case I'm not sure it's even worth the 
> > > > complication of having a quirk - if the value doesn't matter there seems 
> > > > little point in doing a special dance just for the sake of semantic 
> > > > correctness of the in-memory PTEs, in my opinion.
> > > 
> > > Agreed. We should only use quirks if the current (architecturally
> > > compliant) code causes real issues with the hardware. Then the quirk can
> > > be used to either avoid the problematic routines or to take extra steps
> > > to make things work as the architecture intended.
> > > 
> > > I've asked how this IOMMU differs from the architecture on a number of
> > > occasions, but I'm still yet to receive a response other than "it's special".
> > > 
> > 
> > After check further with DE, Our pagetable is refer to ARM-v7's
> > short-descriptor which is a little different from ARM-v8. like bit0(PXN)
> > in section and supersection, I didn't read ARM-v7 spec before, so I add
> > a MTK quirk to disable PXN bit in section and supersection.(if the PXN
> > bit is wrote in ARM-v7 spec, HW will page fault.)
> 
> I've been reviewing this using the ARMv7 ARM (Rev.C of DDI0406C) the whole
> time. PXN is there as an optional field in non-LPAE implementations. That's
> fine and doesn't require any quirks.

Thanks for your confirm.
Then I delete all the PXN bit in here?

Take a example, 
#define ARM_SHORT_PGD_SECTION_XN		(BIT(0) | BIT(4))
I will change it to "BIT(4)".

> 
> > Then I write this code according to ARM-v8 spec defaultly, and add a
> > ARM-v7 quirk?
> 
> No, I don't think you need this, as the v8 and v7 short-descriptor formats
> look compatible to me. You should only need a quirk if architecturally
> compliant code cannot work on your hardware.
> 
> > And there is a little different between ARM-v7 spec and MTK pagetable.
> > It's the XN(bit0) in small page. MTK don't implement XN bit. 
> > The bit[1:0] in MTK's small page should be 2'b10, if it's 2'b11, HW will
> > page fault.
> 
> Aha, thanks! *That* is worthy of a quirk. Something like:
> 
>   IO_PGTABLE_QUIRK_ARM_NO_XN

Thanks, I will add it.

> 
> > (MTK don't implement AP bits too, but HW don't use them, it is ok even
> > though AP bits is wrote)
> 
> Yeah, I think that's fine. The pgtable code will honour the request but
> the h/w will ignore it.
> 
> > In the end, I will add two quirk like this, is it OK?
> 
> I think you only need the one I mentioned above. I don't see the need
> for PXN at all (as I said in the last review).
> 
> Will



WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
	Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
	"cloud.chou-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org"
	<cloud.chou-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	"frederic.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org"
	<frederic.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"arnd-r2nGTMty4D4@public.gmane.org"
	<arnd-r2nGTMty4D4@public.gmane.org>,
	Tomasz Figa <tfiga-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Matthias Brugger
	<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org"
	<pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org>,
	Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org"
	<srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Daniel Kurtz <djkurtz-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Sasha Hauer <kernel@pen>
Subject: Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
Date: Tue, 28 Jul 2015 21:37:43 +0800	[thread overview]
Message-ID: <1438090663.25925.75.camel@mhfsdcap03> (raw)
In-Reply-To: <20150728110023.GH29209-5wv7dgnIgG8@public.gmane.org>

On Tue, 2015-07-28 at 12:00 +0100, Will Deacon wrote:
> On Tue, Jul 28, 2015 at 06:08:14AM +0100, Yong Wu wrote:
> > On Mon, 2015-07-27 at 15:11 +0100, Will Deacon wrote:
> > > On Mon, Jul 27, 2015 at 03:05:38PM +0100, Robin Murphy wrote:
> > > > On 27/07/15 05:21, Yong Wu wrote:
> > > > >>>>> +       } else {        /* page or largepage */
> > > > >>>>> +               if (quirk & IO_PGTABLE_QUIRK_SHORT_MTK) {
> > > > >>>>> +                       if (large) { /* special Bit */
> > > > >>>>
> > > > >>>> This definitely needs a better comment! What exactly are you doing here
> > > > >>>> and what is that quirk all about?
> > > > >>>
> > > > >>> I use this quirk is for MTK Special Bit as we don't have the XN bit in
> > > > >>> pagetable.
> > > > >>
> > > > >> I'm still not really clear about what this is.
> > > > >
> > > > > There is some difference between the standard spec and MTK HW,
> > > > > Our hw don't implement some bits, like XN and AP.
> > > > > So I add a quirk for MTK special.
> > > > 
> > > > When you say it doesn't implement these bits, do you mean that having 
> > > > them set will lead to Bad Things happening in the hardware, or that it 
> > > > will simply ignore them and not enforce any of the protections they 
> > > > imply? The former case would definitely want clearly documenting 
> > > > somewhere, whereas for the latter case I'm not sure it's even worth the 
> > > > complication of having a quirk - if the value doesn't matter there seems 
> > > > little point in doing a special dance just for the sake of semantic 
> > > > correctness of the in-memory PTEs, in my opinion.
> > > 
> > > Agreed. We should only use quirks if the current (architecturally
> > > compliant) code causes real issues with the hardware. Then the quirk can
> > > be used to either avoid the problematic routines or to take extra steps
> > > to make things work as the architecture intended.
> > > 
> > > I've asked how this IOMMU differs from the architecture on a number of
> > > occasions, but I'm still yet to receive a response other than "it's special".
> > > 
> > 
> > After check further with DE, Our pagetable is refer to ARM-v7's
> > short-descriptor which is a little different from ARM-v8. like bit0(PXN)
> > in section and supersection, I didn't read ARM-v7 spec before, so I add
> > a MTK quirk to disable PXN bit in section and supersection.(if the PXN
> > bit is wrote in ARM-v7 spec, HW will page fault.)
> 
> I've been reviewing this using the ARMv7 ARM (Rev.C of DDI0406C) the whole
> time. PXN is there as an optional field in non-LPAE implementations. That's
> fine and doesn't require any quirks.

Thanks for your confirm.
Then I delete all the PXN bit in here?

Take a example, 
#define ARM_SHORT_PGD_SECTION_XN		(BIT(0) | BIT(4))
I will change it to "BIT(4)".

> 
> > Then I write this code according to ARM-v8 spec defaultly, and add a
> > ARM-v7 quirk?
> 
> No, I don't think you need this, as the v8 and v7 short-descriptor formats
> look compatible to me. You should only need a quirk if architecturally
> compliant code cannot work on your hardware.
> 
> > And there is a little different between ARM-v7 spec and MTK pagetable.
> > It's the XN(bit0) in small page. MTK don't implement XN bit. 
> > The bit[1:0] in MTK's small page should be 2'b10, if it's 2'b11, HW will
> > page fault.
> 
> Aha, thanks! *That* is worthy of a quirk. Something like:
> 
>   IO_PGTABLE_QUIRK_ARM_NO_XN

Thanks, I will add it.

> 
> > (MTK don't implement AP bits too, but HW don't use them, it is ok even
> > though AP bits is wrote)
> 
> Yeah, I think that's fine. The pgtable code will honour the request but
> the h/w will ignore it.
> 
> > In the end, I will add two quirk like this, is it OK?
> 
> I think you only need the one I mentioned above. I don't see the need
> for PXN at all (as I said in the last review).
> 
> Will

WARNING: multiple messages have this Message-ID (diff)
From: yong.wu@mediatek.com (Yong Wu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
Date: Tue, 28 Jul 2015 21:37:43 +0800	[thread overview]
Message-ID: <1438090663.25925.75.camel@mhfsdcap03> (raw)
In-Reply-To: <20150728110023.GH29209@arm.com>

On Tue, 2015-07-28 at 12:00 +0100, Will Deacon wrote:
> On Tue, Jul 28, 2015 at 06:08:14AM +0100, Yong Wu wrote:
> > On Mon, 2015-07-27 at 15:11 +0100, Will Deacon wrote:
> > > On Mon, Jul 27, 2015 at 03:05:38PM +0100, Robin Murphy wrote:
> > > > On 27/07/15 05:21, Yong Wu wrote:
> > > > >>>>> +       } else {        /* page or largepage */
> > > > >>>>> +               if (quirk & IO_PGTABLE_QUIRK_SHORT_MTK) {
> > > > >>>>> +                       if (large) { /* special Bit */
> > > > >>>>
> > > > >>>> This definitely needs a better comment! What exactly are you doing here
> > > > >>>> and what is that quirk all about?
> > > > >>>
> > > > >>> I use this quirk is for MTK Special Bit as we don't have the XN bit in
> > > > >>> pagetable.
> > > > >>
> > > > >> I'm still not really clear about what this is.
> > > > >
> > > > > There is some difference between the standard spec and MTK HW,
> > > > > Our hw don't implement some bits, like XN and AP.
> > > > > So I add a quirk for MTK special.
> > > > 
> > > > When you say it doesn't implement these bits, do you mean that having 
> > > > them set will lead to Bad Things happening in the hardware, or that it 
> > > > will simply ignore them and not enforce any of the protections they 
> > > > imply? The former case would definitely want clearly documenting 
> > > > somewhere, whereas for the latter case I'm not sure it's even worth the 
> > > > complication of having a quirk - if the value doesn't matter there seems 
> > > > little point in doing a special dance just for the sake of semantic 
> > > > correctness of the in-memory PTEs, in my opinion.
> > > 
> > > Agreed. We should only use quirks if the current (architecturally
> > > compliant) code causes real issues with the hardware. Then the quirk can
> > > be used to either avoid the problematic routines or to take extra steps
> > > to make things work as the architecture intended.
> > > 
> > > I've asked how this IOMMU differs from the architecture on a number of
> > > occasions, but I'm still yet to receive a response other than "it's special".
> > > 
> > 
> > After check further with DE, Our pagetable is refer to ARM-v7's
> > short-descriptor which is a little different from ARM-v8. like bit0(PXN)
> > in section and supersection, I didn't read ARM-v7 spec before, so I add
> > a MTK quirk to disable PXN bit in section and supersection.(if the PXN
> > bit is wrote in ARM-v7 spec, HW will page fault.)
> 
> I've been reviewing this using the ARMv7 ARM (Rev.C of DDI0406C) the whole
> time. PXN is there as an optional field in non-LPAE implementations. That's
> fine and doesn't require any quirks.

Thanks for your confirm.
Then I delete all the PXN bit in here?

Take a example, 
#define ARM_SHORT_PGD_SECTION_XN		(BIT(0) | BIT(4))
I will change it to "BIT(4)".

> 
> > Then I write this code according to ARM-v8 spec defaultly, and add a
> > ARM-v7 quirk?
> 
> No, I don't think you need this, as the v8 and v7 short-descriptor formats
> look compatible to me. You should only need a quirk if architecturally
> compliant code cannot work on your hardware.
> 
> > And there is a little different between ARM-v7 spec and MTK pagetable.
> > It's the XN(bit0) in small page. MTK don't implement XN bit. 
> > The bit[1:0] in MTK's small page should be 2'b10, if it's 2'b11, HW will
> > page fault.
> 
> Aha, thanks! *That* is worthy of a quirk. Something like:
> 
>   IO_PGTABLE_QUIRK_ARM_NO_XN

Thanks, I will add it.

> 
> > (MTK don't implement AP bits too, but HW don't use them, it is ok even
> > though AP bits is wrote)
> 
> Yeah, I think that's fine. The pgtable code will honour the request but
> the h/w will ignore it.
> 
> > In the end, I will add two quirk like this, is it OK?
> 
> I think you only need the one I mentioned above. I don't see the need
> for PXN at all (as I said in the last review).
> 
> Will

  reply	other threads:[~2015-07-28 13:37 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-16  9:04 [PATCH v3 0/6] MT8173 IOMMU SUPPORT Yong Wu
2015-07-16  9:04 ` Yong Wu
2015-07-16  9:04 ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 1/6] dt-bindings: iommu: Add binding for mediatek IOMMU Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 2/6] dt-bindings: mediatek: Add smi dts binding Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-21 17:11   ` Will Deacon
2015-07-21 17:11     ` Will Deacon
2015-07-21 17:11     ` Will Deacon
2015-07-24  5:24     ` Yong Wu
2015-07-24  5:24       ` Yong Wu
2015-07-24  5:24       ` Yong Wu
2015-07-24 16:53       ` Will Deacon
2015-07-24 16:53         ` Will Deacon
2015-07-24 16:53         ` Will Deacon
2015-07-27  4:21         ` Yong Wu
2015-07-27  4:21           ` Yong Wu
2015-07-27  4:21           ` Yong Wu
2015-07-27 14:05           ` Robin Murphy
2015-07-27 14:05             ` Robin Murphy
2015-07-27 14:05             ` Robin Murphy
2015-07-27 14:11             ` Will Deacon
2015-07-27 14:11               ` Will Deacon
2015-07-27 14:11               ` Will Deacon
2015-07-28  5:08               ` Yong Wu
2015-07-28  5:08                 ` Yong Wu
2015-07-28  5:08                 ` Yong Wu
2015-07-28 11:00                 ` Will Deacon
2015-07-28 11:00                   ` Will Deacon
2015-07-28 11:00                   ` Will Deacon
2015-07-28 13:37                   ` Yong Wu [this message]
2015-07-28 13:37                     ` Yong Wu
2015-07-28 13:37                     ` Yong Wu
2015-07-28 13:47                     ` Will Deacon
2015-07-28 13:47                       ` Will Deacon
2015-07-28 13:47                       ` Will Deacon
2015-07-31  7:55           ` Yong Wu
2015-07-31 11:32             ` Will Deacon
2015-07-31 11:32               ` Will Deacon
2015-07-31 11:32               ` Will Deacon
2015-09-14 12:25     ` Yong Wu
2015-09-14 12:25       ` Yong Wu
2015-09-14 12:25       ` Yong Wu
2015-09-16 12:55       ` Will Deacon
2015-09-16 12:55         ` Will Deacon
2015-09-16 12:55         ` Will Deacon
2015-09-17  2:38         ` Yong Wu
2015-09-17  2:38           ` Yong Wu
2015-09-17  2:38           ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 4/6] memory: mediatek: Add SMI driver Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-21 14:59   ` Will Deacon
2015-07-21 14:59     ` Will Deacon
2015-07-21 14:59     ` Will Deacon
2015-07-24  5:43     ` Yong Wu
2015-07-24  5:43       ` Yong Wu
2015-07-24  5:43       ` Yong Wu
2015-07-24 16:55       ` Will Deacon
2015-07-24 16:55         ` Will Deacon
2015-07-24 16:55         ` Will Deacon
2015-07-27  4:24         ` Yong Wu
2015-07-27  4:24           ` Yong Wu
2015-07-27  4:24           ` Yong Wu
2015-07-27 15:48           ` Will Deacon
2015-07-27 15:48             ` Will Deacon
2015-07-27 15:48             ` Will Deacon
2015-07-27 13:23   ` Robin Murphy
2015-07-27 13:23     ` Robin Murphy
2015-07-27 13:23     ` Robin Murphy
2015-07-27 15:31     ` Russell King - ARM Linux
2015-07-27 15:31       ` Russell King - ARM Linux
2015-07-27 15:31       ` Russell King - ARM Linux
2015-07-27 15:49       ` Robin Murphy
2015-07-27 15:49         ` Robin Murphy
2015-07-27 15:49         ` Robin Murphy
2015-07-29  5:41         ` Yong Wu
2015-07-29  5:41           ` Yong Wu
2015-07-29  5:41           ` Yong Wu
2015-07-29 10:31           ` Will Deacon
2015-07-29 10:31             ` Will Deacon
2015-07-29 10:31             ` Will Deacon
2015-07-29  6:32     ` Yong Wu
2015-07-29  6:32       ` Yong Wu
2015-07-29  6:32       ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 6/6] dts: mt8173: Add iommu/smi nodes for mt8173 Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-23 14:40   ` Daniel Kurtz
2015-07-23 14:40     ` Daniel Kurtz
2015-07-23 14:40     ` Daniel Kurtz
2015-07-29  7:29     ` Yong Wu
2015-07-29  7:29       ` Yong Wu
2015-07-29  7:29       ` Yong Wu

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=1438090663.25925.75.camel@mhfsdcap03 \
    --to=yong.wu@mediatek.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Robin.Murphy@arm.com \
    --cc=arnd@arndb.de \
    --cc=cloud.chou@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=djkurtz@google.com \
    --cc=frederic.chen@mediatek.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --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=mitchelh@codeaurora.org \
    --cc=pebolle@tiscali.nl \
    --cc=robh+dt@kernel.org \
    --cc=srv_heupstream@mediatek.com \
    --cc=tfiga@google.com \
    --cc=treding@nvidia.com \
    --cc=will.deacon@arm.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.