[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47203073.7090809@garzik.org>
Date: Thu, 25 Oct 2007 01:58:11 -0400
From: Jeff Garzik <jeff@...zik.org>
To: Kristen Carlson Accardi <kristen.c.accardi@...el.com>
CC: akpm@...ux-foundation.org, linux-ide@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ata: ahci: Enable enclosure management via LED (resend)
Kristen Carlson Accardi wrote:
> Enable enclosure management via LED
>
> As described in the AHCI spec, some AHCI controllers may support
> Enclosure management via a variety of protocols. This patch
> adds support for the LED message type that is specified in
> AHCI 1.1 and higher.
>
> Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@...el.com>
>
> ---
> drivers/ata/ahci.c | 153 +++++++++++++++++++++++++++++++++++++++++++++-
> drivers/ata/libata-scsi.c | 5 -
> include/linux/libata.h | 3
> 3 files changed, 157 insertions(+), 4 deletions(-)
Comments:
1) it seems a bit questionable that the attributes are globally
writeable, even by unpriveleged heathens?
2) ahci_led_locate_store() and ahci_led_fault()_store are the same, save
for a single constant
3) Don't document ahci_em_messages values (like SGPIO) which are not
actually supported in the code. Feel free to put these in a comment to
make sure others follow your lead, however
4) ahci_transmit_led_message() is issued completely without any locking.
that does not look safe in the face of libata-eh doing a reset?
5) please run through scripts/checkpatch in 2.6.24-rc1, there are
several "use tabs not spaces" type errors and some other minor style nits
6) ATA_FLAG_EM is added but never used
7) Is it valid to check capabilities bit 6 (EMS) on AHCI 1.0? I would
tend to shy away from assuming that all silicon gives us sane 'reserved'
bits :)
8) when is this actually used? do you have a sample user in userspace?
does a userspace daemon watch disk activity and manage LEDs somehow?
I'm a bit cloudy on the usage need of this.
9) overall, sans the above comments, the overall goal seems OK to me,
and the patch seems pretty good.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists