From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Subject: Re: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon interface with FAN fault attribute Date: Tue, 26 Jun 2018 09:32:32 -0700 Message-ID: <20180626163232.GA32079@roeck-us.net> References: <1530015037-67361-1-git-send-email-vadimp@mellanox.com> <1530015037-67361-12-git-send-email-vadimp@mellanox.com> <20180626142838.GC5064@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Lunn , "davem@davemloft.net" , "netdev@vger.kernel.org" , "rui.zhang@intel.com" , "edubezval@gmail.com" , "jiri@resnulli.us" , mlxsw , Michael Shych To: Vadim Pasternak Return-path: Received: from bh-25.webhostbox.net ([208.91.199.152]:60160 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752093AbeFZQcg (ORCPT ); Tue, 26 Jun 2018 12:32:36 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Jun 26, 2018 at 02:47:01PM +0000, Vadim Pasternak wrote: > > > > -----Original Message----- > > From: Andrew Lunn [mailto:andrew@lunn.ch] > > Sent: Tuesday, June 26, 2018 5:29 PM > > To: Vadim Pasternak > > Cc: davem@davemloft.net; netdev@vger.kernel.org; linux@roeck-us.net; > > rui.zhang@intel.com; edubezval@gmail.com; jiri@resnulli.us; mlxsw > > ; Michael Shych > > Subject: Re: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon interface > > with FAN fault attribute > > > > > +static ssize_t mlxsw_hwmon_fan_fault_show(struct device *dev, > > > + struct device_attribute *attr, > > > + char *buf) > > > +{ > > > + struct mlxsw_hwmon_attr *mlwsw_hwmon_attr = > > > + container_of(attr, struct mlxsw_hwmon_attr, > > dev_attr); > > > + struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon; > > > + char mfsm_pl[MLXSW_REG_MFSM_LEN]; > > > + u16 tach; > > > + int err; > > > + > > > + mlxsw_reg_mfsm_pack(mfsm_pl, mlwsw_hwmon_attr->type_index); > > > + err = mlxsw_reg_query(mlxsw_hwmon->core, MLXSW_REG(mfsm), > > mfsm_pl); > > > + if (err) { > > > + dev_err(mlxsw_hwmon->bus_info->dev, "Failed to query > > fan\n"); > > > + return err; > > > + } > > > + tach = mlxsw_reg_mfsm_rpm_get(mfsm_pl); > > > + > > > + return sprintf(buf, "%u\n", (tach < mlxsw_hwmon->tach_min) ? 1 : 0); > > > +} > > > > Documentation/hwmon/sysfs-interface says: > > > > Alarms are direct indications read from the chips. The drivers do NOT make > > comparisons of readings to thresholds. This allows violations between readings > > to be caught and alarmed. The exact definition of an alarm (for example, > > whether a threshold must be met or must be exceeded to cause an alarm) is > > chip-dependent. > > > > Now, this is a fault, not an alarm. But does the same apply? > Yes, it does. There are no "soft" alarms / faults. > Hi Andrew, > > Hardware provides minimum value for tachometer. > Tachometer is considered as faulty in case it's below this > value. This is for user space to decide, not for the kernel. > In case any tachometer is faulty, PWM according to the > system requirements should be set to 100% until the fault system requirements. Again, this is for user space to decide. > is not recovered (f.e. by physical replacing of bad unit). > This is the motivation to expose fan{x}_fault in the way > it's exposed. > > Thanks, > Vadim. > > > > > Andrew