linux-kernel - [PATCH 0/1] hwmon: (pmbus) Try to match MFR

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

Date:   Wed, 16 Feb 2022 12:55:36 +0100
From:   Erik Rosen <erik.rosen@...ormote.com>
To:     Jean Delvare <jdelvare@...e.com>,
        Guenter Roeck <linux@...ck-us.net>,
        linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
        Chu Lin <linchuyuan@...gle.com>,
        Jason Ling <jasonling@...gle.com>
Cc:     Erik Rosen <erik.rosen@...ormote.com>
Subject: [PATCH 0/1] hwmon: (pmbus) Try to match MFR_MODEL to pmbus device id

The UCD3138 chip from TI used in a number of Flex pmbus converters
(BMR310, BMR458, BMR480, BMR490 and BMR491) has a bug in the PMBus
interface hardware that causes it to not respond properly after
trying to read a register that does not exist
(see the 'UCD3138 Integrated Power Controller Family Errata').
This will mess up the pmbus driver's auto-detection process.

To remedy this situation the current version of the driver
supports a flag named PMBUS_READ_STATUS_AFTER_FAILED_CHECK.
If this flag is set the driver will read the STATUS register
after each failed register check with the assumption that this
will reset the hardware interface to a known state.

This strategy significantly improves the situation but does
not completely resolve the issue. In rare cases this seems
to be insufficient to reset the interface and the auto-detection
still fails.

In addition to this, to use this workaround one must explicitly
instruct the driver to expect for instance a BMR490 module.
Otherwise the driver will default to the generic behaviour.

We have a situation where the client wants to use the generic
pmbus driver to monitor the temperature of the converter,
but does not know a priori exactly what converter model is
actually installed; only that it supports PMBus.

To solve this problem, it is possible to use the MFR_MODEL
command to try and match the model name to the device id name
and predefine the functions supported by this specific converter.
In this way one can avoid the auto-detection process
altogether for the problematic models. If there is no match,
the driver reverts to auto-detection.

Erik Rosen (1):
  Try to match MFR_MODEL to pmbus device id

 drivers/hwmon/pmbus/pmbus.c | 57 +++++++++++++++++++++++++++++++------
 1 file changed, 49 insertions(+), 8 deletions(-)

base-commit: df0cc57e057f18e44dac8e6c18aba47ab53202f9
-- 
2.20.1