Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4879488imm; Tue, 31 Jul 2018 01:30:12 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfCqOq/s5jjIe0m0zI2k6sKgufEF7O+N2LFttMyRm3u3Wz2pf/NdmSmAg+eOAGILS/nSFFU X-Received: by 2002:a17:902:6a83:: with SMTP id n3-v6mr19478970plk.246.1533025812184; Tue, 31 Jul 2018 01:30:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533025812; cv=none; d=google.com; s=arc-20160816; b=p0dAPpOfoz9/EynffAvMLAhr+pbR2M5z37Lgt9lrHm+Z4uwi6Oi5LOvOr+r9jkW1Ft q0NB9iGvZsLze8OQC0nO9gNB93rkwdYDlty2hVuwOsJYisf6/tc9Uy3PZD6y4nDJRNKZ bPqfbBZVxGwILSy1ll5uGPJrDtjIaj8lBB79VYFpx036rJNn2Gr8yBLGZMOYhFYwg8FC NQxj23xEe9fM3iUmgD8GvK6KcB2f6fsCNvY329O+nrkhKd9VU0GSPTZ9aEAaiEyAk+yE UJaf7GiGRM8vQq2uHTGaMRrgC1bDzrSPhoRHzPU0x4fvcGbT3+o6oqnG8t2ZqHeseOSm peUw== 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=85gcoFQHtyO7OqtRdDr1CISGZDAMXVdmWKkPHOGAw20=; b=yEUD2Pbuycm9w3xE2V+ojl5NILf9LID2QrHp04If2PIAruB8pSesOQ+tS+vyAU+bl7 X1X7gQAOKBgyLcpUaOdQPOx1P4eeMl+dQmtiMwfxhR9Ilu3UDA2NBOPpKtgrl4PADnnp qMQuHJtT/XS1er4WmZXG+TR03eLN/xTfhXIXXSjept8NDNNfugbYED12UuPJlIa/m4Pf 1X9wVFLljBJJOnrh5u65E9mh1VHJYhK0+KIbSErqE0Y5mf8zwOA1RGh1Pz9nVxgHEbEw eBCCYaXm6QhBsoukyfzlXWG9kXm6EwOr8kg+VaepqLGKpg+JEwrB0jtiDAmxF4BJ03TR E0QQ== 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 p2-v6si11304404pli.289.2018.07.31.01.29.57; Tue, 31 Jul 2018 01:30:12 -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 S1729660AbeGaKIV (ORCPT + 99 others); Tue, 31 Jul 2018 06:08:21 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:35901 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727307AbeGaKIV (ORCPT ); Tue, 31 Jul 2018 06:08:21 -0400 Received: by mail-lj1-f195.google.com with SMTP id u7-v6so12967355lji.3; Tue, 31 Jul 2018 01:29:07 -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=85gcoFQHtyO7OqtRdDr1CISGZDAMXVdmWKkPHOGAw20=; b=KnjBFcloCvUnQtMVhK98X8vFJ/tuWsDulqU0XG594LvzQDL2fUORthDwkksWsXb5Qf kUpRrlrEWAiYJkl5XndEyY/P5Q8w2oOsjYlQEbsWLRBKEQOZ9cnjxnPfW8b1hANB9S5F b2DNCxwmHPK/7uMydJWkzeEWelNnT70uufVBT+YLPrkRgWYsHEdgeNwvhnK4fzCqrKyy 1mhwZuAHcHG0eUAZPMMKjxEhTNwKtbw4ZfHWrOCJAzMcnvmSncRJTR1OlVZd0cdfYhZO sVDvWUhk08rLBJOMXz30CSEKmbgEA+6xkcwKz0zW/hivNW5OvTCDesRNLLp8kNUaKJin vjzQ== X-Gm-Message-State: AOUpUlEoLoq/eFd6RIgj0YF0kvTeM5+SsOIySUl6L/baHjMFFQ+OI4r/ B33Ad4cCL/X5rYKfT0JtwBI= X-Received: by 2002:a2e:7014:: with SMTP id l20-v6mr16180889ljc.141.1533025747251; Tue, 31 Jul 2018 01:29:07 -0700 (PDT) Received: from localhost.localdomain ([213.255.186.46]) by smtp.gmail.com with ESMTPSA id g2-v6sm1892972lfb.52.2018.07.31.01.29.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 31 Jul 2018 01:29:06 -0700 (PDT) Date: Tue, 31 Jul 2018 11:28:58 +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: <20180731073023.GA2956@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180626081319.GA2118@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, 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] > > > > > + if (rval) { > > > > > + dev_err(&pdev->dev, "failed to register clkdev for bd71837"); > > > > > + goto err_clean_provider; > > > > > + } > > > > > + > > > > > + platform_set_drvdata(pdev, c); > > > > > + > > > > > + return 0; > > > > > + > > > > > +err_clean_provider: > > > > > + of_clk_del_provider(pdev->dev.parent->of_node); > > > > > +err_out: > > > > > + return rval; > > > > > +} > > > > > + > > > > > +static int bd71837_clk_remove(struct platform_device *pdev) > > > > > +{ > > > > > + if (pdev->dev.parent->of_node) > > > > > + of_clk_del_provider(pdev->dev.parent->of_node); > > > > > > > > Use devm so this can go away. Or is devm not used because the parent > > > > of_node is the provider? That's annoying. > > > > > > What would be the correct workaround for this? > > > > Smash the clk driver into the overall PMIC node. That should work. Or > > possibly assign the same of_node to the child device when creating it? > > I'm not sure if that causes some sort of problem with DT code though, so > > it would be good to check with Rob H if that's a bad idea or not. > > 1. Assign MFD node to subdevice node in MFD when creating the cells. > 2. Assign parent->of_node to dev.of_node in clk subdevice. > 3. Create devm_of_clk_add_hw_provider_w_node() which does something > like (not compiled pseudo) code below > > int devm_of_clk_add_hw_provider_w_node(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; > } > EXPORT_SYMBOL_GPL(devm_of_clk_add_hw_provider_w_node); > > 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_w_node(dev, get, dev->of_node, > data); > } > EXPORT_SYMBOL_GPL(devm_of_clk_add_hw_provider); 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? Best regards Matti Vaittinen