SATA backplane activity LEDs

SATA backplane activity LEDs

[Ian Pilcher]

I am trying to get the drive activity LEDs in my Thecus N5550 NAS
working with a standard distribution kernel.  These LEDs are controlled
by an NXP PCA9532 dimmer, rather than the SiI 3132 SATA controller.  I
have been able to build the Thecus modules for a standard kernel, and I
am able to control the LEDs manually (through their non-standard
/proc/thecus_io interface).

Thecus uses a modified libata-core.c and libahci.c to control the LEDs,
replacing ata_qc_new and ata_qc_free with variants that turn the LEDs
on and off.  If at all possible, I would prefer not to be this
intrusive.

Is there any better way to do this?

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

Re: SATA backplane activity LEDs

[Ian Pilcher]

On 08/05/2013 03:40 PM, Ian Pilcher wrote:
> I am trying to get the drive activity LEDs in my Thecus N5550 NAS
> working with a standard distribution kernel.  These LEDs are controlled
> by an NXP PCA9532 dimmer, rather than the SiI 3132 SATA controller.  I
> have been able to build the Thecus modules for a standard kernel, and I
> am able to control the LEDs manually (through their non-standard
> /proc/thecus_io interface).

I was wrong about the use of the SiI controller.  The backplane-
connected drives in this NAS are driven by the AHCI controller built in
to the ICH10R chipset.  (The SiI 3132 appears to be used only for the
eSATA port.)

All of which makes Thecus's modifications to libahci a lot more logical.

> Thecus uses a modified libata-core.c and libahci.c to control the LEDs,
> replacing ata_qc_new and ata_qc_free with variants that turn the LEDs
> on and off.  If at all possible, I would prefer not to be this
> intrusive.

I've come up with this approach, which allows me to "wrap" any of the
functions in ahci_ops:

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/libata.h>

extern struct ata_port_operations ahci_ops;

/* Original value of ahci_ops.qc_issue */
static unsigned int (*ahci_qc_issue)(struct ata_queued_cmd *);

static unsigned int thecus_qc_issue(struct ata_queued_cmd *qc)
{
        printk(KERN_INFO "thecus_qc_issue called\n");
        return ahci_qc_issue(qc);
}

static int __init thecus_ahci_init(void)
{
        ahci_qc_issue = ahci_ops.qc_issue;
        ahci_ops.qc_issue = thecus_qc_issue;
        return 0;
}

static void __exit thecus_ahci_exit(void)
{
        ahci_ops.qc_issue = ahci_qc_issue;
}

MODULE_AUTHOR("Ian Pilcher");
MODULE_DESCRIPTION("AHCI driver \"hooks\" for Thecus drive LEDs");
MODULE_LICENSE("GPL");

module_init(thecus_ahci_init);
module_exit(thecus_ahci_exit);

This appears to work in initial smoke testing, but it seems really
hackish and ugly.  OTOH, it's the only approach I can come up with that
will not require modifying/replacing the distro-provided drivers.

Is there a better way?

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================