On Thu, Jun 27, 2013 at 12:13:32PM -0700, Greg KH wrote:
> On Thu, Jun 27, 2013 at 09:11:36PM +0200, Bjørn Mork wrote:
> > 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?
>
> For this one, no, it's not, we should keep it around, as people do rely
> on it, and we now have the proper warnings in place if it gets used.
>
> So I'll not apply this one to the tree, thanks for the review.
Fair enough, the generic driver could be a reasonable exception.
Removing the redundant module parameter would perhaps have the benefit
of making people aware of the dynamic interface so that new ids are more
likely to be tested with the other drivers as well? And breaking
existing configurations based on the generic ("only for prototypes")
driver could arguably be acceptable if there is something to gain from
doing so (e.g. gets people to send us the ids to be added to the proper
drivers)?
Thanks,
Johan
--
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
