Re: [PATCH net-next v3 4/6] eth: fbnic: report temperature and voltage thresholds via hwmon

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unsupported threshold attributes are unconditionally exposed in sysfs, violating hwmon is_visible semantics.
--

commit 7ed3607652912ec9e3313daf244c76341872a2fc
Author: Zinc Lim <limzhineng2@gmail.com>

eth: fbnic: report temperature and voltage thresholds via hwmon

The firmware capability response carries per-board temperature
(min/max/crit) and voltage (min/max) thresholds. These are parsed and
exposed through the hwmon interface, returning -ENODATA if the firmware
did not report them.

> diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c b/drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c
> index c8e7ff1d36fc1..7dc4d705f5662 100644
> --- a/drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c
> +++ b/drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c
> @@ -7,16 +7,6 @@
>  #include "fbnic.h"
>  #include "fbnic_mac.h"
>  
[ ... ]
>  static umode_t fbnic_hwmon_is_visible(const void *drvdata,
>  				      enum hwmon_sensor_types type,
>  				      u32 attr, int channel)
>  {
>  	return 0444;
>  }

[Severity: Medium]
Does this unconditionally expose sysfs attributes even when they are not
supported by the firmware?

Since this patch introduces threshold values that might be missing and
represented by FBNIC_SENSOR_NO_DATA, the hwmon is_visible callback should
return 0 for those unsupported attributes rather than having the read
callback unconditionally return -ENODATA. Creating sysfs entries that
cannot be read clutters sysfs and violates the expected hwmon API contract.

Could fbnic_hwmon_is_visible be updated to inspect the cached capabilities
via drvdata and return 0 when the corresponding threshold is set to
FBNIC_SENSOR_NO_DATA?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908225737.3034403-1-limzhineng2@gmail.com?part=4