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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 2F4ECC433B4 for ; Mon, 12 Apr 2021 07:02:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E6EE61206 for ; Mon, 12 Apr 2021 07:02:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236760AbhDLHDJ (ORCPT ); Mon, 12 Apr 2021 03:03:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236705AbhDLHDH (ORCPT ); Mon, 12 Apr 2021 03:03:07 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0570EC061574 for ; Mon, 12 Apr 2021 00:02:50 -0700 (PDT) Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lVqah-0002Yf-Kn; Mon, 12 Apr 2021 09:02:35 +0200 Received: from ukl by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1lVqae-00059Z-JF; Mon, 12 Apr 2021 09:02:32 +0200 Date: Mon, 12 Apr 2021 09:02:32 +0200 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Nobuhiro Iwamatsu Cc: Rob Herring , Thierry Reding , Lee Jones , devicetree@vger.kernel.org, linux-pwm@vger.kernel.org, punit1.agrawal@toshiba.co.jp, yuji2.ishikawa@toshiba.co.jp, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support Message-ID: <20210412070232.6q3cgqvuj53p4cmi@pengutronix.de> References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp> <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp> <20210410135321.oissremqropvrpd3@pengutronix.de> <20210412025536.i5chpp6sighunvfx@toshiba.co.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dbinp4a6o4qjki4w" Content-Disposition: inline In-Reply-To: <20210412025536.i5chpp6sighunvfx@toshiba.co.jp> X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --dbinp4a6o4qjki4w Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 12, 2021 at 11:55:36AM +0900, Nobuhiro Iwamatsu wrote: > Hi Uwe, >=20 > Thanks for your review. >=20 > On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe Kleine-K=F6nig wrote: > > Hello, > >=20 > > just a few small details left to criticize ... > >=20 > > On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote: > > > diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c > > > new file mode 100644 > > > index 000000000000..99d83f94ed86 > > > --- /dev/null > > > +++ b/drivers/pwm/pwm-visconti.c > > > @@ -0,0 +1,188 @@ > > > +// SPDX-License-Identifier: GPL-2.0-only > > > +/* > > > + * Toshiba Visconti pulse-width-modulation controller driver > > > + * > > > + * Copyright (c) 2020 TOSHIBA CORPORATION > > > + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporati= on > > > + * > > > + * Authors: Nobuhiro Iwamatsu > > > + * > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#define PIPGM_PCSR(ch) (0x400 + 4 * (ch)) > > > +#define PIPGM_PDUT(ch) (0x420 + 4 * (ch)) > > > +#define PIPGM_PWMC(ch) (0x440 + 4 * (ch)) > > > + > > > +#define PIPGM_PWMC_PWMACT BIT(5) > > > +#define PIPGM_PWMC_CLK_MASK GENMASK(1, 0) > > > +#define PIPGM_PWMC_POLARITY_MASK GENMASK(5, 5) > > > + > > > +struct visconti_pwm_chip { > > > + struct pwm_chip chip; > > > + void __iomem *base; > > > +}; > > > + > > > +static inline struct visconti_pwm_chip *to_visconti_chip(struct pwm_= chip *chip) > > > +{ > > > + return container_of(chip, struct visconti_pwm_chip, chip); > > > +} > > > + > > > +static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_devi= ce *pwm, > > > + const struct pwm_state *state) > > > +{ > > > + struct visconti_pwm_chip *priv =3D to_visconti_chip(chip); > > > + u32 period, duty_cycle, pwmc0; > > > + > > > + /* > > > + * pwmc is a 2-bit divider for the input clock running at 1 MHz. > > > + * When the settings of the PWM are modified, the new values are sh= adowed in hardware until > > > + * the period register (PCSR) is written and the currently running = period is completed. This > > > + * way the hardware switches atomically from the old setting to the= new. > > > + * Also, disabling the hardware completes the currently running per= iod and keeps the output > > > + * at low level at all times. > >=20 > > Can you please put a paragraph analogous to the one in pwm-sifive in the > > same format. This simplified keeping an overview about the oddities of > > the various supported chips. >=20 > OK, I will check pwm-sifive's, and add. >=20 > >=20 > > > + */ > > > + if (!state->enabled) { > > > + writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm)); > > > + return 0; > > > + } > > > + > > > [...] > > > + > > > +static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm= _device *pwm, > > > + struct pwm_state *state) > > > +{ > > > + struct visconti_pwm_chip *priv =3D chip_to_priv(chip); > > > + u32 period, duty, pwmc0, pwmc0_clk; > > > + > > > + period =3D readl(priv->base + PIPGM_PCSR(pwm->hwpwm)); > > > + if (period) > > > + state->enabled =3D true; > > > + else > > > + state->enabled =3D false; > >=20 > > If PIPGM_PCSR is 0 the hardware is still active and setting a new > > configuration completes the currently running period, right? Then I > > think having always state->enabled =3D true is a better match. > > If PIPGM_PCSR is 0, the hardware is stopped. Even if the settings of > other registers are written, the values of other registers will not work > unless PIPGM_PCSR is written. Correct me if I'm wrong, but how I understand it, PCSR is special as the other registers are shadow until PCSR is written. (And that is irrespective of which value is active in PCSR or what is written to PCSR.) =20 > However, as a logic, if PIPGM_PCSR becomes 0, it is only > visconti_pwm_apply () in this driver, > so I think that this process should always be state-> enabled =3D true > as you pointed out. > I wil drop this, thanks. For me the critical (and only) difference between "off" and "duty cycle =3D 0" is that when a new configuration is to be applied. In the "off" state a new period can (and should) start immediately, while with "duty_cycle =3D 0" the rising edge should be delayed until the currently running period is over.[1] So the thing to do here (IMHO) is: Iff with PIPGM_PCSR =3D 0 configuring a new setting (that is finalized with writing a non-zero value to PIPGM_PCSR) completes the currently running period, then always assume the PWM as enabled. And so if the hardware is stopped and the counter is reset when 0 is written to PIPGM_PCSR, model that as enabled =3D false. Best regards Uwe [1] In practise this is more difficult because several PWMs don't complete periods in general. But the hardware under discussion luckily isn't one of these. And (worse) there are other hardware implementations where off doesn't emit an inactive level. --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --dbinp4a6o4qjki4w Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmBz8IUACgkQwfwUeK3K 7Anv+ggAgcYjZXZNUVrkCgcupmpCm3IMfKahkwjrc5xduTQHdRPMTqPrJhyuwF7a G8bOQ5pxUHH5MEqns/nG8HTPawjKDgy36NLfDdY7yDQdKT15PsvXkHD6wUydcXzd Hn41ovzjGJUi4bkqjI8iLwCARX6ypaKh66IVZ/yRjJA1B2FkCbqfRgE8PHu78NJd GU+OrhCgmXyJ5e7FAcfDn5dlMVTpHbzxyGouC8PXtCCFgC5YLy2+Ajp3Y2ldv5Qs ceQ7LOzHqJ4NsiBq74KTOUFo2lTMZW9kzLl/upBxEhh/7jLRlJHFmx4jyb/LJOKe V+HuRxtoXSlhoOcb2azTl12IPVESZw== =+9VN -----END PGP SIGNATURE----- --dbinp4a6o4qjki4w-- 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=-8.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,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 7F916C433ED for ; Mon, 12 Apr 2021 07:04:40 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 1C1FE60FDB for ; Mon, 12 Apr 2021 07:04:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C1FE60FDB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de 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=desiato.20200630; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc: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=wZihNH5raHP+fceVBVot+bZdK21sHDbMIxOjY+5iId8=; b=m4J/C09qAJO+6SXmbx4pIAGEW Ghwy2a7pp26nXMOqlGXQ67wG5uaG6COqMxeFl6NIEnIHqrnXKeqIcKfDmxx82qK8chQYZ6QN0FuNn UTHYbY2D1p/OTt4xoOG6AXlnyvJcx809fa85rBkRUFTZXswurOjNMvGM/nFG7llaPqxqGgGBxBXs2 RapJjnklcN59ZoO1a6p4Ci9WCSNhXgRyQMv5pTzVdyfSGmdFZL4RW53olrVDyLgyfpUsRq5zTISha RBql1aioisq9x1+BNwjpNkqa4X1om6OdLXkw4lCVl0nrwEZLyt4DHDmMsG5IU05A6KtQKxP/aF+eN Djrg6lqmg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lVqb1-005tm0-M4; Mon, 12 Apr 2021 07:02:55 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lVqay-005tlo-2Y for linux-arm-kernel@desiato.infradead.org; Mon, 12 Apr 2021 07:02:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=lQqtD3PJuKvlGT5XP/FDxUHlnr6uYWm4smsYBFFkR48=; b=PqlUhp/095nzSr4Dd6jzgL6dMg V+lzyyuZsT/qcI4BadBqzhfU7XTwx2eXQDA7apQBq9hssLyC21dwORdG2qXDUAS3gh0wZ6nMnCHVV QNAMUHj+r5UK2N03aAlnCRD/F0wzsyxqcb1S7C6Rck4E0sqZ151Op17ilqvtapEKUsATRteyzjO0v DRxmpN3Jm+NngqHMv8AU4/AAgDFgUZtVHYhlpc7BHgmu/1SqrWPXwdwe6X1ObivMvYDi83K+DAxFj FYgWBv25T2Z4/GoB5dBRzYrxr9vBqe4Kda+CKD3gvI6DgJ1HnRIqHGRDMw+zcd6Ek6bUzWZt9Uphb /ojK+LEw==; Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lVqau-005uvJ-Mb for linux-arm-kernel@lists.infradead.org; Mon, 12 Apr 2021 07:02:50 +0000 Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lVqah-0002Yf-Kn; Mon, 12 Apr 2021 09:02:35 +0200 Received: from ukl by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1lVqae-00059Z-JF; Mon, 12 Apr 2021 09:02:32 +0200 Date: Mon, 12 Apr 2021 09:02:32 +0200 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Nobuhiro Iwamatsu Cc: Rob Herring , Thierry Reding , Lee Jones , devicetree@vger.kernel.org, linux-pwm@vger.kernel.org, punit1.agrawal@toshiba.co.jp, yuji2.ishikawa@toshiba.co.jp, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support Message-ID: <20210412070232.6q3cgqvuj53p4cmi@pengutronix.de> References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp> <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp> <20210410135321.oissremqropvrpd3@pengutronix.de> <20210412025536.i5chpp6sighunvfx@toshiba.co.jp> MIME-Version: 1.0 In-Reply-To: <20210412025536.i5chpp6sighunvfx@toshiba.co.jp> X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210412_000248_764328_27EF693A X-CRM114-Status: GOOD ( 43.87 ) 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: , Content-Type: multipart/mixed; boundary="===============3730956287781569139==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============3730956287781569139== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dbinp4a6o4qjki4w" Content-Disposition: inline --dbinp4a6o4qjki4w Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 12, 2021 at 11:55:36AM +0900, Nobuhiro Iwamatsu wrote: > Hi Uwe, >=20 > Thanks for your review. >=20 > On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe Kleine-K=F6nig wrote: > > Hello, > >=20 > > just a few small details left to criticize ... > >=20 > > On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote: > > > diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c > > > new file mode 100644 > > > index 000000000000..99d83f94ed86 > > > --- /dev/null > > > +++ b/drivers/pwm/pwm-visconti.c > > > @@ -0,0 +1,188 @@ > > > +// SPDX-License-Identifier: GPL-2.0-only > > > +/* > > > + * Toshiba Visconti pulse-width-modulation controller driver > > > + * > > > + * Copyright (c) 2020 TOSHIBA CORPORATION > > > + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporati= on > > > + * > > > + * Authors: Nobuhiro Iwamatsu > > > + * > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#define PIPGM_PCSR(ch) (0x400 + 4 * (ch)) > > > +#define PIPGM_PDUT(ch) (0x420 + 4 * (ch)) > > > +#define PIPGM_PWMC(ch) (0x440 + 4 * (ch)) > > > + > > > +#define PIPGM_PWMC_PWMACT BIT(5) > > > +#define PIPGM_PWMC_CLK_MASK GENMASK(1, 0) > > > +#define PIPGM_PWMC_POLARITY_MASK GENMASK(5, 5) > > > + > > > +struct visconti_pwm_chip { > > > + struct pwm_chip chip; > > > + void __iomem *base; > > > +}; > > > + > > > +static inline struct visconti_pwm_chip *to_visconti_chip(struct pwm_= chip *chip) > > > +{ > > > + return container_of(chip, struct visconti_pwm_chip, chip); > > > +} > > > + > > > +static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_devi= ce *pwm, > > > + const struct pwm_state *state) > > > +{ > > > + struct visconti_pwm_chip *priv =3D to_visconti_chip(chip); > > > + u32 period, duty_cycle, pwmc0; > > > + > > > + /* > > > + * pwmc is a 2-bit divider for the input clock running at 1 MHz. > > > + * When the settings of the PWM are modified, the new values are sh= adowed in hardware until > > > + * the period register (PCSR) is written and the currently running = period is completed. This > > > + * way the hardware switches atomically from the old setting to the= new. > > > + * Also, disabling the hardware completes the currently running per= iod and keeps the output > > > + * at low level at all times. > >=20 > > Can you please put a paragraph analogous to the one in pwm-sifive in the > > same format. This simplified keeping an overview about the oddities of > > the various supported chips. >=20 > OK, I will check pwm-sifive's, and add. >=20 > >=20 > > > + */ > > > + if (!state->enabled) { > > > + writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm)); > > > + return 0; > > > + } > > > + > > > [...] > > > + > > > +static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm= _device *pwm, > > > + struct pwm_state *state) > > > +{ > > > + struct visconti_pwm_chip *priv =3D chip_to_priv(chip); > > > + u32 period, duty, pwmc0, pwmc0_clk; > > > + > > > + period =3D readl(priv->base + PIPGM_PCSR(pwm->hwpwm)); > > > + if (period) > > > + state->enabled =3D true; > > > + else > > > + state->enabled =3D false; > >=20 > > If PIPGM_PCSR is 0 the hardware is still active and setting a new > > configuration completes the currently running period, right? Then I > > think having always state->enabled =3D true is a better match. > > If PIPGM_PCSR is 0, the hardware is stopped. Even if the settings of > other registers are written, the values of other registers will not work > unless PIPGM_PCSR is written. Correct me if I'm wrong, but how I understand it, PCSR is special as the other registers are shadow until PCSR is written. (And that is irrespective of which value is active in PCSR or what is written to PCSR.) =20 > However, as a logic, if PIPGM_PCSR becomes 0, it is only > visconti_pwm_apply () in this driver, > so I think that this process should always be state-> enabled =3D true > as you pointed out. > I wil drop this, thanks. For me the critical (and only) difference between "off" and "duty cycle =3D 0" is that when a new configuration is to be applied. In the "off" state a new period can (and should) start immediately, while with "duty_cycle =3D 0" the rising edge should be delayed until the currently running period is over.[1] So the thing to do here (IMHO) is: Iff with PIPGM_PCSR =3D 0 configuring a new setting (that is finalized with writing a non-zero value to PIPGM_PCSR) completes the currently running period, then always assume the PWM as enabled. And so if the hardware is stopped and the counter is reset when 0 is written to PIPGM_PCSR, model that as enabled =3D false. Best regards Uwe [1] In practise this is more difficult because several PWMs don't complete periods in general. But the hardware under discussion luckily isn't one of these. And (worse) there are other hardware implementations where off doesn't emit an inactive level. --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --dbinp4a6o4qjki4w Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmBz8IUACgkQwfwUeK3K 7Anv+ggAgcYjZXZNUVrkCgcupmpCm3IMfKahkwjrc5xduTQHdRPMTqPrJhyuwF7a G8bOQ5pxUHH5MEqns/nG8HTPawjKDgy36NLfDdY7yDQdKT15PsvXkHD6wUydcXzd Hn41ovzjGJUi4bkqjI8iLwCARX6ypaKh66IVZ/yRjJA1B2FkCbqfRgE8PHu78NJd GU+OrhCgmXyJ5e7FAcfDn5dlMVTpHbzxyGouC8PXtCCFgC5YLy2+Ajp3Y2ldv5Qs ceQ7LOzHqJ4NsiBq74KTOUFo2lTMZW9kzLl/upBxEhh/7jLRlJHFmx4jyb/LJOKe V+HuRxtoXSlhoOcb2azTl12IPVESZw== =+9VN -----END PGP SIGNATURE----- --dbinp4a6o4qjki4w-- --===============3730956287781569139== 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 --===============3730956287781569139==--