From: Markus Probst <markus.probst@posteo.de>
Add the Synology Microp devicetree bindings. Those devices are
microcontrollers found on Synology NAS devices. They are connected to a
serial port on the host device.
Those devices are used to control certain LEDs, fan speeds, a beeper, to
handle buttons, fan failures and to properly shutdown and reboot the
device.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
.../devicetree/bindings/leds/synology,microp.yaml | 40 +++++++++++++++++
.../devicetree/bindings/mfd/synology,microp.yaml | 51 ++++++++++++++++++++++
2 files changed, 91 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/synology,microp.yaml b/Documentation/devicetree/bindings/leds/synology,microp.yaml
new file mode 100644
index 000000000000..f7bf32c240f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/synology,microp.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/synology,microp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synology NAS on-board Microcontroller LEDs
+
+maintainers:
+ - Markus Probst <markus.probst@posteo.de>
+
+description: |
+ This is part of device tree bindings for Synology NAS on-board
+ Microcontroller.
+
+ This device can manage up to 4 leds in Synology NAS devices:
+ - Power
+ - Status
+ - Alert
+ - USB
+
+ The Power and Status LEDs are available on every Synology NAS model,
+ therefore the associated child nodes are mandatory. If the NAS also has
+ a alert or usb led, the associated child nodes need to be added.
+
+properties:
+ compatible:
+ const: synology,microp-leds
+
+patternProperties:
+ "^(power|status|alert|usb)-led$":
+ $ref: /schemas/leds/common.yaml
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - power-led
+ - status-led
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/synology,microp.yaml b/Documentation/devicetree/bindings/mfd/synology,microp.yaml
new file mode 100644
index 000000000000..57bb986d24f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/synology,microp.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/synology,microp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synology NAS on-board Microcontroller
+
+maintainers:
+ - Markus Probst <markus.probst@posteo.de>
+
+description: |
+ Synology Microp is a microcontroller found in Synology NAS devices.
+ It is connected to a serial port on the host device.
+
+ It is a multifunction device with the following sub modules:
+ - LEDs
+
+properties:
+ compatible:
+ const: synology,microp
+
+ leds:
+ $ref: /schemas/leds/synology,microp.yaml
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ mcu {
+ compatible = "synology,microp";
+
+ leds {
+ compatible = "synology,microp-leds";
+
+ power-led {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_POWER;
+ };
+
+ status-led {
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_STATUS;
+ };
+ };
+ };
--
2.52.0On 13/03/2026 20:03, Markus Probst via B4 Relay wrote: > From: Markus Probst <markus.probst@posteo.de> > > Add the Synology Microp devicetree bindings. Those devices are > microcontrollers found on Synology NAS devices. They are connected to a > serial port on the host device. > > Those devices are used to control certain LEDs, fan speeds, a beeper, to > handle buttons, fan failures and to properly shutdown and reboot the > device. > > Signed-off-by: Markus Probst <markus.probst@posteo.de> > --- You keep sending the same without responding to review. NAK Best regards, Krzysztof
On Fri, 2026-03-13 at 20:37 +0100, Krzysztof Kozlowski wrote:
> On 13/03/2026 20:03, Markus Probst via B4 Relay wrote:
> > From: Markus Probst <markus.probst@posteo.de>
> >
> > Add the Synology Microp devicetree bindings. Those devices are
> > microcontrollers found on Synology NAS devices. They are connected to a
> > serial port on the host device.
> >
> > Those devices are used to control certain LEDs, fan speeds, a beeper, to
> > handle buttons, fan failures and to properly shutdown and reboot the
> > device.
> >
> > Signed-off-by: Markus Probst <markus.probst@posteo.de>
> > ---
>
> You keep sending the same without responding to review.
>
> NAK
All review comments have been resolved to my knowledge, but here a
formal reply to all of them.
> A nit, subject: drop second/last, redundant "binding for". The
> "dt-bindings" prefix is already stating that these are bindings.
Has been removed from the patch subject.
> > +description: |
> Do not need '|' unless you need to preserve formatting.
It got removed in v2.
In the current patch revision v3, it is needed because it has ":" in
the description (to ensure it does not get interpreted as property).
Thus it has been readded.
> > +properties:
> > + compatible:
> > + enum:
> > + - synology,microp
> Missing blank line. Look at other bindings how to write one.
Blank line has been added.
> > + power-led:
> > + $ref: /schemas/leds/common.yaml
> > + unevaluatedProperties: false
> > + status-led:
> > + $ref: /schemas/leds/common.yaml
> > + unevaluatedProperties: false
> > + alert-led:
> > + $ref: /schemas/leds/common.yaml
> > + unevaluatedProperties: false
> > + usb-led:
> > + $ref: /schemas/leds/common.yaml
> > + unevaluatedProperties: false
> That's pretty unreadable code.
>
> ... and could be simpler with patternProperties and regex
It has been minified using patternProperties.
> > + no-check-fan:
> Vendor prefix
> > + type: boolean
> > + description: |
> > + Disable fan failure check.
>
> You described the desired Linux feature or behavior, not the actual
> hardware. The bindings are about the latter, so instead you need to
> rephrase the property and its description to match actual hardware
> capabilities/features/configuration etc.
> > +
> > + The fan failure event is triggered on the device, even if
the fan
> > + has been intentionally set to a low speed. This property
prevents a
> > + hardware protection shutdown if a fan failure event is
reported.
> > + no-check-cpu-fan:
>
> You described the desired Linux feature or behavior, not the actual
> hardware. The bindings are about the latter, so instead you need to
> rephrase the property and its description to match actual hardware
> capabilities/features/configuration etc.
The 2 properties have been removed entirely. Thus those comments are
not relevant anymore.
> > + uart {
>
> Drop, unuesed
Has been dropped.
> > + microp {
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
>
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> If you cannot find a name matching your device, please check in
kernel
> sources for similar cases or you can grow the spec (via pull request
to
> DT spec repo).
node name has been changed to mcu.
> You we have tools which save you review time. Most important, save
> maintainers/reviewers time from giving feedback on obvious mistakes.
> You
> must use these tools, otherwise maintainers get grumpy by wasting
their
> time.
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on
the
> patches and (probably) fix more warnings. Some warnings can be
ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
with the exception of
- help paragraph having less than 4 lines in Kconfig (not necessary in
this case)
- of_device_id not being const (it has to be)
- "added, moved or deleted file(s), does MAINTAINERS need updating?"
(file will be added in a following patch)
there are no warnings left.
> This is not an "MFD" device.
It now uses the MFD APIs. By the definiton of @Lee (assuming I
understood it correctly), this device should now qualify as "MFD"
device.
> > +
> > + mcu {
>
> Please read previous comments.
You are likly trying to refer to this comment from you:
> Depending what this is. MCU is generic purpose unit where you load
your
> different FW for different purposes and you have here specific - to
> handle certain aspects of this entire machine. This looks like EC, so
> should be called embedded-controller and placed in that directory.
Synology uses Microchip PIC for this purpose. On a Synology DS215j, it
uses a "Microchip PIC16F1829". At least to me, this looks like a
general purpose microcontroller with firmware from synology flashed
onto it. Therefore it is a MCU.
If I did miss any relevant comments, let me know.
(Replies on replies on review comments have not been included here).
>
> Best regards,
> Krzysztof
Thanks
- Markus Probst
On 13/03/2026 21:29, Markus Probst wrote:
>
>> This is not an "MFD" device.
> It now uses the MFD APIs. By the definiton of @Lee (assuming I
> understood it correctly), this device should now qualify as "MFD"
> device.
No. Using Linux framework does not make this device MFD, since there is
no such term of hardware as MFD. Otherwise please explain or link to
verifiable external source describing what sort of device class is MFD,
because for sure this is not MFD how Wikipedia defines it.
>
>>> +
>>> + mcu {
>>
>> Please read previous comments.
>
> You are likly trying to refer to this comment from you:
>> Depending what this is. MCU is generic purpose unit where you load
> your
>> different FW for different purposes and you have here specific - to
>> handle certain aspects of this entire machine. This looks like EC, so
>> should be called embedded-controller and placed in that directory.
> Synology uses Microchip PIC for this purpose. On a Synology DS215j, it
> uses a "Microchip PIC16F1829". At least to me, this looks like a
It does not matter what chip is used. Every component uses some sort of
chip.
> general purpose microcontroller with firmware from synology flashed
> onto it. Therefore it is a MCU.
Every chip is then an MCU with such logic. Every PMIC, every EC.
This is for me clearly embedded controller and that's where this should
be placed and called.
Best regards,
Krzysztof
On Sat, 2026-03-14 at 09:49 +0100, Krzysztof Kozlowski wrote:
> On 13/03/2026 21:29, Markus Probst wrote:
> >
> > > This is not an "MFD" device.
> > It now uses the MFD APIs. By the definiton of @Lee (assuming I
> > understood it correctly), this device should now qualify as "MFD"
> > device.
>
> No. Using Linux framework does not make this device MFD, since there is
> no such term of hardware as MFD. Otherwise please explain or link to
> verifiable external source describing what sort of device class is MFD
I assumed these comments would also apply for the dt bindings:
-
https://lore.kernel.org/rust-for-linux/DGYAFNSJ7576.1E0JZ2W499ZQ7@kernel.org/
-
https://lore.kernel.org/rust-for-linux/20260309151555.GU183676@google.com/
given that using linux MFD APIs also changes the structure of the dt
bindings with added sub-devices.
But it seems no?
> because for sure this is not MFD how Wikipedia defines it.
Wikipedia defines it as a synonym for a "multi-function
product/printer/peripheral"
https://en.wikipedia.org/wiki/Multifunction_device
>
> >
> > > > +
> > > > + mcu {
> > >
> > > Please read previous comments.
> >
> > You are likly trying to refer to this comment from you:
> > > Depending what this is. MCU is generic purpose unit where you load
> > your
> > > different FW for different purposes and you have here specific - to
> > > handle certain aspects of this entire machine. This looks like EC, so
> > > should be called embedded-controller and placed in that directory.
> > Synology uses Microchip PIC for this purpose. On a Synology DS215j, it
> > uses a "Microchip PIC16F1829". At least to me, this looks like a
>
> It does not matter what chip is used. Every component uses some sort of
> chip.
I would be interested in what does matter then.
I did not actually find an exact definition for what
Documentation/devicetree/bindings/mfd
and
Documentation/devicetree/bindings/embedded-controller
is for in the kernel tree or in the devicetree spec.
>
> > general purpose microcontroller with firmware from synology flashed
> > onto it. Therefore it is a MCU.
>
> Every chip is then an MCU with such logic. Every PMIC, every EC.
>
> This is for me clearly embedded controller and that's where this should
> be placed and called.
In that case I will move it to
Documentation/devicetree/bindings/embedded-controller and update the
node name used in the example.
I will wait a bit for the other patches to be reviewed before sending a
next revision.
But I wonder how
Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
got in there then, given it is pretty similar to this device in the
functionality it provides.
>
> Best regards,
> Krzysztof
Thanks
- Markus Probst
On 14/03/2026 13:31, Markus Probst wrote:
> On Sat, 2026-03-14 at 09:49 +0100, Krzysztof Kozlowski wrote:
>> On 13/03/2026 21:29, Markus Probst wrote:
>>>
>>>> This is not an "MFD" device.
>>> It now uses the MFD APIs. By the definiton of @Lee (assuming I
>>> understood it correctly), this device should now qualify as "MFD"
>>> device.
>>
>> No. Using Linux framework does not make this device MFD, since there is
>> no such term of hardware as MFD. Otherwise please explain or link to
>> verifiable external source describing what sort of device class is MFD
> I assumed these comments would also apply for the dt bindings:
> -
> https://lore.kernel.org/rust-for-linux/DGYAFNSJ7576.1E0JZ2W499ZQ7@kernel.org/
> -
> https://lore.kernel.org/rust-for-linux/20260309151555.GU183676@google.com/
I don't understand your question. We talk here about bindings, so why do
you ask if the comments are about bindings?
>
> given that using linux MFD APIs also changes the structure of the dt
> bindings with added sub-devices.
>
> But it seems no?
>
>> because for sure this is not MFD how Wikipedia defines it.
>
> Wikipedia defines it as a synonym for a "multi-function
> product/printer/peripheral"
> https://en.wikipedia.org/wiki/Multifunction_device
I know, not need to state obvious. And this is not a printer.
>
>>
>>>
>>>>> +
>>>>> + mcu {
>>>>
>>>> Please read previous comments.
>>>
>>> You are likly trying to refer to this comment from you:
>>>> Depending what this is. MCU is generic purpose unit where you load
>>> your
>>>> different FW for different purposes and you have here specific - to
>>>> handle certain aspects of this entire machine. This looks like EC, so
>>>> should be called embedded-controller and placed in that directory.
>>> Synology uses Microchip PIC for this purpose. On a Synology DS215j, it
>>> uses a "Microchip PIC16F1829". At least to me, this looks like a
>>
>> It does not matter what chip is used. Every component uses some sort of
>> chip.
> I would be interested in what does matter then.
>
> I did not actually find an exact definition for what
> Documentation/devicetree/bindings/mfd
Because there is no such hardware as MFD.
> and
> Documentation/devicetree/bindings/embedded-controller
> is for in the kernel tree or in the devicetree spec.
Commit msg moving several devices there explained, no?
>
>>
>>> general purpose microcontroller with firmware from synology flashed
>>> onto it. Therefore it is a MCU.
>>
>> Every chip is then an MCU with such logic. Every PMIC, every EC.
>>
>> This is for me clearly embedded controller and that's where this should
>> be placed and called.
> In that case I will move it to
> Documentation/devicetree/bindings/embedded-controller and update the
> node name used in the example.
>
> I will wait a bit for the other patches to be reviewed before sending a
> next revision.
>
> But I wonder how
> Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
> got in there then, given it is pretty similar to this device in the
> functionality it provides.
Great question. How do any bugs, mistakes, different judgments or
imperfectness got merged? How is it possible that code for example is
reviewed but has a bug? Don't ever use arguments that something
somewhere happened, so you can do the same.
Not mentioning that if you even question this, you could at least look
at the history which would tell you if "embedded-controller" directory
existed that time or not.
Best regards,
Krzysztof
On Sat, 2026-03-14 at 14:59 +0100, Krzysztof Kozlowski wrote:
> On 14/03/2026 13:31, Markus Probst wrote:
> > On Sat, 2026-03-14 at 09:49 +0100, Krzysztof Kozlowski wrote:
> > > On 13/03/2026 21:29, Markus Probst wrote:
> > > >
> > > > > This is not an "MFD" device.
> > > > It now uses the MFD APIs. By the definiton of @Lee (assuming I
> > > > understood it correctly), this device should now qualify as "MFD"
> > > > device.
> > >
> > > No. Using Linux framework does not make this device MFD, since there is
> > > no such term of hardware as MFD. Otherwise please explain or link to
> > > verifiable external source describing what sort of device class is MFD
> > I assumed these comments would also apply for the dt bindings:
> > -
> > https://lore.kernel.org/rust-for-linux/DGYAFNSJ7576.1E0JZ2W499ZQ7@kernel.org/
> > -
> > https://lore.kernel.org/rust-for-linux/20260309151555.GU183676@google.com/
>
> I don't understand your question. We talk here about bindings, so why do
> you ask if the comments are about bindings?
>
> >
> > given that using linux MFD APIs also changes the structure of the dt
> > bindings with added sub-devices.
> >
> > But it seems no?
>
> >
> > > because for sure this is not MFD how Wikipedia defines it.
> >
> > Wikipedia defines it as a synonym for a "multi-function
> > product/printer/peripheral"
> > https://en.wikipedia.org/wiki/Multifunction_device
>
> I know, not need to state obvious. And this is not a printer.
>
>
>
> >
> > >
> > > >
> > > > > > +
> > > > > > + mcu {
> > > > >
> > > > > Please read previous comments.
> > > >
> > > > You are likly trying to refer to this comment from you:
> > > > > Depending what this is. MCU is generic purpose unit where you load
> > > > your
> > > > > different FW for different purposes and you have here specific - to
> > > > > handle certain aspects of this entire machine. This looks like EC, so
> > > > > should be called embedded-controller and placed in that directory.
> > > > Synology uses Microchip PIC for this purpose. On a Synology DS215j, it
> > > > uses a "Microchip PIC16F1829". At least to me, this looks like a
> > >
> > > It does not matter what chip is used. Every component uses some sort of
> > > chip.
> > I would be interested in what does matter then.
> >
> > I did not actually find an exact definition for what
> > Documentation/devicetree/bindings/mfd
>
> Because there is no such hardware as MFD.
>
> > and
> > Documentation/devicetree/bindings/embedded-controller
> > is for in the kernel tree or in the devicetree spec.
>
> Commit msg moving several devices there explained, no?
yes.
>
>
> >
> > >
> > > > general purpose microcontroller with firmware from synology flashed
> > > > onto it. Therefore it is a MCU.
> > >
> > > Every chip is then an MCU with such logic. Every PMIC, every EC.
> > >
> > > This is for me clearly embedded controller and that's where this should
> > > be placed and called.
> > In that case I will move it to
> > Documentation/devicetree/bindings/embedded-controller and update the
> > node name used in the example.
> >
> > I will wait a bit for the other patches to be reviewed before sending a
> > next revision.
> >
> > But I wonder how
> > Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
> > got in there then, given it is pretty similar to this device in the
> > functionality it provides.
>
> Great question. How do any bugs, mistakes, different judgments or
> imperfectness got merged? How is it possible that code for example is
> reviewed but has a bug? Don't ever use arguments that something
> somewhere happened, so you can do the same.
I was not trying to use this as an argument. As you can see above I
already agreed to put it into embedded-controller.
I was interested in knowing, if there was a difference between the two
devices I did not know of, as the bindings for this device go into
another directory despite the similarity (no need to answer it anymore,
see below).
But I see why that hasn't been clear.
>
> Not mentioning that if you even question this, you could at least look
> at the history which would tell you if "embedded-controller" directory
> existed that time or not.
yes, that would have made my question entirely obsolete.
>
> Best regards,
> Krzysztof
Thanks
- Markus Probst
© 2016 - 2026 Red Hat, Inc.