hwmon: Remove devm_hwmon_device_unregister() API function
devm_hwmon_device_unregister() has no in-tree user, and its implementation
is wrong since it does not pass the to-be-removed hardware monitoring
device as parameter. I do not envision a valid use for it; drivers needing
it should not have called devm_hwmon_device_register_with_info() in the
first place. Remove it.
Reported-by: Matthew Sanders <m@ttsande.rs> Closes: https://lore.kernel.org/linux-hwmon/488b3bdf870ea76c4b943dbe5fd15ac8113019dc.camel@kernel.org/ Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Andy Shevchenko [Wed, 11 Sep 2024 20:19:03 +0000 (23:19 +0300)]
hwmon: (sch5636) Print unknown ID in error string via %*pE
Instead of custom approach this allows to print escaped strings
via %*pE extension. With this the unknown ID will be printed
as a string. Nonetheless, leave hex values to be printed as well.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Message-ID: <20240911201903.2886874-1-andriy.shevchenko@linux.intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'struct regulator_desc' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security, especially when the structure holds some
function pointers.
This also makes mpq7932_regulators_desc consistent with
mpq7932_regulators_desc_one which is already a "static const struct
regulator_desc".
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
3516 2264 0 5780 1694 drivers/hwmon/pmbus/mpq7932.o
After:
=====
text data bss dec hex filename
5396 384 0 5780 1694 drivers/hwmon/pmbus/mpq7932.o
Patrick Rudolph [Mon, 2 Sep 2024 07:53:16 +0000 (09:53 +0200)]
hwmon: pmbus: pli12096bc: Add write delay
Tests on PLI12096bc showed that sometimes a small delay is necessary
after a write operation before a new operation can be processed.
If not respected the device will probably NACK the data phase of
the SMBus transaction. Tests showed that the probability to observe
transaction errors can be raised by either reading sensor data or
toggling the regulator enable.
Further tests showed that 250 microseconds, as used previously for
the CLEAR_FAULTS workaround, is sufficient.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Message-ID: <20240902075319.585656-5-patrick.rudolph@9elements.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Patrick Rudolph [Mon, 2 Sep 2024 07:53:12 +0000 (09:53 +0200)]
hwmon: pmbus: Implement generic bus access delay
Some drivers, like the max15301 or zl6100, are intentionally delaying
SMBus communications, to prevent transmission errors. As this is necessary
on additional PMBus compatible devices, implement a generic delay mechanism
in the pmbus core.
Introduces two delay settings in the pmbus_driver_info struct, one applies
to every SMBus transaction and the other is for write transaction only.
Once set by the driver the SMBus traffic, using the generic pmbus access
helpers, is automatically delayed when necessary.
The two settings are:
access_delay:
- Unit in microseconds
- Stores the accessed timestamp after every SMBus access
- Delays when necessary before the next SMBus access
write_delay:
- Unit in microseconds
- Stores the written timestamp after a write SMBus access
- Delays when necessary before the next SMBus access
This allows to drop the custom delay code from the drivers and easily
introduce this feature in additional pmbus drivers.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Message-ID: <20240902075319.585656-1-patrick.rudolph@9elements.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Thu, 29 Aug 2024 00:21:41 +0000 (17:21 -0700)]
hwmon: (ina2xx) Use shunt voltage to calculate current
Since the shunt voltage and the current register report the same values
when the chip is calibrated, we can calculate the current directly
from the shunt voltage without relying on chip calibration.
With this change, the current register is no longer accessed. Its
register address is only used to indicate if reading or writing
current or shunt voltage is desired when accessing registers.
Guenter Roeck [Wed, 28 Aug 2024 22:23:53 +0000 (15:23 -0700)]
hwmon: (ina2xx) Add support for current limits
While the chips supported by this driver do not directly support current
limits, they do support setting shunt voltage limits. The shunt voltage
divided by the shunt resistor value is the current. On top of that,
calibration values are set such that in the shunt voltage register and
the current register report the same values. That means we can report and
configure current limits based on shunt voltage limits, and we can do so
with much better accuracy than by setting shunt voltage limits.
Alerts should only be cleared after reported, not immediately after the
alert condition has been cleared. Set the latch enable bit to keep alerts
latched until the alert register has been read from the chip.
Module tests show various overflow problems when writing limits
and other attributes.
in0_crit: Suspected overflow: [max=82, read 0, written 2147483648]
in0_lcrit: Suspected overflow: [max=82, read 0, written 2147483648]
in1_crit: Suspected overflow: [max=40959, read 0, written 2147483647]
in1_lcrit: Suspected overflow: [max=40959, read 0, written 2147483647]
power1_crit: Suspected overflow: [max=134218750, read 0, written 2147483648]
update_interval: Suspected overflow: [max=2253, read 2, written 2147483647]
Implement missing clamping on attribute write operations to avoid those
problems.
While at it, check in the probe function if the shunt resistor value
passed from devicetree is valid, and bail out if it isn't. Also limit
mutex use to the code calling ina2xx_set_shunt() since it isn't needed
when called from the probe function.
hwmon: (ina2xx) Re-initialize chip using regmap functions
If it is necessary to re-initialize the chip, for example because
it has been power cycled, use regmap functions to update register
contents. This ensures that all registers, including the configuration
register and alert registers, are updated to previously configured
values without having to locally cache everything.
For this to work, volatile registers have to be marked as volatile.
Also, the cache needs to be bypassed when reading the calibration
and mask_enable registers. While the calibration register is not
volatile, it will be reset to 0 if the chip has been power cycled.
Most of the bits in the mask_enable register are configuration bits,
except for bit 4 which reports if an alert has been observed.
Both registers need to be marked as non-volatile to be updated
after a power cycle, but it is necessary to bypass the cache when
reading them to detect if the chip has been power cycled and to
read the alert status.
The chip does not support register auto-increments. It is therefore
necessary to configure regmap to use single register read/write
operations. Otherwise regmap tries to write all registers in a single
operation when synchronizing register contents with the hardware,
and the synchronization fails.
Another necessary change is to declare ina226_alert_to_reg() as u16.
So far it returned an s16 which is sign extended to a large negative
value which is then sent to regmap as unsigned int, causing an -EINVAL
error return.
Guenter Roeck [Thu, 1 Aug 2024 23:43:03 +0000 (16:43 -0700)]
hwmon: (ina2xx) Mark regmap_config as const
Recent versions of checkpatch complain that struct regmap_config
should be declared as const.
WARNING: struct regmap_config should normally be const
Doing so reveals a potential problem in the driver: If both supported
chips are present in a single system, the maximum number of registers
may race when devices are instantiated since max_registers is updated
in the probe function. Solve the problem by setting .max_registers to the
maximum register address of all supported chips. This does not make a
practical difference while fixing the potential race condition and reducing
code complexity.
Use bit operations where possible to make the code more generic and to
align it with other drivers. Also use compile time conversion from bit
to mask to reduce runtime overhead.
Fix below warning:
arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dtb: /soc/i2c@2000000/i2c-mux@77/i2c@2/regulator@5c:
failed to match any schema with compatible: ['lltc,ltc3882']
Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Message-ID: <20240829150641.1307906-1-Frank.Li@nxp.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Nathan Chancellor [Wed, 28 Aug 2024 18:05:35 +0000 (11:05 -0700)]
hwmon: (oxp-sensors) Add missing breaks to fix -Wimplicit-fallthrough with clang
clang warns (or errors due to CONFIG_WERROR):
drivers/hwmon/oxp-sensors.c:481:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
drivers/hwmon/oxp-sensors.c:553:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
drivers/hwmon/oxp-sensors.c:556:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
drivers/hwmon/oxp-sensors.c:607:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
Clang is a little more pedantic than GCC, which does not warn when
falling through to a case that is just break or return. Clang's version
is more in line with the kernel's own stance in deprecated.rst, which
states that all switch/case blocks must end in either break,
fallthrough, continue, goto, or return. Add the missing breaks to
silence the warnings.
Fixes: b82b38a49926 ("hwmon: (oxp-sensors) Add support for multiple new devices.") Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Message-ID: <20240828-hwmon-oxp-sensors-fix-clang-implicit-fallthrough-v1-1-dc48496ac67a@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Johannes Kirchmair [Tue, 27 Aug 2024 05:44:54 +0000 (07:44 +0200)]
hwmon: (pwmfan) Do not force disable pwm controller
The pwm1_enable attribute of the pwmfan driver influences the mode of
operation, especially in case of a requested pwm1 duty cycle of zero.
Especially setting pwm1_enable to two, should keep the pwm controller
enabled even if the duty cycle is set to zero [1].
This is not the case at the moment, as the pwm controller is disabled
always if pwm1 is set to zero.
This commit tries to fix this behavior.
[1] https://docs.kernel.org/hwmon/pwm-fan.html
Signed-off-by: Johannes Kirchmair <johannes.kirchmair@skidata.com>
Message-ID: <20240827054454.521494-1-mailinglist1@johanneskirchmair.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Derek J. Clark [Thu, 22 Aug 2024 18:35:25 +0000 (11:35 -0700)]
hwmon: (oxp-sensors) Add support for multiple new devices.
Add support for the OrangePi NEO-01. It uses different registers for PWM
manual mode, set PWM, and read fan speed than previous devices. Valid PWM
input and duty cycle is 1-244, we scale this from 1-255 to maintain
compatibility with the existing interface.
Add OneXPlayer 2 series, OneXFly, and X1 series models. The 2/X1 series use
new registers for turbo button takeover and read fan speed. X1 has an Intel
variant so change the CPU detection at init to only check for the affected
devices. While at it, adjust formatting of some constants and reorder all
cases alphabetically for consistency. Rename OXP_OLD constants to OXP_MINI
for disambiguation. Update code comments for clarity.
Add support for AYANEO models 2S, AIR 1S, Flip series, GEEK 1S, and KUN.
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Kevin Greenberg <kdgreenberg234@protonmail.com> Tested-by: Joshua Tam <csinaction@pm.me> Tested-by: Parth Menon <parthasarathymenon@gmail.com> Tested-by: Philip Müller <philm@manjaro.org> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202408160329.TLNbIwRC-lkp@intel.com/
Message-ID: <20240822183525.27289-2-derekjohn.clark@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Rob Herring (Arm) [Mon, 26 Aug 2024 19:18:11 +0000 (14:18 -0500)]
hwmon: (stts751) Add "st" vendor prefix to "stts751" compatible string
The documented compatible string is "st,stts751", not "stts751". Even if
"stts751" was in use, there's no need to list "stts751" in the DT match
table. The I2C core will strip any vendor prefix and match against the
i2c_device_id table which has an "stts751" entry.
Maximilian Luz [Sun, 11 Aug 2024 00:14:41 +0000 (02:14 +0200)]
hwmon: Add thermal sensor driver for Surface Aggregator Module
Some of the newer Microsoft Surface devices (such as the Surface Book
3 and Pro 9) have thermal sensors connected via the Surface Aggregator
Module (the embedded controller on those devices). Add a basic driver
to read out the temperature values of those sensors.
The EC can have up to 16 thermal sensors connected via a single
sub-device, each providing temperature readings and a label string.
Link: https://github.com/linux-surface/surface-aggregator-module/issues/59 Reviewed-by: Hans de Goede <hdegoede@redhat.com> Co-developed-by: Ivor Wanders <ivor@iwanders.net> Signed-off-by: Ivor Wanders <ivor@iwanders.net> Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Message-ID: <20240811001503.753728-1-luzmaximilian@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Javier Carrasco [Mon, 12 Aug 2024 22:59:53 +0000 (00:59 +0200)]
hwmon: (chipcap2) Drop cc2_disable() in the probe and return dev_err_probe()
There is no need to actively disable a regulator that has not been
enabled by the driver, which makes the call to cc2_disable() in the
probe function meaningless, because the probe function never enables
the device's dedicated regulator.
Once the call to cc2_disable() is dropped, the error paths can directly
return dev_err_probe() in all cases.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Message-ID: <20240813-chipcap2-probe-improvements-v2-1-e9a2932a8a00@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Update datasheet references. Replace misleading 'force parameter needed'
with 'must be instantiated explicitly'. Explain the reason for the missing
auto-detection. Mention all supported chips in Kconfig.
hwmon: (lm92) Replace chip IDs with limit register resolution
The chip IDs are not used by the driver. Drop them. Use driver data to
store the limit register resolution instead, and use this information
when writing temperature limits to improve chip specific rounding and
to avoid writing into unused register bits.
Checking three configuration register bits and the manufacturer ID
register to auto-detect LM92 is a bit vague. Repeat twice on replicated
register addresses to improve detection accuracy. Check the manufacturer
ID first and bail out immediately without reading the other register if
there is a mismatch to reduce the number of i2c transfers needed in that
case. Also explicitly test for an error from reading the configuration
register to avoid potential situations where the returned error masked
against 0xe0 is 0.
While at it, drop "lm92: Found National Semiconductor LM92 chip" detection
noise.
Use of_property_present() to test for property presence rather than
of_get_property(). This is part of a larger effort to remove callers
of of_get_property() and similar functions. of_get_property() leaks
the DT property data pointer which is a problem for dynamically
allocated nodes which may be freed.
Bail out immediately if reading any of the registers used for chip
detection fails, or if it returns an unexpected value. Drop all log
messages from detection code.
Use regmap for local caching, to hide register read/write address
differences, and for multi-byte operations. With this change,
the driver specific lock is no longer necessary.
While at it, check errors seen when initializing the chip and bail out
if chip initialization fails.
Bit 0, 5, and 6 in the status register are reserved and, if set, do not
indicate an alarm. Bit 7 is the 'busy' bit and also does not indicate
an alarm. Mask the non-alarm bits to avoid reporting them to userspace.
hwmon: (max1619) Clamp temperature range when writing limits
Module test code reports underflows when writing sensor limits.
temp2_min: Suspected underflow: [min=-77000, read 101000, written -2147483648]
temp2_max: Suspected underflow: [min=-77000, read 101000, written -2147483648]
temp2_crit: Suspected underflow: [min=-77000, read 101000, written -2147483648]
Clamp temperature ranges when writing limits to fix the problem.
While at it, use sign_extend32() when reading temperatures to make
the code easier to understand.
hwmon: (max6697) Document discrepancy in overtemperature status bit values
In the MAX6581 datasheet Revision 0 to 3, the local channel overtemperature
status is reported in bit 6 of register 0x45, and the overtemperature
status for remote channel 7 is reported in bit 7. In Revision 4 and later,
the local channel overtemperature status is reported in bit 7, and the
remote channel 7 overtemperature status is reported in bit 6. A real
chip was found to match the functionality documented in Revision 4 and
later.
The code was fixed with commit 1ea3fd1eb986 ("hwmon: (max6697) Fix swapped
temp{1,8} critical alarms"). At that time it looked like this was an
original bug. It only turned out later that the problem was the result of
incorrect information in the chip datasheet.
Document the discrepancy to avoid confusion caused by old versions of the
datasheet.
hwmon: (max1668) Replace chip type with number of channels
The only difference between supported chips is the number of channels.
Drop enum chips and list the number of channels in struct i2c_device_id
directly.
Chris Packham [Mon, 22 Jul 2024 22:17:37 +0000 (10:17 +1200)]
hwmon: (adt7475) Add support for configuring initial PWM state
By default the PWM duty cycle in hardware is 100%. On some systems this
can cause unwanted fan noise. Add the ability to specify the fan
connections and initial state of the PWMs via device properties.
Add fan child nodes that allow describing the connections for the
ADT7475 to the fans it controls. This also allows setting some
initial values for the pwm duty cycle and frequency.
Chips reporting overcurrent alarms report it in the second alarm register.
That means the second alarm register has to be read, even if the chip only
supports 8 or fewer ADC channels.
MAX16067 and MAX16068 report undervoltage and overvoltage alarms in
separate registers. Fold register contents together to report both with
the existing alarm attribute. This requires actually storing the chip type
in struct max16065_data. Rename the variable 'chip' to match the variable
name used in the probe function.
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Javier Carrasco [Sun, 21 Jul 2024 15:19:02 +0000 (17:19 +0200)]
hwmon: (ltc2992) use device_for_each_child_node_scoped() to access child nodes
The iterated nodes are direct children of the device node, and the
`device_for_each_child_node()` macro accounts for child node
availability.
`fwnode_for_each_available_child_node()` is meant to access the child
nodes of an fwnode, and therefore not direct child nodes of the device
node.
In this case, the child nodes are not required outside the loop, and
the scoped version of the macro can be used to remove the repetitive
`goto put` pattern.
Use `device_for_each_child_node_scoped_scoped()` to indicate device's
direct child nodes.
hwmon: (lm95234) Use find_closest to find matching update interval
Use find_closest() instead of manually coding it to find best update
interval.
Since find_closest() uses rounding to find the best match, the resulting
update interval will now reflect the update interval that is closest to
the requested value, not the value that is lower or equal to the requested
value.
Merge tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- Fix RPM package build error caused by an incorrect locale setup
- Mark modules.weakdep as ghost in RPM package
- Fix the odd combination of -S and -c in stack protector scripts,
which is an error with the latest Clang
* tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kbuild: Fix '-S -c' in x86 stack protector scripts
kbuild: rpm-pkg: ghost modules.weakdep file
kbuild: rpm-pkg: Fix C locale setup
minmax: simplify and clarify min_t()/max_t() implementation
This simplifies the min_t() and max_t() macros by no longer making them
work in the context of a C constant expression.
That means that you can no longer use them for static initializers or
for array sizes in type definitions, but there were only a couple of
such uses, and all of them were converted (famous last words) to use
MIN_T/MAX_T instead.
Cc: David Laight <David.Laight@aculab.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 3a7e02c040b1 ("minmax: avoid overly complicated constant
expressions in VM code") added the simpler MIN_T/MAX_T macros in order
to avoid some excessive expansion from the rather complicated regular
min/max macros.
The complexity of those macros stems from two issues:
(a) trying to use them in situations that require a C constant
expression (in static initializers and for array sizes)
(b) the type sanity checking
and MIN_T/MAX_T avoids both of these issues.
Now, in the whole (long) discussion about all this, it was pointed out
that the whole type sanity checking is entirely unnecessary for
min_t/max_t which get a fixed type that the comparison is done in.
But that still leaves min_t/max_t unnecessarily complicated due to
worries about the C constant expression case.
However, it turns out that there really aren't very many cases that use
min_t/max_t for this, and we can just force-convert those.
This does exactly that.
Which in turn will then allow for much simpler implementations of
min_t()/max_t(). All the usual "macros in all upper case will evaluate
the arguments multiple times" rules apply.
We should do all the same things for the regular min/max() vs MIN/MAX()
cases, but that has the added complexity of various drivers defining
their own local versions of MIN/MAX, so that needs another level of
fixes first.
projects / users / willy / xarray.git / log