On Wed, Feb 26, 2014 at 1:35 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 21 Feb 2014, Dan Williams wrote: > >> ACPI identifies peer ports by setting their 'group_token' and >> 'group_position' _PLD data to the same value. If a platform has tier >> mismatch [1] , ACPI can override the default (USB3 defined) peer port >> association for internal hubs. External hubs follow the default peer >> association scheme. >> >> Location data is cached as an opaque cookie in usb_port_location data. >> >> Note that we only consider the group_token and group_position attributes >> from the _PLD data as ACPI specifies that group_token is a unique >> identifier. >> >> The bulk of the implementation is recursively fixing up peer >> associations once we detect tier mismatch. Due to the way acpi data is >> associated to a usb_port device (via a callback triggered by > > Is the callback _triggered_ (i.e., asynchronously) by device_register, > or is it simply _invoked_ (synchronously) by device_register? Synchronously, we complete the acpi notification/registration before device_register() for the port returns. >> device_register()) we do not discover tier mismatch until after the port >> has been registered. > > 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 a port has acpi data, don't permit a default matching... sounds good to me! -- 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
