Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
acpi_power_meter hwmon driver.
Fixes: afc6c4aede ("hwmon: (acpi_power_meter) Convert ACPI driver to a platform one")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/5068745.GXAFRqVoOG@rafael.j.wysocki
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In all cases in which a struct acpi_driver is used for binding a driver
to an ACPI device object, a corresponding platform device is created by
the ACPI core and that device is regarded as a proper representation of
underlying hardware. Accordingly, a struct platform_driver should be
used by driver code to bind to that device. There are multiple reasons
why drivers should not bind directly to ACPI device objects [1].
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the hwmon ACPI power meter driver to a
platform one.
After this change, the subordinate hwmon device will be registered
under the platform device representing the ACPI power meter, sysfs
notifications will trigger on that device, and diagnostic messages
will be printed relative to it instead of its ACPI companion.
Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/1952740.tdWV9SEqCh@rafael.j.wysocki
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
To facilitate subsequent conversion of the driver to a platform one,
make it install an ACPI notify handler directly instead of using
a .notify() callback in struct acpi_driver.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/2405555.ElGaqSPkdT@rafael.j.wysocki
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Since acpi_power_meter_notify() and acpi_power_meter_remove() are
.notify() and .remove() callback functions of an ACPI driver,
respectively, the first argument of the former and the only argument
of the latter cannot be NULL. Likewise, the acpi_power_meter_resume()
argument cannot be NULL because it is a system resume callback
function.
Moreover, since all of these functions can only run after
acpi_power_meter_add() has returned 0, the driver_data field in the
struct acpi_device object used by them cannot be NULL either.
Accordingly, drop the redundant "device" checks against NULL from
acpi_power_meter_notify() and acpi_power_meter_remove(), drop the
redundant "dev" check against NULL from acpi_power_meter_resume(),
and drop the redundant acpi_driver_data() checks against NULL from
all of these functions.
Additionally, combine the initialization of the "resource" local
variable in acpi_power_meter_notify() and acpi_power_meter_remove()
with its declaration.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/5085645.31r3eYUQgx@rafael.j.wysocki
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
strcpy() performs no bounds checking on the destination buffer, which
could result in linear overflows beyond the end of the buffer. Although
the source strings here are compile-time constants that fit within the
destination buffers, using strscpy() is the preferred approach as it
provides bounds checking and aligns with the kernel's deprecated API
guidelines.
This change converts the remaining strcpy() calls to strscpy(), matching
the pattern already used throughout other ACPI drivers in
drivers/acpi/*.c.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy
Signed-off-by: Szymon Wilczek <szymonwilczek@gmx.com>
Reviewed-by: lihuisong@huawei.com
Link: https://lore.kernel.org/r/20251220173041.377376-1-szymonwilczek@gmx.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The acpi_power_meter driver's .notify() callback function,
acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock
that is also acquired by callbacks in sysfs attributes of the device
being unregistered which is prone to deadlocks between sysfs access and
device removal.
Address this by moving the hwmon device removal in
acpi_power_meter_notify() outside the lock in question, but notice
that doing it alone is not sufficient because two concurrent
METER_NOTIFY_CONFIG notifications may be attempting to remove the
same device at the same time. To prevent that from happening, add a
new lock serializing the execution of the switch () statement in
acpi_power_meter_notify(). For simplicity, it is a static mutex
which should not be a problem from the performance perspective.
The new lock also allows the hwmon_device_register_with_info()
in acpi_power_meter_notify() to be called outside the inner lock
because it prevents the other notifications handled by that function
from manipulating the "resource" object while the hwmon device based
on it is being registered. The sending of ACPI netlink messages from
acpi_power_meter_notify() is serialized by the new lock too which
generally helps to ensure that the order of handling firmware
notifications is the same as the order of sending netlink messages
related to them.
In addition, notice that hwmon_device_register_with_info() may fail
in which case resource->hwmon_dev will become an error pointer,
so add checks to avoid attempting to unregister the hwmon device
pointer to by it in that case to acpi_power_meter_notify() and
acpi_power_meter_remove().
Fixes: 16746ce8ad ("hwmon: (acpi_power_meter) Replace the deprecated hwmon_device_register")
Closes: https://lore.kernel.org/linux-hwmon/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/
Reported-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When load this mode, we can see the following log:
"power_meter ACPI000D:00: hwmon_device_register() is deprecated. Please
convert the driver to use hwmon_device_register_with_info()."
So replace hwmon_device_register with hwmon_device_register_with_info.
These attributes, 'power_accuracy', 'power_cap_hyst', 'power_average_min'
and 'power_average_max', should have been placed in hwmon_chip_info as
power data type. But these attributes are displayed as string format on
the following case:
a) power1_accuracy --> display like '90.0%'
b) power1_cap_hyst --> display 'unknown' when its value is 0xFFFFFFFF
c) power1_average_min/max --> display 'unknown' when its value is
negative.
To avoid any changes in the display of these sysfs interfaces, we can't
modifiy the type of these attributes in hwmon core and have to put them
to extra_groups.
Please note that the path of these sysfs interfaces are modified
accordingly if use hwmon_device_register_with_info():
old: all sysfs interfaces are under acpi device, namely,
/sys/class/hwmon/hwmonX/device/
now: all sysfs interfaces are under hwmon device, namely,
/sys/class/hwmon/hwmonX/
The new ABI does not guarantee that the underlying path remains the same.
But we have to accept this change so as to replace the deprecated API.
Fortunately, some userspace application, like libsensors, would scan
the two path and handles this automatically. So we can accept this change
so as to drop the deprecated message.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Link: https://lore.kernel.org/r/20250319020638.59925-1-lihuisong@huawei.com
[groeck: Fixed some multi-line alignment issues;
reverted to 32-bit arithmetic in power1_accuracy_show()
fixed bad return code from power_meter_is_visible()]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
We encountered a problem that a fake power alarm is reported to
user on the platform unsupported notifications at the second step
below:
1> Query 'power1_alarm' attribute when the power capping occurs.
2> Query 'power1_alarm' attribute when the power capping is over
and the current average power is less then power cap value.
The root cause is that the resource->power_alarm is set to true
at the first step. And power meter use this old value to show
the power alarm state instead of the current the comparison value.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Link: https://lore.kernel.org/r/20250220030832.2976-1-lihuisong@huawei.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* New drivers
- PMBus client driver for Intel CRPS185 power supply
- PMBus client driver for Texas Instruments TPS25990
* Chip support added to existing drivers
- pmbus/max15301: Add support for MAX15303
- pmbus/adm1275: Add adm1273 support
- lm75: Add NXP P3T1755 support; with it, add I3C support to the driver
- asus-ec-sensors: Add TUF GAMING X670E PLUS
* Other notable changes
- nct6683: Add customer IDs for several MSI and ASRock boards
- tmp108: Add regulator support
- Improve write protect support in PMBus core
- pmbus/dps920ab: Add ability to instantiate through i2c
- The hwmon core now accepts NULL as device name parameter to
[devm_]hwmon_device_register_with_info ans uses the parent device
name as fallback in that case
- The PMBus core now provides the PMBUs revision in a debugfs file
- asus-ec-sensors: Support for optional CPU fan on AMD 600 motherboards
- raspberrypi: Add PM suspend/resume support
- dell-smm: Enable manual fan control support on Dell XPS 9370
- pwm-fan: Default to maximum cooling level if provided
* Various other minor fixes and improvements
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEiHPvMQj9QTOCiqgVyx8mb86fmYEFAmeOX+AACgkQyx8mb86f
mYG4bA/+PJ4hkttSuwK6eR4F1o5l2VQhWPkWn2XzruEJGixhKLJKxKVkUCymmSsd
hepHZnw+aUKUmVeb0StSReshp6oGeOHHlKXUM1zv95HI1NMxMrflzeRuqjVNUnDK
ZitZkOb2WuUWhZIKIu82ole+3tw/0QyAYmSa9FPyp63rQ7C/QAWl2g4h6m3VdDLZ
1ZOimR/OOFAesZMOuEIBMIHnIqzKLr2QEFd5cZVKM5JbpB7LAHah3fPOvRC3sKco
02OOzFOrtZrXIIPDpsnznm6DF8jgbiKjGb8frR6DLAm/uGvPhuXuS0tYnWHAZs5D
nJHDCud1XROK2r9NHDiMZGxCxGOXmB+Fx71jUvY9692NMD2XWUzrqqoOs+c97eeG
YszAe1FL9QpgbLJnsFWurU72uvOMmkIeETZUE2cmkupwH+Ja5sc4sDPwf6S8Pwus
Y0ZonVqsLQb4UasGcfvFUEb8P6LQdshWx5IWxhfDs+xBo+n5pOEtu+ZCF5Z18k6A
A6g4SWWu8QtZOD9fEW0Rt/d9/QtPCTQc8UrJpCofWyKWpLzuoU0Xcs9g/ajLK3Vz
+YxM5Pgj7XMWtvPVx2ntnr5VAVKWCUv/jchWuKYKrGI58g3laPagmJMVEy8wrW9+
MpUGzaNDEMlvv7n4Jr4ipkYv9ltOIheu8pmzuI2PcadvAcKmF28=
=/7Qs
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-v6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon updates from Guenter Roeck:
"New drivers:
- PMBus client driver for Intel CRPS185 power supply
- PMBus client driver for Texas Instruments TPS25990
Chip support added to existing drivers:
- pmbus/max15301: Add support for MAX15303
- pmbus/adm1275: Add adm1273 support
- lm75: Add NXP P3T1755 support; with it, add I3C support to the
driver
- asus-ec-sensors: Add TUF GAMING X670E PLUS
Other notable changes:
- nct6683: Add customer IDs for several MSI and ASRock boards
- tmp108: Add regulator support
- Improve write protect support in PMBus core
- pmbus/dps920ab: Add ability to instantiate through i2c
- The hwmon core now accepts NULL as device name parameter to
[devm_]hwmon_device_register_with_info ans uses the parent device
name as fallback in that case
- The PMBus core now provides the PMBUs revision in a debugfs file
- asus-ec-sensors: Support for optional CPU fan on AMD 600
motherboards
- raspberrypi: Add PM suspend/resume support
- dell-smm: Enable manual fan control support on Dell XPS 9370
- pwm-fan: Default to maximum cooling level if provided
And various other minor fixes and improvements"
* tag 'hwmon-for-v6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (44 commits)
hwmon: pmbus: dps920ab: Add ability to instantiate through i2c
hwmon: (pwm-fan) Default to the Maximum cooling level if provided
hwmon: (asus_atk0110) Use str_enabled_disabled() and str_enable_disable() helpers
hwmon: Fix help text for aspeed-g6-pwm-tach
hwmon: (dell-smm) Add Dell XPS 9370 to fan control whitelist
hwmon: (acpi_power_meter) Fix update the power trip points on failure
hwmon: (acpi_power_meter) Fix uninitialized variables
hwmon: (core) Use device name as a fallback in devm_hwmon_device_register_with_info
hwmon: (pmbus/max15301) Add support for MAX15303
hwmon: (pmbus/adm1275) add adm1273 support
dt-bindings: hwmon: adm1275: add adm1273
hwmon: (nct6683) Add another customer ID for MSI
hwmon: (pwm-fan): Make use of device properties everywhere
hwmon: (lm75) add I3C support for P3T1755
hwmon: (lm75) separate probe into common and I2C parts
hwmon: (lm75) Remove superfluous 'client' member from private struct
hwmon: (lm75) simplify regulator handling
hwmon: (lm75) simplify lm75_write_config()
hwmon: (lm75) Hide register size differences in regmap access functions
hwmon: (pmbus/crps) Add Intel CRPS185 power supply
...
After commit fabb1f813e ("hwmon: (acpi_power_meter) Fix fail to load
module on platform without _PMD method"),
the acpi_power_meter driver fails to load if the platform has _PMD method.
To address this, add a check for successful read_domain_devices().
Tested on Nvidia Grace machine.
Fixes: fabb1f813e ("hwmon: (acpi_power_meter) Fix fail to load module on platform without _PMD method")
Signed-off-by: Kazuhiro Abe <fj1078ii@aa.jp.fujitsu.com>
Link: https://lore.kernel.org/r/20250115073532.3211000-1-fj1078ii@aa.jp.fujitsu.com
[groeck: Dropped unnecessary () from expression]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The power trip points maintained in local should not be updated when '_PTP'
method fails to evaluate.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Link: https://lore.kernel.org/r/20250109081708.27366-3-lihuisong@huawei.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The 'power1_alarm' attribute uses the 'power' and 'cap' in the
acpi_power_meter_resource structure. Currently, these two fields are just
updated when user query 'power' and 'cap' attribute. If user directly query
the 'power1_alarm' attribute without queryng above two attributes, driver
will use uninitialized variables to judge.
So this patch adds the setting of alarm state and update 'cap' in the
notification callback and update 'power' and 'cap' if needed to show the
real alarm state.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Link: https://lore.kernel.org/r/20250109081708.27366-2-lihuisong@huawei.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
According to the ACPI specification, the _PMD method is optional. The
acpi_power_meter driver shouldn't fail to load if the platform has no
_PMD method.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Message-ID: <20241112021228.22914-1-lihuisong@huawei.com>
[groeck: Reworded commit description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The following error can be observed at boot:
[ 3.717920] ACPI Error: No handler for Region [SYSI] (00000000ab9e62c5) [IPMI] (20230628/evregion-130)
[ 3.717928] ACPI Error: Region IPMI (ID=7) has no handler (20230628/exfldio-261)
[ 3.717936] No Local Variables are initialized for Method [_GHL]
[ 3.717938] No Arguments are initialized for method [_GHL]
[ 3.717940] ACPI Error: Aborting method \_SB.PMI0._GHL due to previous error (AE_NOT_EXIST) (20230628/psparse-529)
[ 3.717949] ACPI Error: Aborting method \_SB.PMI0._PMC due to previous error (AE_NOT_EXIST) (20230628/psparse-529)
[ 3.717957] ACPI: \_SB_.PMI0: _PMC evaluation failed: AE_NOT_EXIST
On Dell systems several methods of acpi_power_meter access variables in
IPMI region [0], so wait until IPMI space handler is installed by
acpi_ipmi and also wait until SMI is selected to make the space handler
fully functional.
Since the dependency is inside BIOS's ASL code and it's not
discoverable, so use this fixup is a hack to workaround BIOS issue.
[0] https://www.dell.com/support/manuals/en-us/redhat-enterprise-linux-v8.0/rhel8_rn_pub/advanced-configuration-and-power-interface-acpi-error-messages-displayed-in-dmesg?guid=guid-0d5ae482-1977-42cf-b417-3ed5c3f5ee62
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20240320084317.366853-2-kai.heng.feng@canonical.com
[groeck: Simplified added code]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ACPI specification says:
"If an error occurs while obtaining the meter reading or if the value
is not available then an Integer with all bits set is returned"
Since the "integer" is 32 bits in case of the ACPI power meter,
userspace will get a power reading of 2^32 * 1000 miliwatts (~4.29 MW)
in case of such an error. This was discovered due to a lm_sensors
bugreport (https://github.com/lm-sensors/lm-sensors/issues/460).
Fix this by returning -ENODATA instead.
Tested-by: <urbinek@gmail.com>
Fixes: de584afa5e ("hwmon driver for ACPI 4.0 power meters")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20231124182747.13956-1-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
For bus-based driver, device removal is implemented as:
1 device_remove()->
2 bus->remove()->
3 driver->remove()
Driver core needs no inform from callee(bus driver) about the
result of remove callback. In that case, commit fc7a6209d5
("bus: Make remove callback return void") forces bus_type::remove
be void-returned.
Now we have the situation that both 1 & 2 of calling chain are
void-returned, so it does not make much sense for 3(driver->remove)
to return non-void to its caller.
So the basic idea behind this change is making remove() callback of
any bus-based driver to be void-returned.
This change, for itself, is for device drivers based on acpi-bus.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Lee Jones <lee@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dawei Li <set_pte_at@outlook.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for drivers/platform/surface/*
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* New drivers
- Driver for MAX31760 fan speed controller
- Driver for TEXAS TPS546D24 Buck Converter
- Driver for EMC2301/2/3/5 RPM-based PWM Fan Speed Controller
* Removed drivers
- Drop obsolete asus_wmi_ec_sensors driver
* Cleanups, affecting various drivers
- Use DEFINE_SIMPLE_DEV_PM_OPS where appropriate
- Remove forward declarations
- Move from strlcpy with unused retval to strscpy
- Make use of devm_clk_get_enabled()
- Drop devm_of_pwm_get()
* Other notable cleanup and improvements
- Support for additional USB devide ID and support for reporting
of rail mode via debugfs added to corsair-psu driver
- Support for aditional USB ID in nzxt-smart2 driver
- Support for Aquacomputer High Flow Next in aquacomputer_d5next driver
- Major cleanup of pwm-fan driver
- Major cleanup of mr75203 driver, and added support for new device revision
* Various other minor fixes and cleanups
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEiHPvMQj9QTOCiqgVyx8mb86fmYEFAmM6CSsACgkQyx8mb86f
mYEwFw//SvJ5vW/bS0kynaH2TICzwHDHjH7nBjXyIlqN3ILrrTKyFQgkfqIlqYT9
OYlXaKB6DqRBOZjLCYKNhDy13gdvOh0XBIsX/emqzFDmhGZ6yJtm0u+6CMp7UFGK
3KDf4LSkEJ3QhgOOiROsz1u6CSXdZI8THnIBRCrzve3nlamRaR6n8tvvf6Fqspsa
WQTDg1g2dOjpP6bi1EKre/KiBfjxrzy2/r9WGQr1J7LZb598/F7CPGztJU6P27TE
gHltO4wcAgBgnL3ODBmLPDHyAa91fTmfHCvKRUfaAlZll8ucfXJnlfZVV8YW9ptC
Fm00Wmy8aFX57ziXFlJ7LOFdjdCKyTRVp5ferPHCEuzmztWLdWauwiVV7GkeqzIB
/seHcC59kX7yGKgP2sYV9SlD0GWa2Ax2rJT8gh78ozUgXMUlKkVPSly5ooOaKkEV
nNRLJB40tAK43wwSWNVSw0wPXK0fWfxmyF1AMowNEoC12zDLO0JAlw/sVXj4GneG
sq0ZN6vyAaDdcX3RKan6jTaus2AdHf3vZHqy/xW59Jo+JqoxF7zo1MLRDP2EekWn
x0HbXT5ghWrmntN7mgRPvN1sgebK8L+yGttuJ/guFuYTTy8FrXOKtjhBCcvZHg7C
tiMUAMTl7s6FujcuMEY84ZwwIDczLGpIwxXammIKJiHGBSeHsdk=
=8u0w
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon updates from Guenter Roeck:
"New drivers:
- Driver for MAX31760 fan speed controller
- Driver for TEXAS TPS546D24 Buck Converter
- Driver for EMC2301/2/3/5 RPM-based PWM Fan Speed Controller
Removed drivers:
- Drop obsolete asus_wmi_ec_sensors driver
Cleanups, affecting various drivers:
- Use DEFINE_SIMPLE_DEV_PM_OPS where appropriate
- Remove forward declarations
- Move from strlcpy with unused retval to strscpy
- Make use of devm_clk_get_enabled()
- Drop devm_of_pwm_get()
Other notable cleanup and improvements:
- Support for additional USB devide ID and support for reporting of
rail mode via debugfs added to corsair-psu driver
- Support for aditional USB ID in nzxt-smart2 driver
- Support for Aquacomputer High Flow Next in aquacomputer_d5next
driver
- Major cleanup of pwm-fan driver
- Major cleanup of mr75203 driver, and added support for new device
revision
And various other minor fixes and cleanups"
* tag 'hwmon-for-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (86 commits)
hwmon: (corsair-psu) add USB id of new revision of the HX1000i psu
hwmon: (pmbus/mp2888) Fix sensors readouts for MPS Multi-phase mp2888 controller
dt-bindings: hwmon: sensirion,shtc1: Clean up spelling mistakes and grammar
hwmon: (nct6683) remove unused variable in nct6683_create_attr_group
hwmon: w83627hf: Reorder symbols to get rid of a few forward declarations
hwmon: (ina3221) Use DEFINE_RUNTIME_DEV_PM_OPS() and pm_ptr()
hwmon: (w83627ehf) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (tmp108) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (tmp103) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (tmp102) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (pwm-fan) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (nct6775) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (max6639) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (max31730) witch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (max31722) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (ltc2947) Switch to EXPORT_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (lm90) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (it87) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (gpio-fan) Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
hwmon: (adt7x10) Switch to EXPORT_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
...
These newer PM macros allow the compiler to see what code it can remove
if !CONFIG_PM_SLEEP. This allows the removal of messy #ifdef barriers whilst
achieving the same result.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20220925172759.3573439-4-jic23@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Because acpi_bus_get_acpi_device() is completely analogous to
acpi_fetch_acpi_dev(), rename it to acpi_get_acpi_dev() and
add a kerneldoc comment to it.
Accordingly, rename acpi_bus_put_acpi_device() to acpi_put_acpi_dev()
and update all of the users of these two functions.
While at it, move the acpi_fetch_acpi_dev() header next to the
acpi_get_acpi_dev() header in the header file holding them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
In read_domain_devices(), acpi_bus_get_device() is called to obtain
the ACPI device object attached to the given ACPI handle and
subsequently that object is passed to get_device() for reference
counting, but there is a window between the acpi_bus_get_device()
and get_device() calls in which the ACPI device object in question
may go away.
To address this issue, make read_domain_devices() use
acpi_bus_get_acpi_device() to reference count and return the given
ACPI device object in one go and export that function to modules.
While at it, also make read_domain_devices() and
remove_domain_devices() use acpi_dev_put() instead of calling
put_device() directly on the ACPI device objects returned by
acpi_bus_get_acpi_device().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/11871063.O9o76ZdvQC@kreacher
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use acpi_evaluation_failure_warn() introduced previously instead of
the ACPICA-specific ACPI_EXCEPTION() macro to log warning messages
regarding ACPI object evaluation failures and use dev_err() instead
of ACPI_EXCEPTION() to log _PMC package parsing failures, which is
consistent with the other messages printed by the code in question.
Next, drop the ACPI_MODULE_NAME() definition only used by the ACPICA
message printing macro.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
The double negative makes it hard to read "if (!ACPI_FAILURE(status))".
Replace it with "if (ACPI_SUCCESS(status))".
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This code works okay but Smatch flagged it as a double free. I've
changed three things to make it more clear. 1) Remove the call to
free_capabilities() in acpi_power_meter_add(). This call is a no-op
because the capabilities have not been allocated yet. 2) Set "*str" to
NULL in free_capabilities() so that way the function can be called twice
in a row without leading to a double free. 3) Call free_capabilities()
in read_capabilities() instead of open coding the free.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20201007075148.GB2529578@mwanda
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Although it rarely happens, we should call free_capabilities()
if error happens after read_capabilities() to free allocated strings.
Fixes: de584afa5e ("hwmon driver for ACPI 4.0 power meters")
Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Link: https://lore.kernel.org/r/20200625043242.31175-1-misono.tomohiro@jp.fujitsu.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Damien Le Moal reports a lockdep splat with the acpi_power_meter,
observed with Linux v5.5 and later.
======================================================
WARNING: possible circular locking dependency detected
5.6.0-rc2+ #629 Not tainted
------------------------------------------------------
python/1397 is trying to acquire lock:
ffff888619080070 (&resource->lock){+.+.}, at: show_power+0x3c/0xa0 [acpi_power_meter]
but task is already holding lock:
ffff88881643f188 (kn->count#119){++++}, at: kernfs_seq_start+0x6a/0x160
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (kn->count#119){++++}:
__kernfs_remove+0x626/0x7e0
kernfs_remove_by_name_ns+0x41/0x80
remove_attrs+0xcb/0x3c0 [acpi_power_meter]
acpi_power_meter_notify+0x1f7/0x310 [acpi_power_meter]
acpi_ev_notify_dispatch+0x198/0x1f3
acpi_os_execute_deferred+0x4d/0x70
process_one_work+0x7c8/0x1340
worker_thread+0x94/0xc70
kthread+0x2ed/0x3f0
ret_from_fork+0x24/0x30
-> #0 (&resource->lock){+.+.}:
__lock_acquire+0x20be/0x49b0
lock_acquire+0x127/0x340
__mutex_lock+0x15b/0x1350
show_power+0x3c/0xa0 [acpi_power_meter]
dev_attr_show+0x3f/0x80
sysfs_kf_seq_show+0x216/0x410
seq_read+0x407/0xf90
vfs_read+0x152/0x2c0
ksys_read+0xf3/0x1d0
do_syscall_64+0x95/0x1010
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(kn->count#119);
lock(&resource->lock);
lock(kn->count#119);
lock(&resource->lock);
*** DEADLOCK ***
4 locks held by python/1397:
#0: ffff8890242d64e0 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x9b/0xb0
#1: ffff889040be74e0 (&p->lock){+.+.}, at: seq_read+0x6b/0xf90
#2: ffff8890448eb880 (&of->mutex){+.+.}, at: kernfs_seq_start+0x47/0x160
#3: ffff88881643f188 (kn->count#119){++++}, at: kernfs_seq_start+0x6a/0x160
stack backtrace:
CPU: 10 PID: 1397 Comm: python Not tainted 5.6.0-rc2+ #629
Hardware name: Supermicro Super Server/X11DPL-i, BIOS 3.1 05/21/2019
Call Trace:
dump_stack+0x97/0xe0
check_noncircular+0x32e/0x3e0
? print_circular_bug.isra.0+0x1e0/0x1e0
? unwind_next_frame+0xb9a/0x1890
? entry_SYSCALL_64_after_hwframe+0x49/0xbe
? graph_lock+0x79/0x170
? __lockdep_reset_lock+0x3c0/0x3c0
? mark_lock+0xbc/0x1150
__lock_acquire+0x20be/0x49b0
? mark_held_locks+0xe0/0xe0
? stack_trace_save+0x91/0xc0
lock_acquire+0x127/0x340
? show_power+0x3c/0xa0 [acpi_power_meter]
? device_remove_bin_file+0x10/0x10
? device_remove_bin_file+0x10/0x10
__mutex_lock+0x15b/0x1350
? show_power+0x3c/0xa0 [acpi_power_meter]
? show_power+0x3c/0xa0 [acpi_power_meter]
? mutex_lock_io_nested+0x11f0/0x11f0
? lock_downgrade+0x6a0/0x6a0
? kernfs_seq_start+0x47/0x160
? lock_acquire+0x127/0x340
? kernfs_seq_start+0x6a/0x160
? device_remove_bin_file+0x10/0x10
? show_power+0x3c/0xa0 [acpi_power_meter]
show_power+0x3c/0xa0 [acpi_power_meter]
dev_attr_show+0x3f/0x80
? memset+0x20/0x40
sysfs_kf_seq_show+0x216/0x410
seq_read+0x407/0xf90
? security_file_permission+0x16f/0x2c0
vfs_read+0x152/0x2c0
Problem is that reading an attribute takes the kernfs lock in the kernfs
code, then resource->lock in the driver. During an ACPI notification, the
opposite happens: The resource lock is taken first, followed by the kernfs
lock when sysfs attributes are removed and re-created. Presumably this is
now seen due to some locking related changes in kernfs after v5.4, but it
was likely always a problem.
Fix the problem by not blindly acquiring the lock in the notification
function. It is only needed to protect the various update functions.
However, those update functions are called anyway when sysfs attributes
are read. This means that we can just stop calling those functions from
the notifier, and the resource lock in the notifier function is no longer
needed.
That leaves two situations:
First, METER_NOTIFY_CONFIG removes and re-allocates capability strings.
While it did so under the resource lock, _displaying_ those strings was not
protected, creating a race condition. To solve this problem, selectively
protect both removal/creation and reporting of capability attributes with
the resource lock.
Second, removing and re-creating the attribute files is no longer protected
by the resource lock. That doesn't matter since access to each individual
attribute is protected by the kernfs lock. Userspace may get messed up if
attributes disappear and reappear under its nose, but that is not different
than today, and there is nothing we can do about it without major driver
restructuring.
Last but not least, when removing the driver, remove attribute functions
first, then release capability strings. This avoids yet another race
condition.
Reported-by: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: stable@vger.kernel.org # v5.5+
Tested-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
At boot time, the acpi_power_meter driver logs the following error level
message: "Ignoring unsafe software power cap". Having read about it from
a few sources, it seems that the error message can be quite misleading.
While the message can imply that Linux is ignoring the fact that the
system is operating in potentially dangerous conditions, the truth is
the driver found an ACPI_PMC object that supports software power
capping. The driver simply decides not to use it, perhaps because it
doesn't support the object.
The best solution is probably changing the log level from error to warning.
All sources I have found, regarding the error, have downplayed its
significance. There is not much of a reason for it to be on error level,
while causing potential confusions or misinterpretations.
Signed-off-by: Wang Shenran <shenran268@gmail.com>
Link: https://lore.kernel.org/r/20190724080110.6952-1-shenran268@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details you
should have received a copy of the gnu general public license along
with this program if not write to the free software foundation inc
59 temple place suite 330 boston ma 02111 1307 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 1334 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace S_<PERMS> with octal values.
The conversion was done automatically with coccinelle. The semantic patches
and the scripts used to generate this commit log are available at
https://github.com/groeck/coccinelle-patches/hwmon/.
This patch does not introduce functional changes. It was verified by
compiling the old and new files and comparing text and data sizes.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
... and __initconst if applicable.
Based on similar work for an older kernel in the Grsecurity patch.
[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
<acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
inclusions and remove some inclusions of those files that aren't
necessary.
First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set,
<linux/acpi.h> includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.
Second, there are ordering dependencies between those files that always
have to be met. Namely, it is required that <acpi/acpi_bus.h> be included
prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
latter depends on are always there. And <acpi/acpi.h> which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds. That also is taken care of including
<linux/acpi.h> as appropriate.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since acpi_bus_get_device() returns plain int and not acpi_status,
ACPI_FAILURE() should not be used for checking its return value. Fix
that.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
acpi_power_meter crashes the kernel if it detects an unexpected event
or an internal implementation error. While the detected conditions
suggest that there is a bug in the code, the condition is not fatal.
Replace BUG() with WARN().
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
I've changed employers, so change the email addresses to match.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The second argument of ACPI driver .remove() operation is only used
by the ACPI processor driver and the value passed to that driver
through it is always available from the given struct acpi_device
object's removal_type field. For this reason, the second ACPI driver
.remove() argument is in fact useless, so drop it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jiang Liu <jiang.liu@huawei.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
These drivers use IS_ERR so they should include <linux/err.h>.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Luca Tettamanti <kronos.it@gmail.com>
Cc: Henrik Rydberg <rydberg@euromail.se>
Commit c5dec01822 (acpi_power_meter: Use struct
dev_pm_ops for power management) introduced the following build warning. It is
seen if CONFIG_PM_SLEEP is not defined.
acpi_power_meter.c:930:12: warning: acpi_power_meter_resume defined but not used
Fix it.
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
temperature sensors.
Convert drivers to use devm_ functions and to use dev_pm_ops.
Address a couple of Coverity errors/warnings as well as compile warnings.
Some functional improvements in applesmc driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQDMjFAAoJEMsfJm/On5mBQy0QAIOMh+xxhfpIYmOz6e7lXyGK
IvsYvJ16jvMzkIHxIsCJ8lYo0tQJTVFZAoDE0KnXMt/vpDGuooa/L2Rq0NQwAadF
nb+XijtV042FMScLiGCbJQRyPmVWEpQ1sHvf6Ob+xUido4xTL/J0ObMv1P76Ro5v
OlCWqt5bly9JDDzwTdvmkmVQ7TSLV27IbEy1XFeQ3B9AquIzCsHjLXmyzTGtWuEa
e73pR62m+nEHlIwEyCnH9QBc5fhUyrOm+mzmGWaEZX+PUt4OC2VeBCOB4tyYA1f+
+PV9wcCsFyre4Xdi2mtfyMnqSs6qio07diJB33oAmApKs6dbsfZvwM1gSIVTp8W/
RooxePKN2fFgjnLSbAQZWaC3AMTcrsMlUMVxqZ75BPmQvrm1bxJh/OcWpo5lZM8s
yAmdx587eHABMqvYgs4QVIf3QqmPXi194Qzq4loLHteGDohK8Z6u6t7famx1sRLt
ApqfmcxPAjvpXfQB11VboYTLiFtXJK8T/VwOOoB9L24/dxoymSUa2UQuoeSBdESM
dTTKJQebUcJs6J0OWzGRjKwS/jH8wcGJCzMlcHW9dpxMdh98R4gHHi/UTkfgJi/n
j50/oxpJCyHqGthvKyA77oztWyyfuAdJbG2eKtRNVPriJMP3uuAbbBA9Cl9ytXyh
SUChQ49urUSABI9up1iR
=TcQ+
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon updates from Guenter Roeck:
"New drivers for DA9052/53 PMIC as well as HIH-6130/HIH-6131 humidity
and temperature sensors.
Convert drivers to use devm_ functions and to use dev_pm_ops. Address
a couple of Coverity errors/warnings as well as compile warnings.
Some functional improvements in applesmc driver."
* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (72 commits)
hwmon: (applesmc) Ignore some temperature registers
hwmon: (applesmc) Allow negative temperature values
hwmon: (s3c-hwmon) Use devm_kzalloc instead of kzalloc
hwmon: (w83781d) Fix compile warning
hwmon: (applesmc) Shorten minimum wait time
hwmon: (exynos4_tmu) Use struct dev_pm_ops for power management
hwmon: (gpio-fan) Use struct dev_pm_ops for power management
hwmon: (abituguru3) Use struct dev_pm_ops for power management
hwmon: (abituguru) Use struct dev_pm_ops for power management
hwmon: (acpi_power_meter) Fix unintentional integer overflow
hwmon: (acpi_power_meter) Cleanup and optimizations
hwmon: Honeywell Humidicon HIH-6130/HIH-6131 humidity and temperature sensor driver
hwmon: (applesmc) Skip sensor mapping
hwmon: (ntc_thermistor) Ensure that data->name string is terminated
hwmon: (w83l785ts) Convert to use devm_ functions
hwmon: (w83l785ts) Simplify code and improve readability
hwmon: (smsc47m192) Convert to use devm_ functions
hwmon: (smsc47m1) Convert to use devm_ functions
hwmon: (smsc47b397) Convert to use devm_ functions
hwmon: (k8temp) Convert to use devm_ functions
...
Expression with two integer variables is calculated as integer before it is
converted to u64. This may result in an integer overflow. Fix by declaring
trip point variables as s64 instead of int.
This patch addresses Coverity #200596: Unintentional integer overflow.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
An unsigned value can not be smaller than 0. Remove the check for it.
Use DIV_ROUND_CLOSEST for divide operations converting milli-degrees C into
degrees C. Limit maximum accepted trip point temperature to INT_MAX.
This patch fixes Coverity #115214: Unsigned compared against 0
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
Make the ACPI power meter driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
We don't need to duplicate if (res) checks if we're always running
one or the other.
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
We always register these two together, so move meter_rw_attrs into
meter_ro_attrs and use the same for both since we no longer have two
register_attr paths.
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Key off the attr->set method being present to set the sysfs attribute
as writable.
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
