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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6BAFC43215 for ; Tue, 19 Nov 2019 14:44:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 73CBC20891 for ; Tue, 19 Nov 2019 14:44:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="o8/7NQNC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728319AbfKSOoD (ORCPT ); Tue, 19 Nov 2019 09:44:03 -0500 Received: from mail-lf1-f65.google.com ([209.85.167.65]:39891 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728071AbfKSOoC (ORCPT ); Tue, 19 Nov 2019 09:44:02 -0500 Received: by mail-lf1-f65.google.com with SMTP id f18so4922734lfj.6 for ; Tue, 19 Nov 2019 06:44:00 -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=3HGForXYrnzKKwFOiKAr5qSOuuqdU2k4wA1CfbalcbQ=; b=o8/7NQNCdscgcAzoUXE+jNTk/DJagMvuw5Z5JaWY30/Z/muA51WNthzWcG+/MtHPBP ny6dVonMKRnen+it9ngeeXt1nR2rMvm4MxOKRsW5mUt9arjSEhZM4tMEKXJRcjqQx8t8 UwAYBSUYodJCrJjJxwSpcnYicu7wJuE+0By/ddHV3P+BQR3Lp7t+G1kjRHchnAx24qMJ SA9vVP9M+gd+aI6o0RnPHJ0b1q0yRooX6UUA86zcAYvWai/ge//6X1NsbP93Bwm+VLIX BqN6l+PH8M5Cw6YFIvmW/Ygb/vNNIT3uU4vu68nKXH9wt785xkMpxaAXLMSC4C3ZTGrO vEUw== 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=3HGForXYrnzKKwFOiKAr5qSOuuqdU2k4wA1CfbalcbQ=; b=sexShm3ljdH7YblTlsR/55TTlQdhG+ZVtvCPOQwxe0Jf0jAUWyeA800TMrpKEF56DD Asvhkx5L5752E25TnZWl038mn/VOLQk4xZfd6R6goGbV2GlGkDGORYnx3luFws8DXhsg BiPKtWGjZvj6s9mT0gCT1RCSV0sKsIPyBx7wXlDsHelMmxBK6C/DcoKs7wGKxXkFUZ4V Ga5KLIBlaijnkEnv6lcrqUxt3S6SwNbaIe9PRthnSUnIa/DpD0582bbjUEXdjcMIrO5I UMzpbitonCiTgWlaLYaZDMpKLXS5215the7gEPAI9LIbgXsls5gc6u2Gv9LW+nEj/mTM 3+vw== X-Gm-Message-State: APjAAAWu3c9vdqqxOVqlsYXGQGtxeLpDPqyjiL2WV02mq4jk9MuU2vJa I/4QA0skYVfJ8MO9HAtoPKI+vac5JA/KNHEoTx+XQQ== X-Google-Smtp-Source: APXvYqxiJDKtjaMparegwwsvRl+fvmQtXcsqSKBMv1kiOZ+otWv/0CzoTQp+omLTRtPr/aKLvkVblynEb9GKo+vyzx0= X-Received: by 2002:a19:651b:: with SMTP id z27mr4166813lfb.117.1574174639988; Tue, 19 Nov 2019 06:43:59 -0800 (PST) MIME-Version: 1.0 References: <8dd9dad2765d47fd6c6fec20566326d00e48a696.1574059625.git.matti.vaittinen@fi.rohmeurope.com> In-Reply-To: <8dd9dad2765d47fd6c6fec20566326d00e48a696.1574059625.git.matti.vaittinen@fi.rohmeurope.com> From: Linus Walleij Date: Tue, 19 Nov 2019 15:43:47 +0100 Message-ID: Subject: Re: [PATCH v5 10/16] gpio: devres: Add devm_gpiod_get_parent_array To: Matti Vaittinen Cc: Matti Vaittinen , Lee Jones , Jacek Anaszewski , Pavel Machek , Dan Murphy , Rob Herring , Mark Rutland , Liam Girdwood , Mark Brown , Jonathan Corbet , Michael Turquette , Stephen Boyd , Bartosz Golaszewski , Alessandro Zummo , Alexandre Belloni , Mauro Carvalho Chehab , Jeff Kirsher , Wolfram Sang , Marek Szyprowski , Heiner Kallweit , Nicholas Mc Guire , Phil Edworthy , Linux LED Subsystem , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "linux-kernel@vger.kernel.org" , Linux Doc Mailing List , linux-clk , "open list:GPIO SUBSYSTEM" , linux-rtc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Mon, Nov 18, 2019 at 7:58 AM Matti Vaittinen wrote: > Bunch of MFD sub-devices which are instantiated by MFD do not have > own device-tree nodes but have (for example) the GPIO consumer > information in parent device's DT node. Add resource managed > devm_gpiod_get_array() for such devices so that they can get the > consumer information from parent DT while still binding the GPIO > reservation life-time to this sub-device life time. > > If devm_gpiod_get_array is used as such - then unloading and then > re-loading the child device fails as the GPIOs reserved during first > load are not freed when driver for sub-device is unload (if parent > stays there). > > Signed-off-by: Matti Vaittinen (...) > +static struct gpio_descs *__must_check > +__devm_gpiod_get_array(struct device *gpiodev, > + struct device *managed, > + const char *con_id, > + enum gpiod_flags flags) I'm opposed to functions named __underscore_something() so find a proper name for this function. devm_gpiod_get_array_common() works if nothing else. > @@ -292,19 +284,62 @@ struct gpio_descs *__must_check devm_gpiod_get_array(struct device *dev, > if (!dr) > return ERR_PTR(-ENOMEM); > > - descs = gpiod_get_array(dev, con_id, flags); > + descs = gpiod_get_array(gpiodev, con_id, flags); > if (IS_ERR(descs)) { > devres_free(dr); > return descs; > } > > *dr = descs; > - devres_add(dev, dr); > + if (managed) > + devres_add(managed, dr); > + else > + devres_add(gpiodev, dr); So we only get managed resources if the "managed" device is passed in. > +/** > + * devm_gpiod_get_array - Resource-managed gpiod_get_array() And this function is supposed to be resource managed for sure. > + * @dev: GPIO consumer > + * @con_id: function within the GPIO consumer > + * @flags: optional GPIO initialization flags > + * > + * Managed gpiod_get_array(). GPIO descriptors returned from this function are > + * automatically disposed on driver detach. See gpiod_get_array() for detailed > + * information about behavior and return values. > + */ > +struct gpio_descs *__must_check devm_gpiod_get_array(struct device *dev, > + const char *con_id, > + enum gpiod_flags flags) > +{ > + return __devm_gpiod_get_array(dev, NULL, con_id, flags); So what is this? NULL? Doesn't that mean you just removed all resource management for this call? Or am I reading it wrong? Yours, Linus Walleij