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@amd.com>
---
 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)
 
-- 
2.34.1

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@amd.com>
> ---
>   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
most part avoid the need for including hwmon-sysfs.h in the first place and
at the same time reduce driver code size significantly.

Guenter

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@amd.com>
>> ---
>>   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?

Regards,
Ma Jun

> most part avoid the need for including hwmon-sysfs.h in the first place and
> at the same time reduce driver code size significantly.


> 
> Guenter
>

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@amd.com>
>>> ---
>>>    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