[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e3a691e4-3fbc-98ba-28f0-627364d8b4d7@huawei.com>
Date: Thu, 7 Sep 2023 20:38:56 +0800
From: Wenchao Hao <haowenchao2@...wei.com>
To: Mike Christie <michael.christie@...cle.com>,
"James E . J . Bottomley" <jejb@...ux.ibm.com>,
"Martin K . Petersen" <martin.petersen@...cle.com>,
<linux-scsi@...r.kernel.org>
CC: Hannes Reinecke <hare@...e.de>, <linux-kernel@...r.kernel.org>,
<louhongxiang@...wei.com>, <lixiaokeng@...wei.com>
Subject: Re: [RFC PATCH v2 00/18] scsi: scsi_error: Introduce new error handle
mechanism
On 2023/9/6 23:56, Mike Christie wrote:
> On 9/6/23 6:15 AM, haowenchao (C) wrote:
>>>
>>> If the driver supports performing multiple TMFs/resets in parallel then why
>>> not always enable it?
>>>
>>
>> Not all hardware/drivers support performing multiple TMFs/resets in parallel,
>> so I think it is necessary to call scsi_device_setup_eh/scsi_device_clear_eh
>> in specific drivers.
>
> Ah shoot sorry. I edited my email before I sent it and dropped part of it.
>
> For the scsi_device_setup_eh/scsi_device_clear_eh comment I just meant it could
> be a scsi_host_template field. scsi-ml would then see it and do the
> scsi_device_setup_eh/scsi_device_clear_eh calls for the driver. The drivers
> then don't have to deal with doing slave callouts and handling errors.
>
> Also for the error handling case I think we want to still proceed if
> scsi_device_setup_eh fails. Just use the old EH in that case.
It looks better to add setup_eh/clear_eh in scsi_host_template, I would update in
next version.
Powered by blists - more mailing lists