Stephen,

quoted

quoted

quoted

quoted

Also, I don't like having a subnode in DT. Why can't we use the
same node as the GCC node and create a virtual child device here
for tsens? We can assign the same of_node that this platform
device has so that DT keeps working correctly.

So the current driver looks up data based on compatible strings.

The tsens device is always the same piece of hardware. The only

Well, not always. The one in 8960 does need additional initializations,
requires you to save/restore context as it can be powered off
not being in an always powered on domain etc.

quoted

thing that's changing is the qfprom data and the number of
sensors. So we should be looking at the qfprom compatible string

How? Tsens uses nvmem framework apis to read the qfprom atleast
in this series.

quoted

to figure out how to interpret the qfprom data which would
include the number of sensors and how the data is encoded.

quoted

So you suggesting to create a virtual child device for gcc and
associate the gcc DT node to it? (And have the tsens compatible
mentioned as part of the gcc DT node?)

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
* 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

Is this what you had in mind, or am I at the wrong end of the stick?

regards,
Rajendra