Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Cc: "linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"ysato@users.sourceforge.jp" <ysato@users.sourceforge.jp>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"jesper.nilsson@axis.com" <jesper.nilsson@axis.com>,
	"mulix@mulix.org" <mulix@mulix.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"uclinux-h8-devel@lists.sourceforge.jp" 
	<uclinux-h8-devel@lists.sourceforge.jp>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"geoff@infradead.org" <geoff@infradead.org>,
	"jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-c6x-dev@linux-c6x.org" <linux-c6x-dev@linux-c6x.org>,
	"linux-am33-list@redhat.com" <linux-am33-list@redhat.com>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-cris-kernel@axis.com" <linux-cris-kernel@axis.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"a-jacquiot@ti.com" <a-jacquiot@ti.com>,
	"dalias@libc.org" <dalias@libc.org>,
	"linux-metag@vger.kernel.org" <linux-metag@vger.kernel.org>,
	"nios2-dev@lists.rocketboards.org"
	<nios2-dev@lists.rocketboards.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"shorne@gmail.com" <shorne@gmail.com>,
	"lftan@altera.com" <lftan@altera.com>,
	"deller@gmx.de" <deller@gmx.de>,
	"jdmason@kudzu.us" <jdmason@kudzu.us>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"chris@zankel.net" <chris@zankel.net>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"fenghua.yu@intel.com" <fenghua.yu@intel.com>,
	"jejb@parisc-linux.org" <jejb@parisc-linux.org>,
	"linux-snps-arc@lists.infradead.org" 
	<linux-snps-arc@lists.infradead.org>,
	"msalter@redhat.com" <msalter@redhat.com>,
	"dledford@redhat.com" <dledford@redhat.com>,
	"adi-buildroot-devel@lists.sourceforge.net" 
	<adi-buildroot-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"starvik@axis.com" <starvik@axis.com>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"hskinnemoen@gmail.com" <hskinnemoen@gmail.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"stefan.kristiansson@saunalahti.fi" 
	<stefan.kristiansson@saunalahti.fi>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jonas@southpole.se" <jonas@southpole.se>,
	"geert@linux-m68k.org" <geert@linux-m68k.org>,
	"egtvedt@samfundet.no" <egtvedt@samfundet.no>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>
Subject: Re: [PATCH 2/9] Move dma_ops from archdata into struct device
Date: Wed, 11 Jan 2017 18:17:03 +0000	[thread overview]
Message-ID: <1484158589.2619.14.camel@sandisk.com> (raw)
In-Reply-To: <20170111064803.GB26893@kroah.com>

On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > transfer data between memory and PCIe adapter. Because of performance
> > reasons it is important that the CPU cache is not flushed when such
> > drivers transfer data. Make this possible by allowing these drivers to
> > override the dma_map_ops pointer. Additionally, introduce the function
> > set_dma_ops() that will be used by a later patch in this series.
> 
> When you say things like "additionally", that's a huge flag that this
> needs to be split up into multiple patches.  No need to add
> set_dma_ops() here in this patch.

Hello Greg,

Some architectures already define a set_dma_ops() function. So what this
patch does is to move both the dma_ops pointer and the set_dma_ops()
function from architecture-specific to architecture independent code. I
don't think that it is possible to separate these two changes. But I
understand that how I formulated the patch description caused confusion. I
will rewrite the patch description to make it more clear before I repost
this patch series.

> And I'd argue that it should be dma_ops_set(), and dma_ops_get(), just
> to keep the namespace sane, but that's probably a different set of
> patches...

Every time I rebase and retest this patch series on top of a new kernel
version I have to modify some of the patches to compensate for changes in
the architecture code. So I expect that once Linus merges these patches that
he will have to resolve one or more merge conflicts. Including a rename of
the functions that query and set the dma_ops pointer in this patch series
would increase the number of merge conflicts triggered by this patch series
and would make Linus' job harder. So I hope that you will allow me to
postpone that rename until a later time ...

