On 11/9/23 17:15, Ma, Jun wrote:
Hi Guenter,
On 11/9/2023 1:28 PM, Guenter Roeck wrote:
On 11/8/23 21:14, Ma Jun wrote:
The attribute definiations like &sensor_dev_attr_xx_xx.dev_attr.attr
are widely used in drivers. So add a new macro sensor_sysfs_attr t
to make it easier to understand and use.
For example, user can use the sensor_sysfs_attr(xx_xx) instead of
&sensor_dev_attr_xx_xx.dev_attr.attr
Signed-off-by: Ma Jun <Jun.Ma2@xxxxxxx>
---
include/linux/hwmon-sysfs.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/hwmon-sysfs.h b/include/linux/hwmon-sysfs.h
index d896713359cd..7feae637e3b5 100644
--- a/include/linux/hwmon-sysfs.h
+++ b/include/linux/hwmon-sysfs.h
@@ -14,6 +14,10 @@ struct sensor_device_attribute{
struct device_attribute dev_attr;
int index;
};
+
+#define to_sensor_sysfs_attr(_name) \
+ (&sensor_dev_attr_##_name.dev_attr.attr)
+
#define to_sensor_dev_attr(_dev_attr) \
container_of(_dev_attr, struct sensor_device_attribute, dev_attr)
No. This would just invite people to submit patches converting existing code
to use this new macro. Instead of providing macros to support deprecated APIs,
convert drivers to use an API which is not deprecated. This would for the
Which API is not deprecated do you mean?
[devm_]hwmon_device_register_with_info(). I don't want to encourage
the use of non-standard sysfs atributes either (and, no, I still
don't accept the idea that "frequency" would be a hardware monitoring
attribute).
Guenter
