On 2/22/21 3:59 PM, Oliver Neukum wrote:
Am Sonntag, den 21.02.2021, 11:20 +0100 schrieb Hans de Goede:
Hi,
Hi,
On 2/21/21 9:51 AM, Hui Wang wrote:
Once pre_reset() or post_reset() returns non-zero, the disconnect()
and probe() of the usb_driver will be called. In the disconnect(),
the scsi_host will be removed and be freed after scsi_host_put(), in
the probe(), the new scsi_host and uas_dev_info will be created.
If the usb_reset_device() is triggered by eh_device_reset_handler(),
and pre_reset()/post_reset() returns non-zero, the disconnect() and
probe() will be called, then returns to the eh_device_reset_handler(),
it still accesses old scsi related variables and uas_dev_info, and so
do its caller functions.
Here change the pre_reset() and post_reset() to let them only return
0, after this change, the usb_reset_device() will only reset this
usb devcie from its hub port, will not execute unbind and rebind
usb_driver during reset.
We only return non 0 from the pre/post reset handles if we failed
to ensure the device is in a known state.
correct. Technically it is a bit unfortunate that UAS devices react
a bit different to other SCSI devices, but we definitely cannot hide
a failure. Arguably we should go into OFFLINE state.
But that needs a
good reason beyond theoretical considerations.
Regards
Oliver
OK, will find a UAS device to do the test.
thanks,
Hui.