Re: possible race condition for usb_stor_port_reset and usb_reset_and_verify_device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 7 May 2015, yoma sophian wrote:

> > Besides, the kernel already contains a thread that calls
> > sd_check_events periodically.  Why do you need to write a new one?
> I create the thread since some buggy devices needs to periodically
> polling to let it not going to disconnection.
> Would you mind to let me know which kernel thread that calls
> sd_check_events periodically?

There is not a dedicated thread.  Each block device has a workqueue
item that runs on the system_freezable_power_efficient_wq work queue.  
For more information, see the "Disk events" section of block/genhd.c.  
In particular, look at the disk_check_events() routine.

For a typical USB storage device, the system will poll for media 
changes by calling sd_check_events.

> >> My questions are:
> >> a. is there any system flag such suspend/resume in scsi layer for
> >> checking before sending command to downlayer driver, such as usb.
> >
> > I don't know of any.  In general, the kernel is designed so that no
> > SCSI commands will be sent while the system is in suspend or
> > hibernation, so no checking is needed.
> which flag or callback function we used to determine the system is in
> suspend or hibernation?
> udev->state?

You don't use any flags or callbacks, and you don't determine when the 
system is in suspend or hibernation.  Instead you make your thread 
freezable, so that it will get frozen automatically whenever the system 
goes into suspend or hibernation.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux