From: Ian Pilcher <arequipeno@gmail.com>
To: linux-ide@vger.kernel.org
Subject: Re: SATA backplane activity LEDs
Date: Tue, 06 Aug 2013 13:12:19 -0500 [thread overview]
Message-ID: <ktre9s$va0$1@ger.gmane.org> (raw)
In-Reply-To: <ktp2k8$de0$1@ger.gmane.org>
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.
========================================================================
prev parent reply other threads:[~2013-08-06 18:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 20:40 SATA backplane activity LEDs Ian Pilcher
2013-08-06 18:12 ` Ian Pilcher [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ktre9s$va0$1@ger.gmane.org' \
--to=arequipeno@gmail.com \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).