Re: problem with Roseweil eusb3 enclosure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 02, 2012 at 01:38:26PM -0400, Alan Stern wrote:
> On Fri, 2 Nov 2012, Sarah Sharp wrote:
> 
> > > I don't like that idea.  It would be much simpler to put the port back 
> > > into a useful state.  For example, disable the port, then put it into 
> > > RxDetect, then clear any change bits, and set the port's bit in 
> > > hub->removed_bits.
> > > 
> > > (hub->removed_bits was meant to help implement Windows' "Safely remove
> > > hardware" feature.  When a port's bit is set, khubd will ignore any
> > > device attached to that port until it sees a connect-change.)
> > 
> > Oh, interesting!  I didn't know that.  I think putting the device into
> > disabled, then RxDetect and ignoring it is a good solution, however...
> > 
> > What exactly does khubd do when it ignores the device?  Does it still
> > clear the change bits, but not take any action on them?  Or does it
> > ignore the change bits entirely?
> 
> The other way around -- it pays attention to the port-change bits and
> treats them normally.  The important part is in
> hub_port_connect_change(); if there hasn't been a connect-change or a
> disconnect then it won't try to enumerate a device plugged into the
> port.

Ok, yes, that looks like it will be fine with the xHCI host.  I'll start
on a warm reset fix patch.

> > If khubd completely ignores the port status change bits, I think we have
> > an issue with xHCI.  The xHC only generates a port event when all port
> > change bits were previously cleared (see section 4.19.2).  So if a port
> > change bit gets set and the port status change event is completely
> > ignored by khubd, the xHC won't generate a port status change event on
> > the disconnect.  A port will seem "dead" after a safely remove, if an
> > event like an overcurrent or link state change occurs.
> > 
> > Ignoring one port shouldn't have any affect on port status change event
> > generation for other ports, so I think we're ok there.  I'll just have
> > to take a look at how khubd deals with the hub->removed_bits.
> 
> It's pretty straightforward.  You can play around with it by writing to 
> /sys/bus/usb/devices/.../remove.  The usb_remove_store() routine calls 
> usb_remove_device().

Good to know, thanks!  I think this is what Ubuntu uses when you click
safe remove on the disk drive icon.

Sarah Sharp
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux