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 is. Master aborts on some PCI systems is a "Fatal Exception" and AFAIK that's never been true for any USB device. >> nothing the driver can do about it in this case. Perhaps add some udev >> rules to preserve ethtool settings the same way I've seen udev rules >> to record MAC address to enumerate devices (eth0, eth1, etc.) > > Some usbnet devices may have random MAC address assigned in every > probe(). Ugh - ok. Then those scripts are broken for those devices. C'est la Vie. My point is the mechanism (udev) exists to preserve any settings ethtool can read/record the state of. cheers, grant ps. thanks again for posting the USBNET sg dma series - I will likely back port those to our chromeos-3.8 tree in the near future. -- 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
