Re: [PATCH v3 7/7] leds: add synology microp led driver

[Danilo Krummrich]

On Sun Mar 15, 2026 at 7:47 PM CET, Markus Probst wrote:
> On Sun, 2026-03-15 at 19:20 +0100, Danilo Krummrich wrote:
>> Isn't this handled through IRQs, i.e. you device issues an IRQ and then you read
>> from the serial bus?
>> 
>> (I'm asking since such chips can usually be connected via different busses, e.g.
>> serial and I2C. And with I2C the slave can't issue a transfer by itself.)
>> 
>> Other MFD drivers register their own IRQ chip for this. I.e. one would register
>> an IRQ chip in the MFD driver and pass it to the sub-devices created through
>> mfd_add_devices(). Then the sub-device receives an IRQ and reads the regmap.
> You mean registering a virtual IRQ and triggering it on data receival?

Not really virtual, there are a lot of MFD drivers that register their own IRQ
chip to forward only relevant IRQs to the sub-device.

What you say should work as well, but as mentioned below, I feel like that's
overkill.

> Could you provide an example driver in the tree?

One example would be drivers/mfd/palmas.c, but there should be many more.

>> Now, if you don't have IRQs at all and the only event you get is through
>> receive_buf() (which implies that the chip is only compatible with a serial bus)
>> this technically still works, but might be a bit overkill.
>
> There is a physical IRQ, but the serial device bus abstracts that so
> the driver only has the receive_buf() function. The driver it self is
> not aware of an IRQs.

I think you are confusing the IRQ of the serial bus controller with a device
IRQ. The serial bus controller the device is connected to has an IRQ itself, but
what I mean is a device IRQ line.

This is very common for devices on busses such as I2C, SPI, etc., as they have
master/slave semantics. I.e. the device issues an IRQ and the kernel reads a
register subsequently.

UART does not force master/slave sematics on a bus level though.

That's why I asked whether the device is UART only, or if it supports other
busses as well.

> Having like a reverse regmap would be great (in addition), in which the
> mfd device is the one who calls write and the sub-device has to handle
> it. But I don't think something like this exists in the kernel.

I mean, it's not really that the kernel exposes registers to the device. The
device just uses the fact that the UART is not a master/slave bus and pushes a
single byte to the kernel to signal that a button has been pressed. So, it's
still "IRQ semantics".

(But I see that on abstract level one could argue in this direction.)

TBH, I think that the combination of this chip supporting multiple functions and
being connected through UART, where the device pushes bytes through the UART to
signal events is a bit of an edge case.

As mentioned, if it would be connected through I2C instead, it would be simple:
forward the IRQ and use a regmap, and you can do it entirely with generic
infrastructure and no custom APIs, which in the end is the idea of MFD. I.e. you
can describe the whole sub-device with a struct mfd_cell.

And while we could technically "emulate" this, it remains to be odd and has
unnecessary overhead.

I've seen one other case in the kernel, which is drivers/mfd/rave-sp.c. But this
driver doesn't use MFD infrastructure at all and just goes for a custom API,
which clearly defeats the purpose of MFD in the first place. I.e. it shouldn't
even live under drivers/mfd/.

Greg already mentioned the auxiliary bus, which for a custom API clearly is the
better choice.

But to be honest, the more I hear about this device, the more I feel like a
monolithic driver is all that's needed, as everything else sounds like overhead
that doesn't really provide any value.

I.e. if we can't (easily) use mfd cells and would need a custom API, then why
even split it up at all, given that splitting it up would probably the most
complicated part of the whole driver.

Greg, what do you think?

*me runs away*