[PATCH 0/2] mfd: qcom-pm8008: support PMICs with no interrupt line

The camera PMIC on the Lenovo Yoga Slim 7x Gen 11 (Qualcomm Snapdragon X2
Elite, glymur) has no interrupt line routed on the board. That is not a
wiring omission - the part has no INT pin brought out in this design, and
the sensor resets are driven from TLMM instead.

The part is a PM8010; this board describes it with the qcom,pm8008
compatible, which is what binds the driver touched here.

qcom-pm8008 currently requires an interrupt: the binding marks it required
and the driver fails probe without one, so the PMIC cannot be described at
all on such a board even though everything it provides - the regulators -
works fine without interrupts.

Patch 1 relaxes the binding, patch 2 makes the driver treat the interrupt
as optional and skip the regmap-irq chip when it is absent. Boards that do
wire the interrupt are unaffected.

Tested on a Lenovo Yoga Slim 7x Gen 11 (DMI 83QR, "Yoga Slim 7 14Q8Y11"),
where this PMIC powers an OV08X40 sensor.

The DT change that describes this PMIC is not part of this series; it lands
with the board DTS, which is being upstreamed separately.

Oleg Keri (2):
  dt-bindings: mfd: qcom,pm8008: make the interrupt line optional
  mfd: qcom-pm8008: support PMICs with no interrupt line

 .../devicetree/bindings/mfd/qcom,pm8008.yaml  |  7 +--
 drivers/mfd/qcom-pm8008.c                     | 52 ++++++++++++-------
 2 files changed, 38 insertions(+), 21 deletions(-)

-- 
2.55.0

base-commit: df2908090cda368b01ff43709f51890076c56157

The PM8008 raises an interrupt for its own status, its temperature alarm
and its two GPIOs, but the pin does not have to be routed. On the Lenovo
Yoga Slim 7x Gen 11 it is not: the platform firmware describes the PMIC
with an I2C connection and nothing else, and the vendor driver talks to it
purely over I2C.

Drop interrupts from the required list, along with interrupt-controller
and #interrupt-cells, which cannot work without it. Add a dependency so
that a node claiming to be an interrupt controller still has to say where
its own interrupt comes from.

Signed-off-by: Oleg Keri <redacted>
---
 Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml
index 0c6e1870db1d..db1592e115e8 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml

@@ -88,7 +88,6 @@ properties:
 required:
   - compatible
   - reg
-  - interrupts
   - vdd-l1-l2-supply
   - vdd-l3-l4-supply
   - vdd-l5-supply

@@ -97,10 +96,12 @@ required:
   - gpio-controller
   - "#gpio-cells"
   - gpio-ranges
-  - interrupt-controller
-  - "#interrupt-cells"
   - "#thermal-sensor-cells"
 
+dependentRequired:
+  interrupt-controller: [ interrupts ]
+  "#interrupt-cells": [ interrupts ]
+
 additionalProperties: false
 
 examples:

-- 
2.55.0

The interrupt is only needed for the temperature alarm and the two GPIOs.
Where the pin is not routed the regulators are still perfectly usable, but
probe fails: client->irq is 0 and request_threaded_irq() rejects it.

Skip the IRQ chip in that case and register the regulator cell alone. The
temperature alarm cannot be registered without a domain either, because
its IORESOURCE_IRQ would be handed to the platform device as a raw number
rather than being mapped, and the GPIO cell needs the domain for the same
reason.

Signed-off-by: Oleg Keri <redacted>
---
 drivers/mfd/qcom-pm8008.c | 63 +++++++++++++++++++++++++--------------
 1 file changed, 40 insertions(+), 23 deletions(-)

diff --git a/drivers/mfd/qcom-pm8008.c b/drivers/mfd/qcom-pm8008.c
index 60204cc9a2dc..b51a9657ee56 100644
--- a/drivers/mfd/qcom-pm8008.c
+++ b/drivers/mfd/qcom-pm8008.c

