On 7/1/21 11:31 PM, Greg KH wrote:
Why are ahci devices somehow "special" here? Just add a trigger to the ahci core for LEDs and all should "just work". We've done that for many subsystems already.
It's more complicated than that, as it would need to be a separate trigger for each drive (ATA port).
Are you sure we don't already have LED triggers for disk activity? Have you tried the ledtrig-disk.c driver? It says it works on ATA devices, no reason it can't also work for other device types.
I stumbled on that file myself last night. I either wasn't aware of it before, or I had forgotten its existence, possibly because it's disabled (CONFIG_LEDS_TRIGGER_DISK=n). As mentioned above, I would be looking to enable "per port" LEDs, so it doesn't work in its current form. It does at least give me hope that enhancements might be accepted upstream.
I've invested significant time in kernel patches in the past, only to see them ultimately not be accepted, so I would need to know that upstream was truly interested in such a feature before I would consider making such a commitment.
That's not fair, there is no way anyone can promise anyone that their patches will be accepted, _before_ anyone sees them. What would _you_ do if you were in the kernel maintainer's position and read something like this?
You're right, but that isn't what I intended to say. Basically, I can't afford to invest the time in implementing something if the subsystem maintainers have no interest in the *functionality*, regardless of the state of the code. I.e., if the ATA/LED subsystem maintainers think that software-controlled disk activity LEDs are stupid and have no place in the kernel, then code quality is irrelevant, and anything I do will be a waste of time.
good luck!
Thanks! -- ======================================================================== In Soviet Russia, Google searches you! ========================================================================