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]
Date:   Mon, 11 Apr 2022 15:09:53 -0700
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Arnd Bergmann <arnd@...db.de>, openbmc@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH v2 2/2] misc: Add power-efuse driver

On Tue, Mar 08, 2022 at 12:23:44AM PST, Zev Weiss wrote:
>On Mon, Mar 07, 2022 at 11:07:57PM PST, Greg Kroah-Hartman wrote:
>
>>>+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.)
>

Ping...Mark (or Liam?), any thoughts on an appropriate path forward on 
this?


Thanks,
Zev

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