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 32788382F39; Mon, 16 Mar 2026 13:58:26 +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=1773669507; cv=none; b=grGjnNcJJ4+7hWWGJdd8XHZNfqt/eVOfe04CsU0Ra0aRbjjoJkvvmzYfAGOa6RUFKS6xKG30e+7uaOQABRrklfluyXGew9gHodiB0PBJu/KF0d64kqFyLdTqNmRLrpzRWxwzvkYc1rGgGvo4PYdSWSnluI5MlAGGsNTBKKBxdLY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773669507; c=relaxed/simple; bh=O3/GG12QpLO1UZgLug9usf1QzvRky6kw6Ji7zydi8gU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pxHcr6ff0dRpHFatiIcI+lygZNPilXUJeSBqkVjIrmqUI9R65E3tWJMiepdjIHpk1i3QVi1PXvVsf9FiRed2Vd35GvZ+iCM5j8vfUwwHAjoOnqPpSSIQI/tKFFqfa3AvfgdgJMJbYF4ExKrciZyXvV/XJ9mHMhkkbgs8YBK+ark= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=M9ic3BVM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="M9ic3BVM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 287BEC19421; Mon, 16 Mar 2026 13:58:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1773669506; bh=O3/GG12QpLO1UZgLug9usf1QzvRky6kw6Ji7zydi8gU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=M9ic3BVMtkejqZnGD/X589zYsSaNYNIFpqWnXN0K4rpu7xcbEijzAZQIM+9JkB07p FZhGw4+v3ETjruTkeo0JTZ+b2KgEKnWha59HpfOZVifCFy5SNauZ4Ca5zauENxZJnR YBnRNIrwc4MpPqEfMsi3FJg901LsmKffMc4UrwQc= Date: Mon, 16 Mar 2026 14:58:22 +0100 From: Greg Kroah-Hartman To: Markus Probst Cc: Danilo Krummrich , Markus Probst via B4 Relay , Lee Jones , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Miguel Ojeda , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , "Rafael J. Wysocki" , Igor Korotin , Daniel Almeida , Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Pavel Machek , Len Brown , Robert Moore , 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 Message-ID: <2026031602-drove-timothy-1bb1@gregkh> References: <20260313-synology_microp_initial-v3-0-ad6ac463a201@posteo.de> <20260313-synology_microp_initial-v3-7-ad6ac463a201@posteo.de> <39f1c9bb0dbde9f1b60785f8e838289c888ffdb0.camel@posteo.de> <2026031645-unplowed-purist-9c4b@gregkh> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Mar 16, 2026 at 01:43:44PM +0000, Markus Probst wrote: > On Mon, 2026-03-16 at 07:33 +0100, Greg Kroah-Hartman wrote: > > On Sun, Mar 15, 2026 at 08:41:06PM +0100, Danilo Krummrich wrote: > > > 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? > > > > I think this has yet to be proven to be a kernel driver at all at this > > point, and not just a userspace daemon that listens to the serial port > > and then does what is needed from there :) > > > > Or, if someone can prove that the operations on this serial data stream > > actually do require it to be in the kernel (which I have yet to see a > > list of what this connection does, did I miss it?) then a single driver, > > under the drivers/platform section of the kernel tree makes sense. > The sysoff component is strictly necessary for poweroff and reboot. > > On ARM64 Synology NAS devices it is needed so the device actually > powers off after calling > `syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_POWER_OFF, NULL);` > . Otherwise it would stay on. > Same applies to reboot. So that means a write of a set of bytes to the serial port will cause the machine to reboot or shutdown? > On x86 it isn't clearly documented what sending the poweroff and reboot > command to the microp device exactly does, so this is based on > observations. It should be sent before issuing a poweroff or reboot via > ACPI Sleep. On reboot it resets various device states, so fan speeds go > to default, leds turn off etc., so it behaves like a coldboot. > On poweroff it will mark it as graceful shutdown (i. e. the device > won't turn automatically on, because it thinks a power-loss happend). > > For the other components: > - leds > - hwmon > - input For "input" what exactly does the input device show up as? A power button? Something else? For hwmon, that makes sense to have a kernel driver. For leds, that depends on what you want to do with the led, as in the end you are just controlling it from userspace anyway :) > It could theoratically be implemented in userspace. A userspace daemon > could theoratically control the fan speeds directly, issue a systemd > shutdown on power button press, control the leds directly etc. > > But honestly, I don't understand why this is an argument. > With that argument drivers/leds, drivers/hwmon and drivers/input would > not even exist, because everything could be implemented in userspace > via > - I2C: /dev/i2c-* (drivers/i2c/i2c-dev.c) > - MMIO: /dev/ioport and /dev/mem (drivers/char/mem.c) > - GPIO: /sys/class/gpio (drivers/gpio/gpiolib-sysfs.c) > - SPI: /dev/spidev* (drivers/spi/spidev.c) > - PCI: /sys/class/pci_bus/ (drivers/pci/pci-sysfs.c) > - Serial: /dev/ttyS* > and likely almost any other bus device too. > > Generally speaking, the kernel and its drivers is the layer between > hardware and software. It provides the hardware abstractions as > userspace interfaces. So any software on the same cpu architecture can > work with any hardware, as long as there is a kernel driver. Yes, I kind of know what drivers and classes do and why they are needed, that's not the point here. :) > In the case of this driver, it means > - *any* led daemon can control the leds > - *any* fan control daemon can control the fan speed and frequency > - *any* monitoring software can view the provided sensors > - *any* init system can react to the power button > - *any* process can request a reboot or shutdown > . > I think this is the expected behaviour. Ok great, then make a single driver that handles all of this, like other drivers/platform/ drivers do today, and all should be fine. thanks, greg k-h