lkml.org 
[lkml]   [2022]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 2/2] misc: Add power-efuse driver
On Mon, Mar 07, 2022 at 11:07:57PM PST, Greg Kroah-Hartman wrote:
>On Mon, Mar 07, 2022 at 05:18:10PM -0800, Zev Weiss wrote:
>> +static DEVICE_ATTR(operstate, 0644, efuse_show_operstate, efuse_set_operstate);
>
>DEVICE_ATTR_RW()?
>

Ack.

>> +
>> +#define EFUSE_ERROR_ATTR(name, bit) \
>> + static ssize_t efuse_show_##name(struct device *dev, struct device_attribute *attr, \
>> + char *buf) \
>> + { \
>> + struct efuse *efuse = dev_get_drvdata(dev); \
>> + int status = efuse_update_error_flags(efuse); \
>> + if (status) \
>> + return status; \
>> + return sysfs_emit(buf, "%d\n", !!(efuse->error_flags.cache & bit)); \
>> + } \
>> + static DEVICE_ATTR(name, 0444, efuse_show_##name, NULL)
>
>DEVICE_ATTR_RO()?
>

Ack.

>> +EFUSE_ERROR_ATTR(under_voltage, REGULATOR_ERROR_UNDER_VOLTAGE);
>> +EFUSE_ERROR_ATTR(over_current, REGULATOR_ERROR_OVER_CURRENT);
>> +EFUSE_ERROR_ATTR(regulation_out, REGULATOR_ERROR_REGULATION_OUT);
>> +EFUSE_ERROR_ATTR(fail, REGULATOR_ERROR_FAIL);
>> +EFUSE_ERROR_ATTR(over_temp, REGULATOR_ERROR_OVER_TEMP);
>> +EFUSE_ERROR_ATTR(under_voltage_warn, REGULATOR_ERROR_UNDER_VOLTAGE_WARN);
>> +EFUSE_ERROR_ATTR(over_current_warn, REGULATOR_ERROR_OVER_CURRENT_WARN);
>> +EFUSE_ERROR_ATTR(over_voltage_warn, REGULATOR_ERROR_OVER_VOLTAGE_WARN);
>> +EFUSE_ERROR_ATTR(over_temp_warn, REGULATOR_ERROR_OVER_TEMP_WARN);
>> +
>> +static struct attribute *efuse_attrs[] = {
>> + &dev_attr_operstate.attr,
>> + &dev_attr_under_voltage.attr,
>> + &dev_attr_over_current.attr,
>> + &dev_attr_regulation_out.attr,
>> + &dev_attr_fail.attr,
>> + &dev_attr_over_temp.attr,
>> + &dev_attr_under_voltage_warn.attr,
>> + &dev_attr_over_current_warn.attr,
>> + &dev_attr_over_voltage_warn.attr,
>> + &dev_attr_over_temp_warn.attr,
>> + NULL,
>> +};
>> +ATTRIBUTE_GROUPS(efuse);
>
>Shouldn't these all just be what all regulator drivers report? Or power
>drivers? I find it odd that this would be the first driver that would
>need to export these types of attributes. Surely there's already a
>class for this?
>

The attributes available from the underlying regulator device don't
include the error flags, and while they do include its state
('operstate' here), it's a read-only attribute, and from previous
discussions with Mark I gathered that was unlikely to change (whereas it
being read-write is a critical part of this driver's functionality).

Given his input on the first stab at this I took a while back, I've been
hoping to hear from Mark as to whether this looked more like something
he'd find palatable; perhaps he could chime in on this too? (And/or on
the regulator API question in the cover letter.)


Thanks,
Zev

\
 
 \ /
  Last update: 2022-03-08 09:24    [W:0.093 / U:2.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site