On Wednesday 06 April 2005 11:29 am, Duncan Sands wrote:
> Thanks for replying David.
> 
> > > > When a driver gets a disconnect(interface) call, it must stop using
> > > > all those references ... though it's just barely OK to drop such
> > > > a reference (with the also-not-exported usb_put_intf!) after that
> > > > disconnect() returns.
> > > 
> > > I know this has always been your position (don't do anything after
> > > disconnect) - but then what's the point of reference counting?
> > 
> > Let me flip that around then:  if what I said isn't true, then
> > what would be the point of the disconnect() method?  How would
> > you be expecting drivers to notice and respond to physical device
> > unplug?  Or be unbound from an interface, so that some other driver
> > could then be bind to it?
> 
> Maybe I misunderstood you.  I took your "must stop using all those
> references" to mean: if you use them *any* time after the disconnect
> call returns, then you may die a horrible death (Oops etc).
> It sounds like you meant: you must stop using them *some* time after
> the disconnect (the disconnect call telling you that it's time to
> start shutting things down).

If it's a real physical disconnect, then "some" time suffices.
That's typically what drivers see; issuing URBs will result in
fault codes being returned.  (But that wasn't true when these
debates first started happening ... it only started being true
sometime last year, and only in 2.6 kernels.)

But as Alan pointed out explicitly, and I did implicitly, if
the driver is being unbound from the interface for any other
reason, something _could_ die a horrible death.  Because there
could then be two drivers, both thinking it's OK to talk to the
interface and issuing conflicting commands through its endpoints.
The driver doing so after disconnect() would be in the wrong.
Yes, I can easily imagine scenarios where oopsing would result.

You could adopt the stance that such cases are uncommon, so
your driver would use the "some time" weak rule.  I'd rather
see drivers not relying on things to be "uncommon" though.

- Dave



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to