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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS 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 3BF37C33CA8 for ; Mon, 13 Jan 2020 08:59:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0C27A214D8 for ; Mon, 13 Jan 2020 08:59:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578905975; bh=JfZwSTOrI3J7CIa5OdM8C3bfShk23rBqMg7ZmqPnXd0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=qq0T6LoO2tN7kEdK5SRtT1XoL33gW56ozHNTUaZmK1IJg32K5ZNEmqtA5mBYftTTh TNa4RMCWQ1GmRy5Jdp4ylyj4lalpdDogCvtAZd6b8T1rYMYHZgMrxuwKd0+kB6RudC dCDSpVeeIW/WtHaf24YIUOo00vE+TPqnbCm3NHB8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725815AbgAMI7e (ORCPT ); Mon, 13 Jan 2020 03:59:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:32894 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725268AbgAMI7e (ORCPT ); Mon, 13 Jan 2020 03:59:34 -0500 Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4A09820678; Mon, 13 Jan 2020 08:59:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578905972; bh=JfZwSTOrI3J7CIa5OdM8C3bfShk23rBqMg7ZmqPnXd0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Oi9IO6MWKgGI+YoNaP20pa1l4rq2n7FBdgy/pBOn4XJCDISx2Jdz3ni2uErW4Ldz2 cWG4w1zm8qisUTJI8kAGS2iXzgfSOqAuQwq9GzZNo8NOW7hBs4Wl2kDoXd9byaG6+U TBfAuEQKR39d2TFLq3Hr+4Z3HC0pneZIvN7Sr7ak= Date: Mon, 13 Jan 2020 09:59:29 +0100 From: Maxime Ripard To: =?utf-8?B?QW5kcsOp?= Przywara Cc: Chen-Yu Tsai , Mark Brown , linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@googlegroups.com, Icenowy Zheng , devicetree@vger.kernel.org, Rob Herring , Mark Rutland Subject: Re: [PATCH 1/2] arm64: dts: sun50i: H6: Add SPI controllers nodes and pinmuxes Message-ID: <20200113085929.24iseck4fljw5njh@gilmour.lan> References: <20200108101006.150706-1-andre.przywara@arm.com> <20200108101006.150706-2-andre.przywara@arm.com> <20200111172639.to3lhzros6ca5hj2@gilmour.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ir7fewqs7mlcjtw5" Content-Disposition: inline In-Reply-To: Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org --ir7fewqs7mlcjtw5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 12, 2020 at 03:12:19PM +0000, Andr=E9 Przywara wrote: > On 11/01/2020 17:26, Maxime Ripard wrote: > > Hi Maxime, > > > On Wed, Jan 08, 2020 at 10:10:05AM +0000, Andre Przywara wrote: > >> The Allwinner H6 SoC contains two SPI controllers similar to the H3/A6= 4, > >> but with the added capability of 3-wire and 4-wire operation modes. > >> For now the driver does not support those, but the SPI registers are > >> fully backwards-compatible, just adding bits and registers which were > >> formerly reserved. So we can use the existing driver for the "normal" = SPI > >> modes, for instance to access the SPI NOR flash soldered on the PineH64 > >> board. > >> We use an H6 specific compatible string in addition to the existing H3 > >> string, so when the driver later gains Quad SPI support, it should work > >> automatically without any DT changes. > >> > >> Tested by accessing the SPI flash on a Pine H64 board (SPI0), also > >> connecting another SPI flash to the SPI1 header pins. > >> > >> Signed-off-by: Andre Przywara > >> --- > >> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 54 ++++++++++++++++++++ > >> 1 file changed, 54 insertions(+) > >> > >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64= /boot/dts/allwinner/sun50i-h6.dtsi > >> index 3329283e38ab..40835850893e 100644 > >> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > >> @@ -338,6 +338,30 @@ > >> bias-pull-up; > >> }; > >> > >> + /omit-if-no-ref/ > >> + spi0_pins: spi0-pins { > >> + pins =3D "PC0", "PC2", "PC3"; > >> + function =3D "spi0"; > >> + }; > >> + > >> + /omit-if-no-ref/ > >> + spi0_cs_pin: spi0-cs-pin { > >> + pins =3D "PC5"; > >> + function =3D "spi0"; > >> + }; > > > > It seems suspicious to use it in the Pine H64, since PC5 is also used > > by the eMMC (and this prevents either the SPI or the emmc controller > > to probe, depending on which probed first). > > Argh, good catch! I saw that AW changed the pin sharing between SPI and > MMC2 slightly, but didn't actually check that they made it worse :-( > Because this time it's the MMC CMD pin affected, and not the somewhat > optional DS pin as in the A64. > So I see we can't really have both at the same time. So what about this: > > We keep the SPI flash chip described as in patch 2/2 (as it's soldered > on every board), but mark it as disabled and explain this in a comment. > This way we can't access it under Linux, but keep a potential eMMC chip > accessible. > > In U-Boot's DT copy we could deviate and mark it as "okay", as U-Boot > doesn't use both eMMC and SPI at the same time. I need to check whether > this works or we would need to move the pinmux setup out of the probe > routine into something later. > > And we could go one step further: If U-Boot detects an eMMC connected > (it's on a socket and so optional), it changes the SPI flash status to > "disabled", to allow EFI apps and kernels using this DT to access the > eMMC - which is far more useful than the SPI flash. > Otherwise (no eMMC connected) it can stay at "okay", as there would be > no conflict. > > Does this make sense? It does, it seems like a good plan Maxime --ir7fewqs7mlcjtw5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXhwxcQAKCRDj7w1vZxhR xeN3AP472p91nx9oqXRJe6+0u8r0T386EdVwUUHUSJGHeqdtzwEA8UiwW9E3F42A /XZ5acoOflKaj0ShNtTko85S2oaFWQM= =8bva -----END PGP SIGNATURE----- --ir7fewqs7mlcjtw5-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: [PATCH 1/2] arm64: dts: sun50i: H6: Add SPI controllers nodes and pinmuxes Date: Mon, 13 Jan 2020 09:59:29 +0100 Message-ID: <20200113085929.24iseck4fljw5njh@gilmour.lan> References: <20200108101006.150706-1-andre.przywara@arm.com> <20200108101006.150706-2-andre.przywara@arm.com> <20200111172639.to3lhzros6ca5hj2@gilmour.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ir7fewqs7mlcjtw5" Cc: Chen-Yu Tsai , Mark Brown , linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Icenowy Zheng , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring , Mark Rutland To: =?utf-8?B?QW5kcsOp?= Przywara Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: --ir7fewqs7mlcjtw5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 12, 2020 at 03:12:19PM +0000, Andr=E9 Przywara wrote: > On 11/01/2020 17:26, Maxime Ripard wrote: > > Hi Maxime, > > > On Wed, Jan 08, 2020 at 10:10:05AM +0000, Andre Przywara wrote: > >> The Allwinner H6 SoC contains two SPI controllers similar to the H3/A6= 4, > >> but with the added capability of 3-wire and 4-wire operation modes. > >> For now the driver does not support those, but the SPI registers are > >> fully backwards-compatible, just adding bits and registers which were > >> formerly reserved. So we can use the existing driver for the "normal" = SPI > >> modes, for instance to access the SPI NOR flash soldered on the PineH64 > >> board. > >> We use an H6 specific compatible string in addition to the existing H3 > >> string, so when the driver later gains Quad SPI support, it should work > >> automatically without any DT changes. > >> > >> Tested by accessing the SPI flash on a Pine H64 board (SPI0), also > >> connecting another SPI flash to the SPI1 header pins. > >> > >> Signed-off-by: Andre Przywara > >> --- > >> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 54 ++++++++++++++++++++ > >> 1 file changed, 54 insertions(+) > >> > >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64= /boot/dts/allwinner/sun50i-h6.dtsi > >> index 3329283e38ab..40835850893e 100644 > >> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > >> @@ -338,6 +338,30 @@ > >> bias-pull-up; > >> }; > >> > >> + /omit-if-no-ref/ > >> + spi0_pins: spi0-pins { > >> + pins =3D "PC0", "PC2", "PC3"; > >> + function =3D "spi0"; > >> + }; > >> + > >> + /omit-if-no-ref/ > >> + spi0_cs_pin: spi0-cs-pin { > >> + pins =3D "PC5"; > >> + function =3D "spi0"; > >> + }; > > > > It seems suspicious to use it in the Pine H64, since PC5 is also used > > by the eMMC (and this prevents either the SPI or the emmc controller > > to probe, depending on which probed first). > > Argh, good catch! I saw that AW changed the pin sharing between SPI and > MMC2 slightly, but didn't actually check that they made it worse :-( > Because this time it's the MMC CMD pin affected, and not the somewhat > optional DS pin as in the A64. > So I see we can't really have both at the same time. So what about this: > > We keep the SPI flash chip described as in patch 2/2 (as it's soldered > on every board), but mark it as disabled and explain this in a comment. > This way we can't access it under Linux, but keep a potential eMMC chip > accessible. > > In U-Boot's DT copy we could deviate and mark it as "okay", as U-Boot > doesn't use both eMMC and SPI at the same time. I need to check whether > this works or we would need to move the pinmux setup out of the probe > routine into something later. > > And we could go one step further: If U-Boot detects an eMMC connected > (it's on a socket and so optional), it changes the SPI flash status to > "disabled", to allow EFI apps and kernels using this DT to access the > eMMC - which is far more useful than the SPI flash. > Otherwise (no eMMC connected) it can stay at "okay", as there would be > no conflict. > > Does this make sense? It does, it seems like a good plan Maxime --ir7fewqs7mlcjtw5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXhwxcQAKCRDj7w1vZxhR xeN3AP472p91nx9oqXRJe6+0u8r0T386EdVwUUHUSJGHeqdtzwEA8UiwW9E3F42A /XZ5acoOflKaj0ShNtTko85S2oaFWQM= =8bva -----END PGP SIGNATURE----- --ir7fewqs7mlcjtw5-- 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.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS 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 ACA6AC33CA8 for ; Mon, 13 Jan 2020 08:59:37 +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 7FAE72075B for ; Mon, 13 Jan 2020 08:59:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="tyF79N4P"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Oi9IO6MW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7FAE72075B 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+infradead-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.20170209; h=Sender: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-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oWyrVvTYMEzECkNZxFtDi1TwfW/H3Jg9K/1pdwGYgiA=; b=tyF79N4Pma9EBK2MSjBlBiUco 17DzVSrG0eIhxOF91+a8W/iO2aeVC5XT9sfz1yTTOcdGEOHgGZNh547dqa0H8VIlBSV9dL4KsvyFX MJdHBdiljuXeAqszvzMlGTr49qtqKktnikKCrn77eEHGxEXw8q+JW9MHvjIuC6muXRKXGAbaxUVJ4 svNVaj4ExDWvVbqSqr4iYF1JbpwfUXlJ1+HlBBXs5XHuNhghXEldLsgiKB+/dyj11vQLSwMv57jOw 2op3eyrYnrseGWoZXbgicQlKtLCQPL2N2CPccEr8rWX0d+tLkYy/C0P12zWbcTdaV0d/0FPrmqQKC nzFlcEDmg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iqvZQ-0002Yn-Pt; Mon, 13 Jan 2020 08:59:36 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iqvZN-0002YQ-Mw for linux-arm-kernel@lists.infradead.org; Mon, 13 Jan 2020 08:59:35 +0000 Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4A09820678; Mon, 13 Jan 2020 08:59:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578905972; bh=JfZwSTOrI3J7CIa5OdM8C3bfShk23rBqMg7ZmqPnXd0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Oi9IO6MWKgGI+YoNaP20pa1l4rq2n7FBdgy/pBOn4XJCDISx2Jdz3ni2uErW4Ldz2 cWG4w1zm8qisUTJI8kAGS2iXzgfSOqAuQwq9GzZNo8NOW7hBs4Wl2kDoXd9byaG6+U TBfAuEQKR39d2TFLq3Hr+4Z3HC0pneZIvN7Sr7ak= Date: Mon, 13 Jan 2020 09:59:29 +0100 From: Maxime Ripard To: =?utf-8?B?QW5kcsOp?= Przywara Subject: Re: [PATCH 1/2] arm64: dts: sun50i: H6: Add SPI controllers nodes and pinmuxes Message-ID: <20200113085929.24iseck4fljw5njh@gilmour.lan> References: <20200108101006.150706-1-andre.przywara@arm.com> <20200108101006.150706-2-andre.przywara@arm.com> <20200111172639.to3lhzros6ca5hj2@gilmour.lan> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200113_005933_795286_774B694B X-CRM114-Status: GOOD ( 29.20 ) 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: Mark Rutland , devicetree@vger.kernel.org, linux-sunxi@googlegroups.com, Rob Herring , linux-spi@vger.kernel.org, Chen-Yu Tsai , Mark Brown , Icenowy Zheng , linux-arm-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============9009682315185840296==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============9009682315185840296== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ir7fewqs7mlcjtw5" Content-Disposition: inline --ir7fewqs7mlcjtw5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 12, 2020 at 03:12:19PM +0000, Andr=E9 Przywara wrote: > On 11/01/2020 17:26, Maxime Ripard wrote: > > Hi Maxime, > > > On Wed, Jan 08, 2020 at 10:10:05AM +0000, Andre Przywara wrote: > >> The Allwinner H6 SoC contains two SPI controllers similar to the H3/A6= 4, > >> but with the added capability of 3-wire and 4-wire operation modes. > >> For now the driver does not support those, but the SPI registers are > >> fully backwards-compatible, just adding bits and registers which were > >> formerly reserved. So we can use the existing driver for the "normal" = SPI > >> modes, for instance to access the SPI NOR flash soldered on the PineH64 > >> board. > >> We use an H6 specific compatible string in addition to the existing H3 > >> string, so when the driver later gains Quad SPI support, it should work > >> automatically without any DT changes. > >> > >> Tested by accessing the SPI flash on a Pine H64 board (SPI0), also > >> connecting another SPI flash to the SPI1 header pins. > >> > >> Signed-off-by: Andre Przywara > >> --- > >> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 54 ++++++++++++++++++++ > >> 1 file changed, 54 insertions(+) > >> > >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64= /boot/dts/allwinner/sun50i-h6.dtsi > >> index 3329283e38ab..40835850893e 100644 > >> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > >> @@ -338,6 +338,30 @@ > >> bias-pull-up; > >> }; > >> > >> + /omit-if-no-ref/ > >> + spi0_pins: spi0-pins { > >> + pins =3D "PC0", "PC2", "PC3"; > >> + function =3D "spi0"; > >> + }; > >> + > >> + /omit-if-no-ref/ > >> + spi0_cs_pin: spi0-cs-pin { > >> + pins =3D "PC5"; > >> + function =3D "spi0"; > >> + }; > > > > It seems suspicious to use it in the Pine H64, since PC5 is also used > > by the eMMC (and this prevents either the SPI or the emmc controller > > to probe, depending on which probed first). > > Argh, good catch! I saw that AW changed the pin sharing between SPI and > MMC2 slightly, but didn't actually check that they made it worse :-( > Because this time it's the MMC CMD pin affected, and not the somewhat > optional DS pin as in the A64. > So I see we can't really have both at the same time. So what about this: > > We keep the SPI flash chip described as in patch 2/2 (as it's soldered > on every board), but mark it as disabled and explain this in a comment. > This way we can't access it under Linux, but keep a potential eMMC chip > accessible. > > In U-Boot's DT copy we could deviate and mark it as "okay", as U-Boot > doesn't use both eMMC and SPI at the same time. I need to check whether > this works or we would need to move the pinmux setup out of the probe > routine into something later. > > And we could go one step further: If U-Boot detects an eMMC connected > (it's on a socket and so optional), it changes the SPI flash status to > "disabled", to allow EFI apps and kernels using this DT to access the > eMMC - which is far more useful than the SPI flash. > Otherwise (no eMMC connected) it can stay at "okay", as there would be > no conflict. > > Does this make sense? It does, it seems like a good plan Maxime --ir7fewqs7mlcjtw5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXhwxcQAKCRDj7w1vZxhR xeN3AP472p91nx9oqXRJe6+0u8r0T386EdVwUUHUSJGHeqdtzwEA8UiwW9E3F42A /XZ5acoOflKaj0ShNtTko85S2oaFWQM= =8bva -----END PGP SIGNATURE----- --ir7fewqs7mlcjtw5-- --===============9009682315185840296== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============9009682315185840296==--