Bart.
From justinpopo6@gmail.com Wed Jan 11 20:44:53 2017
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Jan 2017 20:45:00 +0100 (CET)
Received: from lpdvsmtp01.broadcom.com ([192.19.211.62]:41172 "EHLO
        relay.smtp.broadcom.com" rhost-flags-OK-OK-OK-OK)
        by eddie.linux-mips.org with ESMTP id S23993908AbdAKToxPNcNY (ORCPT
        <rfc822;linux-mips@linux-mips.org>); Wed, 11 Jan 2017 20:44:53 +0100
Received: from mail-irv-17.broadcom.com (mail-irv-17.broadcom.com [10.15.198.34])
        by relay.smtp.broadcom.com (Postfix) with ESMTP id 04C9E2802D1;
        Wed, 11 Jan 2017 11:44:50 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.10.3 relay.smtp.broadcom.com 04C9E2802D1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=broadcom.com;
        s=dkimrelay; t=1484163890;
        bh=5WUogODucyNiaQB2A0nAyqk1OMr/MUjr0qN8UEvKlTU=;
        h=From:To:Cc:Subject:Date:From;
        b=fBu+HL6NSCJ1V1RmDebC9dqf9R/PbLAa8R1U4AXV0uBEWthw+a3OnfgBYN2D3Rlmu
         v/ZjYWHKpBQPzEydljfwh6JsWca92Ap/r5bI3vT2cN92u75C1hKjrhkUt+ZQG/xk37
         yqai1ez63Kr6o0GHf+HpMYEuOGgKUjco7dDZa/wc=
Received: from stb-bld-02.irv.broadcom.com (stb-bld-02.broadcom.com [10.13.134.28])
        by mail-irv-17.broadcom.com (Postfix) with ESMTP id 6DAA281F52;
        Wed, 11 Jan 2017 11:44:49 -0800 (PST)
From:   justinpopo6@gmail.com
To:     linux-mips@linux-mips.org
Cc:     bcm-kernel-feedback-list@broadcom.com, leonid.yegoshin@imgtec.com,
        f.fainelli@gmail.com, Justin Chen <justin.chen@broadcom.com>
Subject: [PATCH] MIPS: Add cacheinfo support
Date:   Wed, 11 Jan 2017 11:44:32 -0800
Message-Id: <20170111194432.24283-1-justinpopo6@gmail.com>
X-Mailer: git-send-email 2.11.0
Return-Path: <justinpopo6@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 56274
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: justinpopo6@gmail.com
Precedence: bulk
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
List-software: Ecartis version 1.0.0
List-Id: linux-mips <linux-mips.eddie.linux-mips.org>
X-List-ID: linux-mips <linux-mips.eddie.linux-mips.org>
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
X-list: linux-mips
Content-Length: 3766
Lines: 124

From: Justin Chen <justin.chen@broadcom.com>

Add cacheinfo support for MIPS architectures.

Use information from the cpuinfo_mips struct to populate the
cacheinfo struct. This allows an architecture agnostic approach,
however this also means if cache information is not properly
populated within the cpuinfo_mips struct, there is nothing
we can do. (I.E. c-r3k.c)

Signed-off-by: Justin Chen <justin.chen@broadcom.com>
---
 arch/mips/kernel/Makefile    |  2 +-
 arch/mips/kernel/cacheinfo.c | 85 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/kernel/cacheinfo.c

diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index 4a603a3..904a9c4 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -7,7 +7,7 @@ extra-y		:= head.o vmlinux.lds
 obj-y		+= cpu-probe.o branch.o elf.o entry.o genex.o idle.o irq.o \
 		   process.o prom.o ptrace.o reset.o setup.o signal.o \
 		   syscall.o time.o topology.o traps.o unaligned.o watch.o \
-		   vdso.o
+		   vdso.o cacheinfo.o
 
 ifdef CONFIG_FUNCTION_TRACER
 CFLAGS_REMOVE_ftrace.o = -pg
diff --git a/arch/mips/kernel/cacheinfo.c b/arch/mips/kernel/cacheinfo.c
new file mode 100644
index 0000000..a92bbba
--- /dev/null
+++ b/arch/mips/kernel/cacheinfo.c
@@ -0,0 +1,85 @@
+/*
+ * MIPS cacheinfo support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#include <linux/cacheinfo.h>
+
+/* Populates leaf and increments to next leaf */
+#define populate_cache(cache, leaf, c_level, c_type)		\
+	leaf->type = c_type;					\
+	leaf->level = c_level;					\
+	leaf->coherency_line_size = c->cache.linesz;		\
+	leaf->number_of_sets = c->cache.sets;			\
+	leaf->ways_of_associativity = c->cache.ways;		\
+	leaf->size = c->cache.linesz * c->cache.sets *		\
+		c->cache.ways;					\
+	leaf++;
+
+static int __init_cache_level(unsigned int cpu)
+{
+	struct cpuinfo_mips *c = &current_cpu_data;
+	struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+	int levels = 0, leaves = 0;
+
+	/*
+	 * If Dcache is not set, we assume the cache structures
+	 * are not properly initialized.
+	 */
+	if (c->dcache.waysize)
+		levels += 1;
+	else
+		return -ENOENT;
+
+
+	leaves += (c->icache.waysize) ? 2 : 1;
+
+	if (c->scache.waysize) {
+		levels++;
+		leaves++;
+	}
+
+	if (c->tcache.waysize) {
+		levels++;
+		leaves++;
+	}
+
+	this_cpu_ci->num_levels = levels;
+	this_cpu_ci->num_leaves = leaves;
+	return 0;
+}
+
+static int __populate_cache_leaves(unsigned int cpu)
+{
+	struct cpuinfo_mips *c = &current_cpu_data;
+	struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+	struct cacheinfo *this_leaf = this_cpu_ci->info_list;
+
+	if (c->icache.waysize) {
+		populate_cache(dcache, this_leaf, 1, CACHE_TYPE_DATA);
+		populate_cache(icache, this_leaf, 1, CACHE_TYPE_INST);
+	} else {
+		populate_cache(dcache, this_leaf, 1, CACHE_TYPE_UNIFIED);
+	}
+
+	if (c->scache.waysize)
+		populate_cache(scache, this_leaf, 2, CACHE_TYPE_UNIFIED);
+
+	if (c->tcache.waysize)
+		populate_cache(tcache, this_leaf, 3, CACHE_TYPE_UNIFIED);
+
+	return 0;
+}
+
+DEFINE_SMP_CALL_CACHE_FUNCTION(init_cache_level)
+DEFINE_SMP_CALL_CACHE_FUNCTION(populate_cache_leaves)
-- 
2.10.2

WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Cc: "linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"ysato@users.sourceforge.jp" <ysato@users.sourceforge.jp>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"jesper.nilsson@axis.com" <jesper.nilsson@axis.com>,
	"mulix@mulix.org" <mulix@mulix.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"uclinux-h8-devel@lists.sourceforge.jp"
	<uclinux-h8-devel@lists.sourceforge.jp>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"geoff@infradead.org" <geoff@infradead.org>,
	"jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-c6x-dev@linux-c6x.org" <linux-c6x-dev@linux-c6x.org>,
	"linux-am33-list@redhat.com" <linux-am33-list@redhat.com>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-cris-kernel@axis.com" <linux-cris-kernel@axis.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"a-jacquiot@ti.com" <a-jacquiot@ti.com>,
	"dalias@libc.org" <dalias@libc.org>,
	"linux-metag@vger.kernel.org" <linux-metag@vger.kernel.org>,
	"nios2-dev@lists.rocketboards.org"
	<nios2-dev@lists.rocketboards.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"shorne@gmail.com" <shorne@gmail.com>,
	"lftan@altera.com" <lftan@altera.com>,
	"deller@gmx.de" <deller@gmx.de>,
	"jdmason@kudzu.us" <jdmason@kudzu.us>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"chris@zankel.net" <chris@zankel.net>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"fenghua.yu@intel.com" <fenghua.yu@intel.com>,
	"jejb@parisc-linux.org" <jejb@parisc-linux.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"msalter@redhat.com" <msalter@redhat.com>,
	"dledford@redhat.com" <dledford@redhat.com>,
	"adi-buildroot-devel@lists.sourceforge.net"
	<adi-buildroot-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"starvik@axis.com" <starvik@axis.com>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"hskinnemoen@gmail.com" <hskinnemoen@gmail.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"stefan.kristiansson@saunalahti.fi"
	<stefan.kristiansson@saunalahti.fi>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jonas@southpole.se" <jonas@southpole.se>,
	"geert@linux-m68k.org" <geert@linux-m68k.org>,
	"egtvedt@samfundet.no" <egtvedt@samfundet.no>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>
Subject: Re: [PATCH 2/9] Move dma_ops from archdata into struct device
Date: Wed, 11 Jan 2017 18:17:03 +0000	[thread overview]
Message-ID: <1484158589.2619.14.camel@sandisk.com> (raw)
Message-ID: <20170111181703.pW6Ng4bymz7RvDQJX2eF9RRdSYxt_JB9KzSZc2jKNjk@z> (raw)
In-Reply-To: <20170111064803.GB26893@kroah.com>

On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > transfer data between memory and PCIe adapter. Because of performance
> > reasons it is important that the CPU cache is not flushed when such
> > drivers transfer data. Make this possible by allowing these drivers to
> > override the dma_map_ops pointer. Additionally, introduce the function
> > set_dma_ops() that will be used by a later patch in this series.
> 
> When you say things like "additionally", that's a huge flag that this
> needs to be split up into multiple patches.  No need to add
> set_dma_ops() here in this patch.

Hello Greg,

Some architectures already define a set_dma_ops() function. So what this
patch does is to move both the dma_ops pointer and the set_dma_ops()
function from architecture-specific to architecture independent code. I
don't think that it is possible to separate these two changes. But I
understand that how I formulated the patch description caused confusion. I
will rewrite the patch description to make it more clear before I repost
this patch series.

> And I'd argue that it should be dma_ops_set(), and dma_ops_get(), just
> to keep the namespace sane, but that's probably a different set of
> patches...

Every time I rebase and retest this patch series on top of a new kernel
version I have to modify some of the patches to compensate for changes in
the architecture code. So I expect that once Linus merges these patches that
he will have to resolve one or more merge conflicts. Including a rename of
the functions that query and set the dma_ops pointer in this patch series
would increase the number of merge conflicts triggered by this patch series
and would make Linus' job harder. So I hope that you will allow me to
postpone that rename until a later time ...

Bart.

  reply	other threads:[~2017-01-11 18:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170111005648.14988-1-bart.vanassche@sandisk.com>
2017-01-11  0:56 ` [PATCH 1/9] treewide: Constify most dma_map_ops structures Bart Van Assche
2017-01-11  0:56   ` Bart Van Assche
2017-01-11  0:56 ` [PATCH 2/9] Move dma_ops from archdata into struct device Bart Van Assche
2017-01-11  0:56   ` Bart Van Assche
2017-01-11  6:46   ` Greg Kroah-Hartman
2017-01-11 18:03     ` Bart Van Assche
2017-01-11 18:03       ` Bart Van Assche
2017-01-11 20:29       ` gregkh
2017-01-11 20:29         ` gregkh
2017-01-11  6:48   ` Greg Kroah-Hartman
2017-01-11 18:17     ` Bart Van Assche [this message]
2017-01-11 18:17       ` Bart Van Assche
2017-01-11 20:31       ` gregkh
2017-01-11 20:31         ` gregkh
2017-01-11 22:28         ` Bart Van Assche
2017-01-11 22:28           ` Bart Van Assche
2017-01-12  7:35           ` gregkh
2017-01-12  7:35             ` gregkh

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=1484158589.2619.14.camel@sandisk.com \
    --to=bart.vanassche@sandisk.com \
    --cc=a-jacquiot@ti.com \
    --cc=adi-buildroot-devel@lists.sourceforge.net \
    --cc=catalin.marinas@arm.com \
    --cc=chris@zankel.net \
    --cc=dalias@libc.org \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=dhowells@redhat.com \
    --cc=dledford@redhat.com \
    --cc=egtvedt@samfundet.no \
    --cc=fenghua.yu@intel.com \
    --cc=geert@linux-m68k.org \
    --cc=geoff@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=hskinnemoen@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jcmvbkbc@gmail.com \
    --cc=jdmason@kudzu.us \
    --cc=jejb@parisc-linux.org \
    --cc=jesper.nilsson@axis.com \
    --cc=jonas@southpole.se \
    --cc=joro@8bytes.org \
    --cc=lftan@altera.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-am33-list@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-c6x-dev@linux-c6x.org \
    --cc=linux-cris-kernel@axis.com \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-metag@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=msalter@redhat.com \
    --cc=mulix@mulix.org \
    --cc=nios2-dev@lists.rocketboards.org \
    --cc=openrisc@lists.librecores.org \
    --cc=shorne@gmail.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=starvik@axis.com \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=uclinux-h8-devel@lists.sourceforge.jp \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    --cc=ysato@users.sourceforge.jp \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox