From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35002C433EF for ; Tue, 8 Mar 2022 08:23:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238477AbiCHIYl (ORCPT ); Tue, 8 Mar 2022 03:24:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233073AbiCHIYk (ORCPT ); Tue, 8 Mar 2022 03:24:40 -0500 Received: from thorn.bewilderbeest.net (thorn.bewilderbeest.net [IPv6:2605:2700:0:5::4713:9cab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E49F53EB92 for ; Tue, 8 Mar 2022 00:23:44 -0800 (PST) Received: from hatter.bewilderbeest.net (174-21-187-98.tukw.qwest.net [174.21.187.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: zev) by thorn.bewilderbeest.net (Postfix) with ESMTPSA id 93415D5; Tue, 8 Mar 2022 00:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bewilderbeest.net; s=thorn; t=1646727824; bh=nCIeA+pD7UIkhYfAGPyqv1fA/V0MCCLPp3PnFFH4JuE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=P7/5TLXwWe+M9EPD48wklgkHZzEuUAzzU8pHSUXPUTwPljH/I2Jb+HIPgiAShEl/S QHok6BwBnjEb0t8XNWoG7Y8fTyrX5JdHvWFSrZ0CnJ9YYmC5DBkwg/Y4rKfRN/8VgN gGw9SE2mRFLF2JU6VlYa+IOMM3Wjs6weHhN2laI8= Date: Tue, 8 Mar 2022 00:23:43 -0800 From: Zev Weiss To: Greg Kroah-Hartman Cc: Arnd Bergmann , openbmc@lists.ozlabs.org, linux-kernel@vger.kernel.org, Mark Brown , Liam Girdwood Subject: Re: [PATCH v2 2/2] misc: Add power-efuse driver Message-ID: References: <20220308011811.10353-1-zev@bewilderbeest.net> <20220308011811.10353-3-zev@bewilderbeest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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