From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luben Tuikov Date: Thu, 17 Apr 2003 22:29:11 +0000 Subject: Re: [PATCH] scsi_set_host_offline (resend) Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Oliver Neukum wrote: >>*But*, the _important__point_ is that the LLDD must be able to handle >>requests (queuecommand()) to non-existant (= just removed) devices, >>and not oops, or whatever. > > > For how long? That's the question. As soon as scsi_dev_removal()/scsi_set_dev_offline() returns you may assume you can free all _your_ resources. I.e. the upper subsystem should handle it from that point on. >>So, in effect, you just call usb_dev_removal(dev) (to be written), >>and free _your_ resources on the device. (note important point above) > > > The way it is in USB is a little different as the USB device drivers do > not go directly to the hardware. It would be: > > HCD -> USB core -> LLDD -> generic SCSI -> ... > Steps 1 to 3 work, 4 doesn't. Not yet, soon maybe. > If they can't block, they cannot clean up commands still in flight. > Eventually something needs to wait for the outstanding commands. I don't see it. (Upper level: ) Pending commands could be invalidated at once, via their callback to the upper subsystem; and any new incoming commands to device x could be invalidated at the moment they come in. (Lower level: ) Note that during the call to scsi_dev_removal() your driver may get its host_reset/device_reset function called to abort all pending commands (so as to leave the device in a predictable state). At which point, depending on the transport, _your__driver_ may need to sleep until the task management function response comes back (say over a network). All in all, it's not that bad. -- Luben ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel