On Wed, 24 Aug 2011, Hans de Goede wrote: > Hi, > > First of all: A big thanks to Alan for working on this. From my POV > the code looks good, but I'm only familiar with the usb parts > and not with the scsi parts. > > One generic concern is the use of scsi_lock(host) in the > scsi_device_open / close callbacks. We need to be sure non > of the callers of these can already be holding the lock. The callers always runs in process context (because file open/close always uses process context) and the lock is a spinlock. So no, the lock can't be held at the wrong time. > On 08/24/2011 10:45 PM, Greg KH wrote: > > I don't like the fact that if a driver doesn't contain check_busy() then > > it will automatically fall back to looking like it was a DISCONNECT > > call, which could give userspace a false sense of "everything was fine" > > when trying this out. > > I've to agree with Greg here, what to do in case of a driver not > implementing check_busy and thus not really offering USBDEVFS_TRY_DISCONNECT > is policy and thus should be left to userspace. I suggest we just return > -ENOTTY in case of USBDEVFS_TRY_DISCONNECT and the bound driver does not > have checkbusy, then userspace can decide wether to fallback to a regular > disconnect, or to give up. Okay, I'll change the patch. But the real question is whether the basic idea is acceptable. 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
