linux-kernel - Re: [PATCH] [v1 1/1]hwmon:(pmbus) Validate the data for chip supporting vout_mode (PMBUS_HAVE

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] [day] [month] [year] [list]

Message-ID: <22ea65b3-5832-c340-195d-058cf3c34f8d@roeck-us.net>
Date:   Wed, 12 Oct 2022 21:35:25 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     karthik gengan <gengankarthik@...il.com>
Cc:     Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [v1 1/1]hwmon:(pmbus) Validate the data for chip
 supporting vout_mode (PMBUS_HAVE_VOUT) in the linear config.

On 10/12/22 20:42, karthik gengan wrote:
> Hi Guenter,
> 
> Thanks for your response but I need some more valuable suggestions...
> 
>          In the pmbus_data structure, we are updating the vout_out mode
> value based on the config ( linear, vid .direct) and this structure is declared
> in pmbus_core.c .so the low-level driver could not able to access this
> structure.
> 
> Guidance required,
>       1. Move the pumbus_data structure declaration to pmbus.h, so that low-level
>            the driver can check and update the vout_mode if the value
> is not proper.   (or)
>       2.  if the vout_mode attribute value is exposed in the sysfs, the
> user-level application
>            can modify the value. ( if the value is not proper).
>                                 (or)
>        3. if an ioctl call is exposed for the vout_mode then the
> user-level application can
>             able to update the value. ( if the value is not proper).
> 
> (or)  guide me to a better approach to handle this issue.
> 

Have a look at drivers/hwmon/pmbus/stpddc60.c. That chip reports a wrong
value for PMBUS_VOUT_MODE, and the driver provides the expected value
to the PMBus core. Taking that as example, the simple solution is to have
the chip driver report the expected value. There is no need to get
userspace involved. Actually, involving userspace would be completely wrong.

> For reference,
>            UCD90xx vendor claims that vout_mode value should be present
> if the chip
> supports PMBUS_VOUT_MODE command. Hence the patch validated the vout_mode
> value for PMBUS_VOUT_MODE supported chip.
> 

Not sure if I understand, but if any of the chips supported by the ucd9009
driver does not support the VOUT_MODE command or reports a wrong value,
just extend ucd9000_read_byte_data() to report whatever value the command
should return.

That would need some confirmation, though - I don't recall any such problem,
and  UCD90xxx Sequencer and System Health Controller PMBUS Command Reference
(SLVU352) clearly states that the command is supported.

Guenter