From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39BCA221D89; Sun, 15 Mar 2026 20:41:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773607273; cv=none; b=heh5eYuSzdMQ8f9BQnKeWO+HedphMrCCpQQ+Neia5lCY90rJXWbFmAUfSFyMt6vIA+vRQ9PV/pEzUyN4YAGK1S4RYFs5dswvRoWME9AT8GWfQEqOAN0DYecJyS6zb+ex6+jatC4rctX1rSv9TcbioQ1S06h3Oy9ukezT8Z4jhfI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773607273; c=relaxed/simple; bh=ZG2i/wUEe+jX3Uu2IabuhXNhfK0TQVp34srUSuF0ZE0=; h=Mime-Version:Content-Type:Date:Message-Id:To:From:Subject:Cc: References:In-Reply-To; b=BPOMs9RmGMBdO7dOxbx9DihaGT5Kfv1wCWLGWC98XI6g9Z2eg4IEjvY4ZjGLfpzy7k2m/fI9T61asupZNA3grEqZBMSoF8cczZPAMeXvaVG+h4UJ2LsBm8XECnpV8i3WXTbIjV/sbBvSakRkfR0gyk7IMxF9TEUxivW3wd7Kg3k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=n3u7BT1P; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="n3u7BT1P" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32E46C19421; Sun, 15 Mar 2026 20:41:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773607272; bh=ZG2i/wUEe+jX3Uu2IabuhXNhfK0TQVp34srUSuF0ZE0=; h=Date:To:From:Subject:Cc:References:In-Reply-To:From; b=n3u7BT1P80OBjNPqGpoAkBqfpJx7qkWwItZx9xtzbcQ1S9oOGi9Ipx3p1Ia4cs43a 6vw7zRb5Qj0WWQDydDrN5VzJC3JqbDyAhNrVYFTi19xESJSuNv+IbSdRL592royxRn XTVttAlonN9i4QnLbgxWM9F4ywIe4BNHCxLFt1D/MyanKXsd5iyTbCTyhnySnBODf0 I5EWiLyzLdzG7m27mTba+sTEmEDV5rm3EwVtEflCcSncHWwiAhsVkCXpYL5OeVUu/m nN7eRANa0qymi27chtkgiSXhwdxCZ8gatSXXh8n/j16iE0QPh26J9FK7v+klYNkfAt kfiuSyWpke2iQ== Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sun, 15 Mar 2026 20:41:06 +0100 Message-Id: To: "Markus Probst" From: "Danilo Krummrich" Subject: Re: [PATCH v3 7/7] leds: add synology microp led driver Cc: "Markus Probst via B4 Relay" , "Lee Jones" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Greg Kroah-Hartman" , "Miguel Ojeda" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "Rafael J. Wysocki" , "Igor Korotin" , "Daniel Almeida" , "Bjorn Helgaas" , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , "Pavel Machek" , "Len Brown" , "Robert Moore" , , , , , , , , References: <20260313-synology_microp_initial-v3-0-ad6ac463a201@posteo.de> <20260313-synology_microp_initial-v3-7-ad6ac463a201@posteo.de> <39f1c9bb0dbde9f1b60785f8e838289c888ffdb0.camel@posteo.de> In-Reply-To: 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? >>=20 >> (I'm asking since such chips can usually be connected via different buss= es, e.g. >> serial and I2C. And with I2C the slave can't issue a transfer by itself.= ) >>=20 >> Other MFD drivers register their own IRQ chip for this. I.e. one would r= egister >> an IRQ chip in the MFD driver and pass it to the sub-devices created thr= ough >> mfd_add_devices(). Then the sub-device receives an IRQ and reads the reg= map. > 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 ser= ial 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 devic= e 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 h= ave 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. Th= e device just uses the fact that the UART is not a master/slave bus and pushe= s 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 function= s and being connected through UART, where the device pushes bytes through the UAR= T to signal events is a bit of an edge case. As mentioned, if it would be connected through I2C instead, it would be sim= ple: 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 should= n'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 over= head that doesn't really provide any value. I.e. if we can't (easily) use mfd cells and would need a custom API, then w= hy 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*