Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1117762ybf; Fri, 28 Feb 2020 14:34:50 -0800 (PST) X-Google-Smtp-Source: APXvYqz/NJldHhQY2A4LJMxy1ekLLp7/oPtQUHtHi3ILO5lfyOFwx0V8sDrsaIeaaGAwGJfywBQl X-Received: by 2002:aca:c3d1:: with SMTP id t200mr2485182oif.41.1582929289982; Fri, 28 Feb 2020 14:34:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582929289; cv=none; d=google.com; s=arc-20160816; b=pQUPkpJqRMT/zxruHO5VAtfmKOUoJUPMp8kD05zLoVN3w5zkS+/I2wm+IH+6Edeor4 70OG+vd/8uKAZoR8zG7NN0TPyNIixBxzc58lakEeOPRlcH6TuGtJChVqEieqhu3dhGvP bbb53EmHBa/FYyy5BRTI+eLpPxauqRx/oTapnpHpBuVgCQSlElbpso/3sXwmgBqgrBwd TEJFLe3WPlmODjjAIcJpgAgvLO0WLqw2OgwpvF2rTLaC+BfnleNBarjEbZ5IJ4s0redG +bKJEiy74kZ/8+MFG7tPMvfF63R/vSxoQs+yGJIDHtB/oFn8lYcMWg7/7zf1/j7qyn9+ uVUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=kpMCwJPHsrLHrJr/d/YMgs2GY9/L334aO8TrlrMaCrA=; b=bi59Mbr34ys/WotNjQ26eh9xrdbSsey0bR+SSV9+vSUHBAWGs3fo+ZD2DxqKHtKZT7 w6zmoL15gCb+sLTES1pwk2cyPgyG2iMnryMUlH0N6vjWq8ymZmd7l6kOGz8+Dao8v0+E atTLjrvN36EeE8N57hXZoI5/g1rEBvoY/89j1eX+SFbBnlRqFynPhh2qlsWuYVVRj/J9 gQDIeIzHEKkmxmlSU+1lAtjUR/ZdAiJ2Mi/C57MDetOUHld+j6XYH/JpDGsxvuopwzJw 6WizJ4xeMVKr0FIBM2iykbTseV0BJe4j3m5KxW/zFhtEsze0CNghihpX5sanuDK8nizi t/IQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=g0xgaarU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 71si2533623otm.111.2020.02.28.14.34.36; Fri, 28 Feb 2020 14:34:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=g0xgaarU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726720AbgB1WdM (ORCPT + 99 others); Fri, 28 Feb 2020 17:33:12 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:43395 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725957AbgB1WdM (ORCPT ); Fri, 28 Feb 2020 17:33:12 -0500 Received: by mail-lj1-f195.google.com with SMTP id e3so5039527lja.10 for ; Fri, 28 Feb 2020 14:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kpMCwJPHsrLHrJr/d/YMgs2GY9/L334aO8TrlrMaCrA=; b=g0xgaarU05W3RSjtAPA9tblHgqI6V0WPrwGkBFm1qkHKVRGZCKgYUKlrVXvftftHow nnsJ7vO0KEApkPGIbs4EuQF6ysI3PtAWtYxocPPwiFezn49DVXs0JgdF8ugNvdvJSnXC oCSYRW7DSRCFAzBU4mp/E3C4uS+SpA0DGRZVqTPZMe5TPIGLJ/7DzuD5pAY9aTRRGXc4 eBHRMO/0odwgM3kPTcsEgdG2TRgcZSsXO48emgRRJZB65r8PSjSYEj+jJZHhtguCGsZP V9+uwYPRBEjD00y8GLfojLelEEWNO/7Ocv/ur+p1nu+asiIjpD9Pc/SglIpw3nTMi1xC HcdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kpMCwJPHsrLHrJr/d/YMgs2GY9/L334aO8TrlrMaCrA=; b=ejRcST7ytNTDpUnKnXOD4dcv9qWLK0aWFvSl1pqbmgEcgmx5ahKUdFe9YkpyTCbrEe cZ8O8pVbY2cEU++gV+bVcnGP1DiIjuhth9+loP6gElalkhOFychuwAIx0H8hpn9l63Xh O1M453Tsy2ywnwO+Ra2Q+XNN3boKkUd6Ws/+ZRa2xRq74RE365fgU6wdH7sniU+EXHjn 3SYkQo0Heu2IMfrYFZpbKsq1RlW97E3jk+CglSr35v1Gw7j8wYhC1OT35t4Fj9F+TA2r yC69vwBcTjUNYPXdQnoZ9cw9/pgrkiV/W28K6t6/61nM+fRO+7OHIDjVT1gJDycU94No 4cig== X-Gm-Message-State: ANhLgQ3MrKtNLJFBCCLwNFNpay0uXGVvLyyQQNPicnTge31Mn4GyHx1A 76mo49h2Le0FY/GaHcsQzVVKcSLI1uWaAGZx/8rp+w== X-Received: by 2002:a2e:9013:: with SMTP id h19mr4375691ljg.223.1582929188647; Fri, 28 Feb 2020 14:33:08 -0800 (PST) MIME-Version: 1.0 References: <20200221154837.18845-1-brgl@bgdev.pl> <20200221154837.18845-4-brgl@bgdev.pl> In-Reply-To: <20200221154837.18845-4-brgl@bgdev.pl> From: Linus Walleij Date: Fri, 28 Feb 2020 23:32:57 +0100 Message-ID: Subject: Re: [PATCH v5 3/5] gpiolib: use kref in gpio_desc To: Bartosz Golaszewski Cc: Srinivas Kandagatla , Khouloud Touil , Geert Uytterhoeven , "open list:GPIO SUBSYSTEM" , "linux-kernel@vger.kernel.org" , Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 21, 2020 at 4:48 PM Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > GPIO descriptors are freed by consumers using gpiod_put(). The name of > this function suggests some reference counting is going on but it's not > true. > > Use kref to actually introduce reference counting for gpio_desc objects. > Add a corresponding gpiod_get() helper for increasing the reference count. > > This doesn't change anything for already existing (correct) drivers but > allows us to keep track of GPIO descs used by multiple users. > > Signed-off-by: Bartosz Golaszewski I'm having some trouble figuring out if we might be reinventing a wheel here. A while back there was a proposed patch to add device links between GPIO producers and consumers, so that a GPIO chip won't be dropped while there are active consumers. (I don't remember who sent the patch.) We have a similar functionality in pin control if the .link_consumers property is set on the pincontrol device. I was thinking about making that compulsory at one point. The device links use a kref already existing in struct device and would in this case be the kref in the struct device for the struct gpio_device. So if that existed, gpiod_ref could just grab another device_link_add(). Maybe we should just add device links between all GPIO consumers (devices) and struct gpio_device:s struct device and implement it like this so we don't have to back out of this later? C.f. commit commit 036f394dd77f8117346874151793ec38967d843f pinctrl: Enable device link creation for pin control (...) > @@ -81,6 +81,7 @@ struct gpio_descs *__must_check gpiod_get_array(struct device *dev, > struct gpio_descs *__must_check gpiod_get_array_optional(struct device *dev, > const char *con_id, > enum gpiod_flags flags); > +struct gpio_desc *gpiod_ref(struct gpio_desc *desc); > void gpiod_put(struct gpio_desc *desc); > void gpiod_put_array(struct gpio_descs *descs); You forgot to add a stub for the case where GPIOLIB is not compiled in I think? (Lower in the same file.) Yours, Linus Walleij