From: Markus Probst <markus.probst@posteo.de>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: "Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
"Lee Jones" <lee@kernel.org>, "Pavel Machek" <pavel@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
platform-driver-x86@vger.kernel.org, linux-leds@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v7 2/2] dt-bindings: embedded-controller: Add synology microp devices
Date: Wed, 15 Apr 2026 20:54:29 +0000 [thread overview]
Message-ID: <8c8555b3375375dac47a22fad40080fd5b4228a5.camel@posteo.de> (raw)
In-Reply-To: <125cad6c-fb58-4498-a967-41778f6f91f6@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4226 bytes --]
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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
prev parent reply other threads:[~2026-04-15 21:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-11 15:27 [PATCH v7 0/2] Introduce Synology Microp driver Markus Probst via B4 Relay
2026-04-11 15:27 ` [PATCH v7 1/2] platform: Add initial synology microp driver Markus Probst via B4 Relay
2026-04-11 16:55 ` Onur Özkan
2026-04-11 15:27 ` [PATCH v7 2/2] dt-bindings: embedded-controller: Add synology microp devices Markus Probst via B4 Relay
2026-04-12 8:26 ` Krzysztof Kozlowski
2026-04-12 13:21 ` Markus Probst
2026-04-12 13:22 ` Krzysztof Kozlowski
2026-04-15 20:54 ` Markus Probst [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8c8555b3375375dac47a22fad40080fd5b4228a5.camel@posteo.de \
--to=markus.probst@posteo.de \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=dakr@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=pavel@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox