Re: [PATCH v7 2/2] dt-bindings: embedded-controller: Add synology microp devices

[Markus Probst]

On Sun, 2026-04-12 at 15:22 +0200, Krzysztof Kozlowski wrote:
> On 12/04/2026 15:21, Markus Probst wrote:
> > On Sun, 2026-04-12 at 10:26 +0200, Krzysztof Kozlowski wrote:
> > > On Sat, Apr 11, 2026 at 05:27:35PM +0200, Markus Probst wrote:
> > > > +properties:
> > > > +  compatible:
> > > > +    enum:
> > > > +      - synology,ds923p-microp
> > > > +      - synology,ds918p-microp
> > > > +      - synology,ds214play-microp
> > > > +      - synology,ds225p-microp
> > > > +      - synology,ds425p-microp
> > > > +      - synology,ds710p-microp
> > > > +      - synology,ds1010p-microp
> > > > +      - synology,ds723p-microp
> > > > +      - synology,ds1522p-microp
> > > > +      - synology,rs422p-microp
> > > > +      - synology,ds725p-microp
> > > > +      - synology,ds118-microp
> > > > +      - synology,ds124-microp
> > > > +      - synology,ds223-microp
> > > > +      - synology,ds223j-microp
> > > > +      - synology,ds1823xsp-microp
> > > > +      - synology,rs822p-microp
> > > > +      - synology,rs1221p-microp
> > > > +      - synology,rs1221rpp-microp
> > > > +      - synology,ds925p-microp
> > > > +      - synology,ds1525p-microp
> > > > +      - synology,ds1825p-microp
> > > 
> > > Previous comment is not resolved. For example you stated that ds723p is
> > > compatible with ds725p, so this should be expressed.
> > Using this expression?
> > 
> > properties:
> >   compatible:
> >     oneOf:
> >       - enum:
> >           - synology,ds923p-microp
> >           - synology,ds1522p-microp
> >       - enum:
> >           - synology,ds918p-microp
> >           - synology,ds415p-microp
> >       - const: synology,ds214play-microp
> > ...
> > ?
> > If so shall there each be a description?
> 
> No, you changed nothing. You need fallbacks, please read example-schema
> or DTS101 slides.
The documentation says to "use fallback compatibles when devices are
the same as or a superset of prior implementations" [1].

Differences are not publicly documented in this device, making it hard
to tell if it is a superset or the same implementation. This would make
no device a fallback, as compatibility is not guaranteed. I could
imagine it would be an ABI breakage if a fallback is no longer
considered compatible with a device later on.

If deciding based on driver compatibility (accepting loss of features
and accounting for future driver features), one device entry would look
like this:

- items:
  - const: synology,ds923p-microp
  - const: synology,ds1522p-microp
  - const: synology,ds925p-microp # no current sensor from here
  - const: synology,ds425p-microp
  - const: synology,ds1525p-microp
  - const: synology,ds918p-microp
  - const: synology,ds1823xsp-microp # no fan failure check from here
  - const: synology,ds1825p-microp

which isn't maintainable in this size for ~22 entries.


But the example schema

- items:
  - enum:
    - vendor,soc4-ip
    - vendor,soc3-ip
    - vendor,soc2-ip
  - enum:
    - vendor,soc1-ip

also does not have all of the previous devices as fallbacks (assuming
"vendor,soc3-ip" is compatible with "vendor,soc2-ip" and so on).

Only adding devices as fallbacks with the exact same known feature set
would ignore the other devices with less features which would still
work (e.g. "synology,ds925p-microp" would still work on a ds923+, but
the "current sensor" would not be accessible).

So my question is, what makes a device eligible to be a fallback for
another device?

Just using the one device that is compatible with most of the devices
(having the least features) for all of the compatible devices as
fallback like in the example?


I would prefer a generic "synology,microp-x64" entry as fallback only,
which only supports the baseline of features (power led, status led,
shutdown/reboot, power button, fan speed), which all devices I am aware
of support.
But documentation explicitly states "DON’T use wildcards or device-
family names in compatible strings" [1], so I think I am not allowed to
do that.

Thanks
- Markus Probst

[1] https://docs.kernel.org/devicetree/bindings/writing-bindings.html

> 
> Best regards,
> Krzysztof

Attachment: signature.asc
Description: This is a digitally signed message part