Re: [PATCH RFC 0/4] leds: extend disk trigger

[Damien Le Moal <dlemoal@kernel.org>]

On 1/29/26 00:44, Markus Probst wrote:
>> That will allow checking if anything is missing in the kernel
>> interface to do that nicely.
> There is.
> 
> I noticed for leds, that the fwnode path isn't exposed in sysfs.
> "/sys/class/leds/<name>/device/firmware_node/path" exists, but points
> to the parent device.
> 
> Something similar with scsi and ata exists. scsi doesn't expose the
> firmware_node and there is no symlink (or other connection that I am
> ware of) between scsi_* and ata_* in sysfs. This means, I cannot map a
> fwnode path to a block device.
> 
> If I want to distribute a pre-defined config for such led userspace
> daemon alongside the ACPI Overlay for a specific NAS model, I need an
> identifier that is equal across all devices with that specific NAS
> model.
> 
> This is less of an issue for leds, but given that leds could be renamed
> on name collisions the issue still exists.

All of this is not the hot path, so we can work on it.

If new sysfs device attributes for an ATA device, you can add them to
ata_ncq_sdev_attrs in libata-sata.c. These show up as part of the scsi device
attributes, so if you define this well with the scsi side, the same attribute
names can be used for pure scsi devices and ATA devices served with libata.


-- 
Damien Le Moal
Western Digital Research