The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This can instead be done with
i2c_client_get_device_id(). For this driver functionality should
not change. Switch over to remove the last couple users of the
i2c_match_id() function from kernel.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-12-afd@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This can instead be done with
i2c_client_get_device_id(). For this driver functionality should
not change. Switch over to remove the last couple users of the
i2c_match_id() function from kernel.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-11-afd@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This can be done instead with
i2c_client_get_device_id() which doesn't need the i2c_device_id
passed in so we do not need to have that forward declared, allowing
us to move the i2c_device_id table down to its more natural spot
with the other module info.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-10-afd@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has another benefit:
* It also checks for device match data, which means we do not have
to manually check that first.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-9-afd@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has another benefit:
* It also checks for device match data, which means we do not have
to manually check that first.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-8-afd@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has another benefit:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove that.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-7-afd@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has another benefit:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove that.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-6-afd@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has another benefit:
* It also checks for device match data. That means we do not have
to manually check that first.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-5-afd@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove that.
* It also checks for device match data, which allows for OF and
ACPI based probing.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-4-afd@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has another benefit:
* It also checks for device match data, which allows for OF based
probing. That means we do not have to manually check those first
and can remove that check.
As i2c_get_match_data() return NULL/0 on failure which also matches
the enum for "cffps1", switch around the enum order so cffps_unknown
is index 0 and existing behavior is preserved.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-3-afd@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has another benefit:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove that.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260306171652.951274-2-afd@ti.com
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 asus_atk0110 ACPI driver to a platform
one.
After this change, the subordinate hwmon device will be registered under
the platform device used for driver binding and messages will be printed
relative to that device instead of its ACPI companion.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
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/3691136.iIbC2pHGDl@rafael.j.wysocki
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Instead of failing probe when the "adi,rsense-nano-ohms" firmware property
is not provided, default rsense to (NANO/MILLI), or 1 milli-Ohm. This
allows the device to probe without requiring firmware properties, which
might be useful for some high level testing.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20260304-hwmon-ltc4282-minor-improvs-v1-2-344622924d3a@analog.com
[groeck: Clarify that the default is 1 milli-Ohm. No functional change.]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The LTC4282 driver does not implement an I2C .detect() callback, meaning no
I2C address scanning is performed. Update the documentation to
reflect this by replacing the listed I2C address ranges with "-".
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20260304-hwmon-ltc4282-minor-improvs-v1-1-344622924d3a@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
OF_GPIO is selected automatically on all OF systems. Any symbols it
controls also provide stubs so there's really no reason to select it
explicitly.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260304-gpio-of-kconfig-v1-9-d597916e79e7@oss.qualcomm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Replace sprintf() with sysfs_emit() when writing to sysfs buffers.
sysfs_emit() performs proper bounds checking and is the preferred
helper for sysfs output.
No functional change intended.
Signed-off-by: Amay Agarwal <tt@turingtested.xyz>
Link: https://lore.kernel.org/r/20260303152456.35763-6-tt@turingtested.xyz
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Replace sprintf() with sysfs_emit() when writing to sysfs buffers.
sysfs_emit() performs proper bounds checking and is the preferred
helper for sysfs output.
No functional change intended.
Signed-off-by: Amay Agarwal <tt@turingtested.xyz>
Link: https://lore.kernel.org/r/20260303152456.35763-5-tt@turingtested.xyz
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Replace sprintf() with sysfs_emit() when writing to sysfs buffers.
sysfs_emit() performs proper bounds checking and is the preferred
helper for sysfs output.
No functional change intended.
Signed-off-by: Amay Agarwal <tt@turingtested.xyz>
Link: https://lore.kernel.org/r/20260303152456.35763-4-tt@turingtested.xyz
[groeck: Fixed continuation line alignment]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Replace sprintf() with sysfs_emit() when writing to sysfs buffers.
sysfs_emit() performs proper bounds checking and is the preferred
helper for sysfs output.
No functional change intended.
Signed-off-by: Amay Agarwal <tt@turingtested.xyz>
Link: https://lore.kernel.org/r/20260303152456.35763-3-tt@turingtested.xyz
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Replace sprintf() with sysfs_emit() when writing to sysfs buffers.
sysfs_emit() performs proper bounds checking and is the preferred helper
for sysfs output.
No functional change intended
Signed-off-by: Amay Agarwal <tt@turingtested.xyz>
Link: https://lore.kernel.org/r/20260303152456.35763-2-tt@turingtested.xyz
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The INA219 has the lowest three bits of the bus voltage register
zero-reserved, the bus_voltage_shift ina2xx_config field was introduced
to accommodate for that.
The INA234 has four bits of the bus voltage, of the shunt voltage, and
of the current registers zero-reserved but the latter two were
implemented by choosing a 16x higher shunt_div instead of a separate
field specifying a bit shift.
This is possible because shunt voltage and current are divided by
shunt_div, hence a 16x higher shunt_div results in a 16x smaller LSB for
both the shunt voltage and the current register, perfectly accounting
for the missing bit shift.
For consistency and correctness, account for the reserved bits via
shunt_voltage_shift and current_shift configuration fields as already
done for voltage registers and use the conversion constants given in the
INA234 datasheet.
Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
Link: https://lore.kernel.org/r/20260303-ina234-shift-v1-2-318c33ac4480@pengutronix.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The list of supported chips in the header is incomplete and contains no
other information not readily available. Remove the list and instead
hint that the chips supported by this driver have 219/226 compatible
register layout [unlike the ones supported by e.g. ina238].
Remove the unused INA226_DIE_ID define.
Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
Link: https://lore.kernel.org/r/20260303-ina234-shift-v1-1-318c33ac4480@pengutronix.de
[groeck: macro -> define in commit message]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add hardware monitoring support for the LattePanda Sigma SBC
(DFRobot, ITE IT8613E EC). The driver reads fan speed and
temperatures via direct port I/O, as the BIOS disables the
ACPI EC interface.
Signed-off-by: Mariano Abad <weimaraner@gmail.com>
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>
TMP110 and TMP113 temperature sensors are software compatible
with TMP102 sensor but have different accuracy (maximum error).
Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
Link: https://lore.kernel.org/r/20260225095132.29954-1-flaviu.nistor@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Extend the PMBus core vrm_version handling to support NVIDIA nvidia195mv
VID mode. This adds a new VRM/VID encoding type and the corresponding
voltage conversion logic so devices reporting nvidia195mv can have their
VOUT/VID values interpreted correctly by the hwmon PMBus core.
Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
Link: https://lore.kernel.org/r/20260223050804.4287-3-Ashish.Yadav@infineon.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add of_device_id table to allow the driver to be matched via
Device Tree. This is required for supporting the AHT10/20/DHT20
sensors on platforms using DT.
Signed-off-by: Hao Yu <haoyufine@gmail.com>
Link: https://lore.kernel.org/r/20260223173853.30617-3-haoyufine@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add Aosong AHT10, AHT20 and DHT20 temperature and humidity sensors
to the trivial-devices documentation. These sensors use a standard
I2C interface and do not require complex binding definitions.
Signed-off-by: Hao Yu <haoyufine@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260223173853.30617-2-haoyufine@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
INA234 is register compatible to INA226 (excepting manufacturer and die
or device id registers) but has different scaling.
Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>
Reviewed-by: Bence Csókás <bence98@sch.bme.hu> # v2
Tested-by: Jens Almer <bagawk@gmail.com>
Tested-by: Jonas Rebmann <jre@pengutronix.de>
Link: https://lore.kernel.org/r/20260220112024.97446-4-ian.ray@gehealthcare.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* Make sysfs entries documentation easier to maintain.
* Use multi-line enum.
* Correct "has_power_average" comment.
Create a new "has_update_interval" member for chips which support
averaging.
Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>
Reviewed-by: Bence Csókás <bence98@sch.bme.hu> # v2
Tested-by: Jens Almer <bagawk@gmail.com>
Link: https://lore.kernel.org/r/20260220112024.97446-3-ian.ray@gehealthcare.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add a compatible string for the INA234 device, which is like INA226 but
has different scaling.
Note that the device tree compatible must be different since the driver
uses the compatible to configure the scaling.
Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> # v1
Tested-by: Jens Almer <bagawk@gmail.com>
Link: https://lore.kernel.org/r/20260220112024.97446-2-ian.ray@gehealthcare.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The GPD Win 5 is a new device by GPD with an AMD AI MAX 385/395 chip.
It uses the same fan control registers as the GPD Win Duo. This
information was provided by GPD.
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://lore.kernel.org/r/20260220161601.2344291-1-lkml@antheas.dev
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Unlike older GIC variants, the GICv3 DT bindings do not support
specifying a CPU mask in PPI interrupt specifiers. Drop the masks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Prevent the system from becoming unstable or unusable due to a flood of
memory allocation error messages under memory pressure.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/alpine.DEB.2.21.2603291252380.60268@angie.orcam.me.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
bnxt_hwrm_func_backing_store_qcaps_v2() stores resp->type from the
firmware response in ctxm->type and later uses that value to index
fixed backing-store metadata arrays such as ctx_arr[] and
bnxt_bstore_to_trace[].
ctxm->type is fixed by the current backing-store query type and matches
the array index of ctx->ctx_arr. Set ctxm->type from the current loop
variable instead of depending on resp->type.
Also update the loop to advance type from next_valid_type in the for
statement, which keeps the control flow simpler for non-valid and
unchanged entries.
Fixes: 6a4d0774f0 ("bnxt_en: Add support for new backing store query firmware API")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Tested-by: Michael Chan <michael.chan@broadcom.com>
Link: https://patch.msgid.link/20260328234357.43669-1-pengpeng@iscas.ac.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Netfilter flowtable can theoretically try to offload flower rules as soon
as a net_device is registered while all the other ones are not
registered or initialized, triggering a possible NULL pointer dereferencing
of qdma pointer in airoha_ppe_set_cpu_port routine. Moreover, if
register_netdev() fails for a particular net_device, there is a small
race if Netfilter tries to offload flowtable rules before all the
net_devices are properly unregistered in airoha_probe() error patch,
triggering a NULL pointer dereferencing in airoha_ppe_set_cpu_port
routine. In order to avoid any possible race, delay offloading until
all net_devices are registered in the networking subsystem.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260329-airoha-regiser-race-fix-v2-1-f4ebb139277b@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When building netlink messages, tc_chain_fill_node() never initializes
the tcm_info field of struct tcmsg. Since the allocation is not zeroed,
kernel heap memory is leaked to userspace through this 4-byte field.
The fix simply zeroes tcm_info alongside the other fields that are
already initialized.
Fixes: 32a4f5ecd7 ("net: sched: introduce chain object to uapi")
Signed-off-by: Yochai Eisenrich <echelonh@gmail.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260328211436.1010152-1-echelonh@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King says:
====================
net: stmmac: qcom-ethqos: more cleanups
Further cleanups to qcom-ethqos, mainly concentrating on the RGMII
code, making it clearer what the differences are for each speed, thus
making the code more readable.
I'm still not really happy with this. The speed specific configuration
remains split between ethqos_fix_mac_speed_rgmii() and
ethqos_rgmii_macro_init(), where the latter is only ever called from
the former. So, I think further work is needed here - maybe it needs
restructuring into the various componenet parts of the RGMII block?
====================
Link: https://patch.msgid.link/acZDEg9wdjhBTHlL@shell.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Move the determination of the phase shift enable alongside the register
update, and make "phase_shift" unsigned.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Link: https://patch.msgid.link/E1w62o3-0000000E3DE-3Vf8@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
