Instead of if conditions with line splits, use the usual error handling
pattern with a separate variable to improve readability. Handle error
print with a label instead of trying to chain everything into a single
if condition.
No functional changes intended.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20230824132832.78705-14-ilpo.jarvinen@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Instead of if conditions with line splits, use the usual error handling
pattern with a separate variable to improve readability.
No functional changes intended.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20230824132832.78705-7-ilpo.jarvinen@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Instead of if conditions with line splits, use the usual error handling
pattern with a separate variable to improve readability.
No functional changes intended.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20230824132832.78705-6-ilpo.jarvinen@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
After doing performance optimizations the pli1209 driver failed to
probe with a probabilty of 2%. It wasn't able to read the PMBUS_OPERATION
register due to an -EIO error.
An investigation showed that the PLI1209 takes 230 usec to execute the
CLEAR_FAULTS command. During that time it's busy and NACKs all requests
on the SMBUS interface. It also NACKs reads on PMBUS_STATUS_BYTE
making it impossible to poll the BUSY flag.
Add a custom write_data function to just wait for not BUSY unconditionally
after sending a CLEAR_FAULTS command.
TEST: Verified using an I2C bus analyser that no more NACKs are seen after
sending a CLEAR_FAULTS command.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230817092527.808631-3-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The pmbus_check_byte_register function already calls clear
fault page, so there's no need to do it again in
pmbus_identify_common.
TEST: Verified using an I2C bus analyser to confirm that only
one clear fault page is being send instead of two in a row.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230817092527.808631-2-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Observing I2C traffic revealed consecutive transmission of CLEAR_FAULT
commands. While this doesn't cause issues, it extends driver probe time.
Avoid invoking pmbus_clear_fault_page for virtual registers, as they're
managed by the driver, not the chip.
TEST: Verified using an I2C bus analyzer that only one CLEAR_FAULT
command is send instead 5 in a row.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230817092527.808631-1-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'chip' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
ucd9200.c:106:10: error: cast to smaller integer type 'enum chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-15-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'chip' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
ucd9000.c:591:10: error: cast to smaller integer type 'enum chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-14-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'chip_id' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
tps53679.c:238:13: error: cast to smaller integer type 'enum chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-13-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'vs' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
ibm-cffps.c:492:8: error: cast to smaller integer type 'enum versions' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-12-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'id' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
tmp513.c:724:14: error: cast to smaller integer type 'enum tmp51x_ids' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-11-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'type' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
max6697.c:705:16: error: cast to smaller integer type 'enum chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-10-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'chip_id' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
max20730.c:719:13: error: cast to smaller integer type 'enum chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-9-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'kind' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
lm90.c:2768:16: error: cast to smaller integer type 'enum chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-8-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'type' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
lm85.c:1562:16: error: cast to smaller integer type 'enum chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-7-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'kind' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
lm75.c:581:10: error: cast to smaller integer type 'enum lm75_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-6-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'kind' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
lm63.c:1108:16: error: cast to smaller integer type 'enum chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-5-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'chip' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
ina2xx.c:627:10: error: cast to smaller integer type 'enum ina2xx_ids' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-4-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'chip' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
ads7828.c:142:10: error: cast to smaller integer type 'enum ads7828_chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'type' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
ad7418.c:256:16: error: cast to smaller integer type 'enum chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'chip' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
adt7475.c:1655:10: error: cast to smaller integer type 'enum chips' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810093157.94244-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Additional TEMP registers for nct6798d, nct6799d-r and nct6796d-s
This allows the max/max_hyst/crit attributes to be shown/stored
* Increase NUM_TEMP from 10 to 12
* Separate TEMP/MON_TEMP/OVER/HYST/CRIT registers
* Rename "PECI Calibration" to include "TSI" too
* Update ALARM/BEEP bits for temps for 6799
* For 6799, keep temp_fixed_num at 6, but increase
num_temp_alarms/num_temp_beeps to 7/8
Tested with NCT6799D-R showing additional sysfs attributes:
* temp3-temp8: max/max_hyst/beep/alarm
* temp3-temp6: crit/offset
Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws>
Link: https://lore.kernel.org/r/20230802185820.3642399-1-ahmad@khalifa.ws
[groeck: Addressed cosmetic checkpatch complaints]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add base support for Renesas HS3001 temperature
and humidity sensors and its compatibles HS3002,
HS3003 and HS3004.
The sensor has a fix I2C address 0x44. The resolution
is fixed to 14bit (ref. Missing feature).
Missing feature:
- Accessing non-volatile memory: Custom board has no
possibility to control voltage supply of sensor. Thus,
we cannot send the necessary control commands within
the first 10ms after power-on.
Signed-off-by: Andre Werner <andre.werner@systec-electronic.com>
Link: https://lore.kernel.org/r/20230725042207.22310-2-andre.werner@systec-electronic.com
[groeck: Cosmetic documentation fixup; added documentation to index;
replaced probe_new with probe dropped unused variable]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add binding for Renesas HS3001 Temperature and Relative Humidity Sensor.
Signed-off-by: Andre Werner <andre.werner@systec-electronic.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230726051635.9778-1-andre.werner@systec-electronic.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The following warning is given by the Smatch static checker:
drivers/hwmon/hp-wmi-sensors.c:1937 hp_wmi_sensors_init()
error: uninitialized symbol 'pevents'.
If there are no instances of the HPBIOS_PlatformEvents WMI object
available, init_platform_events() never initializes this pointer,
which may then be passed to hp_wmi_debugfs_init() uninitialized.
The impact should be limited because hp_wmi_debugfs_init() uses this
pointer only if the count of HPBIOS_PlatformEvents instances is _not_
zero, while conversely, it will be uninitialized only if the count of
such instances _is_ zero. However, passing it uninitialized still
constitutes a bug.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/linux-hwmon/f72c129b-8c57-406a-bf41-bd889b65ea0f@moroto.mountain/
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230725094817.588640-1-james@equiv.tech
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Commit 2a2b13ae50 ("platform/x86: wmi: Allow retrieving the number of
WMI object instances") means we no longer need to find this ourselves.
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230722172513.9324-2-james@equiv.tech
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* Add additional VIN/IN_MIN/IN_MAX register values
* Separate ALARM/BEEP bits for nct6799
* Update scaling factors for nct6799
Registers/alarms match for NCT6796D-S and NCT6799D-R
Tested on NCT6799D-R for new IN/MIN/MAX and ALARMS
Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws>
Link: https://lore.kernel.org/r/20230719224142.411237-1-ahmad@khalifa.ws
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
MP2973 & MP2971 return PGOOD instead of PB_STATUS_POWER_GOOD_N.
Fix that in the read_word_data hook.
MP2975 should not be affected, but that has not been confirmed with
hardware.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230731092204.2933045-1-Naresh.Solanki@9elements.com
[groeck: Rephrased description to indicate that MP2975 is likely not affected]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for PMBUS_IOUT_OC_FAULT_LIMIT.
Add a helper function to convert the limit to LINEAR11 format
and read data->info.phases[0] on MP2971 and MP2973 as well.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230714135124.2645339-8-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support to expose the PMBUS regulator.
Tested on MP2973 and MP2971.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230714135124.2645339-7-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for MP2971 and MP2973, the successor of MP2975.
The major differences are:
- On MP2973 and MP2971 the Vref cannot be read and thus most of
the OVP/current calculations won't work.
- MP2973 and MP2971 also support LINEAR format for VOUT
- MP2973 and MP2971 do not support OVP2
- On MP2973 and MP2971 most registers are in LINEAR format
- The IMVP9_EN bit has a different position
- Per phase current sense haven't been implemented.
As on MP2975 most of the FAULT_LIMIT and WARN_LIMIT registers
have been redefined and doesn't provide the functionality as
defined in PMBUS spec.
Tested on MP2973 and MP2971.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230714135124.2645339-6-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In order to add support for MP2973 and MP2971 replace hardcoded
phase count for both channels by a variable.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230714135124.2645339-5-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In order to upstream MP2973/MP2971 simplify the code by removing support
for various VOUT formats. The MP2973 and MP2971 supports all PMBUS
supported formats for VOUT, while the MP2975 only support DIRECT and
VID for VOUT.
In DIRECT mode all chips report the voltage in 1mV/LSB.
Configure the chip to use DIRECT format for VOUT and drop the code
conversion code for other formats. The to be added chips MP2973/MP2971
will be configured to also report VOUT in DIRECT format.
The maximum voltage that can be reported in DIRECT format is 32768mV.
This is sufficient as the maximum output voltage for VR12/VR13 is
3040 mV.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230714135124.2645339-4-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for differntiating between the chips.
The following commits will make use of this mechanism.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230714135124.2645339-3-Naresh.Solanki@9elements.com
[groeck: double-cast of_device_get_match_data() to make gcc happy]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add test if thermistor sensor type attribute should be visible, i.e.
test if the attribute is defined.
Signed-off-by: Frank Crawford <frank@crawford.emu.id.au>
Link: https://lore.kernel.org/r/20230707123005.956415-3-frank@crawford.emu.id.au
[groeck: Dropped unnecessary 'type' variable in it87_temp_is_visible()]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The temperature sensor type will need to be used in multiple places, so
split it out into its own function.
Signed-off-by: Frank Crawford <frank@crawford.emu.id.au>
Link: https://lore.kernel.org/r/20230707123005.956415-2-frank@crawford.emu.id.au
[groeck: Dropped unnecessary 'type' variable in show_temp_type()]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Move detection logic to the start of init() function so we won't
instantiate the driver if the board is not compatible.
Signed-off-by: Joaquín Ignacio Aramendía <samsagax@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20230717222526.229984-3-samsagax@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* Increase available bits, IN: 16 to 24, FAN: 8 to 12,
TEMP: 6 to 12
* Reorder alarm/beep definitions to match in order to allow
additional inputs in the future
* Remove comments about 'unused' bits as probe() is a better
reference
Testing note:
* Tested on nct6799 with IN/FAN/TEMP, and changing min/max/high/hyst,
that triggers the corresponding alarms correctly. Good confirmation
on the original mapping of the registers and masks.
As to be expected, only 4 fans and 2 temps (fixed) have limits
currently on nct6799 on my board.
* Trouble with testing intrusion alarms and beeps, no way to confirm
those. As I understand now, intrusion/caseopen is probably not
connected on my board.
And I haven't seen a buzzer on a board in ages.
Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws>
Link: https://lore.kernel.org/r/20230717201050.1657809-1-ahmad@khalifa.ws
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
SMM665 and related chips are power controller/sequencer chips from
Summit Microelectronics. The company was acquired by Qualcomm in 2012,
and support for the chip series stopped.
The chips are long since gone from active use, making the driver
unsupportable and just consuming space and compile time. Remove it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
nct6799d-r and nct6796d-s are very similar and chip_id is only
different in the version nibblet.
Since both will be detected by the driver anyway due to the
chipid mask, they should be labeled together for dmesg msg.
Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws>
Link: https://lore.kernel.org/r/20230715195244.1334723-1-ahmad@khalifa.ws
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This patch introduces support for handling more than 32 DIMMs by
utilizing bitmap operations. The changes ensure that the driver can
handle a higher number of DIMMs efficiently.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Link: https://lore.kernel.org/r/20230711152144.755177-1-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
strlcpy() reads the entire source buffer first.
This read may exceed the destination size limit.
This is both inefficient and can lead to linear read
overflows if a source string is not NUL-terminated [1].
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with direct assignment.
strlcpy in this file is used to copy fixed-length strings which can be
completely avoided by direct assignment and is safe to do so. strlen()
is used to return the length of @tbuf.
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
[2] https://github.com/KSPP/linux/issues/89
Signed-off-by: Azeem Shaikh <azeemshaikh38@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230712214307.2424810-1-azeemshaikh38@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230714174607.4057185-1-robh@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
