Message ID | 20231003145114.21637-5-brgl@bgdev.pl |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp2138960vqb; Tue, 3 Oct 2023 07:51:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IErFB+6bgbzioFos5q95XaqIZmWFWbFHuNGV59FcyLStkiKrmbOaSIgIzBl6Hv7X+BnkoF3 X-Received: by 2002:a17:903:2445:b0:1c4:fae:bf4a with SMTP id l5-20020a170903244500b001c40faebf4amr16836050pls.16.1696344704249; Tue, 03 Oct 2023 07:51:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696344704; cv=none; d=google.com; s=arc-20160816; b=U+GKEf5i75jfpSOWZtc1J4857WfWz24JxEsjCrZaezlD2prBdWV5PP8gbDc8gAzpBZ 30q+It2P2W0lStJoe9wumsRL00MAruRiuirdQI6JCLfeX1Ohcd3C0kJoCvzT3hEWfeHP YSGEs7uRWKC05cnO5LAHwtUY4CqwQ3/rBjunY7yyy6lDD3h/2ue+t1dy4g/aiVwt0NyA 6J2Gl7fEE354jzhpOZnHex0gkr4VRqook7CYLv+5toUbvfWSS5aVmXfmdJ1w9eea+CBn w70k9e+/s8v9ETlKWqXZ7MGpBF90wxPsJS9F2OHE6eFGTJMwwCRVtMxigXICHgwHchp1 47dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=YhFi4LGhC2Y5nFrUut/uRJGJvyUMlfTO1AC2VY89hk8=; fh=YUoJqI9bwQiwY05flNJ/0hnSZHR/oHyv05rJ14tRcQo=; b=k6yoZeVzG5bgmtMZvizXFmU3xFJQKQzc8bWKoBv95TzVsHlqfj7PIX07KOb1GA/fdb oFwvSwr0wI2IQORhjdWKciSONy+iycN/jzyreJC1JDAtlOXspNiaAQRjqZZ9oc/37hiW IsRxQsYpZcnSHIzPbgDxwzsY0SYqbdBnhQ7106AzkfXELDHvYlJ+0VQ3NJCewz1KzkQd IS0yBRwfSN5OVehER0WcW+0gwrmJrUZLb5Vjt5nEyXnnORUbSLBuNE6aoGXtZhwGMW1H HxvNdUAXDaAJ3c4c0PZodPc/RPDCd1Te8akUkgZKELtDWb2qUPAkzoHGqXfZnqT1Hzm+ QIog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=iuvyjCbZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id e6-20020a170902b78600b001c5bb1f0cccsi1489220pls.275.2023.10.03.07.51.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 07:51:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=iuvyjCbZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id AC5DA819A69E; Tue, 3 Oct 2023 07:51:43 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240203AbjJCOvg (ORCPT <rfc822;chrisfriedt@gmail.com> + 17 others); Tue, 3 Oct 2023 10:51:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240197AbjJCOv3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 3 Oct 2023 10:51:29 -0400 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3DAAAF for <linux-kernel@vger.kernel.org>; Tue, 3 Oct 2023 07:51:26 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4064876e8b8so10425265e9.0 for <linux-kernel@vger.kernel.org>; Tue, 03 Oct 2023 07:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20230601.gappssmtp.com; s=20230601; t=1696344685; x=1696949485; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=YhFi4LGhC2Y5nFrUut/uRJGJvyUMlfTO1AC2VY89hk8=; b=iuvyjCbZ78hdbjmZ0dri6ZMBHVwGLWdrU60z4En12fGtM4w10l3wqAWLJBP2mL6bak kDMkgLbKCdovizExDeH4YikokkSLdoxrmDkwnTWGNiouuy/WX3EBCtHSi3fPU+e40Ejj mZ7Za5VTFyUJpHhnr6YyE0RRXUQyOMgkg5ue5LxKZhVIvLYnrNsRChHSmMV3tt3B752g NwKnAsXAGLvmKqLmn5HeD1iugQHA8KOsrvAkLkUypFb9m/r+OW15a4pRcwwQgz+eN5u+ HtAzzxMwBuD+oychOBL9Jpt/vhviSIHhPWkKhcYS89yu0VE2XV03dZPMpOmP7ZRlIb0X fURg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696344685; x=1696949485; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YhFi4LGhC2Y5nFrUut/uRJGJvyUMlfTO1AC2VY89hk8=; b=UBW7eQX/JaYqVIUf9EQXi4maH2cPjVa7aZZO0nTwnMrvJHJGTbKRyUahconFLBhDpr js03PDYzQBlfCcA+dXvd72jaivgRxRuUoNtP0/vhD8cOqbsFsMHmc7zrD8hb6w17OrnN D8Mm+auOiNbwksopZOjl11ysh7e0tO97KUCg3wRV2DVJIVSbpq1qRNqdJLEj1SLFIY1E HfMiu7mEejtsYcZrLIPKsDeQh71CYaqS9QGsY+bDC/G6GrAlsizeAjgRpsAhVGfcQOnE 3xiBnXoHekwR+C7h3bIMGgQbb9z+A/i+mx1OGr2qaWPIZ7fMTHpaTtVTCAegLzBUSAML jBHg== X-Gm-Message-State: AOJu0Yz2g8fB0SciNHSAM0Rvc1JBVkPm6IOG9tSm9wkQIFlYcfi6NPaL IFLRMdV+IcKgDx7IcU40zvgEkA== X-Received: by 2002:a05:600c:3d98:b0:406:52e4:cd23 with SMTP id bi24-20020a05600c3d9800b0040652e4cd23mr12565592wmb.0.1696344685191; Tue, 03 Oct 2023 07:51:25 -0700 (PDT) Received: from brgl-uxlite.home ([2a01:cb1d:334:ac00:1f2d:3479:a5de:fa35]) by smtp.gmail.com with ESMTPSA id c15-20020a05600c0acf00b003fe29f6b61bsm1462773wmr.46.2023.10.03.07.51.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 07:51:24 -0700 (PDT) From: Bartosz Golaszewski <brgl@bgdev.pl> To: Linus Walleij <linus.walleij@linaro.org>, Andy Shevchenko <andy@kernel.org> Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Bartosz Golaszewski <bartosz.golaszewski@linaro.org>, Kent Gibson <warthog618@gmail.com> Subject: [PATCH 04/36] gpio: cdev: use pinctrl_gpio_can_use_line_new() Date: Tue, 3 Oct 2023 16:50:42 +0200 Message-Id: <20231003145114.21637-5-brgl@bgdev.pl> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20231003145114.21637-1-brgl@bgdev.pl> References: <20231003145114.21637-1-brgl@bgdev.pl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 03 Oct 2023 07:51:43 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778746344450604426 X-GMAIL-MSGID: 1778746344450604426 |
Series |
pinctrl: don't use GPIOLIB global numberspace in helpers
|
|
Commit Message
Bartosz Golaszewski
Oct. 3, 2023, 2:50 p.m. UTC
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Use the improved variant of pinctrl_gpio_can_use_line() which takes a pointer to the gpio_chip and a controller-relative offset. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> --- drivers/gpio/gpiolib-cdev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
Comments
On Tue, Oct 03, 2023 at 04:50:42PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Use the improved variant of pinctrl_gpio_can_use_line() which takes a > pointer to the gpio_chip and a controller-relative offset. > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > --- > drivers/gpio/gpiolib-cdev.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c > index 31fc71a612c2..54ee075410db 100644 > --- a/drivers/gpio/gpiolib-cdev.c > +++ b/drivers/gpio/gpiolib-cdev.c > @@ -2287,8 +2287,7 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc, > * FIXME: find a non-racy way to retrieve this information. Maybe a > * lock common to both frameworks? > */ > - ok_for_pinctrl = > - pinctrl_gpio_can_use_line(gc->base + info->offset); > + ok_for_pinctrl = pinctrl_gpio_can_use_line_new(gc, info->offset); > _new?? In what sense? I agree with the change in principle, just not comfortable with the naming. Cheers, Kent.
On Tue, Oct 3, 2023 at 6:02 PM Kent Gibson <warthog618@gmail.com> wrote: > On Tue, Oct 03, 2023 at 04:50:42PM +0200, Bartosz Golaszewski wrote: ... > I agree with the change in principle, just not comfortable with the naming. +1 here. I proposed some names, have you seen my comment(s)?
On Tue, Oct 03, 2023 at 06:17:27PM +0300, Andy Shevchenko wrote: > On Tue, Oct 3, 2023 at 6:02 PM Kent Gibson <warthog618@gmail.com> wrote: > > On Tue, Oct 03, 2023 at 04:50:42PM +0200, Bartosz Golaszewski wrote: > > ... > > > I agree with the change in principle, just not comfortable with the naming. > > +1 here. I proposed some names, have you seen my comment(s)? > I have now - any of those work for me. Whichever is consistent with what we are using for gpiochip functions in gpiolib would make most sense to me. Cheers, Kent.
On Tue, Oct 3, 2023 at 5:24 PM Kent Gibson <warthog618@gmail.com> wrote: > > On Tue, Oct 03, 2023 at 06:17:27PM +0300, Andy Shevchenko wrote: > > On Tue, Oct 3, 2023 at 6:02 PM Kent Gibson <warthog618@gmail.com> wrote: > > > On Tue, Oct 03, 2023 at 04:50:42PM +0200, Bartosz Golaszewski wrote: > > > > ... > > > > > I agree with the change in principle, just not comfortable with the naming. > > > > +1 here. I proposed some names, have you seen my comment(s)? > > > > I have now - any of those work for me. > Whichever is consistent with what we are using for gpiochip functions in > gpiolib would make most sense to me. > Does it really matter? It's not here to stay, it's temporary and exists only until the whole series is applied - which given that it's limited to gpio and pinctrl, shouldn't take more than one release cycle. There are plenty of examples of this naming convention for temporary symbols - there's even an ongoing effort to replace all .remove() callbacks with .remove_new() which will then be changed back to .remove() treewide. Bart
On Tue, Oct 03, 2023 at 08:07:05PM +0200, Bartosz Golaszewski wrote: > On Tue, Oct 3, 2023 at 5:24 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > On Tue, Oct 03, 2023 at 06:17:27PM +0300, Andy Shevchenko wrote: > > > On Tue, Oct 3, 2023 at 6:02 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > On Tue, Oct 03, 2023 at 04:50:42PM +0200, Bartosz Golaszewski wrote: > > > > > > ... > > > > > > > I agree with the change in principle, just not comfortable with the naming. > > > > > > +1 here. I proposed some names, have you seen my comment(s)? > > > > > > > I have now - any of those work for me. > > Whichever is consistent with what we are using for gpiochip functions in > > gpiolib would make most sense to me. > > > > Does it really matter? It's not here to stay, it's temporary and > exists only until the whole series is applied - which given that it's > limited to gpio and pinctrl, shouldn't take more than one release > cycle. > > There are plenty of examples of this naming convention for temporary > symbols - there's even an ongoing effort to replace all .remove() > callbacks with .remove_new() which will then be changed back to > .remove() treewide. > This was the only patch that I was included into, so I didn't realise there was a treewide rename at the end. Even so, using _new suffix for that purpose is poor (well pinctrl_gpio_free_new() did draw a laugh, but other than that...). Perhaps use something specific to the patch series so it is clear what its purpose is? Cheers, Kent.
On Wed, Oct 4, 2023 at 6:16 AM Kent Gibson <warthog618@gmail.com> wrote: > > On Tue, Oct 03, 2023 at 08:07:05PM +0200, Bartosz Golaszewski wrote: > > On Tue, Oct 3, 2023 at 5:24 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > > > On Tue, Oct 03, 2023 at 06:17:27PM +0300, Andy Shevchenko wrote: > > > > On Tue, Oct 3, 2023 at 6:02 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > > On Tue, Oct 03, 2023 at 04:50:42PM +0200, Bartosz Golaszewski wrote: > > > > > > > > ... > > > > > > > > > I agree with the change in principle, just not comfortable with the naming. > > > > > > > > +1 here. I proposed some names, have you seen my comment(s)? > > > > > > > > > > I have now - any of those work for me. > > > Whichever is consistent with what we are using for gpiochip functions in > > > gpiolib would make most sense to me. > > > > > > > Does it really matter? It's not here to stay, it's temporary and > > exists only until the whole series is applied - which given that it's > > limited to gpio and pinctrl, shouldn't take more than one release > > cycle. > > > > There are plenty of examples of this naming convention for temporary > > symbols - there's even an ongoing effort to replace all .remove() > > callbacks with .remove_new() which will then be changed back to > > .remove() treewide. > > > > This was the only patch that I was included into, so I didn't realise > there was a treewide rename at the end. I didn't want to spam 20+ maintainers with the entire series of 36 patches. Should have probably Cc'ed everyone on the cover letter though. > Even so, using _new suffix for that purpose is poor (well > pinctrl_gpio_free_new() did draw a laugh, but other than that...). > Perhaps use something specific to the patch series so it is clear what > its purpose is? > I think Linus will end up applying the entire series to his tree in one go in which case the name really doesn't matter. Do we really need to bikeshed about the name which will exist for as long as it takes to apply the series on his laptop? I much more care about preserving bisectability across the series which it does. Bart
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c index 31fc71a612c2..54ee075410db 100644 --- a/drivers/gpio/gpiolib-cdev.c +++ b/drivers/gpio/gpiolib-cdev.c @@ -2287,8 +2287,7 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc, * FIXME: find a non-racy way to retrieve this information. Maybe a * lock common to both frameworks? */ - ok_for_pinctrl = - pinctrl_gpio_can_use_line(gc->base + info->offset); + ok_for_pinctrl = pinctrl_gpio_can_use_line_new(gc, info->offset); spin_lock_irqsave(&gpio_lock, flags);