* [PATCH v4 11/12] hwmon: spd5118: Add I3C support
From: Akhil R @ 2026-06-16 9:54 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260616095429.3947205-1-akhilrajeev@nvidia.com>
Add a regmap config and a probe function to support I3C-based
communication with SPD5118 devices.
On an I3C bus, SPD5118 devices are enumerated via SETAASA and always
require an ACPI or device tree entry. Device matching is hence through
the OF match tables only and does not need an I3C class match table. The
device identity is verified in the type registers before proceeding to
the common probe function.
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/hwmon/Kconfig | 9 ++++---
drivers/hwmon/spd5118.c | 56 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5c2d3ff5fce8..c4bf5475fcb3 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2354,12 +2354,15 @@ config SENSORS_INA3221
config SENSORS_SPD5118
tristate "SPD5118 Compliant Temperature Sensors"
- depends on I2C
+ depends on I3C_OR_I2C
select REGMAP_I2C
+ select REGMAP_I3C if I3C
help
If you say yes here you get support for SPD5118 (JEDEC JESD300)
- compliant temperature sensors. Such sensors are found on DDR5 memory
- modules.
+ compliant temperature sensors using I2C or I3C bus interface.
+ Such sensors are found on DDR5 memory modules.
+
+ This driver supports both I2C and I3C interfaces.
This driver can also be built as a module. If so, the module
will be called spd5118.
diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
index 6ba37a719300..9724cf70b61d 100644
--- a/drivers/hwmon/spd5118.c
+++ b/drivers/hwmon/spd5118.c
@@ -18,6 +18,7 @@
#include <linux/bits.h>
#include <linux/err.h>
#include <linux/i2c.h>
+#include <linux/i3c/device.h>
#include <linux/hwmon.h>
#include <linux/module.h>
#include <linux/mutex.h>
@@ -464,6 +465,27 @@ static const struct regmap_config spd5118_regmap8_config = {
.num_ranges = ARRAY_SIZE(spd5118_i2c_regmap_range_cfg),
};
+/*
+ * SPD5118 2-byte register address format (JESD300-5, Tables 7 & 20):
+ * Byte 1 (on wire first): MemReg | BlkAddr[0] | Address[5:0]
+ * Byte 2 (on wire second): 0000 | BlkAddr[4:1]
+ *
+ * The address byte (with MemReg and lower address bits) must be sent first,
+ * followed by the upper block address byte. With regmap 16-bit register
+ * format, this maps to little-endian: the low byte of the 16-bit value is
+ * transmitted first. No range config is needed since I3C does not use MR11
+ * page switching.
+ */
+static const struct regmap_config spd5118_regmap_i3c_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = 0x7ff,
+ .reg_format_endian = REGMAP_ENDIAN_LITTLE,
+ .writeable_reg = spd5118_writeable_reg,
+ .volatile_reg = spd5118_volatile_reg,
+ .cache_type = REGCACHE_MAPLE,
+};
+
static int spd5118_suspend(struct device *dev)
{
struct spd5118_data *data = dev_get_drvdata(dev);
@@ -701,7 +723,39 @@ static struct i2c_driver spd5118_i2c_driver = {
.address_list = IS_ENABLED(CONFIG_SENSORS_SPD5118_DETECT) ? normal_i2c : NULL,
};
-module_i2c_driver(spd5118_i2c_driver);
+/* I3C */
+
+static int spd5118_i3c_probe(struct i3c_device *i3cdev)
+{
+ struct device *dev = i3cdev_to_dev(i3cdev);
+ struct regmap *regmap;
+ u8 regval[2];
+ int err;
+
+ regmap = devm_regmap_init_i3c(i3cdev, &spd5118_regmap_i3c_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap), "regmap init failed\n");
+
+ err = regmap_bulk_read(regmap, SPD5118_REG_TYPE, regval, 2);
+ if (err)
+ return dev_err_probe(dev, err, "failed to read device type\n");
+
+ if (regval[0] != 0x51 || regval[1] != 0x18)
+ return -ENODEV;
+
+ return spd5118_common_probe(dev, regmap);
+}
+
+static struct i3c_driver spd5118_i3c_driver = {
+ .driver = {
+ .name = "spd5118_i3c",
+ .of_match_table = spd5118_of_ids,
+ .pm = pm_sleep_ptr(&spd5118_pm_ops),
+ },
+ .probe = spd5118_i3c_probe,
+};
+
+module_i3c_i2c_driver(spd5118_i3c_driver, &spd5118_i2c_driver);
MODULE_AUTHOR("René Rebe <rene@exactcode.de>");
MODULE_AUTHOR("Guenter Roeck <linux@roeck-us.net>");
--
2.43.0
^ permalink raw reply related
* [PATCH v4 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Akhil R @ 2026-06-16 9:54 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260616095429.3947205-1-akhilrajeev@nvidia.com>
Enable I3C subsystem (I3C), Synopsys DesignWare I3C master controller
(DW_I3C_MASTER), and SPD5118 hwmon temperature sensor (SENSORS_SPD5118)
as modules.
The NVIDIA Vera CPU uses SOCAMM LPDDR5X memory module, which contains
SPD5118 (JEDEC JESD300) compliant temperature sensor. This sensor is
accessible over the I3C bus through the DesignWare I3C controller present
on the SoC. Enabling these configs allows monitoring memory module
temperatures on platforms such as Vera Rubin. Vera is an ACPI-based
platform and does not use device tree.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f2e6ae93e533..65d9eb56e978 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -640,6 +640,8 @@ CONFIG_I2C_UNIPHIER_F=y
CONFIG_I2C_XILINX=m
CONFIG_I2C_RCAR=y
CONFIG_I2C_CROS_EC_TUNNEL=y
+CONFIG_I3C=m
+CONFIG_DW_I3C_MASTER=m
CONFIG_SPI=y
CONFIG_SPI_APPLE=m
CONFIG_SPI_ARMADA_3700=y
@@ -769,6 +771,7 @@ CONFIG_SENSORS_SL28CPLD=m
CONFIG_SENSORS_AMC6821=m
CONFIG_SENSORS_INA2XX=m
CONFIG_SENSORS_INA3221=m
+CONFIG_SENSORS_SPD5118=m
CONFIG_SENSORS_TMP102=m
CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
CONFIG_CPU_THERMAL=y
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: Joey Lu @ 2026-06-16 10:01 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Hui-Ping Chen, Neil Armstrong, Conor Dooley, Vinod Koul,
devicetree, Catalin Marinas, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel, Joey Lu, Jacky Huang,
Arnd Bergmann, linux-phy, Shan-Chun Hung
In-Reply-To: <178153082322.1456470.14205688450934768854.robh@kernel.org>
On 6/15/2026 9:40 PM, Rob Herring (Arm) wrote:
> On Mon, 15 Jun 2026 13:49:09 +0800, Joey Lu wrote:
>> The MA35D1 has two USB PHY ports managed by the same hardware block:
>>
>> - PHY0 (index 0): OTG port shared between the DWC2 gadget controller
>> and EHCI0/OHCI0 host controllers. A hardware mux follows the USB
>> ID pin automatically.
>>
>> - PHY1 (index 1): dedicated host-only port for EHCI1/OHCI1.
>>
>> Extend the existing binding to cover both ports:
>>
>> - The PHY node is now a child of the system-management syscon node
>> with a reg property. The nuvoton,sys phandle and clocks
>> properties are removed; the driver derives the regmap from its
>> parent, and clock gating is owned by each individual USB controller.
>>
>> - #phy-cells changes from 0 to 1: the cell selects the PHY port.
>>
>> - Two optional board-tuning properties are added: nuvoton,rcalcode
>> for per-port resistor trim and nuvoton,oc-active-high for
>> over-current polarity.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> .../bindings/phy/nuvoton,ma35d1-usb2-phy.yaml | 62 ++++++++++++++-----
>> 1 file changed, 48 insertions(+), 14 deletions(-)
>>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): '#address-cells', '#size-cells', 'usb-phy@60' do not match any of the regexes: '^pinctrl-[0-9]+$'
> from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): compatible: ['nuvoton,ma35d1-reset', 'syscon', 'simple-mfd'] is too long
> from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): reg: [[0, 1078329344], [0, 512]] is too long
> from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260615054911.48821-2-a0987203069@gmail.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
I will fix it.
^ permalink raw reply
* Re: [PATCH v9 2/2] arm64: dts: qcom: Add Xiaomi 12 Lite 5G (taoyao) DTS
From: Konrad Dybcio @ 2026-06-16 10:01 UTC (permalink / raw)
To: Stanislav Zaikin, devicetree
Cc: linux-arm-msm, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-kernel, dmitry.baryshkov
In-Reply-To: <20260608143329.252033-3-zstaseg@gmail.com>
On 6/8/26 4:33 PM, Stanislav Zaikin wrote:
> Xiaomi 12 Lite 5G is a handset released in 2022
>
> This commit has the following features working:
> - Display (with simple fb)
> - Touchscreen
> - UFS
> - Power and volume buttons
> - Pinctrl
> - RPM Regulators
> - Remoteprocs - wifi, bluetooth
> - USB (Device Mode)
>
> Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
> ---
[...]
> +&ipa {
> + firmware-name = "qcom/sm7325/xiaomi/taoyao/ipa_fws.mbn";
> +
> + status = "okay";
> +};
From make dtbs_check:
qcom/sm7325-xiaomi-taoyao.dtb: ipa@1e40000 (qcom,sc7280-ipa): 'memory-region' is a required property
Please fix that (or disable IPA)
Otherwise:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 3/4] iio: adc: ti-ads112c14: implement gain on internal short SYS_MON channel
From: Nuno Sá @ 2026-06-16 10:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: David Lechner (TI), Jonathan Cameron, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kurt Borja, Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <ajECNvjntVg_GjwR@ashevche-desk.local>
On Tue, Jun 16, 2026 at 10:58:46AM +0300, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 05:00:01PM -0500, David Lechner (TI) wrote:
> > Implement support for the programmable gain amplifier on the internal
> > short SYS_MON channel. This channel is used for calibration, so it is
> > useful to be able to set the PGA to the same gain as the external
> > channels. The gain setting is implemented via the `_scale` attribute.
> >
> > In the future, we may want to support different reference voltages for
> > this channel, so the scale_available table is populated during probe
> > rather than being a static table.
>
...
> > +
> > + for (i = 0; i < ARRAY_SIZE(ads112c14_pga_gains_x10); i++) {
> > + int *scale_avail = &data->sys_mon_chan_short_scale_available[i][0];
> > + u32 gain_x10 = ads112c14_pga_gains_x10[i];
> > +
> > + /* NB: slightly odd arrangement to avoid overflow. */
> > + scale_avail[0] = div_u64_rem(div_u64((u64)NANO * 10 /
> > + (MICRO / MILLI) * vref_uV /
> > + gain_x10,
> > + BIT(fsr_bits)),
> > + NANO, &scale_avail[1]);
>
> Oh, what about temporary variable for the inner division? Also note one trick
> to avoid casting (and making it shorter).
>
> u64 foo;
>
> foo = div_u64(10ULL * NANO / (MICRO / MILLI) * vref_uV / gain_x10, BIT(fsr_bits));
>
> /* NB: slightly odd arrangement to avoid overflow. */
> scale_avail[0] = div_u64_rem(foo, NANO, &scale_avail[1]);
>
> Now, with much more readability, it's visible that the first division is just a right shift.
>
> u64 foo;
>
> /* ...a comment to explain voodoo calculations... */
> foo = (10ULL * NANO / (MICRO / MILLI) * vref_uV / gain_x10) >> fsr_bits;
Did not looked enough time but also looks like maybe mul_u64_u32_shr()
could be used? And given that it handles things nicely (even uses 128bit
when possible), might open the door for more simplifications.
Anyways, agree with Andy that in the current patch it's a bit of a pain
to the eyes :).
- Nuno Sá
>
> scale_avail[0] = div_u64_rem(foo, NANO, &scale_avail[1]);
>
> > + }
> > +}
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v4 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: sashiko-bot @ 2026-06-16 10:04 UTC (permalink / raw)
To: Akhil R; +Cc: linux-hwmon, conor+dt, robh, devicetree, Frank.Li, linux-i3c
In-Reply-To: <20260616095429.3947205-2-akhilrajeev@nvidia.com>
> Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> Discovery and Configuration Specification [1] to specify which discovery
> method an I3C device supports during bus initialization. The property is
> a bitmap, where a bit value of 1 indicates support for that method, and 0
> indicates lack of support.
>
> Bit 0: SETDASA CCC (Direct)
> Bit 1: SETAASA CCC (Broadcast)
> Bit 2: Other CCC (vendor / standards extension)
> All other bits are reserved.
>
> It is specifically needed when an I3C device requires SETAASA for the
> address assignment. SETDASA will be supported by default if this property
> is absent, which means for now the property just serves as a flag to
> enable SETAASA, but keep the property as a bitmap to align with the
> specifications.
>
> [1] https://www.mipi.org/mipi-disco-for-i3c-download
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=1
^ permalink raw reply
* Re: [PATCH V13 7/9] iio: imu: inv_icm42607: Add Accelerometer for icm42607
From: Andy Shevchenko @ 2026-06-16 10:04 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
Chris Morgan
In-Reply-To: <20260615172554.160910-8-macroalpha82@gmail.com>
On Mon, Jun 15, 2026 at 12:25:50PM -0500, Chris Morgan wrote:
> Add icm42607 accelerometer sensor for icm42607.
...
> +static int inv_icm42607_accel_read_odr(struct inv_icm42607_state *st,
> + int *val, int *val2)
> +{
> + unsigned int odr;
> + unsigned int i;
> +
> + guard(mutex)(&st->lock);
> +
> + odr = st->conf.accel.odr;
> +
> + for (i = 5; i < ARRAY_SIZE(inv_icm42607_accel_odr); ++i) {
Same comment stays. Why pre-increment?
> + if (i == odr)
> + break;
> + }
> + if (i >= ARRAY_SIZE(inv_icm42607_accel_odr))
> + return -EINVAL;
> +
> + *val = inv_icm42607_accel_odr[i][0];
> + *val2 = inv_icm42607_accel_odr[i][1];
> +
> + return IIO_VAL_INT_PLUS_MICRO;
> +}
...
> +static int inv_icm42607_accel_write_odr(struct iio_dev *indio_dev,
> + int val, int val2)
> +{
> + struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int idx;
> + int ret;
> +
> + for (idx = 5; idx < ARRAY_SIZE(inv_icm42607_accel_odr); ++idx) {
Ditto.
> + if (val == inv_icm42607_accel_odr[idx][0] &&
> + val2 == inv_icm42607_accel_odr[idx][1])
> + break;
> + }
> + if (idx >= ARRAY_SIZE(inv_icm42607_accel_odr))
> + return -EINVAL;
> +
> + conf.odr = idx;
> +
> + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> + ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> + if (ret)
> + return ret;
> +
> + guard(mutex)(&st->lock);
> +
> + return inv_icm42607_set_accel_conf(st, &conf, NULL);
> +}
...
> +int inv_icm42607_set_accel_conf(struct inv_icm42607_state *st,
> + struct inv_icm42607_sensor_conf *conf,
> + unsigned int *sleep_ms)
> +{
> + struct inv_icm42607_sensor_conf *oldconf = &st->conf.accel;
> + unsigned int val;
> + int ret;
> +
> + if (conf->mode < 0)
> + conf->mode = oldconf->mode;
Also as per below.
> + if (conf->fs < 0)
> + conf->fs = oldconf->fs;
> + if (conf->odr < 0)
> + conf->odr = oldconf->odr;
> + if (conf->filter < 0)
> + conf->filter = oldconf->filter;
This conditional is not immediately used below...
> + if (conf->fs != oldconf->fs || conf->odr != oldconf->odr) {
> + val = FIELD_PREP(INV_ICM42607_ACCEL_CONFIG0_FS_SEL_MASK, conf->fs);
> + val |= FIELD_PREP(INV_ICM42607_ACCEL_CONFIG0_ODR_MASK, conf->odr);
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG0, val);
> + if (ret)
> + return ret;
> + oldconf->fs = conf->fs;
> + oldconf->odr = conf->odr;
> + }
...you can move it here.
> + if (conf->filter != oldconf->filter) {
> + if (conf->mode == INV_ICM42607_SENSOR_MODE_LOW_POWER) {
> + val = FIELD_PREP(INV_ICM42607_ACCEL_CONFIG1_AVG_MASK, conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
> + INV_ICM42607_ACCEL_CONFIG1_AVG_MASK, val);
> + } else {
> + val = FIELD_PREP(INV_ICM42607_ACCEL_CONFIG1_FILTER_MASK,
> + conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
> + INV_ICM42607_ACCEL_CONFIG1_FILTER_MASK, val);
> + }
> + if (ret)
> + return ret;
> + oldconf->filter = conf->filter;
> + }
> +
> + return inv_icm42607_set_pwr_mgmt0(st, st->conf.gyro.mode, conf->mode,
> + st->conf.temp_en, sleep_ms);
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
From: Marco Felsch @ 2026-06-16 10:05 UTC (permalink / raw)
To: Liu Ying
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260610-imx93-ldb-v3-3-c9b65d742753@nxp.com>
On 26-06-10, Liu Ying wrote:
> DY1212W-4856 [1] is a 12.1" (WXGA) TFT LCD panel with LVDS interface.
> The panel's 40-pin connector allows it to be directly connected to
> i.MX93 11x11 EVK board.
>
> Link: https://www.nxp.com/design/design-center/development-boards-and-designs/dy1212w-4856-tft-lcd-panel-with-lvds-interface:DY1212W-4856 [1]
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 4 ++
> .../freescale/imx93-11x11-evk-dy1212w-4856.dtso | 81 ++++++++++++++++++++++
> 2 files changed, 85 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 8ddaab127ab9..dbe27d757c86 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -588,6 +588,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-tianma-tm050rdh03.dtb
>
> dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
> +
> +imx93-11x11-evk-dy1212w-4856-dtbs += imx93-11x11-evk.dtb imx93-11x11-evk-dy1212w-4856.dtbo
> +dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk-dy1212w-4856.dtb
> +
> dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-frdm.dtb
>
> imx93-11x11-frdm-pixpaper-dtbs += imx93-11x11-frdm.dtb imx93-11x11-frdm-pixpaper.dtbo
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso
> new file mode 100644
> index 000000000000..35f7c5699e3a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2026 NXP
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/clock/imx93-clock.h>
> +
> +&{/} {
> + panel-lvds {
> + compatible = "boe,ev121wxm-n10-1850";
> + backlight = <&backlight_lvds>;
> + power-supply = <&buck4>;
> +
> + panel-timing {
> + /*
> + * Set clock frequency to 71142858Hz to accommodate
> + * IMX93_CLK_VIDEO_PLL rate at 498000000Hz in a rate
> + * table.
> + */
> + clock-frequency = <71142858>;
> + hactive = <1280>;
> + vactive = <800>;
> + hfront-porch = <48>;
> + hback-porch = <80>;
> + hsync-len = <32>;
> + vfront-porch = <3>;
> + vback-porch = <14>;
> + vsync-len = <6>;
> + };
> +
> + port {
> + panel_lvds_in: endpoint {
> + remote-endpoint = <&ldb_lvds_ch0>;
> + };
> + };
> + };
> +};
> +
> +&backlight_lvds {
> + status = "okay";
> +};
> +
> +&lcdif {
> + status = "okay";
> +};
> +
> +&lvds_bridge {
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + ldb_lvds_ch0: endpoint {
> + remote-endpoint = <&panel_lvds_in>;
> + };
> + };
> + };
You could just make use of the ldb_lvds_ch0 phandle you added previously
and drop the complete override.
Regards,
Marco
> +};
> +
> +&media_blk_ctrl {
> + assigned-clocks = <&clk IMX93_CLK_MEDIA_AXI>,
> + <&clk IMX93_CLK_MEDIA_APB>,
> + <&clk IMX93_CLK_MEDIA_DISP_PIX>,
> + <&clk IMX93_CLK_VIDEO_PLL>;
> + assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1>,
> + <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>,
> + <&clk IMX93_CLK_VIDEO_PLL>;
> + /*
> + * Set IMX93_CLK_MEDIA_DISP_PIX rate to 71142858Hz to accommodate
> + * IMX93_CLK_VIDEO_PLL rate at 498000000Hz in a rate table.
> + */
> + assigned-clock-rates = <400000000>, <133333333>, <71142858>, <498000000>;
> + status = "okay";
> +};
>
> --
> 2.43.0
>
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply
* [PATCH 0/4] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Fenglin Wu @ 2026-06-16 10:08 UTC (permalink / raw)
To: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel, Fenglin Wu
Qualcomm PMIH010x PMIC has a haptics module inside and it could drive
a LRA actuator with several play modes, including: DIRECT_PLAY, FIFO,
PAT_MEM, SWR, etc. Add an initial driver to support two of the play
modes using the input force-feedback framework:
-- FF_CONSTANT effect for DIRECT_PLAY mode which drives sinusoidual
waveforms with fixed period and amplitude, which would generate
a constant vibration effect on the LRA actuator.
-- FF_PERIODIC effect with FF_CUSTOM for FIFO streaming mode, which
can play an arbitrary waveform composed of a sequence of 8-bit
samples at a configurable play rate.
Also, add the device node in the existing pmih0108 dtsi files, and enble
the haptics device for several boards by updating the vmax and
lra-period sttings according to the LRA components that mounted on each
of them.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
Fenglin Wu (4):
dt-bindings: input: Add binding for Qualcomm SPMI PMIC haptics
dt-bindings: mfd: qcom,spmi-pmic: Document haptics device
input: misc: Add Qualcomm SPMI PMIC haptics driver
arm64: dts: qcom: Add PMIH0108 haptics device node
.../bindings/input/qcom,spmi-haptics.yaml | 119 +++
.../devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 +
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 +
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 7 +
arch/arm64/boot/dts/qcom/pmih0108-kaanapali.dtsi | 9 +
arch/arm64/boot/dts/qcom/pmih0108.dtsi | 9 +
arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 7 +
arch/arm64/boot/dts/qcom/sm8750-qrd.dts | 7 +
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/qcom-spmi-haptics.c | 831 +++++++++++++++++++++
11 files changed, 1012 insertions(+)
---
base-commit: 66725039f7090afe14c31bd259e2059a68f04023
change-id: 20260616-qcom-spmi-haptics-3cc97e7b232e
Best regards,
--
Fenglin Wu <fenglin.wu@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/4] dt-bindings: input: Add binding for Qualcomm SPMI PMIC haptics
From: Fenglin Wu @ 2026-06-16 10:08 UTC (permalink / raw)
To: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel, Fenglin Wu
In-Reply-To: <20260616-qcom-spmi-haptics-v1-0-d24e422de6b4@oss.qualcomm.com>
Add binding document for the haptics module inside Qualcomm PMIH010X.
Assisted-by: Claude:claude-4-6-sonnet
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
.../bindings/input/qcom,spmi-haptics.yaml | 119 +++++++++++++++++++++
1 file changed, 119 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml b/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml
new file mode 100644
index 000000000000..0e26d68563dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/qcom,spmi-haptics.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Haptics device inside Qualcomm Technologies, Inc. PMIH010X
+
+maintainers:
+ - Fenglin Wu <fenglin.wu@oss.qualcomm.com>
+
+description: |
+ The Qualcomm PMIH010X PMIC integrates a haptics module (HAP530_HV) that
+ drives an LRA (Linear Resonant Actuator) with output voltage up to 10 V.
+ Two play modes are supported:
+
+ DIRECT_PLAY: The hardware outputs sinusoidal waveforms whose period is
+ defined by lra-period-us and whose peak voltage is defined by vmax-mv.
+ The driving amplitude can be scaled in the range [0, 255] via a single
+ register byte. Hardware-based LRA auto-resonance tracking is enabled by
+ default in this mode, allowing the haptics engine to follow the actual
+ resonant frequency of the LRA and update the driving period accordingly
+ to achieve stronger vibration magnitude.
+
+ FIFO streaming: The hardware can play an arbitrary waveform composed of a
+ sequence of 8-bit samples at a configurable play rate. Samples are
+ pre-filled into the internal FIFO memory of the haptics module and
+ continuously replenished via the FIFO-empty IRQ until all samples have
+ been played. The following play rate values are accepted:
+ -- 0(T_LRA): each FIFO byte drives one full sinusoidal cycle with the
+ period defined in lra-period-us.
+ -- 1/2/3(T_LRA_DIV_2/4/8): each FIFO byte drives a half/quarter/eighth
+ sinusoidal cycle with the period defined in lra-period-us.
+ -- 8/9/10/11/12/13(8KHz/16KHz/24KHz/32KHz/44.1KHz/48KHz): the FIFO
+ data is treated as PCM samples and drives the output with an
+ arbitrarily shaped waveform. This mode is typically used to define
+ custom driving waveforms for specific vibration effects such as fast
+ attack, crisp brake, etc.
+
+ In FIFO streaming mode, hardware-based LRA auto-resonance tracking is
+ disabled by default. Because this mode is intended to drive arbitrary
+ waveforms that may not follow the resonant frequency, autonomous hardware
+ resonance correction would interfere with the intended output.
+
+ In the driver, FIFO streaming is implemented using an FF_PERIODIC effect
+ with an FF_CUSTOM waveform. The expected custom data layout is:
+ custom_data[0] = play rate code (see qcom,wf-play-rate values below)
+ custom_data[1] = vmax in mV; 0 = use device default (qcom,vmax-mv)
+ custom_data[2..] = signed 8-bit PCM samples (at least one required)
+
+properties:
+ compatible:
+ const: qcom,pmih010x-haptics
+
+ reg:
+ items:
+ - description: HAP_CFG module base address
+ - description: HAP_PTN module base address
+
+ reg-names:
+ items:
+ - const: hap-cfg
+ - const: hap-ptn
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: fifo-empty
+
+ qcom,vmax-mv:
+ description:
+ Maximum allowed output driving voltage in millivolts, rounded to the
+ nearest 50 mV step. This is the peak driving voltage in DIRECT_PLAY mode
+ which outputs sinusoidal waveforms. The value should be equal to the square
+ root of 2 times the Vrms voltage of the LRA.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 50
+ maximum: 10000
+
+ qcom,lra-period-us:
+ description:
+ LRA actuator initial resonance period in microseconds
+ (1,000,000 / resonant_freq_hz). Used to configure T_LRA-based play
+ rates and the auto-resonance zero-crossing window.
+ minimum: 5
+ maximum: 20475
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - qcom,vmax-mv
+ - qcom,lra-period-us
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ haptics@f000 {
+ compatible = "qcom,pmih010x-haptics";
+ reg = <0xf000>, <0xf100>;
+ reg-names = "hap-cfg", "hap-ptn";
+ interrupts = <0x7 0xf0 0x1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "fifo-empty";
+
+ qcom,vmax-mv = <1300>;
+ qcom,lra-period-us = <5880>;
+ };
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: mfd: qcom,spmi-pmic: Document haptics device
From: Fenglin Wu @ 2026-06-16 10:08 UTC (permalink / raw)
To: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel, Fenglin Wu
In-Reply-To: <20260616-qcom-spmi-haptics-v1-0-d24e422de6b4@oss.qualcomm.com>
Some of the Qualcomm SPMI PMIC has haptics device in it, add it in the
device list.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
index 644c42b5e2e5..773f4cba5935 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
@@ -165,6 +165,10 @@ patternProperties:
type: object
$ref: /schemas/pinctrl/qcom,pmic-gpio.yaml#
+ "^haptics@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/input/qcom,spmi-haptics.yaml#
+
"^led-controller@[0-9a-f]+$":
type: object
$ref: /schemas/leds/qcom,spmi-flash-led.yaml#
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: qcom: Add PMIH0108 haptics device node
From: Fenglin Wu @ 2026-06-16 10:08 UTC (permalink / raw)
To: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel, Fenglin Wu
In-Reply-To: <20260616-qcom-spmi-haptics-v1-0-d24e422de6b4@oss.qualcomm.com>
Add haptics device node in the PMIH0108 PMIC base dtsi files, and enable
it on several boards according to the LRA (Linear Resonant Actuator)
component mounted on each of them.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 +++++++
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 7 +++++++
arch/arm64/boot/dts/qcom/pmih0108-kaanapali.dtsi | 9 +++++++++
arch/arm64/boot/dts/qcom/pmih0108.dtsi | 9 +++++++++
arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 7 +++++++
arch/arm64/boot/dts/qcom/sm8750-qrd.dts | 7 +++++++
6 files changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
index 07247dc98b70..7e3f59fc008e 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
@@ -952,6 +952,13 @@ wifi@0 {
};
};
+&pmih0108_e1_haptics {
+ status = "okay";
+
+ qcom,lra-period-us = <6667>;
+ qcom,vmax-mv = <3600>;
+};
+
&pmh0101_flash {
status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
index da0e8f9091c3..0865afec47ac 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
@@ -744,6 +744,13 @@ led@3 {
};
};
+&pmih0108_e1_haptics {
+ status = "okay";
+
+ qcom,lra-period-us = <7692>;
+ qcom,vmax-mv = <1850>;
+};
+
&pon_resin {
linux,code = <KEY_VOLUMEDOWN>;
diff --git a/arch/arm64/boot/dts/qcom/pmih0108-kaanapali.dtsi b/arch/arm64/boot/dts/qcom/pmih0108-kaanapali.dtsi
index b73b0e82c3d3..22c83c549ce9 100644
--- a/arch/arm64/boot/dts/qcom/pmih0108-kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmih0108-kaanapali.dtsi
@@ -59,6 +59,15 @@ pmih0108_e1_gpios: gpio@8800 {
#interrupt-cells = <2>;
};
+ pmih0108_e1_haptics: haptics@f000 {
+ compatible = "qcom,pmih010x-haptics";
+ reg = <0xf000>, <0xf100>;
+ reg-names = "hap-cfg", "hap-ptn";
+ interrupts = <0x7 0xf0 0x1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "fifo-empty";
+ status = "disabled";
+ };
+
pmih0108_e1_eusb2_repeater: phy@fd00 {
compatible = "qcom,pm8550b-eusb2-repeater";
reg = <0xfd00>;
diff --git a/arch/arm64/boot/dts/qcom/pmih0108.dtsi b/arch/arm64/boot/dts/qcom/pmih0108.dtsi
index 1c875995d881..d942d6c2fd03 100644
--- a/arch/arm64/boot/dts/qcom/pmih0108.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmih0108.dtsi
@@ -59,6 +59,15 @@ pmih0108_gpios: gpio@8800 {
#interrupt-cells = <2>;
};
+ pmih0108_haptics: haptics@f000 {
+ compatible = "qcom,pmih010x-haptics";
+ reg = <0xf000>, <0xf100>;
+ reg-names = "hap-cfg", "hap-ptn";
+ interrupts = <0x7 0xf0 0x1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "fifo-empty";
+ status = "disabled";
+ };
+
pmih0108_eusb2_repeater: phy@fd00 {
compatible = "qcom,pm8550b-eusb2-repeater";
reg = <0xfd00>;
diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
index 3837f6785320..7a3b8c440d00 100644
--- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
@@ -1138,6 +1138,13 @@ wifi@0 {
};
};
+&pmih0108_haptics {
+ status = "okay";
+
+ qcom,lra-period-us = <6667>;
+ qcom,vmax-mv = <3600>;
+};
+
&pmih0108_eusb2_repeater {
qcom,tune-usb2-preem = /bits/ 8 <0x3>;
qcom,tune-usb2-amplitude = /bits/ 8 <0xa>;
diff --git a/arch/arm64/boot/dts/qcom/sm8750-qrd.dts b/arch/arm64/boot/dts/qcom/sm8750-qrd.dts
index 801c46d55602..4a1079984307 100644
--- a/arch/arm64/boot/dts/qcom/sm8750-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8750-qrd.dts
@@ -933,6 +933,13 @@ &pon_resin {
status = "okay";
};
+&pmih0108_haptics {
+ status = "okay";
+
+ qcom,lra-period-us = <5880>;
+ qcom,vmax-mv = <1700>;
+};
+
&pmih0108_eusb2_repeater {
status = "okay";
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Fenglin Wu @ 2026-06-16 10:08 UTC (permalink / raw)
To: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel, Fenglin Wu
In-Reply-To: <20260616-qcom-spmi-haptics-v1-0-d24e422de6b4@oss.qualcomm.com>
Add an initial driver for the Qualcomm PMIH010x PMIC haptics module,
named as HAP530_HV. This module supports several play modes, including
DIRECT_PLAY, FIFO, PAT_MEM, and SWR, each with distinct data sourcing
and hardware data handling logic. Currently, the driver provides support
for two play modes using the input force-feedback framework: FF_CONSTANT
effect for DIRECT_PLAY mode and FF_PERIODIC effect with FF_CUSTOM
waveform for FIFO mode.
Assisted-by: Claude:claude-4-6-sonnet
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/qcom-spmi-haptics.c | 831 +++++++++++++++++++++++++++++++++
3 files changed, 843 insertions(+)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 1f6c57dba030..eac939978ce4 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -236,6 +236,17 @@ config INPUT_PMIC8XXX_PWRKEY
To compile this driver as a module, choose M here: the
module will be called pmic8xxx-pwrkey.
+config INPUT_QCOM_SPMI_HAPTICS
+ tristate "Qualcomm SPMI PMIC haptics support"
+ depends on INPUT && MFD_SPMI_PMIC
+ help
+ Say Y to enable support for the Qualcomm PMIH010X SPMI PMIC haptics
+ module. Supports DIRECT_PLAY, FIFO streaming play modes via the
+ Linux input force-feedback framework.
+
+ To compile this driver as a module, choose M here: the module will
+ be called qcom-spmi-haptics.
+
config INPUT_SPARCSPKR
tristate "SPARC Speaker support"
depends on PCI && SPARC64
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 2281d6803fce..c5c9aa139a11 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_PWM_VIBRA) += pwm-vibra.o
+obj-$(CONFIG_INPUT_QCOM_SPMI_HAPTICS) += qcom-spmi-haptics.o
obj-$(CONFIG_INPUT_QNAP_MCU) += qnap-mcu-input.o
obj-$(CONFIG_INPUT_RAVE_SP_PWRBUTTON) += rave-sp-pwrbutton.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
diff --git a/drivers/input/misc/qcom-spmi-haptics.c b/drivers/input/misc/qcom-spmi-haptics.c
new file mode 100644
index 000000000000..75b3e338b54e
--- /dev/null
+++ b/drivers/input/misc/qcom-spmi-haptics.c
@@ -0,0 +1,831 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/device.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/pm_runtime.h>
+#include <linux/spinlock.h>
+#include <linux/uaccess.h>
+#include <linux/workqueue.h>
+
+/* HAP_CFG register offsets, bit fields, value constants */
+#define HAP_CFG_INT_RT_STS_REG 0x10
+#define FIFO_EMPTY_BIT BIT(1)
+#define HAP_CFG_EN_CTL_REG 0x46
+#define HAPTICS_EN_BIT BIT(7)
+#define HAP_CFG_VMAX_REG 0x48
+#define VMAX_STEP_MV 50
+#define VMAX_MV_MAX 10000
+#define HAP_CFG_SPMI_PLAY_REG 0x4C
+#define PLAY_EN_BIT BIT(7)
+#define PAT_SRC_MASK GENMASK(2, 0)
+#define PAT_SRC_FIFO 0
+#define PAT_SRC_DIRECT_PLAY 1
+#define HAP_CFG_TLRA_OL_HIGH_REG 0x5C
+#define TLRA_OL_MSB_MASK GENMASK(3, 0)
+#define TLRA_STEP_US 5
+#define HAP_CFG_TLRA_OL_LOW_REG 0x5D
+#define HAP_CFG_DRV_DUTY_CFG_REG 0x60
+#define ADT_DRV_DUTY_EN_BIT BIT(7)
+#define ADT_BRK_DUTY_EN_BIT BIT(6)
+#define DRV_DUTY_MASK GENMASK(5, 3)
+#define AUTORES_DRV_DUTY_62P5 2
+#define BRK_DUTY_MASK GENMASK(2, 0)
+#define AUTORES_BRK_DUTY_62P5 5
+#define HAP_CFG_ZX_WIND_CFG_REG 0x62
+#define ZX_DEBOUNCE_MASK GENMASK(6, 4)
+#define AUTORES_ZX_DEBOUNCE 3
+#define ZX_WIN_HEIGHT_MASK GENMASK(2, 0)
+#define AUTORES_ZX_WIN_HEIGHT 2
+#define HAP_CFG_AUTORES_CFG_REG 0x63
+#define AUTORES_EN_BIT BIT(7)
+#define AUTORES_EN_DLY_MASK GENMASK(6, 2)
+#define AUTORES_EN_DLY_CYCLES 10
+#define AUTORES_ERR_WIN_MASK GENMASK(1, 0)
+#define AUTORES_ERR_WIN_25PCT 1
+#define HAP_CFG_FAULT_CLR_REG 0x66
+#define ZX_TO_FAULT_CLR_BIT BIT(4)
+#define SC_CLR_BIT BIT(2)
+#define AUTO_RES_ERR_CLR_BIT BIT(1)
+#define HPWR_RDY_FAULT_CLR_BIT BIT(0)
+#define FAULT_CLR_ALL (ZX_TO_FAULT_CLR_BIT | SC_CLR_BIT | \
+ AUTO_RES_ERR_CLR_BIT | HPWR_RDY_FAULT_CLR_BIT)
+#define HAP_CFG_RAMP_DN_CFG2_REG 0x86
+#define AUTORES_PRE_HIZ_DLY_10US 1
+
+/* HAP_PTN register offsets, bit fields, value constants */
+#define HAP_PTN_REVISION2_REG 0x01
+#define HAP_PTN_FIFO_DIN_0_REG 0x20
+#define HAP_PTN_FIFO_PLAY_RATE_REG 0x24
+#define FIFO_PLAY_RATE_MASK GENMASK(3, 0)
+#define HAP_PTN_DIRECT_PLAY_REG 0x26
+#define HAP_PTN_FIFO_EMPTY_CFG_REG 0x2A
+#define FIFO_THRESH_LSB 64
+#define HAP_PTN_FIFO_DIN_1B_REG 0x2C
+#define HAP_PTN_MEM_OP_ACCESS_REG 0x2D
+#define MEM_FLUSH_RELOAD_BIT BIT(0)
+#define HAP_PTN_MMAP_FIFO_REG 0xA0
+#define MMAP_FIFO_EXIST_BIT BIT(7)
+#define MMAP_FIFO_LEN_MASK GENMASK(6, 0)
+#define HAP_PTN_PATX_PLAY_CFG_REG 0xA2
+
+#define HAP530_MEM_TOTAL_BYTES 8192
+#define FIFO_EMPTY_THRESH 280
+#define FIFO_INIT_FILL 320
+
+#define HAPTICS_AUTOSUSPEND_MS 1000
+
+/*
+ * FF_CUSTOM data layout (custom_data[] of type s16):
+ * [0] = play rate (PLAY_RATE_*)
+ * [1] = vmax in mV (0 = use device default from qcom,vmax-mv)
+ * [2..N-1] = signed 8-bit PCM samples packed one per s16 (lower byte used)
+ */
+#define CUSTOM_DATA_RATE_IDX 0
+#define CUSTOM_DATA_VMAX_IDX 1
+#define CUSTOM_DATA_SAMPLE_START 2
+
+#define HAPTICS_MAX_EFFECTS 8
+
+enum qcom_haptics_mode {
+ HAPTICS_DIRECT_PLAY,
+ HAPTICS_FIFO,
+};
+
+enum qcom_haptics_play_rate {
+ PLAY_RATE_T_LRA = 0,
+ PLAY_RATE_T_LRA_DIV_2 = 1,
+ PLAY_RATE_T_LRA_DIV_4 = 2,
+ PLAY_RATE_T_LRA_DIV_8 = 3,
+ /* 4–7 are reserved */
+ PLAY_RATE_F_8KHZ = 8,
+ PLAY_RATE_F_16KHZ = 9,
+ PLAY_RATE_F_24KHZ = 10,
+ PLAY_RATE_F_32KHZ = 11,
+ PLAY_RATE_F_44P1KHZ = 12,
+ PLAY_RATE_F_48KHZ = 13,
+ PLAY_RATE_MAX = PLAY_RATE_F_48KHZ,
+};
+
+struct qcom_haptics_effect {
+ enum qcom_haptics_mode mode;
+ enum qcom_haptics_play_rate play_rate;
+ u32 vmax_mv;
+ s8 *fifo_data;
+ u32 data_len;
+};
+
+/**
+ * struct qcom_haptics
+ * @dev: underlying SPMI device
+ * @regmap: regmap for SPMI register access
+ * @input: input device exposing the FF interface
+ * @cfg_base: base address of the CFG peripheral
+ * @ptn_base: base address of the PTN peripheral
+ * @t_lra_us: LRA resonance period in microseconds
+ * @vmax_mv: maximum actuator drive voltage in millivolts
+ * @fifo_len: programmed HW FIFO depth in bytes
+ * @gain: playback gain scaler
+ * @play_work: deferred work item that starts or stops playback
+ * @play_lock: mutex lock to serialize playbacks
+ * @cur_effect_id: index into @effects[] identifying the active effect
+ * @fifo_empty_irq: IRQ number for the FIFO-empty interrupt
+ * @play_request: true when a playback is requested
+ * @pm_ref_held: true while a pm_runtime_get is held
+ * @irq_enabled: true if fifo_empty_irq is enabled
+ * @fifo_lock: spinlock protecting the FIFO streaming data
+ * @fifo_data: pointer of the data buffer for FIFO streaming
+ * @data_len: length of the data buffer for current effect
+ * @data_written: number of samples written to the hardware FIFO
+ * @data_done: flag to indicate that all samples have been written
+ * @effects: table of the effects
+ */
+struct qcom_haptics {
+ struct device *dev;
+ struct regmap *regmap;
+ struct input_dev *input;
+
+ u32 cfg_base;
+ u32 ptn_base;
+ u32 t_lra_us;
+ u32 vmax_mv;
+ u32 fifo_len;
+ u16 gain;
+
+ struct work_struct play_work;
+ struct mutex play_lock; /* mutex used to serialize playbacks */
+ int cur_effect_id;
+ int fifo_empty_irq;
+ bool play_request;
+ bool pm_ref_held;
+ bool irq_enabled;
+
+ spinlock_t fifo_lock; /* protect the FIFO data during play */
+ const s8 *fifo_data;
+ u32 data_len;
+ u32 data_written;
+ bool data_done;
+
+ struct qcom_haptics_effect effects[HAPTICS_MAX_EFFECTS];
+};
+
+static int cfg_write(struct qcom_haptics *h, u32 off, u32 val)
+{
+ return regmap_write(h->regmap, h->cfg_base + off, val);
+}
+
+static int cfg_update_bits(struct qcom_haptics *h, u32 off, u32 mask, u32 val)
+{
+ return regmap_update_bits(h->regmap, h->cfg_base + off, mask, val);
+}
+
+static int ptn_write(struct qcom_haptics *h, u32 off, u32 val)
+{
+ return regmap_write(h->regmap, h->ptn_base + off, val);
+}
+
+static int ptn_update_bits(struct qcom_haptics *h, u32 off, u32 mask, u32 val)
+{
+ return regmap_update_bits(h->regmap, h->ptn_base + off, mask, val);
+}
+
+static int ptn_bulk_write(struct qcom_haptics *h, u32 off,
+ const void *buf, size_t count)
+{
+ return regmap_bulk_write(h->regmap, h->ptn_base + off, buf, count);
+}
+
+static int haptics_clear_faults(struct qcom_haptics *h)
+{
+ return cfg_write(h, HAP_CFG_FAULT_CLR_REG, FAULT_CLR_ALL);
+}
+
+static int haptics_set_vmax(struct qcom_haptics *h, u32 vmax_mv)
+{
+ return cfg_write(h, HAP_CFG_VMAX_REG, vmax_mv / VMAX_STEP_MV);
+}
+
+static int haptics_config_lra_period(struct qcom_haptics *h)
+{
+ u32 tmp = h->t_lra_us / TLRA_STEP_US;
+ int ret;
+
+ ret = cfg_write(h, HAP_CFG_TLRA_OL_HIGH_REG, (tmp >> 8) & TLRA_OL_MSB_MASK);
+ if (ret)
+ return ret;
+
+ return cfg_write(h, HAP_CFG_TLRA_OL_LOW_REG, tmp & 0xFF);
+}
+
+static int haptics_enable_module(struct qcom_haptics *h, bool enable)
+{
+ return cfg_update_bits(h, HAP_CFG_EN_CTL_REG, HAPTICS_EN_BIT,
+ enable ? HAPTICS_EN_BIT : 0);
+}
+
+static int haptics_configure_autores(struct qcom_haptics *h)
+{
+ int ret;
+
+ /* AUTORES_CFG: enable, 10-cycle delay, 25% error window */
+ ret = cfg_write(h, HAP_CFG_AUTORES_CFG_REG,
+ AUTORES_EN_BIT |
+ FIELD_PREP(AUTORES_EN_DLY_MASK, AUTORES_EN_DLY_CYCLES) |
+ FIELD_PREP(AUTORES_ERR_WIN_MASK, AUTORES_ERR_WIN_25PCT));
+ if (ret)
+ return ret;
+
+ /* DRV_DUTY: adaptive drive/brake duty cycles at 62.5% */
+ ret = cfg_write(h, HAP_CFG_DRV_DUTY_CFG_REG,
+ ADT_DRV_DUTY_EN_BIT | ADT_BRK_DUTY_EN_BIT |
+ FIELD_PREP(DRV_DUTY_MASK, AUTORES_DRV_DUTY_62P5) |
+ FIELD_PREP(BRK_DUTY_MASK, AUTORES_BRK_DUTY_62P5));
+ if (ret)
+ return ret;
+
+ /* Pre-HIZ delay: 10 µs */
+ ret = cfg_write(h, HAP_CFG_RAMP_DN_CFG2_REG, AUTORES_PRE_HIZ_DLY_10US);
+ if (ret)
+ return ret;
+
+ /* Zero-cross window: debounce 3, no hysteresis, height 2 */
+ return cfg_write(h, HAP_CFG_ZX_WIND_CFG_REG,
+ FIELD_PREP(ZX_DEBOUNCE_MASK, AUTORES_ZX_DEBOUNCE) |
+ FIELD_PREP(ZX_WIN_HEIGHT_MASK, AUTORES_ZX_WIN_HEIGHT));
+}
+
+static int haptics_write_fifo_chunk(struct qcom_haptics *h,
+ const s8 *data, u32 len)
+{
+ u32 i, bulk_len = ALIGN_DOWN(len, 4);
+ int ret;
+
+ for (i = 0; i < bulk_len; i += 4) {
+ ret = ptn_bulk_write(h, HAP_PTN_FIFO_DIN_0_REG, &data[i], 4);
+ if (ret)
+ return ret;
+ }
+
+ for (; i < len; i++) {
+ ret = ptn_write(h, HAP_PTN_FIFO_DIN_1B_REG, (u8)data[i]);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * Configure the hardware FIFO memory boundary.
+ * FIFO occupies addresses [0, fifo_len).
+ */
+static int haptics_configure_fifo_mmap(struct qcom_haptics *h)
+{
+ u32 fifo_len, fifo_units;
+
+ /* Config all memory space for FIFO usage for now */
+ fifo_len = HAP530_MEM_TOTAL_BYTES;
+ fifo_len = ALIGN_DOWN(fifo_len, 64);
+ fifo_units = fifo_len / 64;
+ h->fifo_len = fifo_len;
+
+ return ptn_write(h, HAP_PTN_MMAP_FIFO_REG,
+ MMAP_FIFO_EXIST_BIT |
+ FIELD_PREP(MMAP_FIFO_LEN_MASK, fifo_units - 1));
+}
+
+static u32 haptics_gain_scaled_vmax(struct qcom_haptics *h, u32 vmax_mv)
+{
+ u32 v = (u32)((u64)vmax_mv * h->gain / 0xFFFF);
+
+ return max_t(u32, v, VMAX_STEP_MV);
+}
+
+static void haptics_fifo_irq_enable(struct qcom_haptics *h, bool enable)
+{
+ if (h->irq_enabled == enable)
+ return;
+
+ if (enable)
+ enable_irq(h->fifo_empty_irq);
+ else
+ disable_irq_nosync(h->fifo_empty_irq);
+
+ h->irq_enabled = enable;
+}
+
+/*
+ * Must be called with play_lock held.
+ * Clears PLAY_EN and resets any FIFO-specific state.
+ */
+static void haptics_stop_locked(struct qcom_haptics *h)
+{
+ unsigned long flags;
+
+ cfg_write(h, HAP_CFG_SPMI_PLAY_REG, 0);
+
+ if (h->effects[h->cur_effect_id].mode == HAPTICS_FIFO) {
+ ptn_write(h, HAP_PTN_FIFO_EMPTY_CFG_REG, 0);
+ haptics_fifo_irq_enable(h, false);
+ spin_lock_irqsave(&h->fifo_lock, flags);
+ h->fifo_data = NULL;
+ spin_unlock_irqrestore(&h->fifo_lock, flags);
+ }
+}
+
+static int haptics_start_direct_play(struct qcom_haptics *h, int effect_id)
+{
+ struct ff_effect *ffe = &h->input->ff->effects[effect_id];
+ u8 amplitude = (u8)((u32)ffe->u.constant.level * 255 / 0x7FFF);
+ int ret;
+
+ ret = haptics_clear_faults(h);
+ if (ret)
+ return ret;
+
+ /* Enable auto-resonance for DIRECT_PLAY mode */
+ ret = cfg_update_bits(h, HAP_CFG_AUTORES_CFG_REG,
+ AUTORES_EN_BIT, AUTORES_EN_BIT);
+ if (ret)
+ return ret;
+
+ ret = haptics_set_vmax(h, haptics_gain_scaled_vmax(h, h->vmax_mv));
+ if (ret)
+ return ret;
+
+ ret = ptn_write(h, HAP_PTN_DIRECT_PLAY_REG, amplitude);
+ if (ret)
+ return ret;
+
+ return cfg_write(h, HAP_CFG_SPMI_PLAY_REG,
+ PLAY_EN_BIT | FIELD_PREP(PAT_SRC_MASK, PAT_SRC_DIRECT_PLAY));
+}
+
+static int haptics_start_fifo(struct qcom_haptics *h, int effect_id)
+{
+ struct qcom_haptics_effect *eff = &h->effects[effect_id];
+ u32 vmax = eff->vmax_mv ? eff->vmax_mv : h->vmax_mv;
+ unsigned long flags;
+ u32 init_len;
+ int ret;
+
+ ret = haptics_clear_faults(h);
+ if (ret)
+ return ret;
+
+ /* Disable auto-resonance for FIFO mode */
+ ret = cfg_update_bits(h, HAP_CFG_AUTORES_CFG_REG, AUTORES_EN_BIT, 0);
+ if (ret)
+ return ret;
+
+ ret = haptics_set_vmax(h, haptics_gain_scaled_vmax(h, vmax));
+ if (ret)
+ return ret;
+
+ ret = ptn_update_bits(h, HAP_PTN_FIFO_PLAY_RATE_REG,
+ FIFO_PLAY_RATE_MASK,
+ FIELD_PREP(FIFO_PLAY_RATE_MASK, eff->play_rate));
+ if (ret)
+ return ret;
+
+ /* Flush FIFO before loading new data */
+ ret = ptn_write(h, HAP_PTN_MEM_OP_ACCESS_REG, MEM_FLUSH_RELOAD_BIT);
+ if (ret)
+ return ret;
+ ret = ptn_write(h, HAP_PTN_MEM_OP_ACCESS_REG, 0);
+ if (ret)
+ return ret;
+
+ /* Write the initial chunk and initialise streaming state */
+ init_len = min_t(u32, eff->data_len, FIFO_INIT_FILL);
+ ret = haptics_write_fifo_chunk(h, eff->fifo_data, init_len);
+ if (ret)
+ return ret;
+
+ spin_lock_irqsave(&h->fifo_lock, flags);
+ h->fifo_data = eff->fifo_data;
+ h->data_len = eff->data_len;
+ h->data_written = init_len;
+ h->data_done = (init_len >= eff->data_len);
+ spin_unlock_irqrestore(&h->fifo_lock, flags);
+
+ /*
+ * Set empty threshold. When threshold > 0 the hardware fires the
+ * FIFO-empty interrupt when occupancy drops below the threshold,
+ * allowing the driver to refill. A threshold of 0 disables the IRQ.
+ */
+ ret = ptn_write(h, HAP_PTN_FIFO_EMPTY_CFG_REG, h->data_done ? 0 :
+ FIFO_EMPTY_THRESH / FIFO_THRESH_LSB);
+ if (ret)
+ return ret;
+ if (!h->data_done)
+ haptics_fifo_irq_enable(h, true);
+
+ return cfg_write(h, HAP_CFG_SPMI_PLAY_REG,
+ PLAY_EN_BIT | FIELD_PREP(PAT_SRC_MASK, PAT_SRC_FIFO));
+}
+
+/*
+ * Threaded IRQ handler for the FIFO-empty interrupt.
+ *
+ * While a FIFO play is in progress the hardware fires this interrupt when
+ * the number of samples in the FIFO drops below the programmed threshold.
+ * The handler refills the FIFO from the effect's data buffer. When all
+ * samples have been written the threshold is set to zero, which suppresses
+ * further interrupts; the hardware drains the remaining samples naturally
+ * and the play work handler stops the engine on the next invocation.
+ */
+static irqreturn_t haptics_fifo_empty_irq(int irq, void *dev_id)
+{
+ struct qcom_haptics *h = dev_id;
+ unsigned long flags;
+ u32 sts, to_write;
+ int ret;
+
+ ret = regmap_read(h->regmap,
+ h->cfg_base + HAP_CFG_INT_RT_STS_REG, &sts);
+ if (ret || !(sts & FIFO_EMPTY_BIT))
+ return IRQ_HANDLED;
+
+ spin_lock_irqsave(&h->fifo_lock, flags);
+
+ if (!h->fifo_data) {
+ spin_unlock_irqrestore(&h->fifo_lock, flags);
+ return IRQ_HANDLED;
+ }
+
+ if (h->data_done) {
+ ptn_write(h, HAP_PTN_FIFO_EMPTY_CFG_REG, 0);
+ h->fifo_data = NULL;
+ h->play_request = false;
+ schedule_work(&h->play_work);
+ spin_unlock_irqrestore(&h->fifo_lock, flags);
+ return IRQ_HANDLED;
+ }
+
+ /* Refill: write the next chunk, conservatively sized to the threshold */
+ to_write = min_t(u32, h->data_len - h->data_written,
+ h->fifo_len - FIFO_EMPTY_THRESH);
+ haptics_write_fifo_chunk(h, &h->fifo_data[h->data_written], to_write);
+ h->data_written += to_write;
+
+ if (h->data_written >= h->data_len) {
+ /* Last chunk enqueued; disable threshold to stop further IRQs */
+ h->data_done = true;
+ ptn_write(h, HAP_PTN_FIFO_EMPTY_CFG_REG, 0);
+ }
+
+ spin_unlock_irqrestore(&h->fifo_lock, flags);
+ return IRQ_HANDLED;
+}
+
+static void haptics_play_work(struct work_struct *work)
+{
+ struct qcom_haptics *h = container_of(work, struct qcom_haptics, play_work);
+ int id, ret;
+
+ mutex_lock(&h->play_lock);
+
+ if (!h->play_request) {
+ haptics_stop_locked(h);
+ if (h->pm_ref_held) {
+ pm_runtime_mark_last_busy(h->dev);
+ pm_runtime_put_autosuspend(h->dev);
+ h->pm_ref_held = false;
+ }
+ goto unlock;
+ }
+
+ ret = pm_runtime_resume_and_get(h->dev);
+ if (ret < 0) {
+ dev_err(h->dev, "failed to resume device: %d\n", ret);
+ goto unlock;
+ }
+ h->pm_ref_held = true;
+
+ id = h->cur_effect_id;
+
+ switch (h->effects[id].mode) {
+ case HAPTICS_DIRECT_PLAY:
+ ret = haptics_start_direct_play(h, id);
+ break;
+ case HAPTICS_FIFO:
+ ret = haptics_start_fifo(h, id);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ if (ret) {
+ dev_err(h->dev, "failed to start effect %d: %d\n", id, ret);
+ pm_runtime_put_autosuspend(h->dev);
+ h->pm_ref_held = false;
+ }
+
+unlock:
+ mutex_unlock(&h->play_lock);
+}
+
+static int haptics_upload_effect(struct input_dev *dev,
+ struct ff_effect *effect,
+ struct ff_effect *old)
+{
+ struct qcom_haptics *h = input_get_drvdata(dev);
+ struct qcom_haptics_effect *priv;
+ int id = effect->id;
+ s16 *buf;
+ u32 i;
+
+ if (id < 0 || id >= HAPTICS_MAX_EFFECTS)
+ return -EINVAL;
+
+ priv = &h->effects[id];
+
+ switch (effect->type) {
+ case FF_CONSTANT:
+ kfree(priv->fifo_data);
+ priv->fifo_data = NULL;
+ priv->data_len = 0;
+ priv->mode = HAPTICS_DIRECT_PLAY;
+ return 0;
+
+ case FF_PERIODIC:
+ if (effect->u.periodic.waveform != FF_CUSTOM)
+ return -EINVAL;
+ /*
+ * Minimum 3 elements: play-rate code + vmax + at least one sample.
+ * No upper bound: the FIFO is refilled continuously from the IRQ
+ * handler, so any length of PCM data is supported.
+ */
+ if (effect->u.periodic.custom_len < 3)
+ return -EINVAL;
+
+ buf = memdup_array_user(effect->u.periodic.custom_data,
+ effect->u.periodic.custom_len,
+ sizeof(s16));
+ if (IS_ERR(buf))
+ return PTR_ERR(buf);
+
+ if (buf[CUSTOM_DATA_RATE_IDX] > PLAY_RATE_MAX) {
+ kfree(buf);
+ return -EINVAL;
+ }
+
+ priv->play_rate = (u8)buf[CUSTOM_DATA_RATE_IDX];
+ priv->vmax_mv = (u32)clamp_val(buf[CUSTOM_DATA_VMAX_IDX], 0, VMAX_MV_MAX);
+ priv->data_len = effect->u.periodic.custom_len - CUSTOM_DATA_SAMPLE_START;
+
+ kfree(priv->fifo_data);
+ priv->fifo_data = kmalloc(priv->data_len, GFP_KERNEL);
+ if (!priv->fifo_data) {
+ kfree(buf);
+ return -ENOMEM;
+ }
+
+ /* Pack: one s8 sample per s16 slot (lower byte) */
+ for (i = 0; i < priv->data_len; i++)
+ priv->fifo_data[i] = (s8)buf[CUSTOM_DATA_SAMPLE_START + i];
+
+ kfree(buf);
+ priv->mode = HAPTICS_FIFO;
+ return 0;
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static int haptics_playback(struct input_dev *dev, int effect_id, int val)
+{
+ struct qcom_haptics *h = input_get_drvdata(dev);
+
+ h->cur_effect_id = effect_id;
+ h->play_request = (val > 0);
+ schedule_work(&h->play_work);
+ return 0;
+}
+
+static int haptics_erase(struct input_dev *dev, int effect_id)
+{
+ struct qcom_haptics *h = input_get_drvdata(dev);
+ struct qcom_haptics_effect *priv = &h->effects[effect_id];
+
+ kfree(priv->fifo_data);
+ priv->fifo_data = NULL;
+ priv->data_len = 0;
+ return 0;
+}
+
+static void haptics_set_gain(struct input_dev *dev, u16 gain)
+{
+ struct qcom_haptics *h = input_get_drvdata(dev);
+
+ h->gain = gain;
+}
+
+static int qcom_haptics_probe(struct platform_device *pdev)
+{
+ struct qcom_haptics *h;
+ struct input_dev *input;
+ struct ff_device *ff;
+ u32 regs[2];
+ int ret, irq;
+
+ h = devm_kzalloc(&pdev->dev, sizeof(*h), GFP_KERNEL);
+ if (!h)
+ return -ENOMEM;
+
+ h->dev = &pdev->dev;
+
+ h->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ if (!h->regmap)
+ return dev_err_probe(&pdev->dev, -ENODEV,
+ "no regmap from parent\n");
+
+ ret = device_property_read_u32_array(&pdev->dev, "reg", regs,
+ ARRAY_SIZE(regs));
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "failed to read 'reg' property\n");
+
+ h->cfg_base = regs[0];
+ h->ptn_base = regs[1];
+
+ ret = of_property_read_u32(h->dev->of_node, "qcom,lra-period-us",
+ &h->t_lra_us);
+ if (ret)
+ return dev_err_probe(h->dev, ret, "missing qcom,lra-period-us\n");
+
+ ret = of_property_read_u32(h->dev->of_node, "qcom,vmax-mv", &h->vmax_mv);
+ if (ret)
+ return dev_err_probe(h->dev, ret, "missing qcom,vmax-mv\n");
+
+ h->vmax_mv = clamp(h->vmax_mv, (u32)VMAX_STEP_MV, (u32)VMAX_MV_MAX);
+
+ ret = haptics_config_lra_period(h);
+ if (ret)
+ return ret;
+
+ ret = haptics_configure_autores(h);
+ if (ret)
+ return ret;
+
+ ret = haptics_set_vmax(h, h->vmax_mv);
+ if (ret)
+ return ret;
+
+ ret = haptics_configure_fifo_mmap(h);
+ if (ret)
+ return ret;
+
+ mutex_init(&h->play_lock);
+ spin_lock_init(&h->fifo_lock);
+ INIT_WORK(&h->play_work, haptics_play_work);
+ h->gain = 0xFFFF;
+
+ irq = platform_get_irq_byname(pdev, "fifo-empty");
+ if (irq < 0)
+ return dev_err_probe(&pdev->dev, irq,
+ "failed to get fifo-empty IRQ\n");
+
+ ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
+ haptics_fifo_empty_irq,
+ IRQF_ONESHOT,
+ "qcom-haptics-fifo-empty", h);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "failed to request fifo-empty IRQ\n");
+
+ h->fifo_empty_irq = irq;
+ disable_irq_nosync(irq);
+
+ input = devm_input_allocate_device(&pdev->dev);
+ if (!input)
+ return -ENOMEM;
+
+ input->name = "qcom-spmi-haptics";
+ input_set_drvdata(input, h);
+ h->input = input;
+
+ input_set_capability(input, EV_FF, FF_CONSTANT);
+ input_set_capability(input, EV_FF, FF_PERIODIC);
+ input_set_capability(input, EV_FF, FF_CUSTOM);
+ input_set_capability(input, EV_FF, FF_GAIN);
+
+ ret = input_ff_create(input, HAPTICS_MAX_EFFECTS);
+ if (ret)
+ return ret;
+
+ ff = input->ff;
+ ff->upload = haptics_upload_effect;
+ ff->playback = haptics_playback;
+ ff->erase = haptics_erase;
+ ff->set_gain = haptics_set_gain;
+
+ ret = input_register_device(input);
+ if (ret) {
+ input_ff_destroy(input);
+ return dev_err_probe(&pdev->dev, ret,
+ "failed to register input device\n");
+ }
+
+ platform_set_drvdata(pdev, h);
+
+ /*
+ * Grab a reference on behalf of probe (usage_count → 1), mark the
+ * device active, then enable runtime PM.
+ */
+ pm_runtime_get_noresume(&pdev->dev);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ pm_runtime_set_autosuspend_delay(&pdev->dev, HAPTICS_AUTOSUSPEND_MS);
+ devm_pm_runtime_set_active_enabled(&pdev->dev);
+ pm_runtime_put_autosuspend(&pdev->dev);
+
+ return 0;
+}
+
+static void qcom_haptics_remove(struct platform_device *pdev)
+{
+ struct qcom_haptics *h = platform_get_drvdata(pdev);
+
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+
+ cancel_work_sync(&h->play_work);
+ mutex_lock(&h->play_lock);
+ haptics_stop_locked(h);
+ haptics_enable_module(h, false);
+ mutex_unlock(&h->play_lock);
+
+ input_unregister_device(h->input);
+}
+
+static int qcom_haptics_runtime_suspend(struct device *dev)
+{
+ struct qcom_haptics *h = dev_get_drvdata(dev);
+
+ return haptics_enable_module(h, false);
+}
+
+static int qcom_haptics_runtime_resume(struct device *dev)
+{
+ struct qcom_haptics *h = dev_get_drvdata(dev);
+
+ return haptics_enable_module(h, true);
+}
+
+static int qcom_haptics_suspend(struct device *dev)
+{
+ struct qcom_haptics *h = dev_get_drvdata(dev);
+
+ cancel_work_sync(&h->play_work);
+ mutex_lock(&h->play_lock);
+ haptics_stop_locked(h);
+ if (h->pm_ref_held) {
+ pm_runtime_put_noidle(dev);
+ h->pm_ref_held = false;
+ }
+ mutex_unlock(&h->play_lock);
+ return pm_runtime_force_suspend(dev);
+}
+
+static int qcom_haptics_resume(struct device *dev)
+{
+ return pm_runtime_force_resume(dev);
+}
+
+static const struct dev_pm_ops qcom_haptics_pm_ops = {
+ SYSTEM_SLEEP_PM_OPS(qcom_haptics_suspend, qcom_haptics_resume)
+ RUNTIME_PM_OPS(qcom_haptics_runtime_suspend, qcom_haptics_runtime_resume,
+ NULL)
+};
+
+static const struct of_device_id qcom_haptics_of_match[] = {
+ { .compatible = "qcom,pmih010x-haptics" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, qcom_haptics_of_match);
+
+static struct platform_driver qcom_haptics_driver = {
+ .probe = qcom_haptics_probe,
+ .remove = qcom_haptics_remove,
+ .driver = {
+ .name = "qcom-spmi-haptics",
+ .of_match_table = qcom_haptics_of_match,
+ .pm = pm_ptr(&qcom_haptics_pm_ops),
+ },
+};
+module_platform_driver(qcom_haptics_driver);
+
+MODULE_DESCRIPTION("Qualcomm SPMI PMIC Haptics driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 09/12] i3c: dw-i3c-master: Add ACPI ID for Tegra410
From: sashiko-bot @ 2026-06-16 10:09 UTC (permalink / raw)
To: Akhil R; +Cc: linux-hwmon, robh, conor+dt, linux-i3c, Frank.Li, devicetree
In-Reply-To: <20260616095429.3947205-10-akhilrajeev@nvidia.com>
> Update variable names to generic names and add Tegra410 ACPI ID to
> support the I3C controller in Tegra410, which is a DesignWare I3C host
> controller.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=9
^ permalink raw reply
* Re: [PATCH v4 10/12] hwmon: spd5118: Remove 16-bit addressing
From: sashiko-bot @ 2026-06-16 10:09 UTC (permalink / raw)
To: Akhil R; +Cc: devicetree, Frank.Li, robh, linux-i3c, conor+dt, linux-hwmon
In-Reply-To: <20260616095429.3947205-11-akhilrajeev@nvidia.com>
> The intent of introducing 16-bit addressing was to support I3C, but it
> turns out that I3C does not require reading the Legacy Mode register,
> nor any specific encoding for page translation. The testing of 16-bit
> code was limited and there are no known users for this feature. Remove
> the sections that support 16-bit addressing and prepare the driver to
> support I3C appropriately.
>
> Suggested-by: Guenter Roeck <linux@roeck-us.net>
> Acked-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=10
^ permalink raw reply
* Re: [PATCH v4 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: sashiko-bot @ 2026-06-16 10:10 UTC (permalink / raw)
To: Akhil R; +Cc: linux-hwmon, linux-i3c, Frank.Li, robh, conor+dt, devicetree
In-Reply-To: <20260616095429.3947205-13-akhilrajeev@nvidia.com>
> Enable I3C subsystem (I3C), Synopsys DesignWare I3C master controller
> (DW_I3C_MASTER), and SPD5118 hwmon temperature sensor (SENSORS_SPD5118)
> as modules.
>
> The NVIDIA Vera CPU uses SOCAMM LPDDR5X memory module, which contains
> SPD5118 (JEDEC JESD300) compliant temperature sensor. This sensor is
> accessible over the I3C bus through the DesignWare I3C controller present
> on the SoC. Enabling these configs allows monitoring memory module
> temperatures on platforms such as Vera Rubin. Vera is an ACPI-based
> platform and does not use device tree.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=12
^ permalink raw reply
* Re: [PATCH 2/2] thermal: qcom: Add support for Qualcomm MBG thermal monitoring
From: Konrad Dybcio @ 2026-06-16 10:10 UTC (permalink / raw)
To: Sachin Gupta, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Stephen Boyd, Jishnu Prakash, Kamal Wadhwa,
Amit Kucheria, Thara Gopinath
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
Satya Priya Kakitapalli, Ajit Pandey, Imran Shaik, Taniya Das,
Jagadeesh Kona
In-Reply-To: <20260601-spmi-mbg-driver-v1-2-b4892b55a17f@oss.qualcomm.com>
On 6/1/26 1:01 PM, Sachin Gupta wrote:
> From: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
>
> Add driver for the Qualcomm MBG thermal monitoring device. It monitors
> the die temperature, and when there is a level 1 upper threshold
> violation, it receives an interrupt over spmi. The driver reads
> the fault status register and notifies thermal accordingly.
>
> Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
> Co-developed-by: Sachin Gupta <sachin.gupta@oss.qualcomm.com>
> Signed-off-by: Sachin Gupta <sachin.gupta@oss.qualcomm.com>
> ---
[...]
> +static const struct mbg_map_table map_table[] = {
> + /* minT vtemp0 tc */
The struct is defined 2 lines above, the reader can tell the names
of the fields
> + { -60000, 4337, 1967 },
> + { -40000, 4731, 1964 },
> + { -20000, 5124, 1957 },
> + { 0, 5515, 1949 },
> + { 20000, 5905, 1940 },
> + { 40000, 6293, 1930 },
> + { 60000, 6679, 1921 },
> + { 80000, 7064, 1910 },
> + { 100000, 7446, 1896 },
> + { 120000, 7825, 1878 },
> + { 140000, 8201, 1859 },
> +};
Please add a comment stating this map is not PMIC-specific
[...]
> + /* The HW has a limitation that the trip set must be above 25C */
> + if (temp > MBG_MIN_TRIP_TEMP && temp < MBG_MAX_SUPPORTED_TEMP) {
> + ret = regmap_set_bits(chip->map, chip->base + MBG_TEMP_MON2_MISC_CFG,
> + MON2_UP_THRESH_EN);
> + if (ret < 0)
> + return ret;
> +
> + ret = regmap_write(chip->map, chip->base + MON2_LVL1_UP_THRESH,
> + temp_to_vtemp_mv(temp));
> + if (ret < 0)
> + return ret;
> + } else {
> + dev_dbg(chip->dev, "Set trip b/w 25C and 160C\n");
Should this be an error print, returning an error condition?
> + ret = regmap_clear_bits(chip->map, chip->base + MBG_TEMP_MON2_MISC_CFG,
> + MON2_UP_THRESH_EN);
> + return ret;
> + }
> +
> + /*
> + * Configure the last_temp one degree higher, to ensure the
> + * violated temp is returned to thermal framework when it reads
> + * temperature for the first time after the violation happens.
> + * This is needed to account for the inaccuracy in the conversion
> + * formula used which leads to the thermal framework setting back
> + * the same thresholds in case the temperature it reads does not
> + * show violation.
> + */
> + chip->last_temp = temp + MBG_TEMP_CONSTANT;
Will this work fine if the user tries to set the max temp supported
by the hardware (i.e. is there headroom for max+1)?
> +
> + return ret;
> +}
> +
> +static const struct thermal_zone_device_ops mbg_tm_ops = {
> + .get_temp = mbg_tm_get_temp,
> + .set_trips = mbg_tm_set_trip_temp,
> +};
> +
> +static irqreturn_t mbg_tm_isr(int irq, void *data)
> +{
> + struct mbg_tm_chip *chip = data;
> + int ret, val;
> +
> + scoped_guard(mutex, &chip->lock) {
> + ret = regmap_read(chip->map, chip->base + MBG_TEMP_MON2_FAULT_STATUS, &val);
> + if (ret < 0)
> + return IRQ_HANDLED;
> + }
> +
> + if (FIELD_GET(MON_FAULT_STATUS_MASK, val) & MON_FAULT_LVL1_UPR) {
> + chip->last_thres_crossed = true;
> + dev_dbg(chip->dev, "Notifying Thermal, fault status=%d\n", val);
> + thermal_zone_device_update(chip->tz_dev, THERMAL_TRIP_VIOLATED);
Should the assignment and this call also be guarded by the mutex?
Konrad
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: input: Add binding for Qualcomm SPMI PMIC haptics
From: Konrad Dybcio @ 2026-06-16 10:11 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260616-qcom-spmi-haptics-v1-1-d24e422de6b4@oss.qualcomm.com>
On 6/16/26 12:08 PM, Fenglin Wu wrote:
> Add binding document for the haptics module inside Qualcomm PMIH010X.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
[...]
> + qcom,vmax-mv:
> + description:
> + Maximum allowed output driving voltage in millivolts, rounded to the
> + nearest 50 mV step. This is the peak driving voltage in DIRECT_PLAY mode
> + which outputs sinusoidal waveforms. The value should be equal to the square
> + root of 2 times the Vrms voltage of the LRA.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 50
> + maximum: 10000
multipleOf: 50?
Konrad
^ permalink raw reply
* Re: [PATCH v4 06/12] i3c: master: match I3C device through DT and ACPI
From: sashiko-bot @ 2026-06-16 10:12 UTC (permalink / raw)
To: Akhil R; +Cc: Frank.Li, linux-hwmon, robh, devicetree, linux-i3c, conor+dt
In-Reply-To: <20260616095429.3947205-7-akhilrajeev@nvidia.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] Lockless access to `i3cdev->desc` introduces a Time-of-Check to Time-of-Use (TOCTOU) race, Use-After-Free (UAF), and NULL pointer dereference when a device is concurrently matched and unregistered.
- [Medium] Missing OF and ACPI modalias generation in `i3c_device_uevent` breaks module autoloading for SETAASA-based I3C devices.
Pre-existing issues:
- [High] Matching logic reads uninitialized stack memory when i3cdev->desc is NULL.
--
commit 3dbcf3bf72698f3de90e327e59cfb2913ecd7503
Author: Akhil R <akhilrajeev@nvidia.com>
i3c: master: match I3C device through DT and ACPI
SETAASA-based devices cannot always be identified by PID or DCR; the
standard I3C id_table matching may not be applicable. Allow such devices
to be matched through Device Tree or ACPI.
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index bcc9c2d29c342..1bd545447b817 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[ ... ]
> @@ -345,15 +346,32 @@ static int i3c_device_match(struct device *dev, const struct device_driver *drv)
> {
> struct i3c_device *i3cdev;
> const struct i3c_driver *i3cdrv;
> + u8 static_addr_method = 0;
>
> if (dev->type != &i3c_device_type)
> return 0;
>
> i3cdev = dev_to_i3cdev(dev);
> i3cdrv = drv_to_i3cdrv(drv);
> - if (i3c_device_match_id(i3cdev, i3cdrv->id_table))
> +
> + if (i3cdev->desc && i3cdev->desc->boardinfo)
> + static_addr_method = i3cdev->desc->boardinfo->static_addr_method;
[Severity: High]
Can this lockless access to i3cdev->desc cause a Use-After-Free or NULL
pointer dereference?
If the I3C master is unbound or unregistered concurrently,
i3c_master_unregister_i3c_devs() sets i3cdev->dev->desc = NULL locklessly and
calls device_unregister().
Since i3c_device_match() is called from bus_for_each_dev() without taking the
device lock, if the thread is preempted between checking i3cdev->desc and
reading desc->boardinfo, desc could be freed by i3c_master_bus_cleanup(),
causing a Use-After-Free.
Alternatively, without READ_ONCE(), could the compiler reload i3cdev->desc as
NULL, causing a direct NULL pointer dereference?
> +
> + /*
> + * SETAASA-based devices need not always have a matching ID since
> + * it is not mandatory for such devices to implement deviceinfo
> + * CCC commands. Allow them to register through DT or ACPI.
> + */
> + if (i3cdrv->id_table && i3c_device_match_id(i3cdev, i3cdrv->id_table))
[Severity: High]
This is a pre-existing issue, but can i3c_device_match_id() operate on
uninitialized stack memory here?
If i3cdev->desc is NULL (which can happen concurrently during device teardown
via i3c_master_unregister_i3c_devs()), i3c_device_get_info() returns early
without modifying the devinfo output buffer:
drivers/i3c/device.c:i3c_device_match_id() {
struct i3c_device_info devinfo;
...
i3c_device_get_info(i3cdev, &devinfo);
manuf = I3C_PID_MANUF_ID(devinfo.pid);
...
}
This leaves devinfo uninitialized, causing the matching logic to extract
the manufacturer and part IDs from stack garbage.
> return 1;
>
> + if (static_addr_method & I3C_ADDR_METHOD_SETAASA) {
> + if (of_driver_match_device(dev, drv))
> + return 1;
> + if (acpi_driver_match_device(dev, drv))
> + return 1;
[Severity: Medium]
Since this patch enables Device Tree and ACPI matching, does the bus uevent
callback (i3c_device_uevent()) also need to generate OF and ACPI modaliases?
Without of_device_uevent_modalias() or acpi_device_uevent_modalias(), udev
cannot automatically load the driver based on the DT compatible string or ACPI
HID, which breaks module autoloading for SETAASA-based devices.
> + }
> +
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=6
^ permalink raw reply
* Re: [PATCH V13 8/9] iio: imu: inv_icm42607: Add Gyroscope to icm42607
From: Andy Shevchenko @ 2026-06-16 10:13 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
Chris Morgan
In-Reply-To: <20260615172554.160910-9-macroalpha82@gmail.com>
On Mon, Jun 15, 2026 at 12:25:51PM -0500, Chris Morgan wrote:
> Add gyroscope functions to the icm42607 driver.
...
> +int inv_icm42607_set_gyro_conf(struct inv_icm42607_state *st,
> + struct inv_icm42607_sensor_conf *conf,
> + unsigned int *sleep_ms)
> +{
> + struct inv_icm42607_sensor_conf *oldconf = &st->conf.gyro;
> + unsigned int val;
> + int ret;
> +
> + if (conf->mode < 0)
> + conf->mode = oldconf->mode;
> + if (conf->fs < 0)
> + conf->fs = oldconf->fs;
> + if (conf->odr < 0)
> + conf->odr = oldconf->odr;
> + if (conf->filter < 0)
> + conf->filter = oldconf->filter;
Same comment as per previous patch. But looking at this, can you rather have
a helper that answers the below two questions? Something like
void _assign_conf(..., bool *write_odr, bool *write_filter)
{
...
}
EXPORT_...
in the core driver? But wight both approaches and choose either existing one
(as in this patch series) or what I suggested.
> + if (conf->fs != oldconf->fs || conf->odr != oldconf->odr) {
> + val = FIELD_PREP(INV_ICM42607_GYRO_CONFIG0_FS_SEL_MASK,
> + conf->fs);
> + val |= FIELD_PREP(INV_ICM42607_GYRO_CONFIG0_ODR_MASK,
> + conf->odr);
> + ret = regmap_write(st->map, INV_ICM42607_REG_GYRO_CONFIG0, val);
> + if (ret)
> + return ret;
> + oldconf->fs = conf->fs;
> + oldconf->odr = conf->odr;
> + }
> +
> + if (conf->filter != oldconf->filter) {
> + val = FIELD_PREP(INV_ICM42607_GYRO_CONFIG1_FILTER_MASK,
> + conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_GYRO_CONFIG1,
> + INV_ICM42607_GYRO_CONFIG1_FILTER_MASK, val);
> + if (ret)
> + return ret;
> + oldconf->filter = conf->filter;
> + }
> +
> + return inv_icm42607_set_pwr_mgmt0(st, conf->mode, st->conf.accel.mode,
> + st->conf.temp_en, sleep_ms);
> +}
...
> +{
> + unsigned int odr;
> + unsigned int i;
> +
> + guard(mutex)(&st->lock);
> +
> + odr = st->conf.gyro.odr;
> +
> + for (i = 5; i < ARRAY_SIZE(inv_icm42607_gyro_odr); ++i) {
Same comment, why pre-increment?
> + if (i == odr)
> + break;
> + }
> + if (i >= ARRAY_SIZE(inv_icm42607_gyro_odr))
> + return -EINVAL;
> +
> + *val = inv_icm42607_gyro_odr[i][0];
> + *val2 = inv_icm42607_gyro_odr[i][1];
> +
> + return IIO_VAL_INT_PLUS_MICRO;
> +}
> +
> +static int inv_icm42607_gyro_write_odr(struct iio_dev *indio_dev,
> + int val, int val2)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int idx;
> + struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
> + int ret;
> +
> + for (idx = 5; idx < ARRAY_SIZE(inv_icm42607_gyro_odr); ++idx) {
Ditto.
> + if (val == inv_icm42607_gyro_odr[idx][0] &&
> + val2 == inv_icm42607_gyro_odr[idx][1])
> + break;
> + }
> + if (idx >= ARRAY_SIZE(inv_icm42607_gyro_odr))
> + return -EINVAL;
> +
> + conf.odr = idx;
> +
> + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> + ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> + if (ret)
> + return ret;
> +
> + guard(mutex)(&st->lock);
> +
> + return inv_icm42607_set_gyro_conf(st, &conf, NULL);
> +}
Can be some of the code deduplicated between gyro and accel?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 07/12] i3c: dw-i3c-master: Add SETAASA as supported CCC
From: sashiko-bot @ 2026-06-16 10:13 UTC (permalink / raw)
To: Akhil R; +Cc: Frank.Li, conor+dt, robh, linux-hwmon, linux-i3c, devicetree
In-Reply-To: <20260616095429.3947205-8-akhilrajeev@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Hardware registers are accessed before runtime PM is resumed, potentially causing a bus fault.
--
commit 0dd3a1716725800c8f7459a7e2204416a4488acf
Author: Akhil R <akhilrajeev@nvidia.com>
i3c: dw-i3c-master: Add SETAASA as supported CCC
This commit adds SETAASA and SETHID to the supported list of CCC commands for
the DesignWare I3C host controller. SETAASA assigns predefined static
addresses to all devices on the bus, and SETHID stops HID bit flipping as a
prerequisite.
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index 971b429b76bc8..3e510fddf06c5 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
> @@ -309,6 +309,8 @@ static bool dw_i3c_master_supports_ccc_cmd(struct i3c_master_controller *m,
> case I3C_CCC_GETSTATUS:
> case I3C_CCC_GETMXDS:
> case I3C_CCC_GETHDRCAP:
> + case I3C_CCC_SETAASA:
> + case I3C_CCC_VENDOR(0, true): /* SETHID */
> return true;
> default:
> return false;
[ ... ]
> static int dw_i3c_master_send_ccc_cmd(struct i3c_master_controller *m,
> struct i3c_ccc_cmd *ccc)
> {
> struct dw_i3c_master *master = to_dw_i3c_master(m);
> int ret = 0;
>
> if (ccc->id == I3C_CCC_ENTDAA)
> return -EINVAL;
>
> /* AMD platform specific OD and PP timings */
> if (master->quirks & AMD_I3C_OD_PP_TIMING) {
> amd_configure_od_pp_quirk(master);
> writel(master->i3c_pp_timing, master->regs + SCL_I3C_PP_TIMING);
> writel(master->i3c_od_timing, master->regs + SCL_I3C_OD_TIMING);
> }
>
> ret = pm_runtime_resume_and_get(master->dev);
[Severity: High]
This is a pre-existing issue, but could accessing these hardware registers
before runtime PM is resumed cause a bus fault?
If the device is runtime-suspended, its clocks and power domains are disabled.
Accessing memory-mapped registers of a clock-gated device here might lead to
an asynchronous bus error or a system hang.
Should the register writes be moved after pm_runtime_resume_and_get()
completes successfully?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=7
^ permalink raw reply
* Re: [PATCH v4 08/12] i3c: dw-i3c-master: Add a quirk to skip clock and reset
From: sashiko-bot @ 2026-06-16 10:14 UTC (permalink / raw)
To: Akhil R; +Cc: devicetree, Frank.Li, linux-i3c, linux-hwmon, robh, conor+dt
In-Reply-To: <20260616095429.3947205-9-akhilrajeev@nvidia.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Type confusion when an ACPI device binds via PRP0001, causing memory addresses to be cast to hardware quirk flags.
- [High] Double disable of clocks during driver unbind if the device is runtime suspended.
--
commit 40ac6ebf3eb6f03540ce6b0b57bfd00730536f5d
Author: Akhil R <akhilrajeev@nvidia.com>
i3c: dw-i3c-master: Add a quirk to skip clock and reset
Some ACPI-enumerated devices like Tegra410 do not have clock and reset
resources exposed via the clk/reset frameworks. Unlike device tree,
ACPI on Arm does not model such provider functions.
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index 3e510fddf06c5..a2a4b88c20177 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
[ ... ]
> @@ -1577,18 +1593,33 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
> if (IS_ERR(master->regs))
> return PTR_ERR(master->regs);
>
> - master->core_clk = devm_clk_get_enabled(&pdev->dev, NULL);
> - if (IS_ERR(master->core_clk))
> - return PTR_ERR(master->core_clk);
> -
> - master->pclk = devm_clk_get_optional_enabled(&pdev->dev, "pclk");
> - if (IS_ERR(master->pclk))
> - return PTR_ERR(master->pclk);
> + if (has_acpi_companion(&pdev->dev)) {
> + quirks = (unsigned long)device_get_match_data(&pdev->dev);
[Severity: High]
This is a pre-existing issue, but can this cast cause a type confusion if an
ACPI device uses the PRP0001 HID to bind via OF-style matching?
In that scenario, has_acpi_companion() evaluates to true, but
device_get_match_data() returns a pointer to the OF match data (like struct
dw_i3c_drvdata). Casting this pointer directly to an unsigned long would
interpret the memory address as a quirk bitmask, potentially enabling quirks
randomly depending on the kernel's memory layout.
> + } else if (pdev->dev.of_node) {
> + drvdata = device_get_match_data(&pdev->dev);
> + if (drvdata)
> + quirks = drvdata->flags;
> + }
> + master->quirks = quirks;
>
> - master->core_rst = devm_reset_control_get_optional_exclusive_deasserted(&pdev->dev,
> - "core_rst");
> - if (IS_ERR(master->core_rst))
> - return PTR_ERR(master->core_rst);
> + if (master->quirks & DW_I3C_ACPI_SKIP_CLK_RST) {
> + master->core_clk = NULL;
> + master->pclk = NULL;
> + master->core_rst = NULL;
> + } else {
> + master->core_clk = devm_clk_get_enabled(&pdev->dev, NULL);
[Severity: High]
This is a pre-existing issue, but does using devm_clk_get_enabled() risk a
double-disable during driver unbind if the device is runtime suspended?
If the device is in the RPM_SUSPENDED state when dw_i3c_common_remove() runs,
the clock has already been disabled by the runtime_suspend callback. Because
the remove function calls pm_runtime_disable() without first waking the
device up via pm_runtime_get_sync(), the subsequent automatic devres cleanup
will call clk_disable_unprepare() a second time on the already disabled clock.
> + if (IS_ERR(master->core_clk))
> + return PTR_ERR(master->core_clk);
> +
> + master->pclk = devm_clk_get_optional_enabled(&pdev->dev, "pclk");
> + if (IS_ERR(master->pclk))
> + return PTR_ERR(master->pclk);
> +
> + master->core_rst = devm_reset_control_get_optional_exclusive_deasserted(&pdev->dev,
> + "core_rst");
> + if (IS_ERR(master->core_rst))
> + return PTR_ERR(master->core_rst);
> + }
>
> spin_lock_init(&master->xferqueue.lock);
> INIT_LIST_HEAD(&master->xferqueue.list);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=8
^ permalink raw reply
* Re: [PATCH v4 03/12] i3c: master: Support ACPI enumeration of child devices
From: sashiko-bot @ 2026-06-16 10:15 UTC (permalink / raw)
To: Akhil R; +Cc: linux-hwmon, conor+dt, linux-i3c, Frank.Li, devicetree, robh
In-Reply-To: <20260616095429.3947205-4-akhilrajeev@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] devm_kzalloc allocated 'boardinfo' is leaked for every ACPI child node that is ignored because it lacks I2C/I3C resources.
--
commit 9a388c2056a553d628ce4b8b623a812d4aa08951
Author: Akhil R <akhilrajeev@nvidia.com>
i3c: master: Support ACPI enumeration of child devices
This commit adds support for describing I3C and I2C devices via ACPI tables,
rather than relying solely on the device tree reg property. It implements
reading _ADR and LVR properties from ACPI resources to retrieve the static
address and other device properties.
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index 3b19a5e8f46d0..f0e05bcac26da 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[ ... ]
> @@ -2708,6 +2762,74 @@ static int i3c_master_add_dev(struct i3c_master_controller *master,
> return ret;
> }
>
> +#ifdef CONFIG_ACPI
> +static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
> + struct fwnode_handle *fwnode)
> +{
> + struct acpi_device *adev = to_acpi_device_node(fwnode);
> + acpi_bus_address adr;
> + u32 reg[3] = { 0 };
> + int ret;
> +
> + /*
> + * If the ACPI table entry has _ADR method, it's an I3C device.
> + * Otherwise it may be an I2C device described by an I2cSerialBus
> + * resource. If no I2cSerialBus resource is found, ignore the entry.
> + */
> + if (!acpi_has_method(adev->handle, "_ADR")) {
> + ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
> + if (ret == -ENODEV)
> + return 0;
[Severity: Medium]
Does this leak the boardinfo allocated in i3c_master_add_i2c_boardinfo()?
If an ACPI child lacks an _ADR method, i3c_master_add_i2c_boardinfo()
unconditionally allocates boardinfo using devm_kzalloc().
If the node also lacks an I2cSerialBus resource, i3c_acpi_add_i2c_boardinfo()
returns -ENODEV. This causes i3c_master_add_i2c_boardinfo() to return -ENODEV
without freeing the allocated boardinfo.
Because we catch -ENODEV here and return 0, the overall bus probe continues
and ultimately succeeds. This means the devres-allocated memory stays tied
to the master device, leaking sizeof(struct i2c_dev_boardinfo) for every
ignored ACPI child node.
> +
> + return ret;
> + }
> +
> + adr = acpi_device_adr(adev);
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=3
^ permalink raw reply
* Re: [PATCH v4 02/12] i3c: master: Use unified device property interface
From: sashiko-bot @ 2026-06-16 10:17 UTC (permalink / raw)
To: Akhil R; +Cc: devicetree, Frank.Li, linux-i3c, conor+dt, robh, linux-hwmon
In-Reply-To: <20260616095429.3947205-3-akhilrajeev@nvidia.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Permanent leak of firmware node references in I2C and I3C boardinfo structures.
Pre-existing issues:
- [High] Dangling pointer `desc->dev` causes Use-After-Free on device unregistration if device_register() fails.
--
commit 89419216775e33fb2b850943aa4a2781f19278a1
Author: Akhil R <akhilrajeev@nvidia.com>
i3c: master: Use unified device property interface
Replace all OF-specific functions with unified device property functions
as a prerequisite to support both ACPI and device tree.
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index 109aa50eb1f8f..3b19a5e8f46d0 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[ ... ]
> @@ -1902,7 +1904,8 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
> desc->info.pid);
>
> if (desc->boardinfo)
> - desc->dev->dev.of_node = desc->boardinfo->of_node;
> + device_set_node(&desc->dev->dev,
> + fwnode_handle_get(desc->boardinfo->fwnode));
>
> ret = device_register(&desc->dev->dev);
> if (ret) {
[Severity: High]
This is a pre-existing issue, but can this error path cause a use-after-free
and double-free?
If device_register() fails, put_device() is called which frees the memory
backing desc->dev, but the desc->dev pointer is not set to NULL.
Later during cleanup, the dangling pointer bypasses the NULL check:
i3c_master_unregister_i3c_devs() {
...
if (!i3cdev->dev)
continue;
i3cdev->dev->desc = NULL;
...
}
Does desc->dev need to be set to NULL after put_device() to prevent this?
[ ... ]
> @@ -2623,14 +2630,14 @@ of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
> boardinfo->lvr = reg[2];
>
> list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
> - of_node_get(node);
> + fwnode_handle_get(fwnode);
>
> return 0;
> }
[Severity: Medium]
Does this code leak the fwnode reference?
The result of fwnode_handle_get() is completely discarded. Since
i2c_new_client_device() separately takes and drops its own fwnode reference,
does this initial reference remain unreleased?
[ ... ]
> @@ -2670,14 +2677,14 @@ of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
> return -EINVAL;
>
> boardinfo->init_dyn_addr = init_dyn_addr;
> - boardinfo->of_node = of_node_get(node);
> + boardinfo->fwnode = fwnode_handle_get(fwnode);
> list_add_tail(&boardinfo->node, &master->boardinfo.i3c);
>
> return 0;
> }
[Severity: Medium]
Does this also leak the fwnode reference?
The reference is acquired and stored in the devres-managed boardinfo
structure, but there seems to be no teardown logic for the master->boardinfo
lists to drop it before devres frees them.
As seen earlier in i3c_master_register_new_i3c_devs():
device_set_node(&desc->dev->dev, fwnode_handle_get(desc->boardinfo->fwnode));
A second reference is taken there which is properly dropped by
i3c_device_release(), but does the first reference stored in
boardinfo->fwnode remain stranded?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=2
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: mfd: qcom,spmi-pmic: Document haptics device
From: sashiko-bot @ 2026-06-16 10:17 UTC (permalink / raw)
To: Fenglin Wu; +Cc: conor+dt, robh, linux-input, dmitry.torokhov, devicetree
In-Reply-To: <20260616-qcom-spmi-haptics-v1-2-d24e422de6b4@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Use of a wildcard ('x') in the compatible string.
--
commit 24bf9f2257f4052d27a53163621c8f5173fe1da8
Author: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
dt-bindings: input: Add binding for Qualcomm SPMI PMIC haptics
Add binding document for the haptics module inside Qualcomm PMIH010X.
> diff --git a/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml b/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml
> new file mode 100644
> index 0000000000000..0e26d68563dcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml
> @@ -0,0 +1,119 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
[ ... ]
> +properties:
> + compatible:
> + const: qcom,pmih010x-haptics
[Severity: Low]
Does this introduce a regression by using a wildcard character ('x') in the
compatible string?
Device tree specifications generally forbid wildcards in compatible strings.
Should the specific model name of the first chip in the family
(e.g., "qcom,pmih0108-haptics") be used instead of a wildcard?
[ ... ]
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + pmic {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + haptics@f000 {
> + compatible = "qcom,pmih010x-haptics";
[Severity: Low]
Does this example share the same regression with the wildcard compatible
string?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-qcom-spmi-haptics-v1-0-d24e422de6b4@oss.qualcomm.com?part=2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox