All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	linux-mips <linux-mips@linux-mips.org>,
	Aurelien Jacquiot <a-jacquiot@ti.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	Jonas Bonn <jonas@southpole.se>,
	Russell King <linux@arm.linux.org.uk>,
	<linux-c6x-dev@linux-c6x.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	"arm@kernel.org" <arm@kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	Grant Likely <grant.likely@linaro.org>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	<linux-xtensa@linux-xtensa.org>,
	James Hogan <james.hogan@imgtec.com>,
	devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
	Rob Herring <rob.herring@calxeda.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Chris Zankel <chris@zankel.net>,
	Vineet Gupta <vgupta@synopsys.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] of: Specify initrd location using 64-bit
Date: Mon, 1 Jul 2013 09:58:35 -0400	[thread overview]
Message-ID: <51D18B0B.1060906@ti.com> (raw)
In-Reply-To: <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>

On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
>> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>>> Apart from waste of 32bit, what is the other concern you
>>> have ?
>>
>> You pass a u64 as a physical address which is represented in other
>> parts of the kernel (for a good reason) by phys_addr_t.
>>
>>> I really want to converge on this patch because it
>>> has been a open ended discussion for quite some time. Does
>>> that really break any thing on x86 or your concern is more
>>> from semantics of the physical address.
>> You want to have your code in so you can continue with your work, that
>> is okay. The other two arguments why u64 here is a good thing was "due
>> to what I said earlier" and "+1" and I don't have the time to look
>> that up.
>>
>> There should be no problems on x86 if this goes in as it is now.
>>
>> But think about this: What happens if you boot your ARM device without
>> PAE and your initrd is in the upper region? If you are lucky the kernel
>> looks at a different place where it also has a read permission, notices
>> nothing sane is there, writes a message and continues. And if it is not
>> allowed to read? It is clearly the user's fault for booting a non-PAE
>> kernel.
> 
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.
> 
Thanks all for comments and useful discussion. I will resubmit the
patch with update to fix the printk warnings reported by Vineet and
James post the $subject change.

Am assuming the patch will go via Grant Likely's tree.

Regards,
Santosh

WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	linux-mips <linux-mips@linux-mips.org>,
	Aurelien Jacquiot <a-jacquiot@ti.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	Jonas Bonn <jonas@southpole.se>,
	Russell King <linux@arm.linux.org.uk>,
	linux-c6x-dev@linux-c6x.org,
	the arch/x86 maintainers <x86@kernel.org>,
	"arm@kernel.org" <arm@kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	Grant Likely <grant.likely@linaro.org>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	linux-xtensa@linux-xtensa.org,
	James Hogan <james.hogan@imgtec.com>,
	devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
	Rob Herring <rob.herring@calxeda.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Chris Zankel <chris@zankel.net>,
	Vineet Gupta <vgupta@synopsys.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] of: Specify initrd location using 64-bit
Date: Mon, 1 Jul 2013 09:58:35 -0400	[thread overview]
Message-ID: <51D18B0B.1060906@ti.com> (raw)
Message-ID: <20130701135835.5Lso_A1KFoGgP3IdWChiw9VLVy_RY2-8IqZ9qbfcKAY@z> (raw)
In-Reply-To: <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>

On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
>> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>>> Apart from waste of 32bit, what is the other concern you
>>> have ?
>>
>> You pass a u64 as a physical address which is represented in other
>> parts of the kernel (for a good reason) by phys_addr_t.
>>
>>> I really want to converge on this patch because it
>>> has been a open ended discussion for quite some time. Does
>>> that really break any thing on x86 or your concern is more
>>> from semantics of the physical address.
>> You want to have your code in so you can continue with your work, that
>> is okay. The other two arguments why u64 here is a good thing was "due
>> to what I said earlier" and "+1" and I don't have the time to look
>> that up.
>>
>> There should be no problems on x86 if this goes in as it is now.
>>
>> But think about this: What happens if you boot your ARM device without
>> PAE and your initrd is in the upper region? If you are lucky the kernel
>> looks at a different place where it also has a read permission, notices
>> nothing sane is there, writes a message and continues. And if it is not
>> allowed to read? It is clearly the user's fault for booting a non-PAE
>> kernel.
> 
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.
> 
Thanks all for comments and useful discussion. I will resubmit the
patch with update to fix the printk warnings reported by Vineet and
James post the $subject change.

