netdev - Re: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon interface with FAN fault attribute

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180626142838.GC5064@lunn.ch>
Date:   Tue, 26 Jun 2018 16:28:38 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vadim Pasternak <vadimp@...lanox.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, linux@...ck-us.net,
        rui.zhang@...el.com, edubezval@...il.com, jiri@...nulli.us,
        mlxsw@...lanox.com, michaelsh@...lanox.com
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?

     Andrew