I'm not certain this is a problem... I know blocking is legal in the SCSI error-handling context. Other I/O will continue during this time.
I have to think about this some more....
Matt
On Thu, Mar 20, 2003 at 12:48:02AM +0100, Oliver Neukum wrote:
> Am Mittwoch, 19. März 2003 23:46 schrieb Greg KH:
> > On Fri, Mar 14, 2003 at 07:56:27AM -0800, David Brownell wrote:
> > > Oliver Neukum wrote:
> > > >am I right in assuming that any disconnects/probes _must_ be done
> > > > through driver core? Or is calling usb_device_remove() directly still
> > > > legal?
> > >
> > > I'm not even sure why usb_device_{probe,remove}() are even exported.
> >
> > Someone needs to fix up the usb-storage driver for these functions to be
> > made private.
>
> I just thought about this. It's much less trivial than I thought.
> The patch I made for cleaning up reset is crap.
> We cannot ignore it either. Today I saw a mouse with memory stick
> reader. If this is HID+storage, multiinterface devices are no longer
> theory.
>
> The problem is somewhat involved and I might even be wrong.
> Upon device reset the interfaces whose drivers do not make a reset
> must be notified that they cannot use the device while we reset it.
> Currently this is done via disconnect()ing all interfaces.
> This is potentially lethal. This is done as part of the block io error
> handling path. This means that all memory allocations must be made
> GFP_NOIO or GFP_ATOMIC. Now please correct me if I am wrong,
> but the hotplugging subsystem does exactly that, doesn't it?
>
> Regards
> Oliver
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
I see you've been reading alt.sex.chubby.sheep voraciously.
-- Tanya
User Friendly, 11/24/97
pgp00000.pgp
Description: PGP signature