Am assuming the patch will go via Grant Likely's tree.

Regards,
Santosh

WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>,
	linux-mips <linux-mips@linux-mips.org>,
	Aurelien Jacquiot <a-jacquiot@ti.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Will Deacon <will.deacon@arm.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	Jonas Bonn <jonas@southpole.se>,
	Russell King <linux@arm.linux.org.uk>,
	linux-c6x-dev@linux-c6x.org,
	the arch/x86 maintainers <x86@kernel.org>,
	"arm@kernel.org" <arm@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robherring2@gmail.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	linux-xtensa@linux-xtensa.org,
	James Hogan <james.hogan@imgtec.com>,
	devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
	Rob Herring <rob.herring@calxeda.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Chris Zankel <chris@zankel.net>,
	Vineet Gupta <vgupta@synopsys.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] of: Specify initrd location using 64-bit
Date: Mon, 1 Jul 2013 09:58:35 -0400	[thread overview]
Message-ID: <51D18B0B.1060906@ti.com> (raw)
In-Reply-To: <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>

On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
>> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>>> Apart from waste of 32bit, what is the other concern you
>>> have ?
>>
>> You pass a u64 as a physical address which is represented in other
>> parts of the kernel (for a good reason) by phys_addr_t.
>>
>>> I really want to converge on this patch because it
>>> has been a open ended discussion for quite some time. Does
>>> that really break any thing on x86 or your concern is more
>>> from semantics of the physical address.
>> You want to have your code in so you can continue with your work, that
>> is okay. The other two arguments why u64 here is a good thing was "due
>> to what I said earlier" and "+1" and I don't have the time to look
>> that up.
>>
>> There should be no problems on x86 if this goes in as it is now.
>>
>> But think about this: What happens if you boot your ARM device without
>> PAE and your initrd is in the upper region? If you are lucky the kernel
>> looks at a different place where it also has a read permission, notices
>> nothing sane is there, writes a message and continues. And if it is not
>> allowed to read? It is clearly the user's fault for booting a non-PAE
>> kernel.
> 
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.
> 
Thanks all for comments and useful discussion. I will resubmit the
patch with update to fix the printk warnings reported by Vineet and
James post the $subject change.

Am assuming the patch will go via Grant Likely's tree.

Regards,
Santosh

WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] of: Specify initrd location using 64-bit
Date: Mon, 1 Jul 2013 09:58:35 -0400	[thread overview]
Message-ID: <51D18B0B.1060906@ti.com> (raw)
In-Reply-To: <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>

On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
>> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>>> Apart from waste of 32bit, what is the other concern you
>>> have ?
>>
>> You pass a u64 as a physical address which is represented in other
>> parts of the kernel (for a good reason) by phys_addr_t.
>>
>>> I really want to converge on this patch because it
>>> has been a open ended discussion for quite some time. Does
>>> that really break any thing on x86 or your concern is more
>>> from semantics of the physical address.
>> You want to have your code in so you can continue with your work, that
>> is okay. The other two arguments why u64 here is a good thing was "due
>> to what I said earlier" and "+1" and I don't have the time to look
>> that up.
>>
>> There should be no problems on x86 if this goes in as it is now.
>>
>> But think about this: What happens if you boot your ARM device without
>> PAE and your initrd is in the upper region? If you are lucky the kernel
>> looks at a different place where it also has a read permission, notices
>> nothing sane is there, writes a message and continues. And if it is not
>> allowed to read? It is clearly the user's fault for booting a non-PAE
>> kernel.
> 
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.
> 
Thanks all for comments and useful discussion. I will resubmit the
patch with update to fix the printk warnings reported by Vineet and
James post the $subject change.

Am assuming the patch will go via Grant Likely's tree.

Regards,
Santosh

WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	linux-mips <linux-mips@linux-mips.org>,
	Aurelien Jacquiot <a-jacquiot@ti.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	Jonas Bonn <jonas@southpole.se>,
	Russell King <linux@arm.linux.org.uk>,
	linux-c6x-dev@linux-c6x.org,
	the arch/x86 maintainers <x86@kernel.org>,
	"arm@kernel.org" <arm@kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	Grant Likely <grant.likely@linaro.org>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	linux-xtensa@linux-xtensa.org,
	James Hogan <james.hogan@imgtec.com>
