On Fri, Aug 9, 2013 at 1:25 AM, Grant Grundler <grundler@xxxxxxxxxx> wrote: > On Tue, Aug 6, 2013 at 5:41 PM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote: >> On Wed, Aug 7, 2013 at 1:09 AM, Grant Grundler <grundler@xxxxxxxxxx> wrote: > ... >>> Following that logic, shouldn't all the features/hw_features settings >>> be removed from reset code path? >> >> This patch won't touch other settings because that isn't related with >> this patch. > > Sorry - I didn't mean to imply your patch should do this. I was hoping > for a yes/no answer from you, Eric, or Dave. > > ... >>> I'll note that any "hiccup" in the USB side that causes the device to >>> get dropped and re-probed will cause the same symptom. There is >> >> I am afraid that PCI network devices' setting still won't survive unbound& >> re-probed, will they? > > Correct - but PCI isn't as prone to "dropping off the bus" like USB As far as I know, USB device still won't be disconnected easily, and reset is possible, but we can make setting survive reset by implementing .pre_reset() and .post_reset() callback. Or do you have other situation of USB 'dropping off the bus'? > is. Master aborts on some PCI systems is a "Fatal Exception" and AFAIK > that's never been true for any USB device. I mean rmmod & modprobe still can reset setting of one PCI network device after powering on the device, can't it? Thanks, -- Ming Lei -- 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
