On Wed, 2013-02-06 at 01:16 +0000, Ben Hutchings wrote: > > I don't know why USB differs from PCI, but we do need the dynamic ID here > > as > > there are always new IDs being issued. One of the criteria for adding the > > ID to > > the table is that it works OK with dynamic addition. These devices are > > frequently reported by users that do not have the skills to build their own > > kernel. > > But since there is no way to set the driver_info for a new USB ID > (again, unlike PCI), your change will reject all dynamic IDs. (And in > any case, if the USB core were changed to allow setting driver_info, > userland would have difficulty providing a valid pointer!) > > It looks like the driver_info is really driver-specific data used to > share a probe function between multiple drivers. But you could add > per-driver probe functions that pass the correct rtl_hal_cfg as an extra > argument to rtl_usb_probe(), and then dynamic IDs should work.
Some (PCI?) drivers had/have numbers instead of pointers, so userland can provide a number and it then looks up the pointer in an array. That's only slightly indirected but makes new_id more useful in that case. johannes -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
