Willem Riede <[EMAIL PROTECTED]> suggested to me that I simply set sdev->online = 0 for scsi_set_device_offline()
Any reason that isn't good enough?
On Sun, Feb 02, 2003 at 10:13:17AM -0800, Matthew Dharm wrote:
> So, was any of this ever implemented? As far as I can tell, the required
> changes were:
>
> (o) addition of scsi_schedule_host_removal() (possibly optional)
> (o) implementation of scsi_set_device_offline() (possibly optional)
> (o) change the behavior of the 'hotplug initialization model' to call my
> release function
>
> Matt
>
> On Fri, Jan 24, 2003 at 08:07:29PM -0500, Doug Ledford wrote:
> > On Fri, Jan 24, 2003 at 04:45:53PM -0800, Matthew Dharm wrote:
> > > Okay... so what do I do if it fails? Sleep for a while and try again
> > > later? Wait on a flag somewhere?
> >
> > Well, the better option is what I think we are working on. Instead of
> > trying to remove the host completely, just unhook it from the USB stuff,
> > then call the set_scsi_device_offline(), then send back any outstanding
> > commands via scsi_done(), then possibly call the
> > scsi_schedule_host_removal() if Mike adds that function. Then return.
> > Don't to anything else. Take all the remaining code you would normally
> > run at this point and put it into a function in your source called
> > usb_release() and in your Scsi_Host_Template struct that you pass to the
> > scsi layer, init the release pointer with the address of your
> > usb_release() routine. That way, the scsi layer can do what it's best at,
> > taking care of the clean up details we've been talking about, and when
> > it's all done, it will call your usb_release() routine with a single
> > argument of the host struct you are wanting released. At that point, you
> > can do all the freeing you would have done in that khubd loop (at least I
> > think that's the context you are doing the freeing from now) and know for
> > a fact that not only are you freeing everything, but so is the scsi mid
> > layer. I think this will solve all the issues you've had, because this
> > *won't* leak, it won't block your other actions, and it lets the scsi
> > subsystem clean up properly.
>
> --
> Matthew Dharm Home: [EMAIL PROTECTED]
> Maintainer, Linux USB Mass Storage Driver
>
> We can customize our colonels.
> -- Tux
> User Friendly, 12/1/1998
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed
suction darts!
-- Salesperson to Greg
User Friendly, 12/30/1997
msg11219/pgp00000.pgp
Description: PGP signature
