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=-11.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham 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 21A02C433E7 for ; Tue, 1 Sep 2020 16:05:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 02A7C204EC for ; Tue, 1 Sep 2020 16:05:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731565AbgIAQFj (ORCPT ); Tue, 1 Sep 2020 12:05:39 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:2728 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731519AbgIAQFf (ORCPT ); Tue, 1 Sep 2020 12:05:35 -0400 Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 523AA170988C8A8774D3; Tue, 1 Sep 2020 17:05:31 +0100 (IST) Received: from localhost (10.52.122.233) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 1 Sep 2020 17:05:30 +0100 Date: Tue, 1 Sep 2020 17:03:54 +0100 From: Jonathan Cameron To: Sudeep Holla CC: , , "Will Deacon" , , , Subject: Re: [PATCH 1/9] dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding Message-ID: <20200901170354.0000309a@Huawei.com> In-Reply-To: <20200829170923.29949-2-sudeep.holla@arm.com> References: <20200829170923.29949-1-sudeep.holla@arm.com> <20200829170923.29949-2-sudeep.holla@arm.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.52.122.233] X-ClientProxiedBy: lhreml710-chm.china.huawei.com (10.201.108.61) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Sat, 29 Aug 2020 18:09:15 +0100 Sudeep Holla wrote: > From: Will Deacon > > Add devicetree bindings for a FF-A-compliant hypervisor, its partitions > and their memory regions. The naming is ludicrous but also not by fault. > > Signed-off-by: Will Deacon > (sudeep.holla: Dropped PSA from name and elsewhere as it seem to have > disappeared mysteriously just before the final release) > Signed-off-by: Sudeep Holla As I was reading this out of curiosity... I'm far from a yaml expert but a few things in line. > --- > .../devicetree/bindings/arm/arm,ffa.yaml | 102 ++++++++++++++++++ > .../reserved-memory/arm,ffa-memory.yaml | 71 ++++++++++++ > 2 files changed, 173 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa.yaml > create mode 100644 Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > > diff --git a/Documentation/devicetree/bindings/arm/arm,ffa.yaml b/Documentation/devicetree/bindings/arm/arm,ffa.yaml > new file mode 100644 > index 000000000000..668a5995fcab > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/arm,ffa.yaml > @@ -0,0 +1,102 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/arm,ffa.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Arm Firmware Framework for Arm v8-A > + > +maintainers: > + - Will Deacon > + > +description: | > + Firmware frameworks implementing partition setup according to the FF-A > + specification defined by ARM document number ARM DEN 0077A ("Arm Firmware > + Framework for Arm v8-A") [0] must provide a "manifest and image" for each > + partition to the "partition manager" so that the partition execution contexts > + can be initialised. > + > + In the case of a virtual FFA instance, the manifest and image details can be > + passed to the hypervisor (e.g. Linux KVM) using this binding. > + > + [0] https://developer.arm.com/docs/den0077/latest > + > +properties: > + $nodename: > + const: ffa_hyp > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-hypervisor As below, would enum be more appropriate here? > + > + memory-region: > + $ref: '/schemas/types.yaml#/definitions/phandle' > + description: | > + A phandle to the reserved memory region [1] to be used by the hypervisor. > + The reserved memory region must be compatible with > + "arm,ffa-1.0-hypervisor-memory-region". > + > + [1] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > + > +patternProperties: > + "^ffa_partition[0-9]+$": > + type: object > + description: One or more child nodes, each describing an FFA partition. > + properties: > + $nodename: > + const: ffa_partition > + > + compatible: > + oneOf: enum? > + - const: arm,ffa-1.0-partition > + > + uuid: > + $ref: '/schemas/types.yaml#definitions/string' > + description: | > + The 128-bit UUID [2] of the service implemented by this partition. > + > + [2] https://tools.ietf.org/html/rfc4122 Feels like we should be able to better type wise than a string for this but maybe not... Doesn't seem to be much in the way of precedence. > + > + nr-exec-ctxs: > + $ref: '/schemas/types.yaml#/definitions/uint32' > + description: | > + The number of virtual CPUs to instantiate for this partition. > + > + exec-state: > + description: The execution state in which to execute the partition. > + oneOf: > + - const: "AArch64" > + - const: "AArch32" > + > + entry-point: > + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' > + description: | > + The entry address of the partition specified as an Intermediate > + Physical Address (IPA) encoded according to the '#address-cells' > + property. > + > + memory-region: > + $ref: '/schemas/types.yaml#/definitions/phandle-array' > + description: | > + A list of phandles to FFA reserved memory regions [3] for this > + partition. > + > + [3] Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > + > +additionalProperties: false > + > +examples: > + - | > + ffa_hyp { > + compatible = "arm,ffa-1.0-hypervisor"; > + memory-region = <&ffa_hyp_reserved>; > + > + ffa_partition0 { > + compatible = "arm,ffa-1.0-partition"; > + uuid = "12345678-9abc-def0-1234-56789abcdef0"; > + nr-exec-ctxs = <2>; > + exec-state = "AArch64"; > + entry-point = <0x80000>; > + memory-region = <&ffa_reserved0 &ffa_reserved1>; > + }; > + }; > diff --git a/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > new file mode 100644 > index 000000000000..5335e07abcfc > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > @@ -0,0 +1,71 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reserved-memory/arm,ffa-memory.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Memory Region for Arm Firmware Framework for Arm v8-A > + > +maintainers: > + - Will Deacon > + > +description: | > + This binding allows a FF-A implementation to describe the normal memory > + regions of a partition [1] to a hypervisor according to [2]. > + > + The physical address range reserved for the partition can be specified as a > + static allocation using the 'reg' property or as a dynamic allocation using > + the 'size' property. If both properties are omitted, then the hypervisor can > + allocate physical memory for the partition however it sees fit. > + > + [1] Documentation/devicetree/bindings/arm/arm,ffa.yaml > + [2] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > + > +properties: > + $nodename: > + pattern: "^ffa_mem(@[0-9a-f]+)?$" > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-partition-memory-region If there is just element and it is const why not just? compatible: const: .... I guess it sort of future proofs you for later variants... However in that case, it would be more common to use compatible: enum: - arm,ffa... which is more restrictive but doesn't seem like you need the complexity of oneOf and it's handling of sub schemas here. > + > + ipa-range: > + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' > + description: | > + The Intermediate Physical Address (IPA) range (encoded in the same way as > + a 'reg' property) at which to map the physical memory. If the IPA range is > + larger than the physical memory region then the region is mapped starting > + at the base of the IPA range. > + > + read-only: > + type: boolean > + description: | > + (static allocation only) The memory region has been pre-populated > + by the firmware framework and must be mapped without write permission > + at stage 2. > + > + non-executable: > + type: boolean > + description: | > + The memory region must be mapped without execute permission at stage 2. > + > + > +required: > + - compatible > + > +# The "reserved-memory" binding defines additional properties. > +additionalProperties: true > + > +examples: > + - | > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + > + ffa_reserved0: ffa_mem@100000000 { > + compatible = "arm,ffa-1.0-partition-memory-region"; > + reg = <0x1 0x0 0x0 0x04000000>; // 64M @ 1GB Isn't that at 4GB? > + ipa-range = <0x0 0x0 0x0 0x04000000>; // 64M @ 0x0 > + read-only; > + }; > + }; 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=-11.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_2 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 AD98CC433E2 for ; Tue, 1 Sep 2020 16:07:00 +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 7EA312067C for ; Tue, 1 Sep 2020 16:07:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="x5OjFWpP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EA312067C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=Huawei.com 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:MIME-Version:References:In-Reply-To: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=MDejY20YrKkbPsnIR8jkUHnVzVun2FQN5DXK0KJN5mg=; b=x5OjFWpPVJG3Q48U9N6vqi24H O/q/7OF0FtwUcWVcA0lTAEpyjUfV4MxfGrA8BpPJZP3Rl6fRdElgRWw+14Vjl+dvQCe/JnnApa26K Wi9vufh3M7Smx+jcP3UkAARlcgYWQQIQhPbxIZ32xT+bcZ1Cyh7hFlFGwqBpvHV9pEQ01daoRyged 6KoBlqxc43kC8enHLe9QIoSGZjnJw0VwLJWHt0J/6Vj1lyAVXi1qQddabK/AUaa380lRf9fZrQVVm v/4g6EoUPIINO03MaT06IZ7pjttx6xu1hXV4F+sUT6oYvTSeewddCM5CW7gWDfSq8JfAznbi5FI4f VGyME8kdw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kD8mw-0005ZM-ME; Tue, 01 Sep 2020 16:05:38 +0000 Received: from lhrrgout.huawei.com ([185.176.76.210] helo=huawei.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kD8ms-0005Xg-05 for linux-arm-kernel@lists.infradead.org; Tue, 01 Sep 2020 16:05:35 +0000 Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 523AA170988C8A8774D3; Tue, 1 Sep 2020 17:05:31 +0100 (IST) Received: from localhost (10.52.122.233) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 1 Sep 2020 17:05:30 +0100 Date: Tue, 1 Sep 2020 17:03:54 +0100 From: Jonathan Cameron To: Sudeep Holla Subject: Re: [PATCH 1/9] dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding Message-ID: <20200901170354.0000309a@Huawei.com> In-Reply-To: <20200829170923.29949-2-sudeep.holla@arm.com> References: <20200829170923.29949-1-sudeep.holla@arm.com> <20200829170923.29949-2-sudeep.holla@arm.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 X-Originating-IP: [10.52.122.233] X-ClientProxiedBy: lhreml710-chm.china.huawei.com (10.201.108.61) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200901_120534_236257_08A440DA X-CRM114-Status: GOOD ( 29.37 ) 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: devicetree@vger.kernel.org, kernel-team@android.com, pratikp@quicinc.com, tsoni@quicinc.com, Will Deacon , 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 Sat, 29 Aug 2020 18:09:15 +0100 Sudeep Holla wrote: > From: Will Deacon > > Add devicetree bindings for a FF-A-compliant hypervisor, its partitions > and their memory regions. The naming is ludicrous but also not by fault. > > Signed-off-by: Will Deacon > (sudeep.holla: Dropped PSA from name and elsewhere as it seem to have > disappeared mysteriously just before the final release) > Signed-off-by: Sudeep Holla As I was reading this out of curiosity... I'm far from a yaml expert but a few things in line. > --- > .../devicetree/bindings/arm/arm,ffa.yaml | 102 ++++++++++++++++++ > .../reserved-memory/arm,ffa-memory.yaml | 71 ++++++++++++ > 2 files changed, 173 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa.yaml > create mode 100644 Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > > diff --git a/Documentation/devicetree/bindings/arm/arm,ffa.yaml b/Documentation/devicetree/bindings/arm/arm,ffa.yaml > new file mode 100644 > index 000000000000..668a5995fcab > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/arm,ffa.yaml > @@ -0,0 +1,102 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/arm,ffa.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Arm Firmware Framework for Arm v8-A > + > +maintainers: > + - Will Deacon > + > +description: | > + Firmware frameworks implementing partition setup according to the FF-A > + specification defined by ARM document number ARM DEN 0077A ("Arm Firmware > + Framework for Arm v8-A") [0] must provide a "manifest and image" for each > + partition to the "partition manager" so that the partition execution contexts > + can be initialised. > + > + In the case of a virtual FFA instance, the manifest and image details can be > + passed to the hypervisor (e.g. Linux KVM) using this binding. > + > + [0] https://developer.arm.com/docs/den0077/latest > + > +properties: > + $nodename: > + const: ffa_hyp > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-hypervisor As below, would enum be more appropriate here? > + > + memory-region: > + $ref: '/schemas/types.yaml#/definitions/phandle' > + description: | > + A phandle to the reserved memory region [1] to be used by the hypervisor. > + The reserved memory region must be compatible with > + "arm,ffa-1.0-hypervisor-memory-region". > + > + [1] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > + > +patternProperties: > + "^ffa_partition[0-9]+$": > + type: object > + description: One or more child nodes, each describing an FFA partition. > + properties: > + $nodename: > + const: ffa_partition > + > + compatible: > + oneOf: enum? > + - const: arm,ffa-1.0-partition > + > + uuid: > + $ref: '/schemas/types.yaml#definitions/string' > + description: | > + The 128-bit UUID [2] of the service implemented by this partition. > + > + [2] https://tools.ietf.org/html/rfc4122 Feels like we should be able to better type wise than a string for this but maybe not... Doesn't seem to be much in the way of precedence. > + > + nr-exec-ctxs: > + $ref: '/schemas/types.yaml#/definitions/uint32' > + description: | > + The number of virtual CPUs to instantiate for this partition. > + > + exec-state: > + description: The execution state in which to execute the partition. > + oneOf: > + - const: "AArch64" > + - const: "AArch32" > + > + entry-point: > + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' > + description: | > + The entry address of the partition specified as an Intermediate > + Physical Address (IPA) encoded according to the '#address-cells' > + property. > + > + memory-region: > + $ref: '/schemas/types.yaml#/definitions/phandle-array' > + description: | > + A list of phandles to FFA reserved memory regions [3] for this > + partition. > + > + [3] Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > + > +additionalProperties: false > + > +examples: > + - | > + ffa_hyp { > + compatible = "arm,ffa-1.0-hypervisor"; > + memory-region = <&ffa_hyp_reserved>; > + > + ffa_partition0 { > + compatible = "arm,ffa-1.0-partition"; > + uuid = "12345678-9abc-def0-1234-56789abcdef0"; > + nr-exec-ctxs = <2>; > + exec-state = "AArch64"; > + entry-point = <0x80000>; > + memory-region = <&ffa_reserved0 &ffa_reserved1>; > + }; > + }; > diff --git a/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > new file mode 100644 > index 000000000000..5335e07abcfc > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml > @@ -0,0 +1,71 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reserved-memory/arm,ffa-memory.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Memory Region for Arm Firmware Framework for Arm v8-A > + > +maintainers: > + - Will Deacon > + > +description: | > + This binding allows a FF-A implementation to describe the normal memory > + regions of a partition [1] to a hypervisor according to [2]. > + > + The physical address range reserved for the partition can be specified as a > + static allocation using the 'reg' property or as a dynamic allocation using > + the 'size' property. If both properties are omitted, then the hypervisor can > + allocate physical memory for the partition however it sees fit. > + > + [1] Documentation/devicetree/bindings/arm/arm,ffa.yaml > + [2] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > + > +properties: > + $nodename: > + pattern: "^ffa_mem(@[0-9a-f]+)?$" > + > + compatible: > + oneOf: > + - const: arm,ffa-1.0-partition-memory-region If there is just element and it is const why not just? compatible: const: .... I guess it sort of future proofs you for later variants... However in that case, it would be more common to use compatible: enum: - arm,ffa... which is more restrictive but doesn't seem like you need the complexity of oneOf and it's handling of sub schemas here. > + > + ipa-range: > + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' > + description: | > + The Intermediate Physical Address (IPA) range (encoded in the same way as > + a 'reg' property) at which to map the physical memory. If the IPA range is > + larger than the physical memory region then the region is mapped starting > + at the base of the IPA range. > + > + read-only: > + type: boolean > + description: | > + (static allocation only) The memory region has been pre-populated > + by the firmware framework and must be mapped without write permission > + at stage 2. > + > + non-executable: > + type: boolean > + description: | > + The memory region must be mapped without execute permission at stage 2. > + > + > +required: > + - compatible > + > +# The "reserved-memory" binding defines additional properties. > +additionalProperties: true > + > +examples: > + - | > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + > + ffa_reserved0: ffa_mem@100000000 { > + compatible = "arm,ffa-1.0-partition-memory-region"; > + reg = <0x1 0x0 0x0 0x04000000>; // 64M @ 1GB Isn't that at 4GB? > + ipa-range = <0x0 0x0 0x0 0x04000000>; // 64M @ 0x0 > + read-only; > + }; > + }; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel