[PATCH 5/9] clk: qcom: gcc-msm8960: add child devices support.

[rnayak@codeaurora.org (Rajendra Nayak)]

[]..

>>>> No. The driver should work just fine without having to
>>>> interrogate the device's compatible string. If we still need the
>>>> compatible check for some reason, then we can always match based
>>>> on qcom,gcc-msm8960, qcom,gcc-apq8064, etc. But I don't see why
>>>
>>> Thats not quite possible I guess. 2 drivers (gcc and tsens) matching
>>> the same compatibles? Will it not just depend on which ends up being
>>> the first match?
>>
>> Any thoughts on how to move forward with this?
>>
>> I tried what you were suggesting, and here's what I had to do to get
>> things working
>>
>> * Created a gcc node in DT with gcc and tsens compatibles, with gcc and
>> tsens properties
>
> This is not what I had in mind. This is what's should be in DT
>
>   clock-controller at f000 {
>   	compatible = "qcom,gcc-msm8916";
> 	reg = <0xf000 ...>;
> 	....
>   };
>
>> * gcc driver probes the device/node first given gcc is registered with
>> a core_initcall()
>> * creates a virtual child device attaching the same of_node (having
>> both gcc and tsens compatibles)
>> * gcc ends up probing the virtual device/node _again_ (due to the gcc
>> compatible match), fails
>> * At a later point, tsens driver gets registered (using module_initcall)
>> ends up probing the virtual child node and succeeds
>
> Yeah this might happen though because we've assigned the of_node
> pointer to the tsens device before we register it on the platform
> bus. The other way to pass that data down from gcc to tsens would
> be to not have an of_node assigned to the tsens device, and check
> for that case in the tsens driver. If there isn't an of_node,
> then we look at the parent device's of_node to figure out which
> gcc it is (if this even matters) and parse DT properties.

Parsing DT properties from parent (in the tsens driver) is fine, but
the nvmem apis still expect an of_node for the tsens device and hence
fail.

Associating the of_node of the parent to the tsens device while being
probed ends up with the same issues of gcc ending up probing the device
and failing because tsens defers probe a couple times before a
successful probe.