Document embedded controller used in ASUS Transformer device series.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../asus,transformer-ec.yaml | 98 +++++++++++++++++++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
new file mode 100644
index 000000000000..670c4c2d339d
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASUS Transformer's Embedded Controller
+
+description:
+ Several Nuvoton based Embedded Controllers attached to an I2C bus,
+ running a custom ASUS firmware, specific to the ASUS Transformer
+ device series.
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+allOf:
+ - $ref: /schemas/power/supply/power-supply.yaml
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - asus,p1801-t-ec-pad
+ - asus,sl101-ec-dock
+ - asus,tf600t-ec-pad
+ - asus,tf701t-ec-pad
+
+ - items:
+ - enum:
+ - asus,tf101-ec-dock
+ - asus,tf101g-ec-dock
+ - asus,tf201-ec-dock
+ - asus,tf300t-ec-dock
+ - asus,tf300tg-ec-dock
+ - asus,tf300tl-ec-dock
+ - asus,tf700t-ec-dock
+ - const: asus,transformer-ec-dock
+
+ - items:
+ - enum:
+ - asus,tf201-ec-pad
+ - asus,tf300t-ec-pad
+ - asus,tf300tg-ec-pad
+ - asus,tf300tl-ec-pad
+ - asus,tf700t-ec-pad
+ - const: asus,transformer-ec-pad
+
+ reg:
+ description:
+ The ASUS Transformer EC has a main I2C address and an associated
+ DockRAM device, which provides power-related functions for the
+ embedded controller. Both addresses are required for operation.
+ minItems: 2
+
+ reg-names:
+ items:
+ - const: ec
+ - const: dockram
+
+ interrupts:
+ maxItems: 1
+
+ request-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - request-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ embedded-controller@19 {
+ compatible = "asus,tf201-ec-dock", "asus,transformer-ec-dock";
+ reg = <0x19>, <0x1b>;
+ reg-names = "ec", "dockram";
+
+ interrupt-parent = <&gpio>;
+ interrupts = <151 IRQ_TYPE_LEVEL_LOW>;
+
+ request-gpios = <&gpio 134 GPIO_ACTIVE_LOW>;
+
+ monitored-battery = <&dock_battery>;
+ };
+ };
+...
--
2.51.0On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> Document embedded controller used in ASUS Transformer device series.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> 1 file changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>
> diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> new file mode 100644
> index 000000000000..670c4c2d339d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> @@ -0,0 +1,98 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ASUS Transformer's Embedded Controller
> +
> +description:
> + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> + running a custom ASUS firmware, specific to the ASUS Transformer
> + device series.
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +allOf:
> + - $ref: /schemas/power/supply/power-supply.yaml
> +
> +properties:
> + compatible:
> + oneOf:
> + - enum:
> + - asus,p1801-t-ec-pad
> + - asus,sl101-ec-dock
> + - asus,tf600t-ec-pad
> + - asus,tf701t-ec-pad
> +
> + - items:
> + - enum:
> + - asus,tf101-ec-dock
> + - asus,tf101g-ec-dock
> + - asus,tf201-ec-dock
> + - asus,tf300t-ec-dock
> + - asus,tf300tg-ec-dock
> + - asus,tf300tl-ec-dock
> + - asus,tf700t-ec-dock
> + - const: asus,transformer-ec-dock
> +
> + - items:
> + - enum:
> + - asus,tf201-ec-pad
> + - asus,tf300t-ec-pad
> + - asus,tf300tg-ec-pad
> + - asus,tf300tl-ec-pad
> + - asus,tf700t-ec-pad
> + - const: asus,transformer-ec-pad
Can you explain somewhere here what the "dock" and "pad" devices are and
how they differ? For example, I am currently wondering why tf700t has both
"dock" and "pad".
Also, why are some of the compatibles permitted standalone? That should
be mentioned in your commit message too. Also, other than the sl101, the
standalone ones seem to have the same match data in the mfd driver. Why
are fallbacks not made use of there?
Since this transformer series seems to have multiple programming models
for "ec-pad" devices, it calls into question your use of the generic
fallback compatibles is appropriate and makes it seem like you should be
using device compatibles as a fallback.
The rest looks okay other than the filename, which doesn't match any of
the compatibles that you've got here.
Cheers,
Conor.
> +
> + reg:
> + description:
> + The ASUS Transformer EC has a main I2C address and an associated
> + DockRAM device, which provides power-related functions for the
> + embedded controller. Both addresses are required for operation.
> + minItems: 2
> +
> + reg-names:
> + items:
> + - const: ec
> + - const: dockram
> +
> + interrupts:
> + maxItems: 1
> +
> + request-gpios:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - request-gpios
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + embedded-controller@19 {
> + compatible = "asus,tf201-ec-dock", "asus,transformer-ec-dock";
> + reg = <0x19>, <0x1b>;
> + reg-names = "ec", "dockram";
> +
> + interrupt-parent = <&gpio>;
> + interrupts = <151 IRQ_TYPE_LEVEL_LOW>;
> +
> + request-gpios = <&gpio 134 GPIO_ACTIVE_LOW>;
> +
> + monitored-battery = <&dock_battery>;
> + };
> + };
> +...
> --
> 2.51.0
>
пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
>
> On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> > Document embedded controller used in ASUS Transformer device series.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> > 1 file changed, 98 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > new file mode 100644
> > index 000000000000..670c4c2d339d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > @@ -0,0 +1,98 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ASUS Transformer's Embedded Controller
> > +
> > +description:
> > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> > + running a custom ASUS firmware, specific to the ASUS Transformer
> > + device series.
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +allOf:
> > + - $ref: /schemas/power/supply/power-supply.yaml
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - enum:
> > + - asus,p1801-t-ec-pad
> > + - asus,sl101-ec-dock
> > + - asus,tf600t-ec-pad
> > + - asus,tf701t-ec-pad
> > +
> > + - items:
> > + - enum:
> > + - asus,tf101-ec-dock
> > + - asus,tf101g-ec-dock
> > + - asus,tf201-ec-dock
> > + - asus,tf300t-ec-dock
> > + - asus,tf300tg-ec-dock
> > + - asus,tf300tl-ec-dock
> > + - asus,tf700t-ec-dock
> > + - const: asus,transformer-ec-dock
> > +
> > + - items:
> > + - enum:
> > + - asus,tf201-ec-pad
> > + - asus,tf300t-ec-pad
> > + - asus,tf300tg-ec-pad
> > + - asus,tf300tl-ec-pad
> > + - asus,tf700t-ec-pad
> > + - const: asus,transformer-ec-pad
>
> Can you explain somewhere here what the "dock" and "pad" devices are and
> how they differ? For example, I am currently wondering why tf700t has both
> "dock" and "pad".
"pad" is used for the controller in the tablet itself in the pad
"dock" is used for the controller in the mobile dock keyboard.
Seems quite obvious.
> Also, why are some of the compatibles permitted standalone? That should
> be mentioned in your commit message too. Also, other than the sl101, the
> standalone ones seem to have the same match data in the mfd driver. Why
> are fallbacks not made use of there?
>
Because standalone compatibles describe a unique hw configuration
which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
Different generations, different form-factors.
> Since this transformer series seems to have multiple programming models
> for "ec-pad" devices, it calls into question your use of the generic
> fallback compatibles is appropriate and makes it seem like you should be
> using device compatibles as a fallback.
That is redundant.
>
> The rest looks okay other than the filename, which doesn't match any of
> the compatibles that you've got here.
>
How should I call it then?
> Cheers,
> Conor.
>
> > +
> > + reg:
> > + description:
> > + The ASUS Transformer EC has a main I2C address and an associated
> > + DockRAM device, which provides power-related functions for the
> > + embedded controller. Both addresses are required for operation.
> > + minItems: 2
> > +
> > + reg-names:
> > + items:
> > + - const: ec
> > + - const: dockram
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + request-gpios:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - interrupts
> > + - request-gpios
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > +
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + embedded-controller@19 {
> > + compatible = "asus,tf201-ec-dock", "asus,transformer-ec-dock";
> > + reg = <0x19>, <0x1b>;
> > + reg-names = "ec", "dockram";
> > +
> > + interrupt-parent = <&gpio>;
> > + interrupts = <151 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + request-gpios = <&gpio 134 GPIO_ACTIVE_LOW>;
> > +
> > + monitored-battery = <&dock_battery>;
> > + };
> > + };
> > +...
> > --
> > 2.51.0
> >
On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
> пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
> >
> > On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> > > Document embedded controller used in ASUS Transformer device series.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> > > 1 file changed, 98 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > new file mode 100644
> > > index 000000000000..670c4c2d339d
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > @@ -0,0 +1,98 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: ASUS Transformer's Embedded Controller
> > > +
> > > +description:
> > > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> > > + running a custom ASUS firmware, specific to the ASUS Transformer
> > > + device series.
> > > +
> > > +maintainers:
> > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > +
> > > +allOf:
> > > + - $ref: /schemas/power/supply/power-supply.yaml
> > > +
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + - enum:
> > > + - asus,p1801-t-ec-pad
> > > + - asus,sl101-ec-dock
> > > + - asus,tf600t-ec-pad
> > > + - asus,tf701t-ec-pad
> > > +
> > > + - items:
> > > + - enum:
> > > + - asus,tf101-ec-dock
> > > + - asus,tf101g-ec-dock
> > > + - asus,tf201-ec-dock
> > > + - asus,tf300t-ec-dock
> > > + - asus,tf300tg-ec-dock
> > > + - asus,tf300tl-ec-dock
> > > + - asus,tf700t-ec-dock
> > > + - const: asus,transformer-ec-dock
> > > +
> > > + - items:
> > > + - enum:
> > > + - asus,tf201-ec-pad
> > > + - asus,tf300t-ec-pad
> > > + - asus,tf300tg-ec-pad
> > > + - asus,tf300tl-ec-pad
> > > + - asus,tf700t-ec-pad
> > > + - const: asus,transformer-ec-pad
> >
> > Can you explain somewhere here what the "dock" and "pad" devices are and
> > how they differ? For example, I am currently wondering why tf700t has both
> > "dock" and "pad".
>
> "pad" is used for the controller in the tablet itself in the pad
> "dock" is used for the controller in the mobile dock keyboard.
> Seems quite obvious.
To someone intimately familiar with the devices maybe. Not to the people
you have to justify your patches to. Your response implies that this is
some sort of thing that's like a surface, but please put an explicit
explanation into the binding somewhere as to what each compatible is
for.
> > Also, why are some of the compatibles permitted standalone? That should
> > be mentioned in your commit message too. Also, other than the sl101, the
> > standalone ones seem to have the same match data in the mfd driver. Why
> > are fallbacks not made use of there?
> >
>
> Because standalone compatibles describe a unique hw configuration
> which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
> is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
> for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
> in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
> Different generations, different form-factors.
I don't see any reasons here that eliminate fallback compatibles.
+ { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
+ { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
+ { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
+ { }
Three of them use the same match data, so you need to explain why you've
made these three standalone when all the others that share a programming
model got a generic fallback. Fallback usage is based on programming
model, not based on whether the devices are a physically different, so
your explanation must reflect this.
> > Since this transformer series seems to have multiple programming models
> > for "ec-pad" devices, it calls into question your use of the generic
> > fallback compatibles is appropriate and makes it seem like you should be
> > using device compatibles as a fallback.
>
> That is redundant.
I don't understand how that is a response to what I said.
> > The rest looks okay other than the filename, which doesn't match any of
> > the compatibles that you've got here.
> >
>
> How should I call it then?
Make it match a compatible, just like any other binding.
пн, 16 лют. 2026 р. о 20:50 Conor Dooley <conor@kernel.org> пише:
>
> On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
> > пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
> > >
> > > On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> > > > Document embedded controller used in ASUS Transformer device series.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> > > > 1 file changed, 98 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > > new file mode 100644
> > > > index 000000000000..670c4c2d339d
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > > @@ -0,0 +1,98 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: ASUS Transformer's Embedded Controller
> > > > +
> > > > +description:
> > > > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> > > > + running a custom ASUS firmware, specific to the ASUS Transformer
> > > > + device series.
> > > > +
> > > > +maintainers:
> > > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > +
> > > > +allOf:
> > > > + - $ref: /schemas/power/supply/power-supply.yaml
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + oneOf:
> > > > + - enum:
> > > > + - asus,p1801-t-ec-pad
> > > > + - asus,sl101-ec-dock
> > > > + - asus,tf600t-ec-pad
> > > > + - asus,tf701t-ec-pad
> > > > +
> > > > + - items:
> > > > + - enum:
> > > > + - asus,tf101-ec-dock
> > > > + - asus,tf101g-ec-dock
> > > > + - asus,tf201-ec-dock
> > > > + - asus,tf300t-ec-dock
> > > > + - asus,tf300tg-ec-dock
> > > > + - asus,tf300tl-ec-dock
> > > > + - asus,tf700t-ec-dock
> > > > + - const: asus,transformer-ec-dock
> > > > +
> > > > + - items:
> > > > + - enum:
> > > > + - asus,tf201-ec-pad
> > > > + - asus,tf300t-ec-pad
> > > > + - asus,tf300tg-ec-pad
> > > > + - asus,tf300tl-ec-pad
> > > > + - asus,tf700t-ec-pad
> > > > + - const: asus,transformer-ec-pad
> > >
> > > Can you explain somewhere here what the "dock" and "pad" devices are and
> > > how they differ? For example, I am currently wondering why tf700t has both
> > > "dock" and "pad".
> >
> > "pad" is used for the controller in the tablet itself in the pad
> > "dock" is used for the controller in the mobile dock keyboard.
> > Seems quite obvious.
>
> To someone intimately familiar with the devices maybe. Not to the people
> you have to justify your patches to. Your response implies that this is
> some sort of thing that's like a surface, but please put an explicit
> explanation into the binding somewhere as to what each compatible is
> for.
Ok, fair.
>
> > > Also, why are some of the compatibles permitted standalone? That should
> > > be mentioned in your commit message too. Also, other than the sl101, the
> > > standalone ones seem to have the same match data in the mfd driver. Why
> > > are fallbacks not made use of there?
> > >
> >
> > Because standalone compatibles describe a unique hw configuration
> > which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
> > is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
> > for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
> > in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
> > Different generations, different form-factors.
>
> I don't see any reasons here that eliminate fallback compatibles.
> + { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
> + { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
> + { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
> + { }
> Three of them use the same match data, so you need to explain why you've
> made these three standalone when all the others that share a programming
> model got a generic fallback. Fallback usage is based on programming
> model, not based on whether the devices are a physically different, so
> your explanation must reflect this.
>
> > > Since this transformer series seems to have multiple programming models
> > > for "ec-pad" devices, it calls into question your use of the generic
> > > fallback compatibles is appropriate and makes it seem like you should be
> > > using device compatibles as a fallback.
> >
> > That is redundant.
>
> I don't understand how that is a response to what I said.
>
in other words you propose this:
properties:
compatible:
oneOf:
- items:
- enum:
- asus,sl101-ec-dock
- asus,tf101-ec-dock
- asus,tf101g-ec-dock
- asus,tf201-ec-dock
- asus,tf300t-ec-dock
- asus,tf300tg-ec-dock
- asus,tf300tl-ec-dock
- asus,tf700t-ec-dock
- const: asus,transformer-ec-dock
- items:
- enum:
- asus,p1801-t-ec-pad
- asus,tf201-ec-pad
- asus,tf300t-ec-pad
- asus,tf300tg-ec-pad
- asus,tf300tl-ec-pad
- asus,tf700t-ec-pad
- asus,tf600t-ec-pad
- asus,tf701t-ec-pad
- const: asus,transformer-ec-pad
And in the driver add match to every single entry of enums?
> > > The rest looks okay other than the filename, which doesn't match any of
> > > the compatibles that you've got here.
> > >
> >
> > How should I call it then?
>
> Make it match a compatible, just like any other binding.
On Mon, Feb 16, 2026 at 09:14:40PM +0200, Svyatoslav Ryhel wrote:
> пн, 16 лют. 2026 р. о 20:50 Conor Dooley <conor@kernel.org> пише:
> >
> > On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
> > > пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
> > > >
> > > > On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> > > > > Document embedded controller used in ASUS Transformer device series.
> > > > >
> > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > ---
> > > > > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> > > > > 1 file changed, 98 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..670c4c2d339d
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > > > @@ -0,0 +1,98 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: ASUS Transformer's Embedded Controller
> > > > > +
> > > > > +description:
> > > > > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> > > > > + running a custom ASUS firmware, specific to the ASUS Transformer
> > > > > + device series.
> > > > > +
> > > > > +maintainers:
> > > > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > +
> > > > > +allOf:
> > > > > + - $ref: /schemas/power/supply/power-supply.yaml
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + oneOf:
> > > > > + - enum:
> > > > > + - asus,p1801-t-ec-pad
> > > > > + - asus,sl101-ec-dock
> > > > > + - asus,tf600t-ec-pad
> > > > > + - asus,tf701t-ec-pad
> > > > > +
> > > > > + - items:
> > > > > + - enum:
> > > > > + - asus,tf101-ec-dock
> > > > > + - asus,tf101g-ec-dock
> > > > > + - asus,tf201-ec-dock
> > > > > + - asus,tf300t-ec-dock
> > > > > + - asus,tf300tg-ec-dock
> > > > > + - asus,tf300tl-ec-dock
> > > > > + - asus,tf700t-ec-dock
> > > > > + - const: asus,transformer-ec-dock
> > > > > +
> > > > > + - items:
> > > > > + - enum:
> > > > > + - asus,tf201-ec-pad
> > > > > + - asus,tf300t-ec-pad
> > > > > + - asus,tf300tg-ec-pad
> > > > > + - asus,tf300tl-ec-pad
> > > > > + - asus,tf700t-ec-pad
> > > > > + - const: asus,transformer-ec-pad
> > > > Also, why are some of the compatibles permitted standalone? That should
> > > > be mentioned in your commit message too. Also, other than the sl101, the
> > > > standalone ones seem to have the same match data in the mfd driver. Why
> > > > are fallbacks not made use of there?
> > > >
> > >
> > > Because standalone compatibles describe a unique hw configuration
> > > which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
> > > is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
> > > for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
> > > in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
> > > Different generations, different form-factors.
> >
> > I don't see any reasons here that eliminate fallback compatibles.
> > + { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
> > + { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
> > + { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
> > + { }
> > Three of them use the same match data, so you need to explain why you've
> > made these three standalone when all the others that share a programming
> > model got a generic fallback. Fallback usage is based on programming
> > model, not based on whether the devices are a physically different, so
> > your explanation must reflect this.
> >
> > > > Since this transformer series seems to have multiple programming models
> > > > for "ec-pad" devices, it calls into question your use of the generic
> > > > fallback compatibles is appropriate and makes it seem like you should be
> > > > using device compatibles as a fallback.
> > >
> > > That is redundant.
> >
> > I don't understand how that is a response to what I said.
> >
>
> in other words you propose this:
>
> properties:
> compatible:
> oneOf:
> - items:
> - enum:
> - asus,sl101-ec-dock
> - asus,tf101-ec-dock
> - asus,tf101g-ec-dock
> - asus,tf201-ec-dock
> - asus,tf300t-ec-dock
> - asus,tf300tg-ec-dock
> - asus,tf300tl-ec-dock
> - asus,tf700t-ec-dock
> - const: asus,transformer-ec-dock
>
> - items:
> - enum:
> - asus,p1801-t-ec-pad
> - asus,tf201-ec-pad
> - asus,tf300t-ec-pad
> - asus,tf300tg-ec-pad
> - asus,tf300tl-ec-pad
> - asus,tf700t-ec-pad
> - asus,tf600t-ec-pad
> - asus,tf701t-ec-pad
> - const: asus,transformer-ec-pad
>
> And in the driver add match to every single entry of enums?
No, I was talking about removing the generic compatibles entirely, since
they are not suitably generic to cover all devices at the point of
addition. So like:
items:
- enum:
- asus,tf101-ec-dock
- asus,tf101g-ec-dock
- asus,tf201-ec-dock
- asus,tf300t-ec-dock
- asus,tf300tg-ec-dock
- asus,tf300tl-ec-dock
- const: asus,tf700t-ec-dock
and
items:
- enum:
- asus,p1801-t-ec-pad
- asus,tf600t-ec-pad
- const: asus,tf701t-ec-pad
I dunno about these particular devices, but if there's already two
programming models for these devices, what's to stop there being more
added if/when a new generation of produces arrives?
17 лютого 2026 р. 13:05:09 GMT+02:00, Conor Dooley <conor@kernel.org> пише:
>On Mon, Feb 16, 2026 at 09:14:40PM +0200, Svyatoslav Ryhel wrote:
>> пн, 16 лют. 2026 р. о 20:50 Conor Dooley <conor@kernel.org> пише:
>> >
>> > On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
>> > > пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
>> > > >
>> > > > On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
>> > > > > Document embedded controller used in ASUS Transformer device series.
>> > > > >
>> > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>> > > > > ---
>> > > > > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
>> > > > > 1 file changed, 98 insertions(+)
>> > > > > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>> > > > >
>> > > > > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>> > > > > new file mode 100644
>> > > > > index 000000000000..670c4c2d339d
>> > > > > --- /dev/null
>> > > > > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>> > > > > @@ -0,0 +1,98 @@
>> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> > > > > +%YAML 1.2
>> > > > > +---
>> > > > > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
>> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> > > > > +
>> > > > > +title: ASUS Transformer's Embedded Controller
>> > > > > +
>> > > > > +description:
>> > > > > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
>> > > > > + running a custom ASUS firmware, specific to the ASUS Transformer
>> > > > > + device series.
>> > > > > +
>> > > > > +maintainers:
>> > > > > + - Svyatoslav Ryhel <clamor95@gmail.com>
>> > > > > +
>> > > > > +allOf:
>> > > > > + - $ref: /schemas/power/supply/power-supply.yaml
>> > > > > +
>> > > > > +properties:
>> > > > > + compatible:
>> > > > > + oneOf:
>> > > > > + - enum:
>> > > > > + - asus,p1801-t-ec-pad
>> > > > > + - asus,sl101-ec-dock
>> > > > > + - asus,tf600t-ec-pad
>> > > > > + - asus,tf701t-ec-pad
>> > > > > +
>> > > > > + - items:
>> > > > > + - enum:
>> > > > > + - asus,tf101-ec-dock
>> > > > > + - asus,tf101g-ec-dock
>> > > > > + - asus,tf201-ec-dock
>> > > > > + - asus,tf300t-ec-dock
>> > > > > + - asus,tf300tg-ec-dock
>> > > > > + - asus,tf300tl-ec-dock
>> > > > > + - asus,tf700t-ec-dock
>> > > > > + - const: asus,transformer-ec-dock
>> > > > > +
>> > > > > + - items:
>> > > > > + - enum:
>> > > > > + - asus,tf201-ec-pad
>> > > > > + - asus,tf300t-ec-pad
>> > > > > + - asus,tf300tg-ec-pad
>> > > > > + - asus,tf300tl-ec-pad
>> > > > > + - asus,tf700t-ec-pad
>> > > > > + - const: asus,transformer-ec-pad
>
>> > > > Also, why are some of the compatibles permitted standalone? That should
>> > > > be mentioned in your commit message too. Also, other than the sl101, the
>> > > > standalone ones seem to have the same match data in the mfd driver. Why
>> > > > are fallbacks not made use of there?
>> > > >
>> > >
>> > > Because standalone compatibles describe a unique hw configuration
>> > > which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
>> > > is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
>> > > for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
>> > > in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
>> > > Different generations, different form-factors.
>> >
>> > I don't see any reasons here that eliminate fallback compatibles.
>> > + { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
>> > + { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
>> > + { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
>> > + { }
>> > Three of them use the same match data, so you need to explain why you've
>> > made these three standalone when all the others that share a programming
>> > model got a generic fallback. Fallback usage is based on programming
>> > model, not based on whether the devices are a physically different, so
>> > your explanation must reflect this.
>> >
>> > > > Since this transformer series seems to have multiple programming models
>> > > > for "ec-pad" devices, it calls into question your use of the generic
>> > > > fallback compatibles is appropriate and makes it seem like you should be
>> > > > using device compatibles as a fallback.
>> > >
>> > > That is redundant.
>> >
>> > I don't understand how that is a response to what I said.
>> >
>>
>> in other words you propose this:
>>
>> properties:
>> compatible:
>> oneOf:
>> - items:
>> - enum:
>> - asus,sl101-ec-dock
>> - asus,tf101-ec-dock
>> - asus,tf101g-ec-dock
>> - asus,tf201-ec-dock
>> - asus,tf300t-ec-dock
>> - asus,tf300tg-ec-dock
>> - asus,tf300tl-ec-dock
>> - asus,tf700t-ec-dock
>> - const: asus,transformer-ec-dock
>>
>> - items:
>> - enum:
>> - asus,p1801-t-ec-pad
>> - asus,tf201-ec-pad
>> - asus,tf300t-ec-pad
>> - asus,tf300tg-ec-pad
>> - asus,tf300tl-ec-pad
>> - asus,tf700t-ec-pad
>> - asus,tf600t-ec-pad
>> - asus,tf701t-ec-pad
>> - const: asus,transformer-ec-pad
>>
>> And in the driver add match to every single entry of enums?
>
>No, I was talking about removing the generic compatibles entirely, since
>they are not suitably generic to cover all devices at the point of
>addition. So like:
>
Actually, they all can be grouped under asus,transformer-ec fallback if that is needed, both pad and dock EC have the same core functions just different set of cells. And then in the driver each compatible will get a dedicated matching data. Will this work?
properties:
compatible:
- items:
- enum:
- asus,p1801-t-ec-pad
- asus,sl101-ec-dock
- asus,tf101-ec-dock
- asus,tf101g-ec-dock
- asus,tf201-ec-dock
- asus,tf201-ec-pad
- asus,tf300t-ec-dock
- asus,tf300t-ec-pad
- asus,tf300tg-ec-dock
- asus,tf300tg-ec-pad
- asus,tf300tl-ec-dock
- asus,tf300tl-ec-pad
- asus,tf700t-ec-dock
- asus,tf700t-ec-pad
- asus,tf600t-ec-pad
- asus,tf701t-ec-pad
- const: asus,transformer-ec
And them schema name will match the genetic compatible.
>items:
> - enum:
> - asus,tf101-ec-dock
> - asus,tf101g-ec-dock
> - asus,tf201-ec-dock
> - asus,tf300t-ec-dock
> - asus,tf300tg-ec-dock
> - asus,tf300tl-ec-dock
> - const: asus,tf700t-ec-dock
>
>and
>
>items:
> - enum:
> - asus,p1801-t-ec-pad
> - asus,tf600t-ec-pad
> - const: asus,tf701t-ec-pad
>
>I dunno about these particular devices, but if there's already two
>programming models for these devices, what's to stop there being more
>added if/when a new generation of produces arrives?
There will be no new devices with this EC, last one was around 2013.
On 17/02/2026 12:23, Svyatoslav Ryhel wrote: >>> in other words you propose this: >>> >>> properties: >>> compatible: >>> oneOf: >>> - items: >>> - enum: >>> - asus,sl101-ec-dock >>> - asus,tf101-ec-dock >>> - asus,tf101g-ec-dock >>> - asus,tf201-ec-dock >>> - asus,tf300t-ec-dock >>> - asus,tf300tg-ec-dock >>> - asus,tf300tl-ec-dock >>> - asus,tf700t-ec-dock >>> - const: asus,transformer-ec-dock >>> >>> - items: >>> - enum: >>> - asus,p1801-t-ec-pad >>> - asus,tf201-ec-pad >>> - asus,tf300t-ec-pad >>> - asus,tf300tg-ec-pad >>> - asus,tf300tl-ec-pad >>> - asus,tf700t-ec-pad >>> - asus,tf600t-ec-pad >>> - asus,tf701t-ec-pad >>> - const: asus,transformer-ec-pad >>> >>> And in the driver add match to every single entry of enums? >> >> No, I was talking about removing the generic compatibles entirely, since >> they are not suitably generic to cover all devices at the point of >> addition. So like: >> > > Actually, they all can be grouped under asus,transformer-ec fallback if that is needed, both pad and dock EC have the same core functions just different set of cells. And then in the driver each compatible will get a dedicated matching data. Will this work? Then what does the generic compatible express if it is not used by the SW. Wrap your emails to mailing list style. > > properties: > compatible: > - items: > - enum: > - asus,p1801-t-ec-pad > - asus,sl101-ec-dock > - asus,tf101-ec-dock > - asus,tf101g-ec-dock > - asus,tf201-ec-dock > - asus,tf201-ec-pad > - asus,tf300t-ec-dock > - asus,tf300t-ec-pad > - asus,tf300tg-ec-dock > - asus,tf300tg-ec-pad > - asus,tf300tl-ec-dock > - asus,tf300tl-ec-pad > - asus,tf700t-ec-dock > - asus,tf700t-ec-pad > - asus,tf600t-ec-pad > - asus,tf701t-ec-pad > - const: asus,transformer-ec > > And them schema name will match the genetic compatible. Then what does the generic compatible express? Best regards, Krzysztof
17 лютого 2026 р. 13:32:26 GMT+02:00, Krzysztof Kozlowski <krzk@kernel.org> пише: >On 17/02/2026 12:23, Svyatoslav Ryhel wrote: >>>> in other words you propose this: >>>> >>>> properties: >>>> compatible: >>>> oneOf: >>>> - items: >>>> - enum: >>>> - asus,sl101-ec-dock >>>> - asus,tf101-ec-dock >>>> - asus,tf101g-ec-dock >>>> - asus,tf201-ec-dock >>>> - asus,tf300t-ec-dock >>>> - asus,tf300tg-ec-dock >>>> - asus,tf300tl-ec-dock >>>> - asus,tf700t-ec-dock >>>> - const: asus,transformer-ec-dock >>>> >>>> - items: >>>> - enum: >>>> - asus,p1801-t-ec-pad >>>> - asus,tf201-ec-pad >>>> - asus,tf300t-ec-pad >>>> - asus,tf300tg-ec-pad >>>> - asus,tf300tl-ec-pad >>>> - asus,tf700t-ec-pad >>>> - asus,tf600t-ec-pad >>>> - asus,tf701t-ec-pad >>>> - const: asus,transformer-ec-pad >>>> >>>> And in the driver add match to every single entry of enums? >>> >>> No, I was talking about removing the generic compatibles entirely, since >>> they are not suitably generic to cover all devices at the point of >>> addition. So like: >>> >> >> Actually, they all can be grouped under asus,transformer-ec fallback if that is needed, both pad and dock EC have the same core functions just different set of cells. And then in the driver each compatible will get a dedicated matching data. Will this work? > >Then what does the generic compatible express if it is not used by the SW. > >Wrap your emails to mailing list style. > >> >> properties: >> compatible: >> - items: >> - enum: >> - asus,p1801-t-ec-pad >> - asus,sl101-ec-dock >> - asus,tf101-ec-dock >> - asus,tf101g-ec-dock >> - asus,tf201-ec-dock >> - asus,tf201-ec-pad >> - asus,tf300t-ec-dock >> - asus,tf300t-ec-pad >> - asus,tf300tg-ec-dock >> - asus,tf300tg-ec-pad >> - asus,tf300tl-ec-dock >> - asus,tf300tl-ec-pad >> - asus,tf700t-ec-dock >> - asus,tf700t-ec-pad >> - asus,tf600t-ec-pad >> - asus,tf701t-ec-pad >> - const: asus,transformer-ec >> >> And them schema name will match the genetic compatible. > >Then what does the generic compatible express? > Then enum it is > >Best regards, >Krzysztof
On Tue, Feb 17, 2026 at 01:34:01PM +0200, Svyatoslav Ryhel wrote: > > > 17 лютого 2026 р. 13:32:26 GMT+02:00, Krzysztof Kozlowski <krzk@kernel.org> пише: > >On 17/02/2026 12:23, Svyatoslav Ryhel wrote: > >>>> in other words you propose this: > >>>> > >>>> properties: > >>>> compatible: > >>>> oneOf: > >>>> - items: > >>>> - enum: > >>>> - asus,sl101-ec-dock > >>>> - asus,tf101-ec-dock > >>>> - asus,tf101g-ec-dock > >>>> - asus,tf201-ec-dock > >>>> - asus,tf300t-ec-dock > >>>> - asus,tf300tg-ec-dock > >>>> - asus,tf300tl-ec-dock > >>>> - asus,tf700t-ec-dock > >>>> - const: asus,transformer-ec-dock > >>>> > >>>> - items: > >>>> - enum: > >>>> - asus,p1801-t-ec-pad > >>>> - asus,tf201-ec-pad > >>>> - asus,tf300t-ec-pad > >>>> - asus,tf300tg-ec-pad > >>>> - asus,tf300tl-ec-pad > >>>> - asus,tf700t-ec-pad > >>>> - asus,tf600t-ec-pad > >>>> - asus,tf701t-ec-pad > >>>> - const: asus,transformer-ec-pad > >>>> > >>>> And in the driver add match to every single entry of enums? > >>> > >>> No, I was talking about removing the generic compatibles entirely, since > >>> they are not suitably generic to cover all devices at the point of > >>> addition. So like: > >>> > >> > >> Actually, they all can be grouped under asus,transformer-ec fallback if that is needed, both pad and dock EC have the same core functions just different set of cells. And then in the driver each compatible will get a dedicated matching data. Will this work? > > > >Then what does the generic compatible express if it is not used by the SW. > > > >Wrap your emails to mailing list style. > > > >> > >> properties: > >> compatible: > >> - items: > >> - enum: > >> - asus,p1801-t-ec-pad > >> - asus,sl101-ec-dock > >> - asus,tf101-ec-dock > >> - asus,tf101g-ec-dock > >> - asus,tf201-ec-dock > >> - asus,tf201-ec-pad > >> - asus,tf300t-ec-dock > >> - asus,tf300t-ec-pad > >> - asus,tf300tg-ec-dock > >> - asus,tf300tg-ec-pad > >> - asus,tf300tl-ec-dock > >> - asus,tf300tl-ec-pad > >> - asus,tf700t-ec-dock > >> - asus,tf700t-ec-pad > >> - asus,tf600t-ec-pad > >> - asus,tf701t-ec-pad > >> - const: asus,transformer-ec > >> > >> And them schema name will match the genetic compatible. > > > >Then what does the generic compatible express? > > > > Then enum it is Why would you do that, instead of what I posted earlier in the thread? If you send a flat enum with all devices listed, I'm gonna just be there telling you to consolidate into one device-specific fallback compatible per programming model.
вт, 17 лют. 2026 р. о 16:03 Conor Dooley <conor@kernel.org> пише: > > On Tue, Feb 17, 2026 at 01:34:01PM +0200, Svyatoslav Ryhel wrote: > > > > > > 17 лютого 2026 р. 13:32:26 GMT+02:00, Krzysztof Kozlowski <krzk@kernel.org> пише: > > >On 17/02/2026 12:23, Svyatoslav Ryhel wrote: > > >>>> in other words you propose this: > > >>>> > > >>>> properties: > > >>>> compatible: > > >>>> oneOf: > > >>>> - items: > > >>>> - enum: > > >>>> - asus,sl101-ec-dock > > >>>> - asus,tf101-ec-dock > > >>>> - asus,tf101g-ec-dock > > >>>> - asus,tf201-ec-dock > > >>>> - asus,tf300t-ec-dock > > >>>> - asus,tf300tg-ec-dock > > >>>> - asus,tf300tl-ec-dock > > >>>> - asus,tf700t-ec-dock > > >>>> - const: asus,transformer-ec-dock > > >>>> > > >>>> - items: > > >>>> - enum: > > >>>> - asus,p1801-t-ec-pad > > >>>> - asus,tf201-ec-pad > > >>>> - asus,tf300t-ec-pad > > >>>> - asus,tf300tg-ec-pad > > >>>> - asus,tf300tl-ec-pad > > >>>> - asus,tf700t-ec-pad > > >>>> - asus,tf600t-ec-pad > > >>>> - asus,tf701t-ec-pad > > >>>> - const: asus,transformer-ec-pad > > >>>> > > >>>> And in the driver add match to every single entry of enums? > > >>> > > >>> No, I was talking about removing the generic compatibles entirely, since > > >>> they are not suitably generic to cover all devices at the point of > > >>> addition. So like: > > >>> > > >> > > >> Actually, they all can be grouped under asus,transformer-ec fallback if that is needed, both pad and dock EC have the same core functions just different set of cells. And then in the driver each compatible will get a dedicated matching data. Will this work? > > > > > >Then what does the generic compatible express if it is not used by the SW. > > > > > >Wrap your emails to mailing list style. > > > > > >> > > >> properties: > > >> compatible: > > >> - items: > > >> - enum: > > >> - asus,p1801-t-ec-pad > > >> - asus,sl101-ec-dock > > >> - asus,tf101-ec-dock > > >> - asus,tf101g-ec-dock > > >> - asus,tf201-ec-dock > > >> - asus,tf201-ec-pad > > >> - asus,tf300t-ec-dock > > >> - asus,tf300t-ec-pad > > >> - asus,tf300tg-ec-dock > > >> - asus,tf300tg-ec-pad > > >> - asus,tf300tl-ec-dock > > >> - asus,tf300tl-ec-pad > > >> - asus,tf700t-ec-dock > > >> - asus,tf700t-ec-pad > > >> - asus,tf600t-ec-pad > > >> - asus,tf701t-ec-pad > > >> - const: asus,transformer-ec > > >> > > >> And them schema name will match the genetic compatible. > > > > > >Then what does the generic compatible express? > > > > > > > Then enum it is > > > Why would you do that, instead of what I posted earlier in the thread? > If you send a flat enum with all devices listed, I'm gonna just be there > telling you to consolidate into one device-specific fallback compatible > per programming model. There is no one device-specific fallback compatible! Schema describes HARDWARE not drivers no? I will not use random device compatible from the list as a fallback compatible for a different random unrelated device, that is plain wrong. Discuss this with Krzysztof and come up with something meaningful please.
On 17/02/2026 15:29, Svyatoslav Ryhel wrote: >>>>> properties: >>>>> compatible: >>>>> - items: >>>>> - enum: >>>>> - asus,p1801-t-ec-pad >>>>> - asus,sl101-ec-dock >>>>> - asus,tf101-ec-dock >>>>> - asus,tf101g-ec-dock >>>>> - asus,tf201-ec-dock >>>>> - asus,tf201-ec-pad >>>>> - asus,tf300t-ec-dock >>>>> - asus,tf300t-ec-pad >>>>> - asus,tf300tg-ec-dock >>>>> - asus,tf300tg-ec-pad >>>>> - asus,tf300tl-ec-dock >>>>> - asus,tf300tl-ec-pad >>>>> - asus,tf700t-ec-dock >>>>> - asus,tf700t-ec-pad >>>>> - asus,tf600t-ec-pad >>>>> - asus,tf701t-ec-pad >>>>> - const: asus,transformer-ec >>>>> >>>>> And them schema name will match the genetic compatible. >>>> >>>> Then what does the generic compatible express? >>>> >>> >>> Then enum it is >> >> >> Why would you do that, instead of what I posted earlier in the thread? >> If you send a flat enum with all devices listed, I'm gonna just be there >> telling you to consolidate into one device-specific fallback compatible >> per programming model. > > There is no one device-specific fallback compatible! Schema describes > HARDWARE not drivers no? I will not use random device compatible from You came with "asus,transformer-ec" as fallback which is same random choice, so how one random device is okay, but other not? We asked to use some meaningful device as fallback, to the best of current knowledge. > the list as a fallback compatible for a different random unrelated > device, that is plain wrong. Discuss this with Krzysztof and come up > with something meaningful please. It is not pleasant to review your patches. This happened in the past [1] and recently is not getting better. In multiple threads. Receiving half-baked responses to actual review questions means you do not value our time. I think you somehow annoyed, offended or wasted time of all three DT maintainers. Well, sure, happens. Just understand there might be a reason when your patches do not receive attention or reviews. [1] https://lore.kernel.org/r/CAPVz0n09ZP1i2tasdTvnt8RvjhALvUYjv9u_EGRtnXPOYQtuqQ@mail.gmail.com/ Best regards, Krzysztof
On Tue, Feb 17, 2026 at 04:29:59PM +0200, Svyatoslav Ryhel wrote: > вт, 17 лют. 2026 р. о 16:03 Conor Dooley <conor@kernel.org> пише: > > On Tue, Feb 17, 2026 at 01:34:01PM +0200, Svyatoslav Ryhel wrote: > > > 17 лютого 2026 р. 13:32:26 GMT+02:00, Krzysztof Kozlowski <krzk@kernel.org> пише: > > > >> properties: > > > >> compatible: > > > >> - items: > > > >> - enum: > > > >> - asus,p1801-t-ec-pad > > > >> - asus,sl101-ec-dock > > > >> - asus,tf101-ec-dock > > > >> - asus,tf101g-ec-dock > > > >> - asus,tf201-ec-dock > > > >> - asus,tf201-ec-pad > > > >> - asus,tf300t-ec-dock > > > >> - asus,tf300t-ec-pad > > > >> - asus,tf300tg-ec-dock > > > >> - asus,tf300tg-ec-pad > > > >> - asus,tf300tl-ec-dock > > > >> - asus,tf300tl-ec-pad > > > >> - asus,tf700t-ec-dock > > > >> - asus,tf700t-ec-pad > > > >> - asus,tf600t-ec-pad > > > >> - asus,tf701t-ec-pad > > > >> - const: asus,transformer-ec > > > >> > > > >> And them schema name will match the genetic compatible. > > > > > > > >Then what does the generic compatible express? > > > > > > > > > > Then enum it is > > > > > > Why would you do that, instead of what I posted earlier in the thread? > > If you send a flat enum with all devices listed, I'm gonna just be there > > telling you to consolidate into one device-specific fallback compatible > > per programming model. > > There is no one device-specific fallback compatible! Schema describes > HARDWARE not drivers no? I will not use random device compatible from > the list as a fallback compatible for a different random unrelated > device, that is plain wrong. Which is why I am not mentioning drivers at all, and instead talking about programming models. Fallback compatibles represent similarities in programming model, even if the laptop that these devices are contained in are different, so whatever device compatible you pick might be random (but going chronologically is usually my recommendation) but it won't be unrelated. > Discuss this with Krzysztof and come up with something meaningful please. If you don't consider my reviews to be meaningful, you're welcome to carry a Nacked-by: Conor Dooley <conor.dooley@microchip.com> with a link to this discussion instead. Thanks, Conor.
On Tue, Feb 17, 2026 at 01:23:06PM +0200, Svyatoslav Ryhel wrote:
>
>
> 17 лютого 2026 р. 13:05:09 GMT+02:00, Conor Dooley <conor@kernel.org> пише:
> >On Mon, Feb 16, 2026 at 09:14:40PM +0200, Svyatoslav Ryhel wrote:
> >> пн, 16 лют. 2026 р. о 20:50 Conor Dooley <conor@kernel.org> пише:
> >> >
> >> > On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
> >> > > пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
> >> > > >
> >> > > > On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> >> > > > > Document embedded controller used in ASUS Transformer device series.
> >> > > > >
> >> > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> >> > > > > ---
> >> > > > > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> >> > > > > 1 file changed, 98 insertions(+)
> >> > > > > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> >> > > > >
> >> > > > > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> >> > > > > new file mode 100644
> >> > > > > index 000000000000..670c4c2d339d
> >> > > > > --- /dev/null
> >> > > > > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> >> > > > > @@ -0,0 +1,98 @@
> >> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> >> > > > > +%YAML 1.2
> >> > > > > +---
> >> > > > > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> >> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> > > > > +
> >> > > > > +title: ASUS Transformer's Embedded Controller
> >> > > > > +
> >> > > > > +description:
> >> > > > > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> >> > > > > + running a custom ASUS firmware, specific to the ASUS Transformer
> >> > > > > + device series.
> >> > > > > +
> >> > > > > +maintainers:
> >> > > > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> >> > > > > +
> >> > > > > +allOf:
> >> > > > > + - $ref: /schemas/power/supply/power-supply.yaml
> >> > > > > +
> >> > > > > +properties:
> >> > > > > + compatible:
> >> > > > > + oneOf:
> >> > > > > + - enum:
> >> > > > > + - asus,p1801-t-ec-pad
> >> > > > > + - asus,sl101-ec-dock
> >> > > > > + - asus,tf600t-ec-pad
> >> > > > > + - asus,tf701t-ec-pad
> >> > > > > +
> >> > > > > + - items:
> >> > > > > + - enum:
> >> > > > > + - asus,tf101-ec-dock
> >> > > > > + - asus,tf101g-ec-dock
> >> > > > > + - asus,tf201-ec-dock
> >> > > > > + - asus,tf300t-ec-dock
> >> > > > > + - asus,tf300tg-ec-dock
> >> > > > > + - asus,tf300tl-ec-dock
> >> > > > > + - asus,tf700t-ec-dock
> >> > > > > + - const: asus,transformer-ec-dock
> >> > > > > +
> >> > > > > + - items:
> >> > > > > + - enum:
> >> > > > > + - asus,tf201-ec-pad
> >> > > > > + - asus,tf300t-ec-pad
> >> > > > > + - asus,tf300tg-ec-pad
> >> > > > > + - asus,tf300tl-ec-pad
> >> > > > > + - asus,tf700t-ec-pad
> >> > > > > + - const: asus,transformer-ec-pad
> >
> >> > > > Also, why are some of the compatibles permitted standalone? That should
> >> > > > be mentioned in your commit message too. Also, other than the sl101, the
> >> > > > standalone ones seem to have the same match data in the mfd driver. Why
> >> > > > are fallbacks not made use of there?
> >> > > >
> >> > >
> >> > > Because standalone compatibles describe a unique hw configuration
> >> > > which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
> >> > > is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
> >> > > for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
> >> > > in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
> >> > > Different generations, different form-factors.
> >> >
> >> > I don't see any reasons here that eliminate fallback compatibles.
> >> > + { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
> >> > + { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
> >> > + { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
> >> > + { }
> >> > Three of them use the same match data, so you need to explain why you've
> >> > made these three standalone when all the others that share a programming
> >> > model got a generic fallback. Fallback usage is based on programming
> >> > model, not based on whether the devices are a physically different, so
> >> > your explanation must reflect this.
> >> >
> >> > > > Since this transformer series seems to have multiple programming models
> >> > > > for "ec-pad" devices, it calls into question your use of the generic
> >> > > > fallback compatibles is appropriate and makes it seem like you should be
> >> > > > using device compatibles as a fallback.
> >> > >
> >> > > That is redundant.
> >> >
> >> > I don't understand how that is a response to what I said.
> >> >
> >>
> >> in other words you propose this:
> >>
> >> properties:
> >> compatible:
> >> oneOf:
> >> - items:
> >> - enum:
> >> - asus,sl101-ec-dock
> >> - asus,tf101-ec-dock
> >> - asus,tf101g-ec-dock
> >> - asus,tf201-ec-dock
> >> - asus,tf300t-ec-dock
> >> - asus,tf300tg-ec-dock
> >> - asus,tf300tl-ec-dock
> >> - asus,tf700t-ec-dock
> >> - const: asus,transformer-ec-dock
> >>
> >> - items:
> >> - enum:
> >> - asus,p1801-t-ec-pad
> >> - asus,tf201-ec-pad
> >> - asus,tf300t-ec-pad
> >> - asus,tf300tg-ec-pad
> >> - asus,tf300tl-ec-pad
> >> - asus,tf700t-ec-pad
> >> - asus,tf600t-ec-pad
> >> - asus,tf701t-ec-pad
> >> - const: asus,transformer-ec-pad
> >>
> >> And in the driver add match to every single entry of enums?
> >
> >No, I was talking about removing the generic compatibles entirely, since
> >they are not suitably generic to cover all devices at the point of
> >addition. So like:
> >
>
> Actually, they all can be grouped under asus,transformer-ec fallback if that is needed, both pad and dock EC have the same core functions just different set of cells. And then in the driver each compatible will get a dedicated matching data. Will this work?
>
> properties:
> compatible:
> - items:
> - enum:
> - asus,p1801-t-ec-pad
> - asus,sl101-ec-dock
> - asus,tf101-ec-dock
> - asus,tf101g-ec-dock
> - asus,tf201-ec-dock
> - asus,tf201-ec-pad
> - asus,tf300t-ec-dock
> - asus,tf300t-ec-pad
> - asus,tf300tg-ec-dock
> - asus,tf300tg-ec-pad
> - asus,tf300tl-ec-dock
> - asus,tf300tl-ec-pad
> - asus,tf700t-ec-dock
> - asus,tf700t-ec-pad
> - asus,tf600t-ec-pad
> - asus,tf701t-ec-pad
> - const: asus,transformer-ec
>
> And them schema name will match the genetic compatible.
>
> >items:
> > - enum:
> > - asus,tf101-ec-dock
> > - asus,tf101g-ec-dock
> > - asus,tf201-ec-dock
> > - asus,tf300t-ec-dock
> > - asus,tf300tg-ec-dock
> > - asus,tf300tl-ec-dock
> > - const: asus,tf700t-ec-dock
> >
> >and
> >
> >items:
> > - enum:
> > - asus,p1801-t-ec-pad
> > - asus,tf600t-ec-pad
> > - const: asus,tf701t-ec-pad
> >
> >I dunno about these particular devices, but if there's already two
> >programming models for these devices, what's to stop there being more
> >added if/when a new generation of produces arrives?
>
> There will be no new devices with this EC, last one was around 2013.
And what is to stop the next device in 2027 or w/e having a different
programming model (so a third)? That's my point, I wasn't talking about
there being more devices with two programming models evidenced here.
On 17/02/2026 12:05, Conor Dooley wrote:
> On Mon, Feb 16, 2026 at 09:14:40PM +0200, Svyatoslav Ryhel wrote:
>> пн, 16 лют. 2026 р. о 20:50 Conor Dooley <conor@kernel.org> пише:
>>>
>>> On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
>>>> пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
>>>>>
>>>>> On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
>>>>>> Document embedded controller used in ASUS Transformer device series.
>>>>>>
>>>>>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>>>>>> ---
>>>>>> .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
>>>>>> 1 file changed, 98 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..670c4c2d339d
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>>>>>> @@ -0,0 +1,98 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: ASUS Transformer's Embedded Controller
>>>>>> +
>>>>>> +description:
>>>>>> + Several Nuvoton based Embedded Controllers attached to an I2C bus,
>>>>>> + running a custom ASUS firmware, specific to the ASUS Transformer
>>>>>> + device series.
>>>>>> +
>>>>>> +maintainers:
>>>>>> + - Svyatoslav Ryhel <clamor95@gmail.com>
>>>>>> +
>>>>>> +allOf:
>>>>>> + - $ref: /schemas/power/supply/power-supply.yaml
>>>>>> +
>>>>>> +properties:
>>>>>> + compatible:
>>>>>> + oneOf:
>>>>>> + - enum:
>>>>>> + - asus,p1801-t-ec-pad
>>>>>> + - asus,sl101-ec-dock
>>>>>> + - asus,tf600t-ec-pad
>>>>>> + - asus,tf701t-ec-pad
>>>>>> +
>>>>>> + - items:
>>>>>> + - enum:
>>>>>> + - asus,tf101-ec-dock
>>>>>> + - asus,tf101g-ec-dock
>>>>>> + - asus,tf201-ec-dock
>>>>>> + - asus,tf300t-ec-dock
>>>>>> + - asus,tf300tg-ec-dock
>>>>>> + - asus,tf300tl-ec-dock
>>>>>> + - asus,tf700t-ec-dock
>>>>>> + - const: asus,transformer-ec-dock
>>>>>> +
>>>>>> + - items:
>>>>>> + - enum:
>>>>>> + - asus,tf201-ec-pad
>>>>>> + - asus,tf300t-ec-pad
>>>>>> + - asus,tf300tg-ec-pad
>>>>>> + - asus,tf300tl-ec-pad
>>>>>> + - asus,tf700t-ec-pad
>>>>>> + - const: asus,transformer-ec-pad
>
>>>>> Also, why are some of the compatibles permitted standalone? That should
>>>>> be mentioned in your commit message too. Also, other than the sl101, the
>>>>> standalone ones seem to have the same match data in the mfd driver. Why
>>>>> are fallbacks not made use of there?
>>>>>
>>>>
>>>> Because standalone compatibles describe a unique hw configuration
>>>> which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
>>>> is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
>>>> for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
>>>> in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
>>>> Different generations, different form-factors.
>>>
>>> I don't see any reasons here that eliminate fallback compatibles.
>>> + { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
>>> + { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
>>> + { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
>>> + { }
>>> Three of them use the same match data, so you need to explain why you've
>>> made these three standalone when all the others that share a programming
>>> model got a generic fallback. Fallback usage is based on programming
>>> model, not based on whether the devices are a physically different, so
>>> your explanation must reflect this.
>>>
>>>>> Since this transformer series seems to have multiple programming models
>>>>> for "ec-pad" devices, it calls into question your use of the generic
>>>>> fallback compatibles is appropriate and makes it seem like you should be
>>>>> using device compatibles as a fallback.
>>>>
>>>> That is redundant.
>>>
>>> I don't understand how that is a response to what I said.
>>>
>>
>> in other words you propose this:
>>
>> properties:
>> compatible:
>> oneOf:
>> - items:
>> - enum:
>> - asus,sl101-ec-dock
>> - asus,tf101-ec-dock
>> - asus,tf101g-ec-dock
>> - asus,tf201-ec-dock
>> - asus,tf300t-ec-dock
>> - asus,tf300tg-ec-dock
>> - asus,tf300tl-ec-dock
>> - asus,tf700t-ec-dock
>> - const: asus,transformer-ec-dock
>>
>> - items:
>> - enum:
>> - asus,p1801-t-ec-pad
>> - asus,tf201-ec-pad
>> - asus,tf300t-ec-pad
>> - asus,tf300tg-ec-pad
>> - asus,tf300tl-ec-pad
>> - asus,tf700t-ec-pad
>> - asus,tf600t-ec-pad
>> - asus,tf701t-ec-pad
>> - const: asus,transformer-ec-pad
>>
>> And in the driver add match to every single entry of enums?
>
> No, I was talking about removing the generic compatibles entirely, since
> they are not suitably generic to cover all devices at the point of
> addition. So like:
Yep. Generic compatible has hardly a meaning if you already know it is
not generic enough - some devices are not compatible with it.
Each SoC/platform which pushed to these generic compatible, hit a wall
after some months/years. Apple is a nice example now.
Best regards,
Krzysztof
© 2016 - 2026 Red Hat, Inc.