Johan Hovold <jhovold@xxxxxxxxx> writes: > Remove the vendor and product module parameters which were added a long > time ago when we did not have the dynamic sysfs interface to add new > device ids (and which isn't limited to a single new vid/pid pair). > > A vid/pid pair can be added dynamically using sysfs, for example: > > echo 1234 5678 >/sys/bus/usb-serial/drivers/generic/new_id > > Signed-off-by: Johan Hovold <jhovold@xxxxxxxxx> > --- > drivers/usb/serial/generic.c | 17 +---------------- > 1 file changed, 1 insertion(+), 16 deletions(-) > > diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c > index 1f31e6b..0416575 100644 > --- a/drivers/usb/serial/generic.c > +++ b/drivers/usb/serial/generic.c > @@ -25,17 +25,7 @@ > #include <linux/serial.h> > > #ifdef CONFIG_USB_SERIAL_GENERIC > - > -static __u16 vendor = 0x05f9; > -static __u16 product = 0xffff; > - > -module_param(vendor, ushort, 0); > -MODULE_PARM_DESC(vendor, "User specified USB idVendor"); > - > -module_param(product, ushort, 0); > -MODULE_PARM_DESC(product, "User specified USB idProduct"); Getting rid of this would be nice. Sure. But all these changes are going to break existing, working configurations are they not? And this one in particular is widely used. Yes, we've tried to prevent that and make people add device IDs to other drivers instead, but you still come across new advice using those module parameters all the time. So is this breakage really acceptable? Maybe we could keep the module parameters, but implement them as an alternative way to set dynamic device IDs instead of the static device table hacks? That would enable us to get rid of most of this old code without breaking anything. Bjørn -- 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
