On Wed, Nov 28, 2012 at 01:56:46PM -0500, Alan Stern wrote: > On Wed, 28 Nov 2012, Sarah Sharp wrote: > > > On Wed, Nov 28, 2012 at 12:39:14PM -0500, Alan Stern wrote: > > > Instead, how about sticking the new code into a separate function: > > > > > > void hub_adjust_DeviceRemovable(struct usb_device *hdev, > > > struct usb_hub_descriptor *desc); > > > > > > Call this new function here and at the appropriate place in > > > hcd.c:rh_call_control(). Then no modifications would be needed in > > > ehci-hcd or xhci-hcd. > > > > So you would basically let EHCI and xHCI set the DeviceRemovable bits in > > their hub descriptors and then have the USB core overwrite them? > > It's not an overwrite, it's an "|=". Anyway, that's what Tianyu's > patches already do; I'm merely suggesting that he rearrange the code to > avoid duplication. Ah, ok, sure. > > If a > > userspace program like lsusb asks for the hub descriptors, would they > > see the updated version, or the original version? > > With either Tianyu's original series or my suggested revision, the > program would see the updated version for root hubs and the original > version for non-root hubs. > > > The shared code to overwrite the bits should probably print a warning if > > the host and ACPI bits differ. > > I'm not so sure about that. For one thing, who wants warnings to be > logged every time they run "lsusb -v"? Yeah, that's probably not a great idea. > Also, this sort of thing might be more common than you might expect. > I'd guess that if the ACPI information contains anything useful at all, > it will be different from the [Ex]HCI information. > > Tianyu's patches log such warnings for xHCI but not for EHCI. That > inconsistency is another reason to rework them. Tianyu did that because I asked him to for xHCI. I didn't think about the lsusb implications. You're right that it will probably be annoying to the user, so he should just drop the warning in the shared code. 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
