Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp164941imm; Fri, 3 Aug 2018 01:10:27 -0700 (PDT) X-Google-Smtp-Source: AAOMgpenniW77IcwwDMJT9ObUqENhEB3rWtzFhQDwyU4p/tGLU0yZLClhrNWrc8RfM1kAnln7+AL X-Received: by 2002:a65:5284:: with SMTP id y4-v6mr2528736pgp.283.1533283827681; Fri, 03 Aug 2018 01:10:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533283827; cv=none; d=google.com; s=arc-20160816; b=T3aw0NhcYCJfknKLqy5locTZ1gRPvhCZjE7pjdlCygWLc0SjQYjgX9+ktIZIkDYCne BFgSf0XGkrAhUyU6pbV/vjaOXpw0zE0mV9dG6CChP7EJgVoqYRqV/gdCugEm281p4ElV U7UUcjuObBWEUjLSIrJQvxQ4QsB/lm+/wv8h2OtiA+5ZP3Q3RIocHik42XiKQ6IUUebD mCvqxzi1WAP3FJReVxowKkvfR6HU+8QcryuKAew8jmHfT4UgkmyaIoyFVGoWzX0CEF3w CBtudGj9PvolBRpA7Ox2NK8yXuKPm7YFaX55Ywhz1M6khQsTaEfR0g38kMwSYoA9FIPA tupQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=URDSvYW7O879FCFJt2S98ICv/g3Ln7D2xy2aUNCSlWs=; b=o/CN3+HrXZd1oX1OtkuLtdmdikAsQvaHsX9NX/acQNJalDEVO3tGuBqfg5vhflYH6S Qiz1o+BU9h+dVyQCC1Obi+naH7ydm/7w5e10dZOU3Wq/EpOvegv0VijbIIsT4AfEyXp4 4wObAd9kRdwV40m1E4T0t89mib9FRHwwkSAQb9iQqV3D2LwJbWUtrc0/LVueqwSTf2ZR 44WYAqRHdr5iMdPx6hN6DORX7xd94N8rMO7CBEU4f5S7vHuadpzn4XqNHXjGoyXsVUi1 QeWGEKoffY8VSbzeFP5QhcEo9admdPOnB3v7zKINz1YrydnMBBI1dNDohiDG7TMOrC+j WP/Q== ARC-Authentication-Results: i=1; mx.google.com; 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 a1-v6si4175600pga.639.2018.08.03.01.10.12; Fri, 03 Aug 2018 01:10:27 -0700 (PDT) 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; 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 S1728063AbeHCKEe (ORCPT + 99 others); Fri, 3 Aug 2018 06:04:34 -0400 Received: from mail-lf1-f67.google.com ([209.85.167.67]:40657 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727262AbeHCKEd (ORCPT ); Fri, 3 Aug 2018 06:04:33 -0400 Received: by mail-lf1-f67.google.com with SMTP id y200-v6so3436823lfd.7; Fri, 03 Aug 2018 01:09:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=URDSvYW7O879FCFJt2S98ICv/g3Ln7D2xy2aUNCSlWs=; b=bQpoFN6aG9NtGONrhdoEqbyCRNUnG8L1UP20m52snwFmx84N6RSgjetybeSgziv4Mq rKuV/atSYOkyPMGrVg1blhCXDZGw5CBCZxXh4HGhwgNd6uo+yi/+JQ7C5GPV3JTrXTE1 HmJKIw1Nh+CNIXeeFzFClY6cI93dxL7fZt7UCDZrA0yVA7Eeu+0fiy730ifspGipYIXy ZXFBwgsz8KTCjDWf685OacKr36kkkeUNXba9+h5Yq5gKytPORhmKh6X6AFfj5gwlAINW eKYir2B1ZQb6kljeLd5TnChNqW/IiKOcItb20O/9bPOTIpGEE8aWdBn4Tcg4tWTOhVcM yjkw== X-Gm-Message-State: AOUpUlFFY3f+ex0jXcWQA//FtimOCR0vVul3UOMtwuhb4VKPzi/JVeB0 tnoXBCj8D6fxfiQg8V2UqWdxAN2DbIw= X-Received: by 2002:a19:aac8:: with SMTP id t191-v6mr4174825lfe.68.1533283763023; Fri, 03 Aug 2018 01:09:23 -0700 (PDT) Received: from localhost.localdomain ([213.255.186.46]) by smtp.gmail.com with ESMTPSA id y68-v6sm625744lfd.66.2018.08.03.01.09.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Aug 2018 01:09:21 -0700 (PDT) Date: Fri, 3 Aug 2018 11:09:14 +0300 From: Matti Vaittinen To: Stephen Boyd , robh+dt@kernel.org Cc: Matti Vaittinen , broonie@kernel.org, lee.jones@linaro.org, lgirdwood@gmail.com, mark.rutland@arm.com, mturquette@baylibre.com, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, mikko.mutanen@fi.rohmeurope.com, heikki.haikola@fi.rohmeurope.com Subject: Re: [PATCH v5 4/4] clk: bd71837: Add driver for BD71837 PMIC clock Message-ID: <20180803080914.GA20907@localhost.localdomain> References: <152878945117.16708.12422348324182290971@swboyd.mtv.corp.google.com> <20180612082354.GG20078@localhost.localdomain> <152997029783.143105.16692843405899913246@swboyd.mtv.corp.google.com> <20180626081319.GA2118@localhost.localdomain> <20180731073023.GA2956@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180731073023.GA2956@localhost.localdomain> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 31, 2018 at 11:28:58AM +0300, Matti Vaittinen wrote: > On Tue, Jun 26, 2018 at 11:13:19AM +0300, Matti Vaittinen wrote: > > On Mon, Jun 25, 2018 at 04:44:57PM -0700, Stephen Boyd wrote: > > > Quoting Matti Vaittinen (2018-06-12 01:23:54) > > > > On Tue, Jun 12, 2018 at 12:44:11AM -0700, Stephen Boyd wrote: > > > > > Quoting Matti Vaittinen (2018-06-04 06:19:13) [snip] > > > 3. Create devm_of_clk_add_hw_provider_w_node() which does something > After giving this second thought - I think there is limited amount of use cases where other than own or parent nodes should be used. Actually, the MFD node being parent is pretty much only use case I can think of where something else but own node should be used. Hence function like suggested devm_of_clk_add_hw_provider_w_node might invite thinking of clever hacks... So, perhaps introducing devm_of_clk_add_hw_provider_parent() (see idea below) would be option to consider? I feel the bd71837 driver is not only case where MFD is being parent which has the clock stuff in DT. static int __devm_of_clk_add_hw_provider(struct device *dev, struct clk_hw *(*get)(struct of_phandle_args *clkspec, void *data), struct device_node *of_node, void *data) { struct device_node **ptr; int ret; ptr = devres_alloc(devm_of_clk_release_provider, sizeof(*ptr), GFP_KERNEL); if (!ptr) return -ENOMEM; *ptr = of_node; ret = of_clk_add_hw_provider(of_node, get, data); if (!ret) devres_add(dev, ptr); else devres_free(ptr); return ret; } int devm_of_clk_add_hw_provider(struct device *dev, struct clk_hw *(*get)(struct of_phandle_args *clkspec, void *data), void *data) { return __devm_of_clk_add_hw_provider(dev, get, dev->of_node, data); } EXPORT_SYMBOL_GPL(devm_of_clk_add_hw_provider); int devm_of_clk_add_hw_provider_parent(struct device *dev, struct clk_hw *(*get)(struct of_phandle_args *clkspec, void *data), void *data) { return __devm_of_clk_add_hw_provider(*dev, get, dev->parent->of_node, data); } EXPORT_SYMBOL_GPL(devm_of_clk_add_hw_provider_parent); > just a friendly reminder, what's your opinion on adding this kind of > function (devm_of_clk_add_hw_provider_w_node)? or solutions 1/2? And are > these options safe what comes to reference counting of of_nodes? I thik the reference counting should not be a problem when use is limited to (MFD) parent device nodes, right? Best regards Matti Vaittinen