Re: [PATCH #upstream] libata: make EH fail gracefully if no reset method is available

[Tejun Heo <htejun@gmail.com>]

Jeff Garzik wrote:
> 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 <htejun@gmail.com>
>> ---
>> 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 linux-ide@vger.kernel.org\n");
>> +        dump_stack();
>> +        return -EINVAL;
> 
> ACK, but holding due to hold on prefer-hardreset patch (pinging device
> manufacturers)

Please drop this one.  #upstream-fixes now has a patch to allow drivers
w/o any reset method.

-- 
tejun