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 DD489C433EF for ; Wed, 24 Nov 2021 14:18:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355816AbhKXOVi (ORCPT ); Wed, 24 Nov 2021 09:21:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350704AbhKXOVE (ORCPT ); Wed, 24 Nov 2021 09:21:04 -0500 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F08EEC11223C for ; Wed, 24 Nov 2021 04:46:59 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id y13so9749644edd.13 for ; Wed, 24 Nov 2021 04:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QNxbdxvY1XGwJO5BhsvGP2g9FnaYCe6z/c5imeKTCQc=; b=JAO/GeWYxrwEZ+KX7CN1FibY0RaYaYDktQMXfAGDm6HVGGFB8u3qG7/sKMMalnK5V/ y+nL/khR63DpUwXJpS1dhQQV6ddEDo9nbmUBxbrwsGjbof5O4fOcSJgRfc9f2gdDx8Ye 5GZhrudR0PunvfEXr9OgrZEdnJ9KRMq154DpIDlQ8CY6cXdv7DSbAegAX8vkhR/mh505 JzdqlAUdf1b1BgOwmLbU2B1PziiNESeZ2vUty/cbK/DiWTjLvMQtq5bypBCcLiOkBr9a aHYFAxW7X6PzMqlmsJCe4aVB6M9Zl274zvr6M/C4Ht0BgSTT4Cu4prTQzU/bXfYwIZl9 3o7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QNxbdxvY1XGwJO5BhsvGP2g9FnaYCe6z/c5imeKTCQc=; b=03cRkx4f4Tf1N9n9sRuYHnxcW2sZUjX2cE/2HCcj94kj0bOFFgZEmE9wU7WpBVgrFE T7CTsV9QiQEQdhm7Qee4pavU0dXzkmstM7LW03llrGwtgfD7D0FUbe1Osw5KCgu2hRo+ J2PcqK3y2H1smPf18ISxQz0SjZOhJVjT5c77WlzldMsSQ1RcwGRIgMcyfNhpSP83U5K9 qX23CX4J0VSbxqDMoe+0ok+N981BlOx4QgdHTvkjbox4gPCn+OPbho5JC+tjB3GMs+v9 X4g24vlAv/OlJ8HkAbvz3ngMArIbE+hDzRjXqcf3mJAOhxcEbc0bTig5pRlGlDJwaCAV VAlA== X-Gm-Message-State: AOAM532d6LefK46KgF8YKervmjPjnmN8RpRReNzgpARUDbiasj7VeOtF Xe7zVVV9fQZBkXWU7T8ocYZlHeI+mDORQ4Ma1QmVEw== X-Google-Smtp-Source: ABdhPJyA+W15t1CjEV/znDfMRF9pbH794hXE1Mz4w5XFk6DeON2vEQHijf1ymInLVeDutAJkzB74uutR0+T/MJu13wM= X-Received: by 2002:a05:6402:1e93:: with SMTP id f19mr24830673edf.60.1637758018580; Wed, 24 Nov 2021 04:46:58 -0800 (PST) MIME-Version: 1.0 References: <20210518155013.45622-1-andriy.shevchenko@linux.intel.com> <20210518232451.GA7362@sol> <20210519080434.GA22854@sol> In-Reply-To: From: Bartosz Golaszewski Date: Wed, 24 Nov 2021 13:46:47 +0100 Message-ID: Subject: Re: [PATCH v1 1/2] gpiolib: Never return internal error codes to user space To: Andy Shevchenko Cc: Bartosz Golaszewski , Kent Gibson , linux-gpio , LKML , Linus Walleij , Suresh Balakrishnan Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 23, 2021 at 8:16 PM Andy Shevchenko wrote: > > On Thu, May 20, 2021 at 04:39:50PM +0200, Bartosz Golaszewski wrote: > > On Thu, May 20, 2021 at 3:15 PM Andy Shevchenko > > wrote: > > > > > > On Thu, May 20, 2021 at 4:08 PM Bartosz Golaszewski > > > wrote: > > > > On Wed, May 19, 2021 at 10:30 AM Andy Shevchenko > > > > wrote: > > > > > On Wed, May 19, 2021 at 04:04:34PM +0800, Kent Gibson wrote: > > > > > > On Wed, May 19, 2021 at 10:45:16AM +0300, Andy Shevchenko wrote: > > > > > > > On Wed, May 19, 2021 at 07:24:51AM +0800, Kent Gibson wrote: > > > > > > > > On Tue, May 18, 2021 at 06:50:12PM +0300, Andy Shevchenko wrote: > > > > > > ... > > > > > > > > > > > > Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") > > > > > > > > > Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") > > > > > > > > > Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") > > > > > > ... > > > > > > > > > > > You immediately revert this patch in patch 2. > > > > > > > > My understanding is that is not allowed within a patch set. > > > > > > > > > > > > > > > Why split the patches instead of going direct to the new helper? > > > > > > > > > > > > > > It's for backporting to make it easier. (I deliberately left the context above) > > > > > > > > > > > > > > I can fold them if maintainers think it's okay to do. > > > > > > > > > > > > > > > > > > > Not sure what the constraints are on backporting, but wouldn't it be > > > > > > simpler and cleaner to backport the new helper? > > > > > > > > > > Logically (and ideally) it would be three different patches: > > > > > 1) introduce helper > > > > > 2) use helper > > > > > 3) fix places where it's needed to be done > > > > > > > > > > But the above scheme doesn't fit backporting idea (we don't backport new > > > > > features and APIs without really necessity). So, the options left are: > > > > > > > > > > Option a: One patch (feels a bit like above) > > > > > Option b: Two patches like in this series (yes, you are correct about > > > > > disadvantages) > > > > > > > > > > > But, as you say, it is the maintainers' call. > > > > > > > Third option is to backport this patch but apply the helper > > > > immediately to master. > > > > > > If I got you correctly, you want to have two patches, one for > > > backporting and one for current, correct? But how can we backport > > > something which has never been upstreamed? > > > > > > > Well we would not technically backport anything - there would be one > > patch for mainline and a separate fix for stable. > > So, what should I do here? Send a separate patch for stable branches that fixes the issue and fold this patch into the next one in the series for master. Bart