public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Markus Probst" <markus.probst@posteo.de>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@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>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2 2/2] mfd: Add initial synology microp driver
Date: Mon, 9 Mar 2026 09:43:04 +0000	[thread overview]
Message-ID: <20260309094304.GQ183676@google.com> (raw)
In-Reply-To: <2026030913-agonizing-shoptalk-ed98@gregkh>

On Mon, 09 Mar 2026, 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?
> 
> > 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.

Correct.

If the MFD APIs are not used, your device is not a Linux MFD.

MFD is not a dumping ground for devices with more than one function.

Please place all of the relevant pieces into their respective subsystems.

-- 
Lee Jones [李琼斯]

  reply	other threads:[~2026-03-09  9:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-08 18:41 [PATCH v2 0/2] Introduce Synology Microp driver Markus Probst
2026-03-08 18:41 ` [PATCH v2 1/2] dt-bindings: mfd: Add synology,microp device Markus Probst
2026-03-09  7:17   ` Krzysztof Kozlowski
2026-03-08 18:41 ` [PATCH v2 2/2] mfd: Add initial synology microp driver Markus Probst
2026-03-08 18:55   ` Greg Kroah-Hartman
2026-03-08 19:15     ` Markus Probst
2026-03-09  5:56       ` Greg Kroah-Hartman
2026-03-09  9:43         ` Lee Jones [this message]
2026-03-09 12:52         ` Markus Probst
2026-03-09 13:07           ` Greg Kroah-Hartman
2026-03-09 13:34             ` Markus Probst
2026-03-09 13:32           ` Danilo Krummrich
2026-03-09 13:38             ` Markus Probst
2026-03-09 15:15               ` Lee Jones
2026-03-09 15:20                 ` Markus Probst
2026-03-09 15:27                   ` Lee Jones
2026-03-09 15:37                 ` Danilo Krummrich
2026-03-09 15:50                   ` Lee Jones
2026-03-08 18:56   ` Greg Kroah-Hartman
2026-03-08 19:23     ` Markus Probst
2026-03-09  5:55       ` Greg Kroah-Hartman

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=20260309094304.GQ183676@google.com \
    --to=lee@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=dakr@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=markus.probst@posteo.de \
    --cc=ojeda@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