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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A289AECAAD8 for ; Fri, 16 Sep 2022 15:30:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230238AbiIPPau convert rfc822-to-8bit (ORCPT ); Fri, 16 Sep 2022 11:30:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229479AbiIPPat (ORCPT ); Fri, 16 Sep 2022 11:30:49 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A9305AC75 for ; Fri, 16 Sep 2022 08:30:49 -0700 (PDT) Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MTdFh6xV9z67MnF; Fri, 16 Sep 2022 23:26:16 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (7.191.163.240) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 16 Sep 2022 17:30:47 +0200 Received: from localhost (10.202.226.42) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 16 Sep 2022 16:30:46 +0100 Date: Fri, 16 Sep 2022 16:30:43 +0100 From: Jonathan Cameron To: Nuno =?ISO-8859-1?Q?S=E1?= CC: Jonathan Cameron , Nuno =?ISO-8859-1?Q?S=E1?= , , Michael Hennerich , Lars-Peter Clausen Subject: Re: [PATCH 0/2] ad5593r fix read protocol Message-ID: <20220916163043.000059b3@huawei.com> In-Reply-To: References: <20220913073413.140475-1-nuno.sa@analog.com> <20220915153836.7f8ef80e@jic23-huawei> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.202.226.42] X-ClientProxiedBy: lhrpeml500001.china.huawei.com (7.191.163.213) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org On Fri, 16 Sep 2022 08:05:29 +0200 Nuno Sá wrote: > On Thu, 2022-09-15 at 15:38 +0100, Jonathan Cameron wrote: > > On Tue, 13 Sep 2022 09:34:11 +0200 > > Nuno Sá wrote: > > > > > This patchset fixes the read protocol since it needs a STOP > > > condition > > > between address write and data read. > > > > > > The second change is trivial and only adds an i2c functionality > > > check. > > > > Given we are late in the cycle, I've queued this up for the next > > merge > > window, with a stable tag for the first paatch so it'll get > > backported > > after the merge window. > > > > > > Alright. BTW, not sure If I already asked this but do you have any > preference with regards to CCing stable? Should I have done it when > submitting or do you prefer to handle it yourself? Generally I prefer submitters to not tag for stable and let me make that decision. Often I'll decide to not tag because I'm a little worried about a fix and want it to be in mainline a little while before we backport. I don't mind people sending explicit backport requests though once it's soaked a bit. Mind you, these days the scripts that check for possible fixes often pick these up before I've gotten to sending a backport request. Sometimes I send a note when that happens to ask for it to soak longer, but mostly the delay is enough that I'm happy the patch got enough soaking before that happens. Occasionally I just forget to tag with stable. If that happens then I'm fine with a request to pick it up being sent out once it is upstream! Jonathan > > - Nuno Sá > >