Re: [PATCH v18 0/2] Introduce Synology Microp driver

[Lee Jones]

On Fri, 24 Jul 2026, Markus Probst wrote:

> On Fri, 2026-07-24 at 23:20 +0300, Onur Özkan wrote:
> > On Fri, 24 Jul 2026 18:45:56 +0000
> > Markus Probst <markus.probst@xxxxxxxxx> wrote:
> > 
> > > On Fri, 2026-07-24 at 21:41 +0300, Onur Özkan wrote:
> > > > On Fri, 24 Jul 2026 17:10:44 +0000
> > > > Markus Probst <markus.probst@xxxxxxxxx> wrote:
> > > > 
> > > > > Synology uses a microcontroller in their NAS devices connected to a
> > > > > serial port to control certain LEDs, fan speeds, a beeper, to handle
> > > > > proper shutdown and restart, buttons and fan failures.
> > > > > 
> > > > > This patch series depends on the rust led abstraction [1] and the rust
> > > > > serdev abstraction [2]. The latter already being in driver-core.
> > > > > 
> > > > > This is only a initial version of the driver able to control LEDs.
> > > > > The following rust abstractions would be required, to implement the
> > > > > remaining features:
> > > > > - hwmon (include/linux/hwmon.h)
> > > > > - input (include/linux/input.h)
> > > > > - sysoff handler (include/linux/reboot.h)
> > > > > 
> > > > > [1] https://lore.kernel.org/rust-for-linux/20260716-rust_leds-v23-0-e91f5b608b56@xxxxxxxxx/
> > > > > [2] https://lore.kernel.org/rust-for-linux/20260718-rust_serdev-v16-0-5809384d2e1b@xxxxxxxxx/
> > > > > 
> > > > > Signed-off-by: Markus Probst <markus.probst@xxxxxxxxx>
> > > > > ---
> > > > > Changes in v18:
> > > > > - fix issues reported by Sashiko:
> > > > >   - fix hardware blink delays not reported if every subled has
> > > > >     intensity = 0
> > > > > - fix blink aborting if every subled has intensity = 0
> > > > > - Link to v17: https://patch.msgid.link/20260724-synology_microp_initial-v17-0-e2f70b4dc691@xxxxxxxxx
> > > > > 
> > > > > Changes in v17:
> > > > > - adapted to rust serdev abstraction v16
> > > > > - Link to v16: https://patch.msgid.link/20260629-synology_microp_initial-v16-0-601e91c49e0d@xxxxxxxxx
> > > > > 
> > > > 
> > > > Hi Markus,
> > > > 
> > > > Please avoid sending multiple versions within a very short timeframe and give us
> > > > some time (at least a day) to review before sending another version.
> > > Correct me if I am wrong, but wasn't Sashiko reviews the exception to
> > > this?
> > > 
> > 
> > To me, that doesn't make much sense because it effectively means you could send
> > 3–4 versions depending on how Sashiko behaves. Imagine multiple people sending
> > large patch series several times in a row (and it could easily be more than
> > twice). That would make things much harder for other people as the mailing list
> > would become very spammy.
> Yes, that would be an issue, especially in your example.
> 
> A pre-review Sashiko mailing list would be great to avoid the issue
> alltogether.

You can run Sashiko locally.

-- 
Lee Jones