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 7793F221F1C; Wed, 28 Jan 2026 06:39:06 +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=1769582346; cv=none; b=O/OPwhu4+mMSEf80LpZ9VvpMwRa1bb6g9gL43cGP50EPMIn5aLb/VRlHAzL+87BCuIwKI966WsFit+5F3AcilD6TrGvnrLrgkW84uXi+BK4kn3LltWyVTGsCbyIPvbrRxK6Z4UM8qeh9GMxZ0aw/kvarxWWnKHbj5Cv9T0Sk+j8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769582346; c=relaxed/simple; bh=o/WtRBxzGHwSv6xQweCyJfYQx241NkL25tgSbj+LWRc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=W6sKR/1saHBCXm8lvBtozZMwUJf22xonNWqXb7BRfrLj1BPBgNokEpxN55+DQpsln57S8wGqOpwZG4xRVNdVdxo0T2jLBf7AK9JVia/wTjspiZxtGCxnfJS7ZCl/n80iAYgzN+/uBtzGnWPkgt5ne71BlhS+QkpNjlIY9tvwsC0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZJNgekUQ; 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="ZJNgekUQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0076C4CEF1; Wed, 28 Jan 2026 06:39:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769582346; bh=o/WtRBxzGHwSv6xQweCyJfYQx241NkL25tgSbj+LWRc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ZJNgekUQnsvB5Y63llMBD5JJZOtW7c0LEj6L/nASW1Y/l88BAFCFyLgdWdgdxzfkb lF8PpIlf9H+0S+bZd9l8QM3IhbPt2yy6a/rt2zWaEgGKxme39a60nGAbuHu13u/pc5 q6v4Ghe/VQgYUJiWsXUa6rFptA3a/OHWXHQyJLYpPMvV+MgdAiqLpfAzc9EPa67Qnw 0aL8hwhtE2x98JSlRKVijvXGjNyTj9rz13wScVXtdTQCDeWmkMt2j2cAtqbiNkx5W3 w/dDfZkm3ujgCbex1Vn9+sJ3Zdto0eJ4b/lhf6sOg3xoniqFVLFKuEkh4b6ZOYsPHb m9w9wZd45FvMg== Message-ID: <2382dee0-983f-4c69-af7b-a7a48cad23aa@kernel.org> Date: Wed, 28 Jan 2026 15:34:05 +0900 Precedence: bulk X-Mailing-List: linux-scsi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 0/4] leds: extend disk trigger To: Markus Probst , Niklas Cassel Cc: Lee Jones , Pavel Machek , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Jacek Anaszewski , John Garry , Jason Yan , "James E.J. Bottomley" , "Martin K. Petersen" , Pavel Machek , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, Ian Pilcher References: <20260123-ledtrig_disk_-v1-0-07004756467b@posteo.de> <20f855baaa7c36010eab9997a2f43b4f62be726b.camel@posteo.de> Content-Language: en-US From: Damien Le Moal Organization: Western Digital Research In-Reply-To: <20f855baaa7c36010eab9997a2f43b4f62be726b.camel@posteo.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/28/26 12:34 AM, Markus Probst wrote: >> Having a user space implementation for your feature would also allow >> an upstream kernel, without the need for any custom kernel patches. > Only because it can be done in userspace, doesn't mean it should be. Yes it should. Maintaining userspace is far easier than forcing kernel changes onto users to get blinking LEDs. So unless you have a very strong argument for doing it in the kernel, userspace is probably the right approach. That will apply to any block device, and not just ATA devices. E.g. NAS with M.2 NVMe storage can work with the same. >> There seems to be existing user space applications that handles this, >> I think both the daemon I linked to before, which uses /sys/block//stat >> which is thus per device and not per port, and e.g. this: >> https://linux.die.net/man/8/ledmon >> https://github.com/md-raid-utilities/ledmon >> https://github.com/md-raid-utilities/ledmon/blob/main/src/lib/ahci.c > As far as I can tell, this daemon doesn't actually use the LED > Subsystem, but instead leds directly connected to the storage > controller. > But yes, I would be capable of coding such daemon. Then let's try. That will allow checking if anything is missing in the kernel interface to do that nicely. >> I think my main concern is that I don't think we should bloat the kernel >> for a complex feature that can just as well be implemented in user space. > It is still unclear to me if you worry about the complexity in > drivers/ata/libata-* or drivers/leds/trigger/ledtrig-disk.c It is not so much about complexity but rather the fact that controlling blinking LEDs in the hot IO path is not desirable. While SATA HDDs will be less sensible to the delays caused by the calls to the LED control functions compared to fast NVMe SSDs, we do also need to think about much faster SATA SSDs. So instead of risking performance regressions, let's try to do this in userspace first. -- Damien Le Moal Western Digital Research