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] [thread-next>] [day] [month] [year] [list]
Message-ID: <ca5b7d80-895b-4562-a066-48f7d708d488@roeck-us.net>
Date: Mon, 17 Nov 2025 08:31:32 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Thomas Marangoni <Thomas.Marangoni@...om-group.com>,
 linux-hwmon@...r.kernel.org
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, corbet@....net,
 Jonathan.Cameron@...wei.com, Frank.Li@....com, michal.simek@....com,
 rodrigo.gobbi.7@...il.com, chou.cosmo@...il.com, wenswang@...h.net,
 nuno.sa@...log.com, paweldembicki@...il.com, apokusinski01@...il.com,
 eajames@...ux.ibm.com, vassilisamir@...il.com, heiko@...ech.de,
 neil.armstrong@...aro.org, prabhakar.mahadev-lad.rj@...renesas.com,
 kever.yang@...k-chips.com, mani@...nel.org, dev@...l-k.io,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org
Subject: Re: [PATCH 2/4] hwmon: documentation: add tids

On 11/17/25 04:38, Thomas Marangoni wrote:
> Add tids driver documentation
> ---
>   Documentation/hwmon/tids.rst | 61 ++++++++++++++++++++++++++++++++++++
>   1 file changed, 61 insertions(+)
>   create mode 100644 Documentation/hwmon/tids.rst
> 
> diff --git a/Documentation/hwmon/tids.rst b/Documentation/hwmon/tids.rst
> new file mode 100644
> index 000000000000..f3fea4e416ea
> --- /dev/null
> +++ b/Documentation/hwmon/tids.rst
> @@ -0,0 +1,61 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Kernel driver tids
> +===================
> +
> +Supported Chips:
> +
> +  * WSEN TIDS
> +
> +    Prefix: 'tids'
> +
> +    Addresses scanned: None
> +
> +    Datasheet:
> +
> +      English: https://www.we-online.com/components/products/manual/Manual-um-wsen-tids-2521020222501%20(rev1.2).pdf
> +
> +Author: Thomas Marangoni <Thomas.Marangoni@...om-group.com>
> +
> +
> +Description
> +-----------
> +
> +This driver implements support for the WSEN TIDS chip, a temperature
> +sensor. Temperature is measured in degree celsius. In sysfs interface,
> +all values are scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
> +
> +Usage Notes
> +-----------
> +
> +The device communicates with the I2C protocol. Sensors can have the I2C
> +address 0x38 or 0x3F. See Documentation/i2c/instantiating-devices.rst for methods
> +to instantiate the device.
> +
> +Sysfs entries
> +-------------
> +
> +=============== ============================================
> +temp1_input     Measured temperature in millidegrees Celsius
> +update_interval The interval for polling the sensor, in
> +                milliseconds. Writable. Must be 5, 10, 20
> +                or 40.

As mentioned in the driver feedback, this should be more generous and say
something like "Supported values are 5, 10, 20, or 40".

> +temp1_max_hyst  The temperature in millidegrees Celsius, that
> +                is triggering the temp1_max_alarm. Writable.
> +                The lowest possible value is -39680 and the

As above, s/possible/supported/. We don't usually expect users to know
supported value ranges for update intervals or temperature limits.

> +                highest possible value is 122880. Values are
> +                saved in steps of 640.
> +temp1_min_hyst  The temperature in millidegrees Celsius, that
> +                is triggering the temp1_min_alarm. Writable.
> +                The lowest possible value is -39680 and the
> +                highest possible value is 122880. Values are
> +                saved in steps of 640.

As mentioned in the driver feedback, I think those should be temp1_max
and temp1_min. I see no evidence that those are hysteresis values,
and the description here and in the datasheet confirms this.

> +temp1_max_alarm The alarm will be triggered when the level
> +                reaches the value specified in
> +                temp1_max_hyst. It will reset automatically
> +                once it has been read.
> +temp1_min_alarm The alarm will be triggered when the level
> +                reaches the value specified in
> +                temp1_min_hyst. It will reset automatically
> +                once it has been read.
> +=============== ============================================


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