@@ -183,6 +183,10 @@ static const struct mfd_cell pm8008_cells[] = {
 	MFD_CELL_NAME("pm8008-gpio"),
 };
 
+static const struct mfd_cell pm8008_regulator_cells[] = {
+	MFD_CELL_NAME("pm8008-regulator"),
+};
+
 static void devm_irq_domain_fwnode_release(void *data)
 {
 	struct fwnode_handle *fwnode = data;

@@ -195,9 +199,12 @@ static int pm8008_probe(struct i2c_client *client)
 	struct regmap_irq_chip_data *irq_data;
 	struct device *dev = &client->dev;
 	struct regmap *regmap, *regmap2;
+	const struct mfd_cell *cells;
 	struct fwnode_handle *fwnode;
+	struct irq_domain *domain;
 	struct i2c_client *dummy;
 	struct gpio_desc *reset;
+	int num_cells;
 	char *name;
 	int ret;
 

@@ -231,33 +238,43 @@ static int pm8008_probe(struct i2c_client *client)
 	 */
 	usleep_range(1000, 2000);
 
-	name = devm_kasprintf(dev, GFP_KERNEL, "%pOF-internal", dev->of_node);
-	if (!name)
-		return -ENOMEM;
-
-	name = strreplace(name, '/', ':');
-
-	fwnode = irq_domain_alloc_named_fwnode(name);
-	if (!fwnode)
-		return -ENOMEM;
-
-	ret = devm_add_action_or_reset(dev, devm_irq_domain_fwnode_release, fwnode);
-	if (ret)
-		return ret;
-
-	ret = devm_regmap_add_irq_chip_fwnode(dev, fwnode, regmap, client->irq,
-				IRQF_SHARED, 0, &pm8008_irq_chip, &irq_data);
-	if (ret) {
-		dev_err(dev, "failed to add IRQ chip: %d\n", ret);
-		return ret;
+	if (client->irq > 0) {
+		name = devm_kasprintf(dev, GFP_KERNEL, "%pOF-internal", dev->of_node);
+		if (!name)
+			return -ENOMEM;
+
+		name = strreplace(name, '/', ':');
+
+		fwnode = irq_domain_alloc_named_fwnode(name);
+		if (!fwnode)
+			return -ENOMEM;
+
+		ret = devm_add_action_or_reset(dev, devm_irq_domain_fwnode_release, fwnode);
+		if (ret)
+			return ret;
+
+		ret = devm_regmap_add_irq_chip_fwnode(dev, fwnode, regmap,
+						      client->irq, IRQF_SHARED, 0,
+						      &pm8008_irq_chip, &irq_data);
+		if (ret) {
+			dev_err(dev, "failed to add IRQ chip: %d\n", ret);
+			return ret;
+		}
+
+		domain = regmap_irq_get_domain(irq_data);
+		cells = pm8008_cells;
+		num_cells = ARRAY_SIZE(pm8008_cells);
+	} else {
+		domain = NULL;
+		cells = pm8008_regulator_cells;
+		num_cells = ARRAY_SIZE(pm8008_regulator_cells);
 	}
 
 	/* Needed by GPIO driver. */
-	dev_set_drvdata(dev, regmap_irq_get_domain(irq_data));
+	dev_set_drvdata(dev, domain);
 
-	return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, pm8008_cells,
-				ARRAY_SIZE(pm8008_cells), NULL, 0,
-				regmap_irq_get_domain(irq_data));
+	return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, cells,
+				num_cells, NULL, 0, domain);
 }
 
 static const struct of_device_id pm8008_match[] = {

-- 
2.55.0

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The commit message description is not capitalized, violating MFD subsystem guidelines.
--

commit 18efba6bffe886fb1172493d0880293e52f677a5
Author: Oleg Keri [off-list ref]

mfd: qcom-pm8008: support PMICs with no interrupt line

This commit updates the qcom-pm8008 driver to allow probing PMICs without an
interrupt line. It skips IRQ chip registration if the interrupt is absent and
registers only the regulator cell, since the temperature alarm and GPIO cells
require an IRQ domain.

mfd: qcom-pm8008: support PMICs with no interrupt line

[Severity: Low]
This isn't a bug, but does this commit message subject line follow the MFD
subsystem formatting guidelines? The documentation requires capitalizing the
description after the subsystem prefix, so "support" should likely be changed
to "Support".

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908130745.2545-1-okerixx@gmail.com?part=2

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing mutual dependency between `interrupt-controller` and `#interrupt-cells` allows incomplete device tree nodes to pass schema validation.
--

commit 06521a0a86f05dc0e7f24260abb779ba95c5ab55
Author: Oleg Keri [off-list ref]

dt-bindings: mfd: qcom,pm8008: make the interrupt line optional

The PM8008 raises an interrupt for its own status, its temperature alarm
and its two GPIOs, but the pin does not have to be routed. This commit drops
interrupts, interrupt-controller, and #interrupt-cells from the required list
and adds dependentRequired constraints.

[ ... ]

[Severity: Medium]
Does this regression allow incomplete device tree nodes to pass schema
validation?

The missing mutual dependency between interrupt-controller and
#interrupt-cells means a device tree node could provide interrupt-controller
but omit #interrupt-cells (or vice versa) and still pass validation.

Such a node would fail to function correctly at runtime as an interrupt
provider. Should these two properties be required together?

 additionalProperties: false
 
 examples:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908130745.2545-1-okerixx@gmail.com?part=1

Please drop this series.

It duplicates, as a strict subset, work that was already on the list a day
before I posted:

  [v2,3/6] dt-bindings: mfd: pm8008: Add PM8010 I2C support
  [v2,5/6] mfd: qcom-pm8008: Add support for PM8010 PMIC
  https://lore.kernel.org/all/20260907-glymur_camss-v2-0-75f7982dc983@oss.qualcomm.com/

Nihal's 3/6 relaxes the same required: entries mine does and more, and adds
the qcom,pm8010-i2c compatible; his 5/6 already carries the no-interrupt
path my 2/2 was adding:

  static const struct mfd_cell pm8008_no_irq_cells[] = {
          MFD_CELL_NAME("pm8008-regulator"),
  };

on top of a PM8010 IRQ chip, match data and a pm8010-regulator cell. There
is nothing in my series that his does not do better. My apologies for the
noise - I should have searched the list before posting.

Nihal, if it is useful: the Lenovo Yoga Slim 7x Gen 11 (glymur, DMI 83QR)
has a PM8010 whose INT pin is genuinely not routed on the board, so it
exercises your no-IRQ path rather than being a DT omission. I have been
running an equivalent no-IRQ path there since 2026-08-25 - the LDOs
register and the OV08X40 works - and I am happy to test your series on it
and send a Tested-by once I have actually run it.

Your 6/6 also shows that describing a PM8010 as "qcom,pm8008", which is
what I do today, silently programs the wrong voltage ranges. On that board
the sensor takes dovdd from ldo4 at 1.8 V, and:

  pm8008_pldo_ranges    1504000 + 8000 * n   ->  1.8 V is selector 37
  pm8010_pldo_lv_ranges 1800000 + 200000 * n ->  1.8 V is selector 0

so the same regulator-min/max-microvolt lands on a completely different
register value depending on which compatible the node carries. ldo3 and
ldo6 have the same split. ldo2 and ldo7 happen to map identically because
the nldo and pldo ranges share a base and step and differ only in their
upper bound.

The camera works on my board today despite this, which I would treat as
luck rather than evidence that it is harmless. It does mean your series
fixes a latent bug for boards already describing a PM8010 as qcom,pm8008,
not merely adding a new compatible - worth a line in 6/6 if you respin,
since those boards need the DT change and the driver change together.

Hi Oleg,

On 9/8/2026 7:10 PM, Oleg Keri wrote:

Please drop this series.

It duplicates, as a strict subset, work that was already on the list a day
before I posted:

  [v2,3/6] dt-bindings: mfd: pm8008: Add PM8010 I2C support
  [v2,5/6] mfd: qcom-pm8008: Add support for PM8010 PMIC
  https://lore.kernel.org/all/20260907-glymur_camss-v2-0-75f7982dc983@oss.qualcomm.com/

Nihal's 3/6 relaxes the same required: entries mine does and more, and adds
the qcom,pm8010-i2c compatible; his 5/6 already carries the no-interrupt
path my 2/2 was adding:

  static const struct mfd_cell pm8008_no_irq_cells[] = {
          MFD_CELL_NAME("pm8008-regulator"),
  };

on top of a PM8010 IRQ chip, match data and a pm8010-regulator cell. There
is nothing in my series that his does not do better. My apologies for the
noise - I should have searched the list before posting.

Nihal, if it is useful: the Lenovo Yoga Slim 7x Gen 11 (glymur, DMI 83QR)
has a PM8010 whose INT pin is genuinely not routed on the board, so it
exercises your no-IRQ path rather than being a DT omission. I have been
running an equivalent no-IRQ path there since 2026-08-25 - the LDOs
register and the OV08X40 works - and I am happy to test your series on it
and send a Tested-by once I have actually run it.

Thanks, we would appreciate this. Please note Mark has asked us to split the existing
series, so we would be sending out separate patch series soon for CAMSS support
and PM8010 support.

Your 6/6 also shows that describing a PM8010 as "qcom,pm8008", which is
what I do today, silently programs the wrong voltage ranges. On that board
the sensor takes dovdd from ldo4 at 1.8 V, and:

  pm8008_pldo_ranges    1504000 + 8000 * n   ->  1.8 V is selector 37
  pm8010_pldo_lv_ranges 1800000 + 200000 * n ->  1.8 V is selector 0

so the same regulator-min/max-microvolt lands on a completely different
register value depending on which compatible the node carries. ldo3 and
ldo6 have the same split. ldo2 and ldo7 happen to map identically because
the nldo and pldo ranges share a base and step and differ only in their
upper bound.

The camera works on my board today despite this, which I would treat as
luck rather than evidence that it is harmless. It does mean your series
fixes a latent bug for boards already describing a PM8010 as qcom,pm8008,

Just asking, have you noticed any boards doing this currently ?

Thanks,
Jishnu

not merely adding a new compatible - worth a line in 6/6 if you respin,
since those boards need the DT change and the driver change together.

On 9/10/26 11:10 AM, Jishnu Prakash wrote:

Hi Oleg,

On 9/8/2026 7:10 PM, Oleg Keri wrote:

quoted

Please drop this series.

It duplicates, as a strict subset, work that was already on the list a day
before I posted:

[...]

quoted

The camera works on my board today despite this, which I would treat as
luck rather than evidence that it is harmless. It does mean your series
fixes a latent bug for boards already describing a PM8010 as qcom,pm8008,

Just asking, have you noticed any boards doing this currently ?

Not upstream, I don't think:

$ rg qcom,pm8008 arch -l                                                                                                                                                               
arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts

Konrad

On Thu, 10 Sep 2026 14:40:35 +0530
Jishnu Prakash [off-list ref] wrote:

Please note Mark has asked us to split the existing series, so we would
be sending out separate patch series soon for CAMSS support and PM8010
support.

Great, I'll test the PM8010 one as soon as it's out.

Just asking, have you noticed any boards doing this currently ?

Only mine, and it's not upstream yet. Konrad's list is right - those are
all real PM8008s.

One correction to my earlier mail: the compatible does not change what
gets written to the rail. set_voltage_sel() writes millivolts, so 1.8 V
is 1800 in VSET either way. The wrong compatible only misdescribes the
LDO's range to the regulator core. Sorry for overstating it.

Thanks,
Oleg