Re: [PATCH v3 5/7] dt-bindings: mfd: Add synology,microp device

[Markus Probst]

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@xxxxxxxxxx/
> > -
> > https://lore.kernel.org/rust-for-linux/20260309151555.GU183676@xxxxxxxxxx/
> 
> 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

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