From: Markus Probst <markus.probst@posteo.de>
To: Danilo Krummrich <dakr@kernel.org>,
Markus Probst via B4 Relay
<devnull+markus.probst.posteo.de@kernel.org>
Cc: "Lee Jones" <lee@kernel.org>, "Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.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>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Igor Korotin" <igor.korotin.linux@gmail.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Pavel Machek" <pavel@kernel.org>, "Len Brown" <lenb@kernel.org>,
"Robert Moore" <robert.moore@intel.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
rust-for-linux@vger.kernel.org, driver-core@lists.linux.dev,
linux-pci@vger.kernel.org, linux-leds@vger.kernel.org,
linux-acpi@vger.kernel.org, acpica-devel@lists.linux.dev
Subject: Re: [PATCH v3 7/7] leds: add synology microp led driver
Date: Fri, 13 Mar 2026 21:10:18 +0000 [thread overview]
Message-ID: <9f7fefeca19d2636b7a5802668dff516b2a3e5aa.camel@posteo.de> (raw)
In-Reply-To: <DH1YH0GO75H8.18YSW2VMKRB3C@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]
On Fri, 2026-03-13 at 22:00 +0100, Danilo Krummrich wrote:
> On Fri Mar 13, 2026 at 8:03 PM CET, Markus Probst via B4 Relay wrote:
> > +impl Command {
> > + fn write(self, dev: &platform::Device<Bound>) -> Result {
> > + // SAFETY: Since we have no of and no acpi match table, we assume this is a mfd sub-device
> > + // and our parent is a serial device bus device, bound to the synology microp core driver.
> > + let parent = unsafe { dev.as_ref().parent_unchecked::<serdev::Device<Bound>>() };
>
> Despite being accurate description, "assume" is not what you want to read for a
> safety justification. :)
Apparently this is how all C mfd sub-devices I have seen yet do it. Not
directly using the parent device, but assuming there is a parent
device, and accessing the drvdata of that parent device with most of
the time to little checking.
Some examples:
drivers/leds/leds-lm3533.c:
- assuming there is a parent device
- assuming the drvdata of the parent device has the type `lm3533_led`
- It does check however if drvdata is set.
drivers/leds/leds-upboard.c:
- assuming there is a parent device
- assuming drvdata of the parent device is set
- assuming drvdata of the parent device has the type `upboard_fpga`
>
> We don't want to directly access the serial device from this driver. Instead,
> there should be an abstraction layer of the resource you are accessing.
>
> If this would be I2C or SPI you would request the regmap of the parent at this
> point, e.g.
>
> dev.parent().regmap("led_registers")
>
> Now, this is a serial device, but regmap still works perfectly fine for this
> case. It even allows you to ensure from the MFD driver to restrict the LED
> driver of sending commands that are not LED specific by exposing a LED specific
> regmap. Additionally, if you need additional locking etc. it can all be done
> within the regmap implementation, so you entirely avoid custom APIs.
>
> I'm not sure how common regmap is for serial devices to be honest, but
> apparently there are drivers doing this and I don't really see a reason against
> it.
>
> For instance, there is drivers/iio/imu/bno055/, which is a chip that works on
> both serial and I2C busses and fully abstracts this fact with regmap.
>
> In Rust a regmap will probably become a backend of the generic I/O
> infrastructure we are working on, which will also allow you to use the
> register!() infrastructure, etc.
>
> register!() and some other generic I/O improvements will land this cycle, I/O
> projections are more likely to land next cycle.
>
> > + parent.write_all(
> > + match self {
> > + Self::Power(State::On) => &[0x34],
> > + Self::Power(State::Blink) => &[0x35],
> > + Self::Power(State::Off) => &[0x36],
> > +
> > + Self::Status(_, State::Off) => &[0x37],
> > + Self::Status(StatusLedColor::Green, State::On) => &[0x38],
> > + Self::Status(StatusLedColor::Green, State::Blink) => &[0x39],
> > + Self::Status(StatusLedColor::Orange, State::On) => &[0x3A],
> > + Self::Status(StatusLedColor::Orange, State::Blink) => &[0x3B],
> > +
> > + Self::Alert(State::On) => &[0x4C, 0x41, 0x31],
> > + Self::Alert(State::Blink) => &[0x4C, 0x41, 0x32],
> > + Self::Alert(State::Off) => &[0x4C, 0x41, 0x33],
> > +
> > + Self::Usb(State::On) => &[0x40],
> > + Self::Usb(State::Blink) => &[0x41],
> > + Self::Usb(State::Off) => &[0x42],
> > + },
> > + serdev::Timeout::Max,
> > + )?;
> > + Ok(())
> > + }
> > +}
But this looks like a better solution (the same would probably apply to
the existing C drivers).
Thanks
- Markus Probst
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
next prev parent reply other threads:[~2026-03-13 21:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 19:03 [PATCH v3 0/7] Introduce Synology Microp driver Markus Probst via B4 Relay
2026-03-13 19:03 ` [PATCH v3 1/7] rust: Add `parent_unchecked` function to `Device` Markus Probst via B4 Relay
2026-03-13 19:03 ` [PATCH v3 2/7] rust: add basic mfd abstractions Markus Probst via B4 Relay
2026-03-13 19:03 ` [PATCH v3 3/7] acpi: add acpi_of_match_device_ids Markus Probst via B4 Relay
2026-03-23 19:57 ` Rafael J. Wysocki
2026-03-24 15:30 ` Markus Probst
2026-03-24 16:01 ` Rafael J. Wysocki
2026-03-24 16:26 ` Markus Probst
2026-03-24 17:39 ` Rafael J. Wysocki
2026-03-13 19:03 ` [PATCH v3 4/7] mfd: match acpi devices against PRP0001 Markus Probst via B4 Relay
2026-03-13 19:03 ` [PATCH v3 5/7] dt-bindings: mfd: Add synology,microp device Markus Probst via B4 Relay
2026-03-13 19:37 ` Krzysztof Kozlowski
2026-03-13 20:29 ` Markus Probst
2026-03-14 8:49 ` Krzysztof Kozlowski
2026-03-14 12:31 ` Markus Probst
2026-03-14 13:59 ` Krzysztof Kozlowski
2026-03-14 14:54 ` Markus Probst
2026-03-13 19:03 ` [PATCH v3 6/7] mfd: Add synology microp core driver Markus Probst via B4 Relay
2026-03-13 19:03 ` [PATCH v3 7/7] leds: add synology microp led driver Markus Probst via B4 Relay
2026-03-13 21:00 ` Danilo Krummrich
2026-03-13 21:10 ` Markus Probst [this message]
2026-03-15 15:15 ` Markus Probst
2026-03-15 18:20 ` Danilo Krummrich
2026-03-15 18:47 ` Markus Probst
2026-03-15 19:41 ` Danilo Krummrich
2026-03-16 6:33 ` Greg Kroah-Hartman
2026-03-16 13:43 ` Markus Probst
2026-03-16 13:58 ` Greg Kroah-Hartman
2026-03-16 18:06 ` Markus Probst
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=9f7fefeca19d2636b7a5802668dff516b2a3e5aa.camel@posteo.de \
--to=markus.probst@posteo.de \
--cc=a.hindborg@kernel.org \
--cc=acpica-devel@lists.linux.dev \
--cc=aliceryhl@google.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=conor+dt@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=devnull+markus.probst.posteo.de@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=igor.korotin.linux@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=lee@kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--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