From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E33DEC1B0D8 for ; Sat, 5 Dec 2020 00:17:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A41B922B40 for ; Sat, 5 Dec 2020 00:17:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730692AbgLEARl (ORCPT ); Fri, 4 Dec 2020 19:17:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730647AbgLEARl (ORCPT ); Fri, 4 Dec 2020 19:17:41 -0500 Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37931C061A4F for ; Fri, 4 Dec 2020 16:17:01 -0800 (PST) Received: by mail-oi1-x242.google.com with SMTP id t205so8172098oib.12 for ; Fri, 04 Dec 2020 16:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=utTeGzYjnre0QYpGB+o+Kx5Eh/EBZWte4MIpGCS97Mk=; b=RnvGMIvVG6Xy37R27w0nFCZsfL8SMYfr1j2g6qflxujBDijVLd19buyf8rD4Nict9a JYI9wOCh94Yhtz+hVW/NRKrwlNM+VygZrGeFtpzetbkMWcE5xrE1uJs0fURBEjLdGEui gTaC9pGyXUYKYc7lv0jypQ9tygpmh/+h2bZyVq9Qo0t+CK4AFnm23uuxcSb0XBfs2OHs RTXC5sWfQ0v5CQdk+RSPcRB8EOhoPcuQmj3c75PJoclm9PeOr2dHU81165ghKLCK+ETT veCpidLi8ww6qq92kNe7xD9dhB+lWUoxD2BfNKKoJf9Ndc1NMSoAANI6yofqqiaR1n04 LFYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=utTeGzYjnre0QYpGB+o+Kx5Eh/EBZWte4MIpGCS97Mk=; b=GJxt86BjnjokNDQOvC7plJ6OZMdh8/QpmI0uDPyegNkYXC08AFiCQkdXpqaPz0u9fS gkdVN2v4A2YICpHXahHGJ/PLrvmpI6tBASE27jijANUNshQQJXj8n1VnZssZ3qxogHVO MWQVKTuiPxrYgnQp2ItacDvlNGgTdbJlo0Tdq2oMZcIflM0xiHCQ/NNpdGwLA4LZnEat KbPs9ncx/5e+SJ5D1kcSd+0Ii5lSJPmrr0j3YTQPLTB078OL9xtdDgoLtAdEP53AEGr/ 8soEZqCGJPbMC+QcavPe1oQcOQnQxGkLP04typJZE8HLKRoSNORdU5K5p0uyX9LsfveE EUAQ== X-Gm-Message-State: AOAM533YkN9QuUxKpYIoeJvmYecF8ZDv3cmlVuhfT+5tEv+fHBG1wiKj eJ58YKjdvPLeaEw8mmeuZApHJw== X-Google-Smtp-Source: ABdhPJxfhocvHXizIEP4tvs8LbPR8A8BuVXu9GscgqkwyR3FWCBYfhdQFs9rxANMhBsPduJ4JO39rQ== X-Received: by 2002:aca:6106:: with SMTP id v6mr5106782oib.158.1607127420378; Fri, 04 Dec 2020 16:17:00 -0800 (PST) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id r7sm1013171oih.21.2020.12.04.16.16.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Dec 2020 16:16:59 -0800 (PST) Date: Fri, 4 Dec 2020 18:16:57 -0600 From: Bjorn Andersson To: "Peng Fan (OSS)" Cc: ohad@wizery.com, mathieu.poirier@linaro.org, o.rempel@pengutronix.de, shawnguo@kernel.org, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com, linux-remoteproc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Peng Fan , Richard Zhu Subject: Re: [PATCH V3 1/7] remoteproc: elf: support platform specific memory hook Message-ID: References: <20201204074036.23870-1-peng.fan@oss.nxp.com> <20201204074036.23870-2-peng.fan@oss.nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201204074036.23870-2-peng.fan@oss.nxp.com> Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org On Fri 04 Dec 01:40 CST 2020, Peng Fan (OSS) wrote: > From: Peng Fan > > To arm64, "dc zva, dst" is used in memset. > Per ARM DDI 0487A.j, chapter C5.3.8 DC ZVA, Data Cache Zero by VA, > > "If the memory region being zeroed is any type of Device memory, > this instruction can give an alignment fault which is prioritized > in the same way as other alignment faults that are determined > by the memory type." > > On i.MX platforms, when elf is loaded to onchip TCM area, the region > is ioremapped, so "dc zva, dst" will trigger abort. And ioremap_wc() > on i.MX not able to write correct data to TCM area. > > So we need to use io helpers, and extend the elf loader to support > platform specific memory functions. > > Acked-by: Richard Zhu > Signed-off-by: Peng Fan > Reviewed-by: Mathieu Poirier > --- > drivers/remoteproc/remoteproc_elf_loader.c | 20 ++++++++++++++++++-- > include/linux/remoteproc.h | 4 ++++ > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c > index df68d87752e4..6cb71fe47261 100644 > --- a/drivers/remoteproc/remoteproc_elf_loader.c > +++ b/drivers/remoteproc/remoteproc_elf_loader.c > @@ -129,6 +129,22 @@ u64 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw) > } > EXPORT_SYMBOL(rproc_elf_get_boot_addr); > > +static void rproc_elf_memcpy(struct rproc *rproc, void *dest, const void *src, size_t count) > +{ > + if (!rproc->ops->elf_memcpy) > + memcpy(dest, src, count); > + > + rproc->ops->elf_memcpy(rproc, dest, src, count); Looking at the current set of remoteproc drivers I get a feeling that we'll end up with a while bunch of functions that all just wraps memcpy_toio(). And the reason for this is that we are we're "abusing" the carveout to carry the __iomem pointer without keeping track of it. And this is not the only time we're supposed to use an io-accessor, another example is rproc_copy_segment() in rproc_coredump.c It also means that if a platform driver for some reason where to support both ioremap and normal carveouts the elf_memcpy op would be quite quirky. So I would prefer if we track the knowledge about void *va being a __iomem or not in the struct rproc_mem_entry and make rproc_da_to_va() return this information as well. Then instead of extending the ops we can make this simply call memcpy or memcpy_toio() depending on this. Regards, Bjorn > +} > + > +static void rproc_elf_memset(struct rproc *rproc, void *s, int c, size_t count) > +{ > + if (!rproc->ops->elf_memset) > + memset(s, c, count); > + > + rproc->ops->elf_memset(rproc, s, c, count); > +} > + > /** > * rproc_elf_load_segments() - load firmware segments to memory > * @rproc: remote processor which will be booted using these fw segments > @@ -214,7 +230,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw) > > /* put the segment where the remote processor expects it */ > if (filesz) > - memcpy(ptr, elf_data + offset, filesz); > + rproc_elf_memcpy(rproc, ptr, elf_data + offset, filesz); > > /* > * Zero out remaining memory for this segment. > @@ -224,7 +240,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw) > * this. > */ > if (memsz > filesz) > - memset(ptr + filesz, 0, memsz - filesz); > + rproc_elf_memset(rproc, ptr + filesz, 0, memsz - filesz); > } > > return ret; > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h > index e8ac041c64d9..06c52f88a3fd 100644 > --- a/include/linux/remoteproc.h > +++ b/include/linux/remoteproc.h > @@ -373,6 +373,8 @@ enum rsc_handling_status { > * expects to find it > * @sanity_check: sanity check the fw image > * @get_boot_addr: get boot address to entry point specified in firmware > + * @elf_memcpy: platform specific elf loader memcpy > + * @elf_memset: platform specific elf loader memset > * @panic: optional callback to react to system panic, core will delay > * panic at least the returned number of milliseconds > */ > @@ -392,6 +394,8 @@ struct rproc_ops { > int (*load)(struct rproc *rproc, const struct firmware *fw); > int (*sanity_check)(struct rproc *rproc, const struct firmware *fw); > u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw); > + void (*elf_memcpy)(struct rproc *rproc, void *dest, const void *src, size_t count); > + void (*elf_memset)(struct rproc *rproc, void *s, int c, size_t count); > unsigned long (*panic)(struct rproc *rproc); > }; > > -- > 2.28.0 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83871C4361A for ; Sat, 5 Dec 2020 00:18:54 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 29F4222D6D for ; Sat, 5 Dec 2020 00:18:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29F4222D6D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=DzeJjowNAx8iogceBthCXRg5tGFa9JCOEG+6L5GGL5c=; b=SBHol6aSmZ7ryEIjzbrAHk6dv q4dblQTmerFN3fwnnUTan1h2CklEuBG687DzwmAFL1WLjklMYHjDoRIII5b+9lFWjoZp1juCsYu6p qgeg9sOPihSzvxY+Zn9YIHbt9eUVJJnEtTh+v9ZpArkD1ktdE5c+6gHumWD/FlzZvs3ZnJ8VJCimZ 7cP+CutEnzgInBaadMHHTC/RktiKJL9F9liIAFsKDCwMfVGyq8vpkOQCZciZG1JvFO0JVf10j/cPN hyC7h2YC8k8A2KchuaWwzFHo2DUFarUM+GW8BPJGv6p9auAhEnVB8CXewEBaOP4I+wRV7InySj82S ADg71UaxA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1klLG7-0007QM-Pv; Sat, 05 Dec 2020 00:17:07 +0000 Received: from mail-oi1-x241.google.com ([2607:f8b0:4864:20::241]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1klLG4-0007Pc-3i for linux-arm-kernel@lists.infradead.org; Sat, 05 Dec 2020 00:17:05 +0000 Received: by mail-oi1-x241.google.com with SMTP id p126so8202899oif.7 for ; Fri, 04 Dec 2020 16:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=utTeGzYjnre0QYpGB+o+Kx5Eh/EBZWte4MIpGCS97Mk=; b=RnvGMIvVG6Xy37R27w0nFCZsfL8SMYfr1j2g6qflxujBDijVLd19buyf8rD4Nict9a JYI9wOCh94Yhtz+hVW/NRKrwlNM+VygZrGeFtpzetbkMWcE5xrE1uJs0fURBEjLdGEui gTaC9pGyXUYKYc7lv0jypQ9tygpmh/+h2bZyVq9Qo0t+CK4AFnm23uuxcSb0XBfs2OHs RTXC5sWfQ0v5CQdk+RSPcRB8EOhoPcuQmj3c75PJoclm9PeOr2dHU81165ghKLCK+ETT veCpidLi8ww6qq92kNe7xD9dhB+lWUoxD2BfNKKoJf9Ndc1NMSoAANI6yofqqiaR1n04 LFYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=utTeGzYjnre0QYpGB+o+Kx5Eh/EBZWte4MIpGCS97Mk=; b=ezwG3QbGEev4KXqHht2S0yfKUaQkx7wh1tqFM6M+P8W1ea4M3bzp053OndMhyGjS6t NG2ELt3vGbXU8ybwVQl55jRY0h9P2ZU+1g+z2vwuwCJS44Hrwn0DQj8Dn5+q8X3GrEdz YPKq47UnQVfTGrk4/0RFyU+2BnlOO40Czb881NACIUMGzH1NUgDgJjzVpfk2GZ2v+14Q lSuXnbn1Ig/hVUrMxJsxeU/xyYLL/qnGgdCMG2X/6+3OmrNhFdpUfKCanzHeoNjnaBJv zvfKdxOMb2D7g1ysGFICBcPqMk/8eFl6NiFOHGvp6uqYgtujFeY/ttnLJH5qqwo1MJmw yIKQ== X-Gm-Message-State: AOAM531iQxIVFcANpcP+8IJWWMZQnwkGKdNDfZRfa+F5Mik1hT/dBX2D ZjnSNc4NwNbcPB/PRx4ORfFVCWFzrwhWNg== X-Google-Smtp-Source: ABdhPJxfhocvHXizIEP4tvs8LbPR8A8BuVXu9GscgqkwyR3FWCBYfhdQFs9rxANMhBsPduJ4JO39rQ== X-Received: by 2002:aca:6106:: with SMTP id v6mr5106782oib.158.1607127420378; Fri, 04 Dec 2020 16:17:00 -0800 (PST) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id r7sm1013171oih.21.2020.12.04.16.16.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Dec 2020 16:16:59 -0800 (PST) Date: Fri, 4 Dec 2020 18:16:57 -0600 From: Bjorn Andersson To: "Peng Fan (OSS)" Subject: Re: [PATCH V3 1/7] remoteproc: elf: support platform specific memory hook Message-ID: References: <20201204074036.23870-1-peng.fan@oss.nxp.com> <20201204074036.23870-2-peng.fan@oss.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201204074036.23870-2-peng.fan@oss.nxp.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201204_191704_437484_F01C85FF X-CRM114-Status: GOOD ( 27.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ohad@wizery.com, Peng Fan , Richard Zhu , mathieu.poirier@linaro.org, festevam@gmail.com, s.hauer@pengutronix.de, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, o.rempel@pengutronix.de, linux-imx@nxp.com, kernel@pengutronix.de, shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri 04 Dec 01:40 CST 2020, Peng Fan (OSS) wrote: > From: Peng Fan > > To arm64, "dc zva, dst" is used in memset. > Per ARM DDI 0487A.j, chapter C5.3.8 DC ZVA, Data Cache Zero by VA, > > "If the memory region being zeroed is any type of Device memory, > this instruction can give an alignment fault which is prioritized > in the same way as other alignment faults that are determined > by the memory type." > > On i.MX platforms, when elf is loaded to onchip TCM area, the region > is ioremapped, so "dc zva, dst" will trigger abort. And ioremap_wc() > on i.MX not able to write correct data to TCM area. > > So we need to use io helpers, and extend the elf loader to support > platform specific memory functions. > > Acked-by: Richard Zhu > Signed-off-by: Peng Fan > Reviewed-by: Mathieu Poirier > --- > drivers/remoteproc/remoteproc_elf_loader.c | 20 ++++++++++++++++++-- > include/linux/remoteproc.h | 4 ++++ > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c > index df68d87752e4..6cb71fe47261 100644 > --- a/drivers/remoteproc/remoteproc_elf_loader.c > +++ b/drivers/remoteproc/remoteproc_elf_loader.c > @@ -129,6 +129,22 @@ u64 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw) > } > EXPORT_SYMBOL(rproc_elf_get_boot_addr); > > +static void rproc_elf_memcpy(struct rproc *rproc, void *dest, const void *src, size_t count) > +{ > + if (!rproc->ops->elf_memcpy) > + memcpy(dest, src, count); > + > + rproc->ops->elf_memcpy(rproc, dest, src, count); Looking at the current set of remoteproc drivers I get a feeling that we'll end up with a while bunch of functions that all just wraps memcpy_toio(). And the reason for this is that we are we're "abusing" the carveout to carry the __iomem pointer without keeping track of it. And this is not the only time we're supposed to use an io-accessor, another example is rproc_copy_segment() in rproc_coredump.c It also means that if a platform driver for some reason where to support both ioremap and normal carveouts the elf_memcpy op would be quite quirky. So I would prefer if we track the knowledge about void *va being a __iomem or not in the struct rproc_mem_entry and make rproc_da_to_va() return this information as well. Then instead of extending the ops we can make this simply call memcpy or memcpy_toio() depending on this. Regards, Bjorn > +} > + > +static void rproc_elf_memset(struct rproc *rproc, void *s, int c, size_t count) > +{ > + if (!rproc->ops->elf_memset) > + memset(s, c, count); > + > + rproc->ops->elf_memset(rproc, s, c, count); > +} > + > /** > * rproc_elf_load_segments() - load firmware segments to memory > * @rproc: remote processor which will be booted using these fw segments > @@ -214,7 +230,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw) > > /* put the segment where the remote processor expects it */ > if (filesz) > - memcpy(ptr, elf_data + offset, filesz); > + rproc_elf_memcpy(rproc, ptr, elf_data + offset, filesz); > > /* > * Zero out remaining memory for this segment. > @@ -224,7 +240,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw) > * this. > */ > if (memsz > filesz) > - memset(ptr + filesz, 0, memsz - filesz); > + rproc_elf_memset(rproc, ptr + filesz, 0, memsz - filesz); > } > > return ret; > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h > index e8ac041c64d9..06c52f88a3fd 100644 > --- a/include/linux/remoteproc.h > +++ b/include/linux/remoteproc.h > @@ -373,6 +373,8 @@ enum rsc_handling_status { > * expects to find it > * @sanity_check: sanity check the fw image > * @get_boot_addr: get boot address to entry point specified in firmware > + * @elf_memcpy: platform specific elf loader memcpy > + * @elf_memset: platform specific elf loader memset > * @panic: optional callback to react to system panic, core will delay > * panic at least the returned number of milliseconds > */ > @@ -392,6 +394,8 @@ struct rproc_ops { > int (*load)(struct rproc *rproc, const struct firmware *fw); > int (*sanity_check)(struct rproc *rproc, const struct firmware *fw); > u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw); > + void (*elf_memcpy)(struct rproc *rproc, void *dest, const void *src, size_t count); > + void (*elf_memset)(struct rproc *rproc, void *s, int c, size_t count); > unsigned long (*panic)(struct rproc *rproc); > }; > > -- > 2.28.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel