Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 8575 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]