Re: [PATCH v2 2/2] mfd: Add initial synology microp driver

[Markus Probst <markus.probst@posteo.de>]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

On Mon, 2026-03-09 at 06:56 +0100, Greg Kroah-Hartman wrote:
> On Sun, Mar 08, 2026 at 07:15:16PM +0000, Markus Probst wrote:
> > On Sun, 2026-03-08 at 19:55 +0100, Greg Kroah-Hartman wrote:
> > > On Sun, Mar 08, 2026 at 06:41:20PM +0000, Markus Probst wrote:
> > > > Add a initial synology microp driver, written in Rust.
> > > > The driver targets a microcontroller found in Synology NAS devices. It
> > > > currently only supports controlling of the power led, status led, alert
> > > > led and usb led. Other components such as fan control or handling
> > > > on-device buttons will be added once the required rust abstractions are
> > > > there.
> > > 
> > > Why is this a mfd device?  Shouldn't it be an aux device?
> > > 
> > > But this is just a serial port connection, so why is a kernel driver
> > > needed at all?
> > I am not sure what you mean.
> 
> Can't this just be controlled from userspace over the tty device to the
> uart this device uses?  Why is a kernel driver needed at all?
Like with any other bus device, it can be controlled by userspace.

But the kernel already provides the necessary userspace interfaces for
leds, hwmon, input etc. for any userspace application to access.

Furthermore it is required for proper shutdown and reboot, which is a
kernel task.

On arm devices, it completely takes care of the poweroff and reboot.
There is already a driver here drivers/power/reset/qnap-poweroff.c,
which seems to be primarily developed for QNAP, but works for Synology
too.

On x86 devices, is uses ACPI Sleep, but must still announce the
poweroff / reboot prior to the firmware call to the device for proper
shutdown / reboot. There is no existing driver that takes care of this
yet.

> 
> > It has multiple functions (leds, hwmon, power/reset, input etc.) and
> > does is a multifunction device (mfd).
> > 
> > It does not however use mfd-core or anything from the auxiliary device
> > and instead implements its functionality directly in this driver.
> 
> If it does not use mfd-core, then it should not be in drivers/mfd/
> right?  Instead, use the aux bus code to split this up into different
> devices and attach them that way, as that's what the aux bus code was
> created for.
Yes. I will split it into multiple drivers using the aux bus in the
next revision.

> 
> thanks,
> 
> greg k-h

Thanks
- Markus Probst

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]