Subject: Re: [PATCH] of: Specify initrd location using 64-bit
Date: Mon, 1 Jul 2013 09:58:35 -0400	[thread overview]
Message-ID: <51D18B0B.1060906@ti.com> (raw)
In-Reply-To: <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>

On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
>> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>>> Apart from waste of 32bit, what is the other concern you
>>> have ?
>>
>> You pass a u64 as a physical address which is represented in other
>> parts of the kernel (for a good reason) by phys_addr_t.
>>
>>> I really want to converge on this patch because it
>>> has been a open ended discussion for quite some time. Does
>>> that really break any thing on x86 or your concern is more
>>> from semantics of the physical address.
>> You want to have your code in so you can continue with your work, that
>> is okay. The other two arguments why u64 here is a good thing was "due
>> to what I said earlier" and "+1" and I don't have the time to look
>> that up.
>>
>> There should be no problems on x86 if this goes in as it is now.
>>
>> But think about this: What happens if you boot your ARM device without
>> PAE and your initrd is in the upper region? If you are lucky the kernel
>> looks at a different place where it also has a read permission, notices
>> nothing sane is there, writes a message and continues. And if it is not
>> allowed to read? It is clearly the user's fault for booting a non-PAE
>> kernel.
> 
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.
> 
Thanks all for comments and useful discussion. I will resubmit the
patch with update to fix the printk warnings reported by Vineet and
James post the $subject change.

Am assuming the patch will go via Grant Likely's tree.

