linux-kernel - Re: [PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <54D0A675.7040801@linaro.org>
Date:	Tue, 03 Feb 2015 10:44:05 +0000
From:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:	Stephen Boyd <sboyd@...eaurora.org>,
	Bjorn Andersson <bjorn@...o.se>
CC:	Mike Turquette <mturquette@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Kumar Gala <galak@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	edubezval@...il.com, nrajan@...eaurora.com,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.



On 30/01/15 21:16, Stephen Boyd wrote:
> On 01/30/15 10:06, Srinivas Kandagatla wrote:
>>
>>
>> On 30/01/15 16:57, Bjorn Andersson wrote:
>>> On Fri, Jan 30, 2015 at 2:17 AM, Srinivas Kandagatla
>>> <srinivas.kandagatla@...aro.org> wrote:
>>>> This patch adds support to add child devices to gcc as some of the
>>>> registers mapped by gcc are used by drivers like thermal sensors.
>>>>
>>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
>>>> ---
>>>>    drivers/clk/qcom/gcc-msm8960.c | 10 +++++++++-
>>>>    1 file changed, 9 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/clk/qcom/gcc-msm8960.c
>>>> b/drivers/clk/qcom/gcc-msm8960.c
>>>> index 0cd3e26..3ba77c5 100644
>>>> --- a/drivers/clk/qcom/gcc-msm8960.c
>>>> +++ b/drivers/clk/qcom/gcc-msm8960.c
>>>> @@ -15,6 +15,7 @@
>>>>    #include <linux/bitops.h>
>>>>    #include <linux/err.h>
>>>>    #include <linux/platform_device.h>
>>>> +#include <linux/of_platform.h>
>>>>    #include <linux/module.h>
>>>>    #include <linux/of.h>
>>>>    #include <linux/of_device.h>
>>>> @@ -3658,6 +3659,7 @@ static int gcc_msm8960_probe(struct
>>>> platform_device *pdev)
>>>>           struct clk *clk;
>>>>           struct device *dev = &pdev->dev;
>>>>           const struct of_device_id *match;
>>>> +       int ret;
>>>>
>>>>           match = of_match_device(gcc_msm8960_match_table, &pdev->dev);
>>>>           if (!match)
>>>> @@ -3677,12 +3679,18 @@ static int gcc_msm8960_probe(struct
>>>> platform_device *pdev)
>>>>           if (IS_ERR(clk))
>>>>                   return PTR_ERR(clk);
>>>>
>>>> -       return qcom_cc_probe(pdev, match->data);
>>>> +       ret = qcom_cc_probe(pdev, match->data);
>>>> +       if (ret)
>>>> +               return ret;
>>>> +
>>>> +       return of_platform_populate(pdev->dev.of_node, NULL, NULL,
>>>> &pdev->dev);
>>>
>>> How about calling of_syscon_register() instead? That would give us a
>>> handle to a regmap that can be consumed in e.g. the thermal driver.
>>
>> Two things:
>> - Are you sure, this looks like of_syscon_register() is a static function
>> - gcc node would be required to add "syscon" compatible
>>
>> Unless am missing some patches, Am not sure if going via syscon is
>> right thing here?
>>
>> Stephen Any comments?
>
> I don't understand any of this. We should be making a specific tsens
> device directly in the gcc driver probe and not doing any sort of
> of_platform_populate(). This is what I had, but it probably could be
> done better so that we can assign the struct device's of_node pointer
> before registering on the platform bus.
>
>          platform_device_register_data(&pdev->dev, "tsens8960-tm", -1,
>                          &pdev->dev.of_node, sizeof(&pdev->dev.of_node));
>
Yes this would work too, What are the advantages of doing this way over 
the other? Except the fact that gcc and tsens do not have parent child 
relation in hw p.o.v .

If I get all this correct, we do not want to add a parent child 
hierarchy in DT, but we are Ok doing that inside the gcc driver, that 
seem not correct.

TBH, All this looks bit fiddly, for below reasons
- we re going to have a consolidated bindings for two different drivers 
gcc and tsens.
- Passing of_node as data to other drivers.

On the other hand can't we move a level up and make the common resource 
a syscon node and let both gcc and tsens drivers access it?
Which I think tsens originally attempted doing :-)

??

--srini



> Then if we need to add any properties like #sensor-cells or coefficients
> the tsens driver can use the same of_node that gcc is using.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/