Add driver for TI BQ25630 charger

Documentation/devicetree/bindings/power/supply/bq25630.yaml new file +45 -0

@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/bq25630.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI BQ25630 battery charger
+
+maintainers:
+  - Waqar Hameed <[email protected]>
+
+description: |
+  I2C controlled single cell Li-ion and Li-polymer 5A buck charger.
+  Datasheet: https://www.ti.com/lit/gpn/bq25630
+
+allOf:
+  - $ref: power-supply.yaml#
+
+properties:
+  compatible:
+    const: ti,bq25630
+
+  reg:
+    const: 0x6b
+    description:
+      Device I2C address.
+
+  interrupts:
+    maxItems: 1
+    description: |
+      Device sends active low 256 µs pulse. Type should therefore be
+      IRQ_TYPE_EDGE_FALLING.
+
+  monitored-battery: true
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - monitored-battery
+
+additionalProperties: false
+
+examples:
+  - |

Documentation/devicetree/bindings/power/supply/bq25630.yaml new file +13 -0

+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        charger@6b {
+            compatible = "ti,bq25630";
+            reg = <0x6b>;
+            interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+            monitored-battery = <&bat>;
+        };
+    };
+...

Signature · 1 line

2.39.5

Quoted 9 lines · Waqar Hameed

Add devicetree bindings for the TI BQ25630 battery charger. It's I2C controlled and sends interrupts.

Signed-off-by Waqar Hameed <[email protected]>

---
 .../bindings/power/supply/bq25630.yaml        | 68 +++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/supply/bq25630.yaml

Documentation/devicetree/bindings/power/supply/bq25630.yaml

Quoted 5 lines

Documentation/devicetree/bindings/power/supply/bq25630.yaml new file +0 -0

new file mode 100644
index 0000000000000..57e4286dac7e9

Filename is missing "ti," to match the compatible.

Quoted 6 lines

Documentation/devicetree/bindings/power/supply/bq25630.yaml new file +6 -0

+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    bat: battery {
+        compatible = "simple-battery";

Documentation/devicetree/bindings/power/supply/bq25630.yaml line 55

Quoted 6 lines

Documentation/devicetree/bindings/power/supply/bq25630.yaml new file +6 -0

+        voltage-min-design-microvolt = <1800000>;
+        constant-charge-current-max-microamp = <1344000>;
+        constant-charge-voltage-max-microvolt = <3700000>;
+        charge-term-current-microamp = <128000>;
+        precharge-current-microamp = <1000000>;
+    };

This whole battery node can go,

the tooling will falsify the phandle.

Quoted 10 lines · On Fri, Feb 27, 2026 at 17:31 +0000 Conor Dooley <[email protected]> wrote:

Quoted 9 lines · Waqar Hameed

Add devicetree bindings for the TI BQ25630 battery charger. It's I2C controlled and sends interrupts.

Signed-off-by Waqar Hameed <[email protected]>

---
 .../bindings/power/supply/bq25630.yaml        | 68 +++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/supply/bq25630.yaml

Quoted 7 lines

Documentation/devicetree/bindings/power/supply/bq25630.yaml

Quoted 5 lines

Documentation/devicetree/bindings/power/supply/bq25630.yaml new file +0 -0

new file mode 100644
index 0000000000000..57e4286dac7e9

Filename is missing "ti," to match the compatible.

The majority of TI devices in this folder do not contain the ti, prefix, so I just followed that. But I'll make sure to add it in the next version then!

[...]

Quoted 6 lines

Quoted 6 lines

Documentation/devicetree/bindings/power/supply/bq25630.yaml new file +6 -0

+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    bat: battery {
+        compatible = "simple-battery";

Quoted 8 lines

Documentation/devicetree/bindings/power/supply/bq25630.yaml line 55

Quoted 6 lines

Documentation/devicetree/bindings/power/supply/bq25630.yaml new file +6 -0

+        voltage-min-design-microvolt = <1800000>;
+        constant-charge-current-max-microamp = <1344000>;
+        constant-charge-voltage-max-microvolt = <3700000>;
+        charge-term-current-microamp = <128000>;
+        precharge-current-microamp = <1000000>;
+    };

This whole battery node can go,

Alright, will remove in the next version!

Quoted 1 line

the tooling will falsify the phandle.

I'm guessing you mean that when extracting the example, the insertion of /plugin/ to the *.example.dts-file will "falsify the phandle"?

There are some other examples in this folder that include this node. Not sure if it's worth the churn to fix those as well to help the next person?

On Mon, Mar 02, 2026 at 02:44:19PM +0100, Waqar Hameed wrote:

Quoted 2 lines

I'm guessing you mean that when extracting the example, the insertion of /plugin/ to the *.example.dts-file will "falsify the phandle"?

I'll be honest, I don't know exactly what the mechanism is that fakes the phandles, but it means that any sort of generic device doesn't need to be included in the example.

Quoted 4 lines

There are some other examples in this folder that include this node. Not sure if it's worth the churn to fix those as well to help the next person?

Probably isn't worth the churn /shrug

This patch series contains a fully working driver for the basic functionality for the new TI BQ25630 charger (see datasheet [1]). However, some functionality has no straightforward implementation. The following features have therefore been left out and hopefully we can have some design discussions to reach a clear resolution for the next patch version (hence the RFC tag):

1. The USB OTG functionality (i.e. power *out* from the device) would probably need a minor refactorization to use the MFD sub-system to also register a regulator driver. Looking at the bq257xx driver, this should be the preferred design?

2. Other drivers add a custom sysfs attributes for BATFET control. See for example rt9471 and bq24190. Is this the preferred approach? Should we add a new power sysfs class ABI for this? (There is a TODO left in the code for this.)