Regards,
Santosh

  parent reply	other threads:[~2013-07-01 13:59 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21  0:52 [PATCH] of: Specify initrd location using 64-bit Santosh Shilimkar
2013-06-21  0:52 ` Santosh Shilimkar
2013-06-21  0:52 ` Santosh Shilimkar
2013-06-21  0:52 ` Santosh Shilimkar
2013-06-21  0:52 ` Santosh Shilimkar
2013-06-21  4:39 ` Vineet Gupta
2013-06-21  4:39   ` Vineet Gupta
2013-06-21  4:39   ` Vineet Gupta
2013-06-21  4:39   ` Vineet Gupta
2013-06-21  4:39   ` Vineet Gupta
2013-06-21  8:23   ` James Hogan
2013-06-21  8:23     ` James Hogan
2013-06-21  8:23     ` James Hogan
2013-06-21  8:23     ` James Hogan
2013-06-21  8:23     ` James Hogan
2013-06-21 17:12     ` Santosh Shilimkar
2013-06-21 17:12       ` Santosh Shilimkar
2013-06-21 17:12       ` Santosh Shilimkar
2013-06-21 17:12       ` Santosh Shilimkar
2013-06-21 17:12       ` Santosh Shilimkar
2013-06-21  9:04 ` Sebastian Andrzej Siewior
2013-06-21  9:04   ` Sebastian Andrzej Siewior
2013-06-21  9:04   ` Sebastian Andrzej Siewior
2013-06-21  9:04   ` Sebastian Andrzej Siewior
2013-06-21 17:20   ` Santosh Shilimkar
2013-06-21 17:20     ` Santosh Shilimkar
2013-06-21 17:20     ` Santosh Shilimkar
2013-06-21 17:20     ` Santosh Shilimkar
2013-06-21 17:20     ` Santosh Shilimkar
2013-06-27 20:54     ` Rob Herring
2013-06-27 20:54       ` Rob Herring
2013-06-27 20:54       ` Rob Herring
2013-06-27 20:54       ` Rob Herring
2013-06-28  7:54       ` Sebastian Andrzej Siewior
2013-06-28  7:54         ` Sebastian Andrzej Siewior
2013-06-28  7:54         ` Sebastian Andrzej Siewior
2013-06-28  7:54         ` Sebastian Andrzej Siewior
2013-06-28  9:59       ` Grant Likely
2013-06-28  9:59         ` Grant Likely
2013-06-28  9:59         ` Grant Likely
2013-06-28  9:59         ` Grant Likely
2013-06-28 13:49         ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-28 13:49           ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-28 13:49           ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-28 13:49           ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-28 23:43           ` Santosh Shilimkar
2013-06-28 23:43             ` Santosh Shilimkar
2013-06-28 23:43             ` Santosh Shilimkar
2013-06-28 23:43             ` Santosh Shilimkar
2013-06-28 23:43             ` Santosh Shilimkar
2013-06-29  8:34             ` Geert Uytterhoeven
2013-06-29  8:34               ` Geert Uytterhoeven
2013-06-29  8:34               ` Geert Uytterhoeven
2013-06-29  8:34               ` Geert Uytterhoeven
2013-07-01  7:48             ` Sebastian Andrzej Siewior
2013-07-01  7:48               ` Sebastian Andrzej Siewior
2013-07-01  7:48               ` Sebastian Andrzej Siewior
2013-07-01  7:48               ` Sebastian Andrzej Siewior
2013-07-01  7:59               ` Geert Uytterhoeven
2013-07-01  7:59                 ` Geert Uytterhoeven
2013-07-01  7:59                 ` Geert Uytterhoeven
2013-07-01  7:59                 ` Geert Uytterhoeven
2013-07-01  8:09                 ` Sebastian Andrzej Siewior
2013-07-01  8:09                   ` Sebastian Andrzej Siewior
2013-07-01  8:09                   ` Sebastian Andrzej Siewior
2013-07-01  8:09                   ` Sebastian Andrzej Siewior
2013-07-01 13:58                 ` Santosh Shilimkar [this message]
2013-07-01 13:58                   ` Santosh Shilimkar
2013-07-01 13:58                   ` Santosh Shilimkar
2013-07-01 13:58                   ` Santosh Shilimkar
2013-07-01 13:58                   ` Santosh Shilimkar
  -- strict thread matches above, loose matches on Subject: below --
2012-09-12 16:05 [PATCH] of: specify " Cyril Chemparathy
2012-09-12 16:05 ` Cyril Chemparathy
2012-09-12 16:05 ` Cyril Chemparathy
2012-09-12 16:05 ` Cyril Chemparathy
2012-09-12 16:16 ` Geert Uytterhoeven
2012-09-12 16:16   ` Geert Uytterhoeven
2012-09-12 16:16   ` Geert Uytterhoeven
2012-09-12 18:02   ` Cyril Chemparathy
2012-09-12 18:02     ` Cyril Chemparathy
2012-09-12 18:02     ` Cyril Chemparathy
2012-09-12 18:02     ` Cyril Chemparathy
2012-09-12 18:02     ` Cyril Chemparathy
2012-09-12 19:58     ` Sebastian Andrzej Siewior
2012-09-12 19:58       ` Sebastian Andrzej Siewior
2012-09-12 19:58       ` Sebastian Andrzej Siewior
2012-09-12 22:08       ` Rob Herring
2012-09-12 22:08         ` Rob Herring
2012-09-12 22:08         ` Rob Herring
2012-09-13  6:47         ` Sebastian Andrzej Siewior
2012-09-13  6:47           ` Sebastian Andrzej Siewior
2012-09-13  6:47           ` Sebastian Andrzej Siewior
2012-09-13 21:02           ` Rob Herring
2012-09-13 21:02             ` Rob Herring
2012-09-13 21:02             ` Rob Herring
2012-09-12 20:23 ` Rob Herring
2012-09-12 20:23   ` Rob Herring
2012-09-12 20:23   ` Rob Herring
2012-09-12 20:31   ` Nicolas Pitre
2012-09-12 20:31     ` Nicolas Pitre
2012-09-12 20:31     ` Nicolas Pitre
2012-09-12 20:56     ` Rob Herring
2012-09-12 20:56       ` Rob Herring
2012-09-12 20:56       ` Rob Herring
2012-09-12 20:56       ` Rob Herring
2012-09-12 23:45   ` Cyril Chemparathy
2012-09-12 23:45     ` Cyril Chemparathy
2012-09-12 23:45     ` Cyril Chemparathy
2012-09-12 23:45     ` Cyril Chemparathy
2012-09-12 23:45     ` Cyril Chemparathy

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=51D18B0B.1060906@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=a-jacquiot@ti.com \
    --cc=arm@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=chris@zankel.net \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=geert@linux-m68k.org \
    --cc=grant.likely@linaro.org \
    --cc=james.hogan@imgtec.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=jonas@southpole.se \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-c6x-dev@linux-c6x.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linux@arm.linux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=paulus@samba.org \
    --cc=plagnioj@jcrosoft.com \
    --cc=ralf@linux-mips.org \
    --cc=rob.herring@calxeda.com \
    --cc=robherring2@gmail.com \
    --cc=vgupta@synopsys.com \
    --cc=will.deacon@arm.com \
    --cc=x86@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.