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=-8.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 92E48C2D0CF for ; Mon, 16 Dec 2019 08:30:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 676AD22522 for ; Mon, 16 Dec 2019 08:30:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="GJ6KAmw6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726928AbfLPIaE (ORCPT ); Mon, 16 Dec 2019 03:30:04 -0500 Received: from mail-ua1-f67.google.com ([209.85.222.67]:33766 "EHLO mail-ua1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726897AbfLPIaD (ORCPT ); Mon, 16 Dec 2019 03:30:03 -0500 Received: by mail-ua1-f67.google.com with SMTP id v19so1787114uap.0 for ; Mon, 16 Dec 2019 00:30:03 -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=kDxQhaeLo6rNMVFT3CBcpOhBFhoVMYpLfsYqZHIsllM=; b=GJ6KAmw6S+sq3Ccetl/H3ixiZVhos+PR0jEMWgPCzfx0kYdnBXsUmmddRDGHKCa+IW XpoIFbLS8+19HgHvj1aji88fMJFyb1lR/OZ36673QRjkhDqdlzrIFkgM8oE+oLQDArnf b7+9QxLZM6bFfD0TyRkuo4e0dVkdBL0SKoIBmAyTVM1uFsJHNelZ/+e0ANXGZ4aezkeZ o4gb0cTRAp9bOD/PgQ9vQbyM+lGwK9Ok7JQXcF4SJ5b4Kw9UhJJL2BCwrf0d2BtMgGGk 5R3A+AL4JyWngHzSseIzNmoBzR/zYQxFslU5c3tgyAMleZF6TpW7mWEL4HtKwSHPi2AZ 9W7Q== 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=kDxQhaeLo6rNMVFT3CBcpOhBFhoVMYpLfsYqZHIsllM=; b=st/Dw7+/ryfTe17an0ybxoll+xH7Akqim/dxVzgN0aIVEcmBkE95Kn9r30gfiAw73u s4qrl4Ok1NL5CWALbg/F96SyyQs2iO1IeTiCUaUDOd7ahjjU7hl1ajuQ6bKVR2+yaO+9 +dP9x92rGpCtdRYEt5ddo2soLWVflkiiddCCq0m1EvodOwEnKbmZzW6vAxe1K4w+9q7S nclNLuGL+Si/Zl245SuENgEdEknMl5zS44TXOFnniuN28okuea60zrnaJ5ccwjmFPkg5 Rt1nTYl2WG2rP9/GfuTgIpZj9pVqaAm/elO38myF6ZzrCo90iil4CpvgcTsWCdHrwZ9V b2qg== X-Gm-Message-State: APjAAAWQxZOjLW1i9mvPn99hgyWrI9w9awkXvTilr3NeSLuCEB4eB/se aY0fO2jFFfCKClp67xY7e9SGwyb+EebD19lkFaxpyg== X-Google-Smtp-Source: APXvYqwni+l6XxPCyreJYxRHqzJXidyE2iM9tvx9B737sdIeXKOHoRA6FLpVo5xoUtWtnIiiMdWW6jDBBKJSinB1wok= X-Received: by 2002:ab0:5512:: with SMTP id t18mr22623715uaa.128.1576485002794; Mon, 16 Dec 2019 00:30:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Linus Walleij Date: Mon, 16 Dec 2019 09:29:51 +0100 Message-ID: Subject: Re: [PATCH v6 10/15] gpio: devres: Add devm_gpiod_get_parent_array To: Matti Vaittinen Cc: Matti Vaittinen , Jacek Anaszewski , Pavel Machek , Dan Murphy , Rob Herring , Mark Rutland , Lee Jones , Liam Girdwood , Mark Brown , Jonathan Corbet , Michael Turquette , Stephen Boyd , Bartosz Golaszewski , Alessandro Zummo , Alexandre Belloni , Greg Kroah-Hartman , Arnd Bergmann , Mauro Carvalho Chehab , Wolfram Sang , Phil Edworthy , =?UTF-8?Q?Noralf_Tr=C3=B8nnes?= , 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-leds-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org On Wed, Dec 11, 2019 at 10:47 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 > --- > > Changes since v5: > - renamed internal function (no __ - prefixes for Linus :] ) Thanks, as there are things happening in the GPIO subsystem I have put this one patch on an immutable branch here: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=ib-devm-gpiod-get-parent-array Please ask the maintainer (I guess Lee?) to pull this into wherever the rest of the patches should be merged if you want patches beyond this point to be applied for the next (v5.6) merge window, then this patch is not needed in the series. Yours, Linus Walleij