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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1ECF9C433EF for ; Mon, 27 Sep 2021 11:33:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F105660F6B for ; Mon, 27 Sep 2021 11:33:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234054AbhI0Ley (ORCPT ); Mon, 27 Sep 2021 07:34:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234030AbhI0Les (ORCPT ); Mon, 27 Sep 2021 07:34:48 -0400 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CB36C061575; Mon, 27 Sep 2021 04:33:10 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id lb1-20020a17090b4a4100b001993f863df2so13370086pjb.5; Mon, 27 Sep 2021 04:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=MT15ILJvdwdfJ0S3xCwu9KIiLxiliiJmv2UXlemUS9k=; b=CP9rsMVtkPtI1TX4WVrmWdZ5EB8v1jE7T7hIQ+aKIj7w0UIslwSMPgxsSWPNxDp3fM 9SmAF+8jK2bRThTIxrfPL+ce24bHfYAfXleEeH5FL329lgjUTzWa+5NAaLt4LgDcnIDt 5U2P50ejKTJp0mjYlTmr+Ky8b6hf09aUcWRI8yUWeEjeDPikWZpq0dlgptfV7F+UOCpB ZxgcsAkvOQGuCs2DIL5DRvGaqFIM+SUYzjCtIrR+JR6RhakDVqzGzDp20PWriUsEs3xF GNXVmPU4cWydQ1hVf2x8sGWupISaA1gYMsgZknK7b/tm461NRTNoXrg+VpzjmjRbUqcn ewCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=MT15ILJvdwdfJ0S3xCwu9KIiLxiliiJmv2UXlemUS9k=; b=Nqz037nnbaCUzmCvGbYT9iV4PDma5zq+9v48NNV/8wXXk4oco2dKSwz55nsWpMCCqR mXbPWMTfJXa8CD2dcvR6uaQG41Ih1aY3+gS7+wvTFuBccTLQvaRjvK/hlCtuKO3TuM43 JIXid2vLKLn6h/wbAxhkn4cfGzBf+M1UNAz/0oN0A+giKaZguVgiRaD6U4McNJd68+Ul 7rhEKXwkcxjtBgfLbOa3roP2YhxglyNMJAjdFOQWjejpE+dvzL2ZU/1OzBchETTafoY9 UOgAfNLsHrEz1bf8iw/z65HMb98CGMVOZLqeU0iuKQ+LygOyza4QhtqIPMB6Y5Vi2qih o75g== X-Gm-Message-State: AOAM532ZQKInLFxhTc/ps3C+7WAGfSPL7QiETD5IcdqmvK39bw8G2gII ttHaObgdQdYNd6aTmuLOnn4= X-Google-Smtp-Source: ABdhPJy+c7oavzzGB1I9sxfTfZAjkTwkMzpRzOHevsnj/eF21dgXZmGd2I5XE8ZTm33UIoLmJUZkQg== X-Received: by 2002:a17:90a:19e:: with SMTP id 30mr19124557pjc.131.1632742390212; Mon, 27 Sep 2021 04:33:10 -0700 (PDT) Received: from shinobu (113x37x72x25.ap113.ftth.ucom.ne.jp. [113.37.72.25]) by smtp.gmail.com with ESMTPSA id w142sm16865891pfc.47.2021.09.27.04.33.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Sep 2021 04:33:09 -0700 (PDT) Date: Mon, 27 Sep 2021 20:33:00 +0900 From: William Breathitt Gray To: Jonathan Cameron Cc: Jonathan Cameron , linux-stm32@st-md-mailman.stormreply.com, kernel@pengutronix.de, a.fatoum@pengutronix.de, kamel.bouhara@bootlin.com, gwendal@chromium.org, alexandre.belloni@bootlin.com, david@lechnology.com, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, syednwaris@gmail.com, patrick.havelange@essensium.com, fabrice.gasnier@st.com, mcoquelin.stm32@gmail.com, alexandre.torgue@st.com, o.rempel@pengutronix.de, jarkko.nikula@linux.intel.com, Dan Carpenter Subject: Re: [PATCH v16 07/14] counter: Add character device interface Message-ID: References: <422c765c91d060cdebc4f17f7aeb255d9c1a4e16.1630031207.git.vilhelm.gray@gmail.com> <20210912171821.54af145b@jic23-huawei> <20210926161542.5cf99b58@jic23-huawei> <20210927122000.00007d65@Huawei.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qFJe+gs0QSTquwqB" Content-Disposition: inline In-Reply-To: <20210927122000.00007d65@Huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --qFJe+gs0QSTquwqB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 27, 2021 at 12:20:00PM +0100, Jonathan Cameron wrote: > On Mon, 27 Sep 2021 19:21:17 +0900 > William Breathitt Gray wrote: >=20 > > On Sun, Sep 26, 2021 at 04:15:42PM +0100, Jonathan Cameron wrote: > > > On Mon, 20 Sep 2021 19:09:13 +0900 > > > William Breathitt Gray wrote: > > > =20 > > > > On Sun, Sep 12, 2021 at 05:18:42PM +0100, Jonathan Cameron wrote: = =20 > > > > > On Fri, 27 Aug 2021 12:47:51 +0900 > > > > > William Breathitt Gray wrote: > > > > > =20 > > > > > > This patch introduces a character device interface for the Coun= ter > > > > > > subsystem. Device data is exposed through standard character de= vice read > > > > > > operations. Device data is gathered when a Counter event is pus= hed by > > > > > > the respective Counter device driver. Configuration is handled = via ioctl > > > > > > operations on the respective Counter character device node. > > > > > >=20 > > > > > > Cc: David Lechner > > > > > > Cc: Gwendal Grignou > > > > > > Cc: Dan Carpenter > > > > > > Cc: Oleksij Rempel > > > > > > Signed-off-by: William Breathitt Gray = =20 > > > > >=20 > > > > > Hi William, > > > > >=20 > > > > > Why the bit based lock? It feels like a mutex_trylock() type app= roach or > > > > > spinlock_trylock() would be a more common solution to this proble= m. > > > > > There is precedence for doing what you have here though so I'm no= t that > > > > > worried about it. =20 > > > >=20 > > > > Hi Jonathan, > > > >=20 > > > > We originally used a mutex for this, but Jarkko discovered that this > > > > produced a warning because chrdev_lock would be held when returning= to > > > > user space: > > > > https://lore.kernel.org/linux-arm-kernel/YOq19zTsOzKA8v7c@shinobu/T= /#m6072133d418d598a5f368bb942c945e46cfab9a5 > > > >=20 > > > > Following David Lechner's suggestion, I decided to reimplement > > > > chrdev_lock as a bitmap using an atomic flag. =20 > > >=20 > > > Ok. I'm not sure bit lock was quite what was intended (as there is o= nly one of them) > > > but I suppose it doesn't greatly matter. =20 > >=20 > > It didn't cross my mind before, but would declaring chrdev_lock as an > > atomic_t be a more appropriate solution here because we have only one > > flag? > >=20 > > William Breathitt Gray > >=20 >=20 > It would be less esoteric. This was the first time I've ever come across= the bitlock stuff > whereas atomics are an every day thing. >=20 > Thanks, >=20 > Jonathan I agree. I'll try that out then and reimplement this using atomic_inc_and_test() instead of test_and_set_bit_lock(). William Breathitt Gray --qFJe+gs0QSTquwqB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAmFRq84ACgkQhvpINdm7 VJKSxw/+K++TD+bpwz9akNC7gg8dm4YlOS7y97Z1JAkS+KcKMbTpdrFJJJbrtIIq 3JJi5iMjTtTsAPPl6Wa1qRCst3ryHR7UTEMJdAy2IR08If2piGn2frklSFH68ejU 0zrSBXnmGPmnVdLudetma4gd6MRY6VVNm8ncTbevE7kgo9QJsYvEFxRsrrf/zeHK WRBTPNexTxSuclwr7WO612XFr7cUg3iIjdyDw2NMZplkLyFR/HSuw5pX62RFKAe3 z7NhkBsYF+FK4IraGP+2HlUHZ0v02iK86uGgUf4gmFM0tUHcEpN78Gd8lMm1XmE2 bIhnhm3vGrgcdINfcaKIHWTw6l8Xs7WjIlI8cHP8Mmw04euXtcAK2RFxxBdjn8kq 47yxGD2tReXUGSBuv7lXeja+kJ5CU1GHOVcetCQ7qjGXl8bxR/3W0vhetb1uxtLn LEfXV18JF2eFuXA0vV0fX9BctKWPREOUFGoB+dE/LhlKUTFg/8E2aVFcD3pg7z9I TBtpGA/mNREX9v4eTDvT5G+cYM44hqfYMMwktyk1pomFfU1L7GFBtNs1l5pU1HvR UoTUkDJw12nIBwcOSslERLdsoikGTyrtoq3NXebrwI2CTL9sTuQ4SkLNp5m7GASn 4GCmOs7Gnc3vUL4E6jwgKclaJqCxtDSfN/PmYQ43qJT6p0bHrIU= =xydv -----END PGP SIGNATURE----- --qFJe+gs0QSTquwqB-- 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CE21C433F5 for ; Mon, 27 Sep 2021 11:35:20 +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 0B07E60F0F for ; Mon, 27 Sep 2021 11:35:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0B07E60F0F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=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-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=rkANtDI6P5QLgLlibArIBcgiRlFIgT51yH0e/lnFsdQ=; b=K5rZwL6qqniI4XI3Co1WtwoMVo QRIQ5un/ENlRTLrqVylBhwYnvrptAZebhcVfcIbnJna0IBFrvUW+Z5UMCXMBofflbchSiWOzHmTat V4GQDVXHjGKFOSpwibfU0HGiFHxj0vkp4gqnpzMzA1cHjRIpk4ToMtNewwwuyofwCzfVifCNXK9BI hngGK57mO59uNMPTxPemO6TxfDlKvhBnf5iEGrvK1MLgFaCqhBzloRDxK+TDFmgrM0UiH2aTTpsFE kivO/b0HVe7orT+PmROHP0Ewy+5F9eQ5jkyDPhNfiK4dFLE8bWobVExL6Xh8HzIqMZfHSlZHnm9yI iJTyBK3w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mUot5-002RWB-F0; Mon, 27 Sep 2021 11:33:35 +0000 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mUot0-002RUf-6t for linux-arm-kernel@lists.infradead.org; Mon, 27 Sep 2021 11:33:33 +0000 Received: by mail-pj1-x102c.google.com with SMTP id lb1-20020a17090b4a4100b001993f863df2so13370085pjb.5 for ; Mon, 27 Sep 2021 04:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=MT15ILJvdwdfJ0S3xCwu9KIiLxiliiJmv2UXlemUS9k=; b=CP9rsMVtkPtI1TX4WVrmWdZ5EB8v1jE7T7hIQ+aKIj7w0UIslwSMPgxsSWPNxDp3fM 9SmAF+8jK2bRThTIxrfPL+ce24bHfYAfXleEeH5FL329lgjUTzWa+5NAaLt4LgDcnIDt 5U2P50ejKTJp0mjYlTmr+Ky8b6hf09aUcWRI8yUWeEjeDPikWZpq0dlgptfV7F+UOCpB ZxgcsAkvOQGuCs2DIL5DRvGaqFIM+SUYzjCtIrR+JR6RhakDVqzGzDp20PWriUsEs3xF GNXVmPU4cWydQ1hVf2x8sGWupISaA1gYMsgZknK7b/tm461NRTNoXrg+VpzjmjRbUqcn ewCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=MT15ILJvdwdfJ0S3xCwu9KIiLxiliiJmv2UXlemUS9k=; b=D49pPo73FEdx77ZMZxppmFALkz+e8+leP4iY4TszCPT7dBiiMDTkXLWt1A/Xpd+MRo UGTqjOH6+XlxGK7BQqdkL4rC629L81ELr2I4EBeA0mxCNK7SA7lwd4Twj6kSClCepf+q lZ0ahyQtE/DKuAX1XaG6c1h6Q/vhLey8lfYpm+sU5K67hgQKyomhK8+UINOu3e5+eoSt F0howamBJQZZyVlZJ1mbWPa+FdjEflK8SUnmrWtk/JY2yNeWPjRpgMkEs6+qIdG6wo0C tRaVhr189M7U/yh8NhQLCE2SrOeHLxSLdD2Sqf4eqN2zD2CWrPWFrfYlujXNFyLMFd+k MGKQ== X-Gm-Message-State: AOAM531Ynt84Io0aImuefl9ibDoNFYhS4oY5EuEUE5P9L9nfMB5JrGlo AWe2rXx58uyYiEquz4iLwJY= X-Google-Smtp-Source: ABdhPJy+c7oavzzGB1I9sxfTfZAjkTwkMzpRzOHevsnj/eF21dgXZmGd2I5XE8ZTm33UIoLmJUZkQg== X-Received: by 2002:a17:90a:19e:: with SMTP id 30mr19124557pjc.131.1632742390212; Mon, 27 Sep 2021 04:33:10 -0700 (PDT) Received: from shinobu (113x37x72x25.ap113.ftth.ucom.ne.jp. [113.37.72.25]) by smtp.gmail.com with ESMTPSA id w142sm16865891pfc.47.2021.09.27.04.33.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Sep 2021 04:33:09 -0700 (PDT) Date: Mon, 27 Sep 2021 20:33:00 +0900 From: William Breathitt Gray To: Jonathan Cameron Cc: Jonathan Cameron , linux-stm32@st-md-mailman.stormreply.com, kernel@pengutronix.de, a.fatoum@pengutronix.de, kamel.bouhara@bootlin.com, gwendal@chromium.org, alexandre.belloni@bootlin.com, david@lechnology.com, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, syednwaris@gmail.com, patrick.havelange@essensium.com, fabrice.gasnier@st.com, mcoquelin.stm32@gmail.com, alexandre.torgue@st.com, o.rempel@pengutronix.de, jarkko.nikula@linux.intel.com, Dan Carpenter Subject: Re: [PATCH v16 07/14] counter: Add character device interface Message-ID: References: <422c765c91d060cdebc4f17f7aeb255d9c1a4e16.1630031207.git.vilhelm.gray@gmail.com> <20210912171821.54af145b@jic23-huawei> <20210926161542.5cf99b58@jic23-huawei> <20210927122000.00007d65@Huawei.com> MIME-Version: 1.0 In-Reply-To: <20210927122000.00007d65@Huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210927_043330_280659_8431C349 X-CRM114-Status: GOOD ( 31.13 ) 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="===============1133072435745744187==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============1133072435745744187== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qFJe+gs0QSTquwqB" Content-Disposition: inline --qFJe+gs0QSTquwqB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 27, 2021 at 12:20:00PM +0100, Jonathan Cameron wrote: > On Mon, 27 Sep 2021 19:21:17 +0900 > William Breathitt Gray wrote: >=20 > > On Sun, Sep 26, 2021 at 04:15:42PM +0100, Jonathan Cameron wrote: > > > On Mon, 20 Sep 2021 19:09:13 +0900 > > > William Breathitt Gray wrote: > > > =20 > > > > On Sun, Sep 12, 2021 at 05:18:42PM +0100, Jonathan Cameron wrote: = =20 > > > > > On Fri, 27 Aug 2021 12:47:51 +0900 > > > > > William Breathitt Gray wrote: > > > > > =20 > > > > > > This patch introduces a character device interface for the Coun= ter > > > > > > subsystem. Device data is exposed through standard character de= vice read > > > > > > operations. Device data is gathered when a Counter event is pus= hed by > > > > > > the respective Counter device driver. Configuration is handled = via ioctl > > > > > > operations on the respective Counter character device node. > > > > > >=20 > > > > > > Cc: David Lechner > > > > > > Cc: Gwendal Grignou > > > > > > Cc: Dan Carpenter > > > > > > Cc: Oleksij Rempel > > > > > > Signed-off-by: William Breathitt Gray = =20 > > > > >=20 > > > > > Hi William, > > > > >=20 > > > > > Why the bit based lock? It feels like a mutex_trylock() type app= roach or > > > > > spinlock_trylock() would be a more common solution to this proble= m. > > > > > There is precedence for doing what you have here though so I'm no= t that > > > > > worried about it. =20 > > > >=20 > > > > Hi Jonathan, > > > >=20 > > > > We originally used a mutex for this, but Jarkko discovered that this > > > > produced a warning because chrdev_lock would be held when returning= to > > > > user space: > > > > https://lore.kernel.org/linux-arm-kernel/YOq19zTsOzKA8v7c@shinobu/T= /#m6072133d418d598a5f368bb942c945e46cfab9a5 > > > >=20 > > > > Following David Lechner's suggestion, I decided to reimplement > > > > chrdev_lock as a bitmap using an atomic flag. =20 > > >=20 > > > Ok. I'm not sure bit lock was quite what was intended (as there is o= nly one of them) > > > but I suppose it doesn't greatly matter. =20 > >=20 > > It didn't cross my mind before, but would declaring chrdev_lock as an > > atomic_t be a more appropriate solution here because we have only one > > flag? > >=20 > > William Breathitt Gray > >=20 >=20 > It would be less esoteric. This was the first time I've ever come across= the bitlock stuff > whereas atomics are an every day thing. >=20 > Thanks, >=20 > Jonathan I agree. I'll try that out then and reimplement this using atomic_inc_and_test() instead of test_and_set_bit_lock(). William Breathitt Gray --qFJe+gs0QSTquwqB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAmFRq84ACgkQhvpINdm7 VJKSxw/+K++TD+bpwz9akNC7gg8dm4YlOS7y97Z1JAkS+KcKMbTpdrFJJJbrtIIq 3JJi5iMjTtTsAPPl6Wa1qRCst3ryHR7UTEMJdAy2IR08If2piGn2frklSFH68ejU 0zrSBXnmGPmnVdLudetma4gd6MRY6VVNm8ncTbevE7kgo9QJsYvEFxRsrrf/zeHK WRBTPNexTxSuclwr7WO612XFr7cUg3iIjdyDw2NMZplkLyFR/HSuw5pX62RFKAe3 z7NhkBsYF+FK4IraGP+2HlUHZ0v02iK86uGgUf4gmFM0tUHcEpN78Gd8lMm1XmE2 bIhnhm3vGrgcdINfcaKIHWTw6l8Xs7WjIlI8cHP8Mmw04euXtcAK2RFxxBdjn8kq 47yxGD2tReXUGSBuv7lXeja+kJ5CU1GHOVcetCQ7qjGXl8bxR/3W0vhetb1uxtLn LEfXV18JF2eFuXA0vV0fX9BctKWPREOUFGoB+dE/LhlKUTFg/8E2aVFcD3pg7z9I TBtpGA/mNREX9v4eTDvT5G+cYM44hqfYMMwktyk1pomFfU1L7GFBtNs1l5pU1HvR UoTUkDJw12nIBwcOSslERLdsoikGTyrtoq3NXebrwI2CTL9sTuQ4SkLNp5m7GASn 4GCmOs7Gnc3vUL4E6jwgKclaJqCxtDSfN/PmYQ43qJT6p0bHrIU= =xydv -----END PGP SIGNATURE----- --qFJe+gs0QSTquwqB-- --===============1133072435745744187== 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 --===============1133072435745744187==--