Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3477092imu; Fri, 30 Nov 2018 00:36:10 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vx3W0ci5PM4l1p21NQFTRtYUJWyiuu40qAfj9iJp/RP28/ERw5ZCkk5lh5i9Cl61TNx2GV X-Received: by 2002:a62:2c81:: with SMTP id s123mr4671177pfs.174.1543566970459; Fri, 30 Nov 2018 00:36:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543566970; cv=none; d=google.com; s=arc-20160816; b=l3dmeptuJ5raucZgwcGJ0pnfkd9XHlLcJneNyvdJB0j9+Zh4lOg017RWZuIC/xXPDE CaznRONj7uWbiasDQfWMJif/KAcTmiNzqG8lmt2jbnC5xxMsZStKdN9goWyhD3CfHpxi yxC9trJZjYtSC9xRc8l0h1WsKGplhyT4fsooHdQx3ZWcsWhQ8UZd+86lrMpNW3eoLCol FDingJqw/vl1vi9ZcbGPk/6pOiVpb2BiJo/U9bYN2qlRQEuIqo6NktlcTj2LLW5zaolE xfDw9ntb6judovEhWlFpr/opU0eaYnLG9cl5UTclCzlo88NVkweAewAIjd8783vaM167 akTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=j9eiA6jCR4vF3qrc+6ESjsDMd8n45FCFlDvK7Uj86g0=; b=CHujT/X47j+5qE7e3Fg1UgvlrtUcDRMiZ6MW1polxkqILrJi3T87CQX2XjoXS6w+N3 zqtov00IsN2CS3c/SJbUtTnZMgDk4tAaaUNvRX5ufIciSN01jzLb0Bvqw9M3PM9CpopK tnmgdjqZa2ZWpcIIJYqRZNFLrhPDVwPVBBWy0muvX63ML5Wo/L3bJdDzXvAQTAqHXHIo 8ZtAQsOCwKGHuaXg953H3FGng0Yo0PeTUD3f0iDfpdNYC2bgt0XWpu3Kl3EyD7u0/oFp 3sfgBn6KGQMZKB2L2IHD8uv0uBUUHxKxaMIsQf49xn/ku0RMO4mL++ES+2NIpUlP3nHh +7mw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=ZzYsUpkK; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g1si4841798pld.197.2018.11.30.00.35.56; Fri, 30 Nov 2018 00:36:10 -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=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=ZzYsUpkK; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726825AbeK3Tnx (ORCPT + 99 others); Fri, 30 Nov 2018 14:43:53 -0500 Received: from mail-it1-f195.google.com ([209.85.166.195]:53084 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726629AbeK3Tnx (ORCPT ); Fri, 30 Nov 2018 14:43:53 -0500 Received: by mail-it1-f195.google.com with SMTP id i7so8046467iti.2 for ; Fri, 30 Nov 2018 00:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=j9eiA6jCR4vF3qrc+6ESjsDMd8n45FCFlDvK7Uj86g0=; b=ZzYsUpkKesQzi6VrgswYB/RbdL0QMFkgzjM3IquUv3isgc1DbDJI19D31WcmGvqY4V XQnqxGXqo4WOPzmS98n851mHNVH3hYG4Aln5tTaEbWGNHX1K3W+fGAC5Vi5fQD0NnRMx KXTT6+36Xb2gLIX30+N1AsreNIUVDfU3nSeZS09aMrpDrO9n/bbuVs39Xdsrm4DHPyVR oXWEgpXIDqg8nKPLNvqwN16WemNW4h6uQIk2dGpOFUWLQjJ3xchavQdsO5h8hsxDwVfM zQIeBagBF28bHOriCISNffhx4qnGeEvoxonLz8dVxIb/jq2Qyw40BsJIpp2RCe2bATP4 LC7Q== 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:content-transfer-encoding; bh=j9eiA6jCR4vF3qrc+6ESjsDMd8n45FCFlDvK7Uj86g0=; b=DDEw2a3955M0dpBXhVB93L8Hl+EHiLPsNID5LwiA3qFKsccbKrcYrISCzHtXabG5mK TNuGHnz3OKEpmt09NqwPXAexDf7Ka5jt3l01R2NmMt1AGJKfbrU/JPZmWNKay8bZEdcf BkDcgakzY8AWWx2sF3Lut1gZB4hypcv6/m8pg20hKoU57gKGyw4KR0P7OgTHtUIps4p7 dE7lQf/Vnk78lFcX+CVbvurW3+tNu8QNA4M3rsNqS1qNl8rpRt2llLIPKEXAZU8wCxHn HtgYiKTCCkvqKowcPaFs8WhIzY3tOh9vSmjvMGbUwzc7uTQPb/hNcLjXN5UmUll5G/UC mdaw== X-Gm-Message-State: AA+aEWa62xIaoFcdNW+dhe3FFAVc2LAHtPa8Fk5JM+2gQpLoYrsDtQIM BN9bY12iowgITfiPDpOec/iJ1BuaucPvFwMHRy/JZw== X-Received: by 2002:a02:6f4d:: with SMTP id b13mr4120833jae.57.1543566919853; Fri, 30 Nov 2018 00:35:19 -0800 (PST) MIME-Version: 1.0 References: <20181128104350.31902-1-linus.walleij@linaro.org> <20181129190132.GM2089@sirena.org.uk> In-Reply-To: <20181129190132.GM2089@sirena.org.uk> From: Bartosz Golaszewski Date: Fri, 30 Nov 2018 09:35:09 +0100 Message-ID: Subject: Re: [PATCH 00/10] Regulator ena_gpiod fixups To: Mark Brown Cc: Bartosz Golaszewski , Linus Walleij , lgirdwood@gmail.com, Linux Kernel Mailing List , ckeepax@opensource.cirrus.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org czw., 29 lis 2018 o 20:01 Mark Brown napisa=C5=82(a): > > On Thu, Nov 29, 2018 at 07:38:20PM +0100, Bartosz Golaszewski wrote: > > > I'm wondering if instead of using the non-devm variants of > > gpiod_get_*() routines, we shouldn't provide helpers in the regulator > > framework that would be named accordingly, for example: > > regulator_gpiod_get_optional() etc. even if all they do is call the > > relevant gpiolib function. Those helpers could then be documented as > > passing the control over GPIO lines over to the regulator subsystem. > > > The reason for that is that most driver developers will automatically > > use devm functions whenever available and having a single non-devm > > function without any comment used in a driver normally using devres > > looks like a bug. Expect people sending "fixes" in a couple months. > > I predict that people would then immediately start demanding devm_ > variants of that function... At least we could document it in the code. If I wouldn't know about the reason for not using devm and saw a stray gpiod_get() without a corresponding put() I'd probably send a patch to fix it, but if I saw something like regulator_gpiod_get(), I'd look at what this routine does. Matter of taste I guess, but I'd prefer the latter. At the very least we could add a comment to each call saying that the regulator framework will take care of that resource. Bart