- 02 Mar, 2010 40 commits
-
-
Greg Kroah-Hartman authored
The Barry project's userspace program, bcharge, can better handle this device and functionality, and it also works with the latest phones, which this driver does not support. So remove it, as the userspace code should be used instead. Cc: Chris Frey <cdfrey@foursquare.net> Signed-off-by:Greg Kroah-Hartman <gregkh@suse.de>
-
Oliver Neukum authored
Total removal from the ioctl code path except for the outcall to external modules. Locking is ensured by the normal locks of usbfs. Signed-off-by:
Oliver Neukum <oliver@neukum.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Oliver Neukum authored
BKL was not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
BKL was not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
BKL was not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
BKL was not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
BKL was not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
BKL was not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
BKL was not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
This driver had used BKL to guard against disconnect but was incorrectly converted leaving an SMP race. BKL was added to disconnect() to fix this race BKL was removed from ioctl() as the mutex is sufficient on its own. Signed-off-by:
-
Oliver Neukum authored
BKL not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
BKL not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
BKL not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
BKL not needed at all. Removed without replacement. Signed-off-by:
-
Oliver Neukum authored
BKL was not needed at all. Removed without replacement. Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Ben Hutchings authored
Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Oliver Neukum authored
This pushes BKL down in ioctl handling and drops it for some important ioctls Signed-off-by:
-
Oliver Neukum authored
Straightforward push into the drivers to allow auditing individual drivers separately Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Oliver Neukum authored
Replace it by mutex_lock(&file->f_dentry->d_inode->i_mutex); following the example of the generic method Signed-off-by:
-
Oliver Neukum authored
Locking had long been changed making BKL redundant. Simply remove it. Signed-off-by:
-
Oliver Neukum authored
Replace BKL with usbfs_mutex to protect a global counter and a per file data structure Signed-off-by:
-
Thiago Farina authored
Signed-off-by:
Thiago Farina <tfransosi@gmail.com> Signed-off-by:
-
Gernot Hillier authored
The 4G XS Stick W14 seems to not understand RTS/DTR setting in option_send_setup causing long timeouts on any open() which disturbs a lot of well-known userspace applications like minicom or ModemManager. Therefore, we enable OPTION_BLACKLIST_SENDSETUP blacklisting for it. Signed-off-by:
Gernot Hillier <gernot@hillier.de> Signed-off-by:
-
Gernot Hillier authored
As suggested by Matthias Urlichs, this patch adds a somehow generic mechanism for special handling of devices which don't support all bits expected by this driver. The blacklisting code is heavily stolen from sierra.c, but extended to support different special cases. For now, one case is implemented (OPTION_BLACKLIST_SENDSETUP), targeted at the 4G W14 device: devices which don't understand the setting of RTS/DTR in option_send_setup() causing a USB timeout of 5 s in any userspace open() which leads to errors in most userspace applications. In addition, I prepared another case for devices with interfaces which shall not be accessed by this driver (targeted at the D-Link DWM 652). However, OPTION_BLACKLIST_RESERVED_IF is not fully implemented yet as I have no device to test this. Anyone volunteering to help here? If not, I'll contact the guys who added D-Link DWM 652 support soon. Signed-off-by:
-
Gernot Hillier authored
Carsten Juttner thankfully investigated a bit and found out some details about the chipset used in the 4G W14 device I recently added to option.c. I think this information is useful for reference, so I'd be happy if you could include those bits. Signed-off-by:
-
Németh Márton authored
The id_table field of the struct pci_driver is constant in <linux/pci.h> so it is worth to make pci_ids also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by:
Németh Márton <nm127@freemail.hu> Cc: Julia Lawall <julia@diku.dk> Cc: cocci@diku.dk Signed-off-by:
-
Németh Márton authored
The match_table field of the struct of_device_id is constant in <linux/of_platform.h> so it is worth to make ace_of_match also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by:
-
Németh Márton authored
The match_table field of the struct of_device_id is constant in <linux/of_platform.h> so it is worth to make the initialization data also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by:
-
Németh Márton authored
The id_table field of the struct usb_device_id is constant in <linux/usb.h> so it is worth to make the initialization data also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by:
-
Németh Márton authored
The id_table field of the struct usb_device_id is constant in <linux/usb.h> so it is worth to make the initialization data also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by:
-
Németh Márton authored
The id_table field of the struct usb_device_id is constant in <linux/usb.h> so it is worth to make the initialization data also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by:
-
Németh Márton authored
The id_table field of the struct usb_device_id is constant in <linux/usb.h> so it is worth to make the initialization data also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by:
-
Németh Márton authored
The id_table field of the struct usb_device_id is constant in <linux/usb.h> so it is worth to make the initialization data also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by:
-
Németh Márton authored
The id_table field of the struct usb_device_id is constant in <linux/usb.h> so it is worth to make the initialization data also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by:
-
Roel Kluin authored
Test whether tusb_dma is not NULL before dereferencing Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Cc: Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by:
-
Herbert Xu authored
USB: Move hcd free_dev call into usb_disconnect I found a way to oops the kernel: 1. Open a USB device through devio. 2. Remove the hcd module in the host kernel. 3. Close the devio file descriptor. The problem is that closing the file descriptor does usb_release_dev as it is the last reference. usb_release_dev then tries to invoke the hcd free_dev function (or rather dereferencing the hcd driver struct). This causes an oops as the hcd driver has already been unloaded so the struct is gone. This patch tries to fix this by bringing the free_dev call earlier and into usb_disconnect. I have verified that repeating the above steps no longer crashes with this patch applied. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Cc: stable <stable@kernel.org> Signed-off-by:
-
Pete Zaitcev authored
When hardware is removed on a Stratus, the system may crash like this: ACPI: PCI interrupt for device 0000:7c:00.1 disabled Trying to free nonexistent resource <00000000a8000000-00000000afffffff> Trying to free nonexistent resource <00000000a4800000-00000000a480ffff> uhci_hcd 0000:7e:1d.0: remove, state 1 usb usb2: USB disconnect, address 1 usb 2-1: USB disconnect, address 2 Unable to handle kernel paging request at 0000000000100100 RIP: [<ffffffff88021950>] :uhci_hcd:uhci_scan_schedule+0xa2/0x89c #4 [ffff81011de17e50] uhci_scan_schedule at ffffffff88021918 #5 [ffff81011de17ed0] uhci_irq at ffffffff88023cb8 #6 [ffff81011de17f10] usb_hcd_irq at ffffffff801f1c1f #7 [ffff81011de17f20] handle_IRQ_event at ffffffff8001123b #8 [ffff81011de17f50] __do_IRQ at ffffffff800ba749 This occurs because an interrupt scans uhci->skelqh, which is being freed. We do the right thing: disable the interrupts in the device, and do not do any processing if the interrupt is shared with other source, but it's possible that another CPU gets delayed somewhere (e.g. loops) until we started freeing. The agreed-upon solution is to wait for interrupts to play out before proceeding. No other bareers are neceesary. A backport of this patch was tested on a 2.6.18 based kernel. Testing of 2.6.32-based kernels is under way, but it takes us forever (months) to turn this around. So I think it's a good patch and we should keep it. Tracked in RH bz#516851 Signed-Off-By:
-
Alan Stern authored
This patch (as1329) converts the USB stack over to the PM core's runtime PM framework. This involves numerous changes throughout usbcore, especially to hub.c and driver.c. Perhaps the most notable change is that CONFIG_USB_SUSPEND now depends on CONFIG_PM_RUNTIME instead of CONFIG_PM. Several fields in the usb_device and usb_interface structures are no longer needed. Some code which used to depend on CONFIG_USB_PM now depends on CONFIG_USB_SUSPEND (requiring some rearrangement of header files). The only visible change in behavior should be that following a system sleep (resume from RAM or resume from hibernation), autosuspended USB devices will be resumed just like everything else. They won't remain suspended. But if they aren't in use then they will naturally autosuspend again in a few seconds. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
This patch (as1328) reorders the functions in drivers/usb/core/driver.c so as to put all the routines dependent on CONFIG_PM in one place. Signed-off-by:
-
Alan Stern authored
This patch (as1327) changes the way negative autosuspend delays prevent device from autosuspending. The current code checks for negative values explicitly in the autosuspend_check() routine. The updated code keeps things from getting that far by using usb_autoresume_device() to increment the usage counter when a negative delay is set, and by using usb_autosuspend_device() to decrement the usage counter when a non-negative delay is set. This complicates the set_autosuspend() attribute method code slightly, but it will reduce the overall power management overhead. Signed-off-by:
-
