On Wed, Feb 26, 2014 at 2:07 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 26 Feb 2014, Dan Williams wrote: > >> > I've been thinking about this. Maybe it isn't a problem, because now >> > you don't set up the peer matching until after the port has been >> > registered. All you have to do is allow the ACPI data to prevent a >> > default match if the location data values don't agree. >> > >> > That would simplify this patch an awful lot. >> >> Hm, interesting. It relies on the fact that the firmware must >> identify both peers if it has location data for one, but I think that >> is a reasonable constraint. > > If the firmware doesn't have location data for both peers in a > non-default matching (which presumably means there's a tier mismatch) > then there's no way for us to match them up correctly anyhow. > >> If a port has acpi data, don't permit a default matching... sounds good to me! > > If the port's ACPI data agrees with the default matching, there's no > issue. But if they disagree, don't accept the default match. That way > you never have to correct a mistaken match. So it turns out this simplifies the patch a bit, by getting rid of invalidate_dependent_peers(). However, we still need enumerate_dependent_peers() to handle cases where descendants are registered prior to peering the parents via location data. The big complexity savings is killing the need for a solution like the one proposed in "[RFC PATCH v5 16/16] usb, xhci: flush initial hub discovery to gate port power control" i went ahead and changed 'struct usb_port_location' to 'typedef u32 usb_port_location_t', and am preparing to release a v6 addressing the current comments. -- 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
