>>
>> /* FM Radio Modulator controls */
>> /* Keep the order of the 'case's the same as in v4l2-controls.h! */
>> @@ -1597,6 +1598,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
>> case V4L2_CID_RF_TUNER_PLL_LOCK:
>> *flags |= V4L2_CTRL_FLAG_VOLATILE;
>> break;
>> + case V4L2_CID_TEMPERATURE:
>> + *flags |= V4L2_CTRL_FLAG_READ_ONLY |
>> + V4L2_CTRL_FLAG_VOLATILE;
>
> Add a break!
>
Whoops!
>> }
>> }
>> EXPORT_SYMBOL(v4l2_ctrl_fill);
>> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
>> index bb40129446d4..705b4043c2de 100644
>> --- a/include/uapi/linux/v4l2-controls.h
>> +++ b/include/uapi/linux/v4l2-controls.h
>> @@ -1008,6 +1008,8 @@ enum v4l2_auto_focus_range {
>>
>> #define V4L2_CID_CAMERA_SENSOR_ROTATION (V4L2_CID_CAMERA_CLASS_BASE+35)
>>
>> +#define V4L2_CID_TEMPERATURE (V4L2_CID_CAMERA_CLASS_BASE+36)
>
> Does it make sense to add this to CAMERA_CLASS? Can't this be a generic temperature
> control? (i.e. in USER_BASE) Any device can have a temperature sensor.
>
I see no issue in moving it. Your call.
> I also think that making this an array control would make sense as well in case there
> are multiple temperature sensors.
>
> Brainstorming some more: does this even belong here? Isn't this more a hwmon thing?
> E.g. compare this to drivers/nvme/host/hwmon.c.
>
> A hwmon implementation seems to be a more natural mechanism.
>
> Regards,
>
> Hans
>
>> +
>> /* FM Modulator class control IDs */
>>
>> #define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
>