I reckon it is quite common to have BATFET control for chargers, i.e. being able to set them in "ship mode", "stand-by mode", "shutdown mode" or "idle mode" (example values taken from the BATFET_CTRL register field from datasheet [1])?

3. This device has liquid detection and corrosion mitigation. I couldn't find any existing device driver with this kind of functionality. The datasheet [1] even mentions "patent pending", although it refers to the USB type-C Specification 2.3... :)

When liquid is detected in the charging port, an interrupt is fired. Likewise, an interrupt can be fired when the port is dry enough (according to some configured threshold value). My initial thought was that maybe we can add "liquid detected" to the health sysfs ABI? However, the question still remains though how one should enable/disable and set threshold values for this (new power class sysfs ABI or a custom one only for this driver)?

[1] https://www.ti.com/lit/gpn/bq25630

Quoted 2 lines · On Fri, Feb 27, 2026 at 16:35 +0100 Waqar Hameed <[email protected]> wrote:

This patch series contains a fully working driver for the basic functionality for the new TI BQ25630 charger (see datasheet [1]).

Quoted 9 lines

However, some functionality has no straightforward implementation. The following features have therefore been left out and hopefully we can have some design discussions to reach a clear resolution for the next patch version (hence the RFC tag):

1. The USB OTG functionality (i.e. power *out* from the device) would probably need a minor refactorization to use the MFD sub-system to also register a regulator driver. Looking at the bq257xx driver, this should be the preferred design?

Quoted 9 lines

2. Other drivers add a custom sysfs attributes for BATFET control. See for example rt9471 and bq24190. Is this the preferred approach? Should we add a new power sysfs class ABI for this? (There is a TODO left in the code for this.)

I reckon it is quite common to have BATFET control for chargers, i.e. being able to set them in "ship mode", "stand-by mode", "shutdown mode" or "idle mode" (example values taken from the BATFET_CTRL register field from datasheet [1])?

Quoted 4 lines

3. This device has liquid detection and corrosion mitigation. I couldn't find any existing device driver with this kind of functionality. The datasheet [1] even mentions "patent pending", although it refers to the USB type-C Specification 2.3... :)

Quoted 5 lines

When liquid is detected in the charging port, an interrupt is fired. Likewise, an interrupt can be fired when the port is dry enough (according to some configured threshold value). My initial thought was that maybe we can add "liquid detected" to the health sysfs ABI?

Quoted 5 lines

However, the question still remains though how one should enable/disable and set threshold values for this (new power class sysfs ABI or a custom one only for this driver)?

[1] https://www.ti.com/lit/gpn/bq25630

Friendly ping incoming!

On Wed, May 20, 2026 at 05:49:38PM +0200, Waqar Hameed wrote:

Driver itself LGTM. I think it would be sensible to merge that while the extra features are being prepared, but the DT binding must be fixed first :)

Quoted 5 lines

Quoted 5 lines

However, some functionality has no straightforward implementation. The following features have therefore been left out and hopefully we can have some design discussions to reach a clear resolution for the next patch version (hence the RFC tag):

Quoted 4 lines

Quoted 4 lines

1. The USB OTG functionality (i.e. power *out* from the device) would probably need a minor refactorization to use the MFD sub-system to also register a regulator driver. Looking at the bq257xx driver, this should be the preferred design?

If the regulator is the only part making this a MFD, just create it in the charger driver itself. There are a few examples, just grep for 'struct regulator_ops' in drivers/power/supply.

Quoted 10 lines

Quoted 10 lines

2. Other drivers add a custom sysfs attributes for BATFET control. See for example rt9471 and bq24190. Is this the preferred approach? Should we add a new power sysfs class ABI for this? (There is a TODO left in the code for this.)

I reckon it is quite common to have BATFET control for chargers, i.e. being able to set them in "ship mode", "stand-by mode", "shutdown mode" or "idle mode" (example values taken from the BATFET_CTRL register field from datasheet [1])?

Yes. I usually ask to use custom properties until there are a few users to avoid cluttering the general ABI. I think BATFET is a good candidate. Please add a new property for that one.

Quoted 4 lines

Quoted 4 lines

3. This device has liquid detection and corrosion mitigation. I couldn't find any existing device driver with this kind of functionality. The datasheet [1] even mentions "patent pending", although it refers to the USB type-C Specification 2.3... :)

This is something I also expect to see in more devices; I know a couple of Android devices offer this. But indeed nothing has been submitted so far.

Quoted 5 lines

Quoted 5 lines

When liquid is detected in the charging port, an interrupt is fired. Likewise, an interrupt can be fired when the port is dry enough (according to some configured threshold value). My initial thought was that maybe we can add "liquid detected" to the health sysfs ABI?

Sounds good to me.

Quoted 6 lines

Quoted 6 lines

However, the question still remains though how one should enable/disable and set threshold values for this (new power class sysfs ABI or a custom one only for this driver)?

[1] https://www.ti.com/lit/gpn/bq25630

I had a quick look at the datasheet. I think a new standard property would be sensible:

LIQUID_DETECTION_CONTROL with possible values
off = Not liquid detection is being performed
auto = Periodic liquid detection checks are being done once = Writing this will perform a single check (and return to off)

For the other controls I'm not sure how generalized they are. E.g. for TLQD and ILQD it offers 4 steps, but not explicit current (seconds and amps). OTOH for the voltage explicit values are listed. Maybe just leave them to the default until somebody actually need this configurable?

Quoted 2 lines

Friendly ping incoming!

Sorry for being slow with reviews, I was quite busy and out of office in the whole May.

I suggest that the 3 things are being send on top of the updaed base driver :)