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=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 6C399C47083 for ; Wed, 2 Jun 2021 11:40:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4AD1B613B1 for ; Wed, 2 Jun 2021 11:40:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229640AbhFBLmi (ORCPT ); Wed, 2 Jun 2021 07:42:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:49178 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229482AbhFBLmh (ORCPT ); Wed, 2 Jun 2021 07:42:37 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 47D4A61263; Wed, 2 Jun 2021 11:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622634054; bh=luXM2XCsQ4rkn0y3NiEdRQC6jdfN5IXOZ+jOaRPnlFg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ct7+og3+3E6SYutIXD/pNpjWtrnPmCFf8BaKm/iHB99vZY+0Ci4+qN5bI3F7svYLm Q0et+Mu62jNHaTAsN45RqAtfGxxwbk6vKdVTpWuSYD5jEVcNGW3tXk1Apu0zZ8hmsN 89cyl3YL4CM/jpq0K8oXoVic8apkf2Epv0HLW8qYci6D8W3kVvoHsMNCz+jCsRX8ca B6ZO004XfWD0QH1DMsepoX4luYk53YrJ2bvnUdZ7QstpSdxxAkUZSU1XCTRg4TN3gR 3rQXU8cEYe7v4/vVoMEmH+HSHfbBXvWyH4jXWLXB/c2FuH735NklGthDsVBjWDu0gR s3/dn/jyVRTWA== Date: Wed, 2 Jun 2021 12:40:49 +0100 From: Will Deacon To: Krzysztof Kozlowski Cc: Thierry Reding , Robin Murphy , Joerg Roedel , Jon Hunter , Nicolin Chen , Krishna Reddy , linux-tegra@vger.kernel.org, iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults Message-ID: <20210602114049.GF30593@willie-the-truck> References: <20210420172619.3782831-1-thierry.reding@gmail.com> <20210601122646.GB27832@willie-the-truck> <6826d892-d1ac-e3b1-ebee-68392d11d7c5@canonical.com> <8c70f82f-0db9-2312-7fc4-c079899c25a0@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote: > On 02/06/2021 10:52, Thierry Reding wrote: > > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote: > >> On 02/06/2021 09:33, Krzysztof Kozlowski wrote: > >>> On 01/06/2021 20:08, Thierry Reding wrote: > >>>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote: > >>>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote: > >>>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote: > >>>>>>> From: Thierry Reding > >>>>>>> > >>>>> Probably best if I queue 3-6 on a separate branch once you send a v3, > >>>>> then Krzysztof can pull that in if he needs it. > >>>> > >>>> Patch 5 has a build-time dependency on patch 1, so they need to go in > >>>> together. The reason why I suggested Krzysztof pick these up is because > >>>> there is a restructuring series that this depends on, which will go into > >>>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other > >>>> and mostly unrelated stuff as well. > >>> > >>> I missed that part... what other series are needed for this one? Except > >>> Dmitry's power management set I do not have anything in my sight for > >>> Tegras memory controllers. > >>> > >>> Anyway, I can take the memory bits and provide a stable tag with these. > >>> Recently there was quite a lot work around Tegra memory controllers, so > >>> this makes especially sense if new patches appear. > >> > >> OK, I think I have now the patchset you talked about - "memory: tegra: > >> Driver unification" v2, right? > > > > Yes, that's the one. That series is fairly self-contained, but Dmitry's > > power management set has dependencies that pull in the regulator, clock > > and ARM SoC trees. > > > > I did a test merge of the driver unification series with a branch that > > has Dmitry's patches and all the dependencies and there are no conflicts > > so that, fortunately, doesn't further complicates things. > > > > Do you want me to send you a pull request with Dmitry's memory > > controller changes? You could then apply the unification series on top, > > which should allow this SMMU series to apply cleanly on top of that. > > Makes sense and it looks quite bulletproof for future changes. Let's do > like this. I will apply your patch 1/10 from this v2 on top of it and > driver unification later. Okey doke. Thierry -- please let me know which patches I can queue. Having the SMMU driver changes in the IOMMU tree really helps in case of conflicts with other SMMU changes. As I say, I can put stuff on a separate branch for you if it helps. Will 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=-5.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no 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 B8C90C4708F for ; Wed, 2 Jun 2021 11:41:05 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (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 694EC61263 for ; Wed, 2 Jun 2021 11:41:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 694EC61263 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 3A624402BA; Wed, 2 Jun 2021 11:41:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwgG1Rbeel3j; Wed, 2 Jun 2021 11:41:00 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp4.osuosl.org (Postfix) with ESMTP id 83CBB4024F; Wed, 2 Jun 2021 11:41:00 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 61FDCC000D; Wed, 2 Jun 2021 11:41:00 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 59F60C0001 for ; Wed, 2 Jun 2021 11:40:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 3342D4022B for ; Wed, 2 Jun 2021 11:40:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=kernel.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sb-mRUt2UnS for ; Wed, 2 Jun 2021 11:40:55 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp2.osuosl.org (Postfix) with ESMTPS id 5CD3840146 for ; Wed, 2 Jun 2021 11:40:55 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 47D4A61263; Wed, 2 Jun 2021 11:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622634054; bh=luXM2XCsQ4rkn0y3NiEdRQC6jdfN5IXOZ+jOaRPnlFg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ct7+og3+3E6SYutIXD/pNpjWtrnPmCFf8BaKm/iHB99vZY+0Ci4+qN5bI3F7svYLm Q0et+Mu62jNHaTAsN45RqAtfGxxwbk6vKdVTpWuSYD5jEVcNGW3tXk1Apu0zZ8hmsN 89cyl3YL4CM/jpq0K8oXoVic8apkf2Epv0HLW8qYci6D8W3kVvoHsMNCz+jCsRX8ca B6ZO004XfWD0QH1DMsepoX4luYk53YrJ2bvnUdZ7QstpSdxxAkUZSU1XCTRg4TN3gR 3rQXU8cEYe7v4/vVoMEmH+HSHfbBXvWyH4jXWLXB/c2FuH735NklGthDsVBjWDu0gR s3/dn/jyVRTWA== Date: Wed, 2 Jun 2021 12:40:49 +0100 From: Will Deacon To: Krzysztof Kozlowski Subject: Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults Message-ID: <20210602114049.GF30593@willie-the-truck> References: <20210420172619.3782831-1-thierry.reding@gmail.com> <20210601122646.GB27832@willie-the-truck> <6826d892-d1ac-e3b1-ebee-68392d11d7c5@canonical.com> <8c70f82f-0db9-2312-7fc4-c079899c25a0@canonical.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Cc: iommu@lists.linux-foundation.org, Jon Hunter , Thierry Reding , Nicolin Chen , linux-tegra@vger.kernel.org, Robin Murphy , linux-arm-kernel@lists.infradead.org X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote: > On 02/06/2021 10:52, Thierry Reding wrote: > > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote: > >> On 02/06/2021 09:33, Krzysztof Kozlowski wrote: > >>> On 01/06/2021 20:08, Thierry Reding wrote: > >>>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote: > >>>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote: > >>>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote: > >>>>>>> From: Thierry Reding > >>>>>>> > >>>>> Probably best if I queue 3-6 on a separate branch once you send a v3, > >>>>> then Krzysztof can pull that in if he needs it. > >>>> > >>>> Patch 5 has a build-time dependency on patch 1, so they need to go in > >>>> together. The reason why I suggested Krzysztof pick these up is because > >>>> there is a restructuring series that this depends on, which will go into > >>>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other > >>>> and mostly unrelated stuff as well. > >>> > >>> I missed that part... what other series are needed for this one? Except > >>> Dmitry's power management set I do not have anything in my sight for > >>> Tegras memory controllers. > >>> > >>> Anyway, I can take the memory bits and provide a stable tag with these. > >>> Recently there was quite a lot work around Tegra memory controllers, so > >>> this makes especially sense if new patches appear. > >> > >> OK, I think I have now the patchset you talked about - "memory: tegra: > >> Driver unification" v2, right? > > > > Yes, that's the one. That series is fairly self-contained, but Dmitry's > > power management set has dependencies that pull in the regulator, clock > > and ARM SoC trees. > > > > I did a test merge of the driver unification series with a branch that > > has Dmitry's patches and all the dependencies and there are no conflicts > > so that, fortunately, doesn't further complicates things. > > > > Do you want me to send you a pull request with Dmitry's memory > > controller changes? You could then apply the unification series on top, > > which should allow this SMMU series to apply cleanly on top of that. > > Makes sense and it looks quite bulletproof for future changes. Let's do > like this. I will apply your patch 1/10 from this v2 on top of it and > driver unification later. Okey doke. Thierry -- please let me know which patches I can queue. Having the SMMU driver changes in the IOMMU tree really helps in case of conflicts with other SMMU changes. As I say, I can put stuff on a separate branch for you if it helps. Will _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 AC4FDC47083 for ; Wed, 2 Jun 2021 12:05:24 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 706DC61361 for ; Wed, 2 Jun 2021 12:05:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 706DC61361 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.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=bombadil.20210309; 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=GsRMhQjxxZVxFSQyfEYIath5mjoYEIkh7UbG6B9YVEc=; b=lm21th7n7O8+bq VrhmzPYX5B69YemsTUBa6Kvqet6BghycAxRurYE9uJp2eiCjIH9/gZI+eJiD1qIJKnVdglNEmkWCw 3xSZ9oInzQQXeDHfxRELnmkN3/KnbpNJtUsl3UaBbKqZYdYB80cJny3COjWXfs+D1wbFUBeqiIl2D s7ireqIPhg5vXd7k3JISvIGD+ZzWORGpuGyKqeOiTMFDhK37q8u79T5ZL9thHlNbx/KNvCh5yZKw1 Q2fqYXHeX4PYo08Yg1uajh5q7+VNwZ0qzeat7X01A8JYfUf3fdBDi8QbIy8Dpn6Ad/HEX/IoN7RGn 9vbNCe1mt2e7mLv2Q8kQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1loPaT-003sw5-6z; Wed, 02 Jun 2021 12:03:07 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1loPF1-003nOc-Gp for linux-arm-kernel@lists.infradead.org; Wed, 02 Jun 2021 11:40:57 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 47D4A61263; Wed, 2 Jun 2021 11:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622634054; bh=luXM2XCsQ4rkn0y3NiEdRQC6jdfN5IXOZ+jOaRPnlFg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ct7+og3+3E6SYutIXD/pNpjWtrnPmCFf8BaKm/iHB99vZY+0Ci4+qN5bI3F7svYLm Q0et+Mu62jNHaTAsN45RqAtfGxxwbk6vKdVTpWuSYD5jEVcNGW3tXk1Apu0zZ8hmsN 89cyl3YL4CM/jpq0K8oXoVic8apkf2Epv0HLW8qYci6D8W3kVvoHsMNCz+jCsRX8ca B6ZO004XfWD0QH1DMsepoX4luYk53YrJ2bvnUdZ7QstpSdxxAkUZSU1XCTRg4TN3gR 3rQXU8cEYe7v4/vVoMEmH+HSHfbBXvWyH4jXWLXB/c2FuH735NklGthDsVBjWDu0gR s3/dn/jyVRTWA== Date: Wed, 2 Jun 2021 12:40:49 +0100 From: Will Deacon To: Krzysztof Kozlowski Subject: Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults Message-ID: <20210602114049.GF30593@willie-the-truck> References: <20210420172619.3782831-1-thierry.reding@gmail.com> <20210601122646.GB27832@willie-the-truck> <6826d892-d1ac-e3b1-ebee-68392d11d7c5@canonical.com> <8c70f82f-0db9-2312-7fc4-c079899c25a0@canonical.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210602_044055_665566_9EE0DAA2 X-CRM114-Status: GOOD ( 29.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Joerg Roedel , iommu@lists.linux-foundation.org, Jon Hunter , Thierry Reding , Nicolin Chen , linux-tegra@vger.kernel.org, Robin Murphy , 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 Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote: > On 02/06/2021 10:52, Thierry Reding wrote: > > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote: > >> On 02/06/2021 09:33, Krzysztof Kozlowski wrote: > >>> On 01/06/2021 20:08, Thierry Reding wrote: > >>>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote: > >>>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote: > >>>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote: > >>>>>>> From: Thierry Reding > >>>>>>> > >>>>> Probably best if I queue 3-6 on a separate branch once you send a v3, > >>>>> then Krzysztof can pull that in if he needs it. > >>>> > >>>> Patch 5 has a build-time dependency on patch 1, so they need to go in > >>>> together. The reason why I suggested Krzysztof pick these up is because > >>>> there is a restructuring series that this depends on, which will go into > >>>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other > >>>> and mostly unrelated stuff as well. > >>> > >>> I missed that part... what other series are needed for this one? Except > >>> Dmitry's power management set I do not have anything in my sight for > >>> Tegras memory controllers. > >>> > >>> Anyway, I can take the memory bits and provide a stable tag with these. > >>> Recently there was quite a lot work around Tegra memory controllers, so > >>> this makes especially sense if new patches appear. > >> > >> OK, I think I have now the patchset you talked about - "memory: tegra: > >> Driver unification" v2, right? > > > > Yes, that's the one. That series is fairly self-contained, but Dmitry's > > power management set has dependencies that pull in the regulator, clock > > and ARM SoC trees. > > > > I did a test merge of the driver unification series with a branch that > > has Dmitry's patches and all the dependencies and there are no conflicts > > so that, fortunately, doesn't further complicates things. > > > > Do you want me to send you a pull request with Dmitry's memory > > controller changes? You could then apply the unification series on top, > > which should allow this SMMU series to apply cleanly on top of that. > > Makes sense and it looks quite bulletproof for future changes. Let's do > like this. I will apply your patch 1/10 from this v2 on top of it and > driver unification later. Okey doke. Thierry -- please let me know which patches I can queue. Having the SMMU driver changes in the IOMMU tree really helps in case of conflicts with other SMMU changes. As I say, I can put stuff on a separate branch for you if it helps. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel