I'm testing a revised version of this patch that renames the trigger
to just 'disk' and updates all documentation and default_trigger
definitions to match.  I'm also registering the trigger name
'ide-disk' for now so external tools/scripts/distros won't break while
a depreciation time is chosen.

Once I've verified this behaves on my system, I'm assuming a patch
that touches 25 files should be broken up?  I'm thinking of submitting
in the following chunks:

ledtrig-ide-disk to ledtrig-disk
documentation updates
default-trigger updates
Marvell SATA adjusted to call the trigger

Any objections or comments on this plan of attack?

Josh C

On Tue, Jan 8, 2013 at 8:29 PM, Kim, Milo [off-list ref] wrote:

quoted

-----Original Message-----
From: linux-leds-owner at vger.kernel.org [mailto:linux-leds-
owner at vger.kernel.org] On Behalf Of Jason Cooper
Sent: Wednesday, January 09, 2013 5:04 AM
To: Josh Coombs
Cc: cooloney at gmail.com; linux-kernel at vger.kernel.org; linux-
ide at vger.kernel.org; rpurdie at rpsys.net; linux ARM; jgarzik at pobox.com;
linux-leds at vger.kernel.org
Subject: Re: [PATCH] Allow Marvell SATA driver to work with
LEDS_TRIGGER_IDE_DISK

On Tue, Jan 08, 2013 at 02:18:04PM -0500, Josh Coombs wrote:

quoted

Would it make more sense to add a second trigger
for SATA instead?

I'll leave that up to the led guys, I just wanted to raise the point
that the driver could logically support other types of disks, and we
should come up with a migration path instead of adding capabilities
ad-hoc.

I agree with Jason's suggestion. One more thing to consider.

If we replace the name, 'ide-disk' or 'ide_disk' with general one,
then we should change the value of 'default_trigger' under arch directory also.
LED trigger works if the name is matched with trigger name of LED device.

Thanks,
Milo