[]..

quoted

quoted

quoted

+Optional properties:
+- qcom,sensor-id: List of sensor instances used in a given SoC. A
TSENS IP can
+		  have a fixed number of sensors (like 11) but a given SoC can
+		  use only 5 of these and they might not always the first 5. They
+		  could be sensors 0, 1, 4, 8 and 9. This property is used to
+		  describe the subset of the sensors used. If this property is
+		  missing they are assumed to be the first 'n' sensors numbered
+		  sequentially in which case the number of sensors defaults to
+		  the number of slope values.

Can you please elaborate a bit more on why you could not solve this
using the thermal sensor descriptor id?

quoted

+
+Example:
+tsens: thermal-sensor at 900000 {
+		compatible = "qcom,msm8916-tsens";
+		nvmem-cells = <&tsens_caldata>, <&tsens_calsel>;
+		nvmem-cell-names = "caldata", "calsel";
+		qcom,tsens-slopes = <3200 3200 3200 3200 3200>;

quoted

quoted

quoted

+		qcom,sensor-id = <0 1 2 4 5>;
+		#thermal-sensor-cells = <1>;

How about if you simply make the sensor driver expose all sensors, then
in the
thermal zone descriptor, you pick which sensor to use using the thermal
sensor
descriptor (quoting the binding again):

Hi Eduardo,

What you suggested would work, except for that the calibration data in
eeprom would
be available for only the _subset_ of sensors on the SoC. So the driver in
some way would
need to know which exact sensors the eeprom data corresponds to.

If this does not seem like something which needs to be described in DT, I
can have the
data embedded into the driver so it gets picked based on the right
compatibles.

Hey Eduardo, any thoughts on this?

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation