lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 9 Jun 2011 23:56:22 +0300
From:	"Tanya Brokhman" <tlinder@...eaurora.org>
To:	"'Alan Stern'" <stern@...land.harvard.edu>
Cc:	<greg@...ah.com>, <linux-usb@...r.kernel.org>,
	<linux-arm-msm@...r.kernel.org>, <balbi@...com>,
	<ablay@...eaurora.org>,
	"'open list'" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] usb:dummy_hcd: Force FS device connection according to module parameter

> > @@ -904,12 +908,15 @@ usb_gadget_probe_driver(struct
> usb_gadget_driver *driver,
> >  	dum->gadget.ep0 = &dum->ep [0].ep;
> >  	if (mod_data.is_super_speed)
> >  		dum->gadget.speed = driver->speed;
> > -	else
> > +	else if (mod_data.is_high_speed)
> >  		dum->gadget.speed = min((u8)USB_SPEED_HIGH, (u8)driver-
> >speed);
> 
> Use min_t().

Ok, will update.

> 
> > +	else
> > +		dum->gadget.speed = USB_SPEED_FULL;
> >  	if (dum->gadget.speed < driver->speed)
> > -		dev_dbg(udc_dev(dum), "This device can perform faster if"
> > -				      " you connect it to a "
> > -				      "SupeSpeed port...\n");
> > +		dev_dbg(udc_dev(dum), "This device can perform faster"
> > +				" if you connect it to a %s port...\n",
> > +			(driver->speed == USB_SPEED_SUPER ?
> > +			 "SuperSpeed" : "HighSpeed"));
> >
> >  	if (dum->gadget.speed == USB_SPEED_SUPER) {
> >  		for (i = 0; i < DUMMY_ENDPOINTS; i++)
> > @@ -2417,6 +2424,9 @@ static int __init init (void)
> >  	if (usb_disabled ())
> >  		return -ENODEV;
> >
> > +	if (!mod_data.is_high_speed && mod_data.is_super_speed)
> > +		return -EINVAL;
> 
> Print an error message in the log so that the user will know why the
> failure occurred.
> 

But when the module fails to load the message sais that it's invalid
parameter (or something like that). That's why I thought it will be enough. 
You mean to add something that explains WHY these values are wrong?


Thanks,
Tanya Brokhman
---
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