Tejun Heo wrote:
When no reset method is available, libata currently oopses. Although
the condition can't happen unless there's a bug in a low level driver,
oopsing isn't the best way to report the error condition. Complain,
dump stack and fail reset instead.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
This patch is on top of
upstream (a984f58dd97f22f5113700322fed311a0ee29947)
+ prefer-hardreset patchset
http://thread.gmane.org/gmane.linux.ide/27447
drivers/ata/libata-eh.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 64418f1..8d82b06 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2135,9 +2135,14 @@ int ata_eh_reset(struct ata_link *link, int classify,
if (hardreset) {
reset = hardreset;
ehc->i.action = ATA_EH_HARDRESET;
- } else {
+ } else if (softreset) {
reset = softreset;
ehc->i.action = ATA_EH_SOFTRESET;
+ } else {
+ ata_link_printk(link, KERN_ERR, "BUG: no reset method, "
+ "please report to [EMAIL PROTECTED]");
+ dump_stack();
+ return -EINVAL;
ACK, but holding due to hold on prefer-hardreset patch (pinging device
manufacturers)
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
