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

[Krzysztof Kozlowski]

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?


> 
>>
>>> 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