| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Add simple driver for Medtronic CareLink USB devices.
Reported-by: Benjamin West <bewest@gmail.com>
Tested-by: Benjamin West <bewest@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Add simple driver for Novatel Wireless GPS receivers.
Reported-by: Kirk Madsen <kirkm@Navsys.com>
Tested-by: Kirk Madsen <kirkm@Navsys.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Add support for multi-port simple drivers.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Use direct method for supported baud rates, otherwise use divisors.
Limit baud rate to 12 Mbaud with HX type.
This change has been tested to work with PL-2303HX at 115200, 500000,
1000000, 2000000, 2500000, 3000000 and 4000000 baud rates.
Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
commit bdd405d2a528 ("usb: hub: Prevent hub autosuspend if
usbcore.autosuspend is -1") causes a build error if CONFIG_PM_RUNTIME is
disabled. Fix that by doing a simple #ifdef guard around it.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Michael Welling <mwelling@emacinc.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 039368901ad0a6476c7ecf0cfe4f84d735e30135.
Vivek writes:
We not longer need this patch, since we have planned to remove
the usb-phy drivers for samsung [1], we have completely deleted
the support for the the same from ohci-exynos and ehci-exynos
drivers too [2]. Sorry for the confusion, but this patch can be
dropped and instead we can pick the patches in [2].
[1] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35774.html
[2] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35695.html
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35696.html
Cc: Sachin Kamat <sachin.kamat@samsung.com>
Cc: Vivek Gautam <gautam.vivek@samsung.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Sachin Kamat <sachin.kamat@samsung.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is a bit bigger hammer then I would like to use for this, but for now
it will have to make do. I'm working on getting my hands on one of these so
that I can try to get streams to work (with a quirk flag if necessary) and
then we can re-enable them.
For now this at least makes uas capable disk enclosures work again by forcing
fallback to the usb-storage driver.
https://bugzilla.kernel.org/show_bug.cgi?id=79511
Cc: stable@vger.kernel.org # 3.15
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Make sure to verify the number of ports requested by subdriver to avoid
writing beyond the end of fixed-size array in interface data.
The current usb-serial implementation is limited to eight ports per
interface but failed to verify that the number of ports requested by a
subdriver (which could have been determined from device descriptors) did
not exceed this limit.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Make sure to verify the maximum number of endpoints per type to avoid
writing beyond the end of a stack-allocated array.
The current usb-serial implementation is limited to eight ports per
interface but failed to verify that the number of endpoints of a certain
type reported by a device did not exceed this limit.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Since we want to keep support for both older usb-phys as well as the
newer generic phys, lets first get the generic PHYs and fallback to
older USB-PHYs only when we fail to get the former.
This should fix the issue with ehci-exynos and ohci-exynos, wherein
in the absence of SAMSUNG_USB2PHY config symbol, we end up getting
the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs
are not configured properly.
Reported-by: Sachin Kamat <sachin.kamat@samsung.com>
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Jingoo Han <jg1.han@samsung.com>
Tested-by: Sachin Kamat <sachin.kamat@samsung.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If user specifies that USB autosuspend must be disabled by module
parameter "usbcore.autosuspend=-1" then we must prevent
autosuspend of USB hub devices as well.
commit 596d789a211d introduced in v3.8 changed the original behaivour
and stopped respecting the usbcore.autosuspend parameter for hubs.
Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0"
Cc: [3.8+] <stable@vger.kernel.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Tested-by: Michael Welling <mwelling@emacinc.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
I have a j5 create (JUA210) USB 2 video device and adding it device id
to SIS USB video gets it to work.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Set the default EP max packet value as 8 bytes, because in the case
of low-speed, 'ep_mps' is not set. Thus, the default value of 'ep_mps'
should be considered for the case of low-speed.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The roothub's index per controller is from 0, but the hub port index per hub
is from 1, this patch fixes "can't find device at roohub" problem for connecting
test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical Test.
This patch is for v3.12+.
Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The uSCSI from Newer Technology is a SCSI-USB converter with USB ID 06ca:2003.
Like several other SCSI-USB products, it's a Shuttle Technology OEM device.
Without a suitable entry in unusual-devs.h, the converter can only access the
(single) device with SCSI ID 0. Copying the entry for device 04e6:0002 allows
it to work with devices with other SCSI IDs too.
There are currently six entries for Shuttle-developed SCSI-USB devices in
unusual-devs.h (grep for euscsi):
04e6:0002 Shuttle eUSCSI Bridge USB_SC_DEVICE, USB_PR_DEVICE
04e6:000b Shuttle eUSCSI Bridge USB_SC_SCSI, USB_PR_BULK
04e6:000c Shuttle eUSCSI Bridge USB_SC_SCSI, USB_PR_BULK
050d:0115 Belkin USB SCSI Adaptor USB_SC_SCSI, USB_PR_BULK
07af:0004 Microtech USB-SCSI-DB25 USB_SC_DEVICE, USB_PR_DEVICE
07af:0005 Microtech USB-SCSI-HD50 USB_SC_DEVICE, USB_PR_DEVICE
lsusb -v output for the uSCSI lists
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
This patch adds an entry for the uSCSI to unusual_devs.h.
Signed-off-by: Mark Knibbs <markk@clara.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This was used back when usbip-host was an interface device driver;
after the conversion to device driver, the table remained unused.
Remove it in order to stop receiving a warning about it.
Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
At this point, USB/IP kernel code is fully functional
and can be moved out of staging.
Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into work-linus
Felipe writes:
usb: fixes for v3.17-rc2
Here's our first set of fixes for v3.17-rc cycle. Most fixes are
pretty minor changes like the signedness bug in dwc3, or the wrong
string format on MUSB.
The most interesting part is the addition of Intel Quark X1000 support
to PCH UDC.
Signed-of-by: Felipe Balbi <balbi@ti.com>
|
|
This patch fixes a potential security issue in the whiteheat USB driver
which might allow a local attacker to cause kernel memory corrpution. This
is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On
EHCI and XHCI busses it's possible to craft responses greater than 64
bytes leading a buffer overflow.
Signed-off-by: James Forshaw <forshaw@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into work-linus
Johan writes:
USB-serial fixes for v3.17-rc2
These updates fix the log level for some option log messages that started
bothering people after a recent change.
They also fix some issues reported against the zte_ev driver by moving most
device ids back from the zte_ev driver to the option driver (and removing two
duplicate ids). The zte_ev driver is planned to be removed in 3.18.
Some new device ids are also added.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
The variable $(PWD) is useless, and it may break the compilation.
For example, it breaks the kernel compilation when it's done with
buildroot :
/home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/bin/ccache
/home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
-Wp,-MD,drivers/usb/gadget/legacy/.hid.o.d -nostdinc -isystem
/home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/include
-I./arch/arm/include -Iarch/arm/include/generated -Iinclude
-I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi
-I./include/uapi -Iinclude/generated/uapi -include
./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp
-funwind-tables -marm -D__LINUX_ARM_ARCH__=5 -march=armv5te
-mtune=arm9tdmi -msoft-float -Uarm -fno-delete-null-pointer-checks -O2
--param=allow-store-data-races=0 -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer
-fno-var-tracking-assignments -g -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack
-Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO
-I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/
-I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/udc/
-I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/function/
-DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hid)"
-D"KBUILD_MODNAME=KBUILD_STR(g_hid)" -c -o
drivers/usb/gadget/legacy/hid.o drivers/usb/gadget/legacy/hid.c
drivers/usb/gadget/epautoconf.c:23:26: erreur fatale: gadget_chips.h :
Aucun fichier ou dossier de ce type
This compilation line include :
..../buildroot/driver/usb/gadget
but the real path is :
..../buildroot/output/build/linux-3.17-rc1/driver/usb/gadget
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
This patch is to enable the USB gadget device for Intel Quark X1000
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@intel.com>
Signed-off-by: Bing Niu <bing.niu@intel.com>
Signed-off-by: Alvin (Weike) Chen <alvin.chen@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
If the pending buffers in the queue could not be pushed to the udc
endpoint we have to cancel the uvc_queue. Otherwise the gadget will get
stuck on this error. This patch calls uvc_queue_cancel if usb_ep_queue
failed.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
linux-2.6/drivers/usb/wusbcore/wa-xfer.c: In function 'wa_buf_in_cb':
linux-2.6/drivers/usb/wusbcore/wa-xfer.c:2590: warning: 'rpipe' may be used uninitialized in this function
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Suggested-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
linux-2.6/drivers/usb/core/hub.c: In function 'usb_disconnect':
linux-2.6/drivers/usb/core/hub.c:2110: warning: 'hub' may be used uninitialized in this function
linux-2.6/drivers/usb/core/hub.c:2111: warning: 'port1' may be used uninitialized in this function
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
linux-2.6/drivers/usb/dwc2/gadget.c: In function 's3c_hsotg_irq_enumdone':
linux-2.6/drivers/usb/dwc2/gadget.c:1904: warning: 'ep_mps' may be used uninitialized in this function
Acked-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When we manually need to move the TR dequeue pointer we need to set the
correct cycle bit as well. Previously we used the trb pointer from the
last event received as a base, but this was changed in
commit 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer")
to use the dequeue pointer from the endpoint context instead
It turns out some Asmedia controllers advance the dequeue pointer
stored in the endpoint context past the event triggering TRB, and
this messed up the way the cycle bit was calculated.
Instead of adding a quirk or complicating the already hard to follow cycle bit
code, the whole cycle bit calculation is now simplified and adapted to handle
event and endpoint context dequeue pointer differences.
Fixes: 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer")
Reported-by: Maciej Puzio <mx34567@gmail.com>
Reported-by: Evan Langlois <uudruid74@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Maciej Puzio <mx34567@gmail.com>
Tested-by: Evan Langlois <uudruid74@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
AMD xHC also needs short tx quirk after tested on most of chipset
generations. That's because there is the same incorrect behavior like
Fresco Logic host. Please see below message with on USB webcam
attached on xHC host:
[ 139.262944] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[ 139.266934] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[ 139.270913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[ 139.274937] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[ 139.278914] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[ 139.282936] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[ 139.286915] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[ 139.290938] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[ 139.294913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[ 139.298917] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
Reported-by: Arindam Nath <arindam.nath@amd.com>
Tested-by: Shriraj-Rai P <shriraj-rai.p@amd.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G
Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a
the integrated Intel xhci controller on a Haswell laptop:
00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04)
The following error gets logged to dmesg:
xhci error: Transfer event TRB DMA ptr not part of current TD
Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found
fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
failures of the same port] added the check of the reliable port, but
it also replaced the device argument to dev_err() wrongly, which leads
to a NULL dereference.
This patch restores the right device, port_dev->dev. Also, since
dev_err() itself shows the port number, reduce the port number shown
in the error message, essentially reverting to the state before the
commit 5ee0f803cc3a.
[The fix suggested by Hannes, and the error message cleanup suggested
by Alan Stern]
Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce failures of the same port')
Reported-by: Hannes Reinecke <hare@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit a9232076374334ca2bc2a448dfde96d38a54349a.
It introduced a dead lock, and did not fix anything.
it made netif_tx_lock() be called in IRQ context, but in softirq context,
the same lock is locked without disabling IRQ. In fact, the commit a923207637
did not fix anything, since netif_stop_queue did not free the any resource
[ 10.154920] =================================
[ 10.156026] [ INFO: inconsistent lock state ]
[ 10.156026] 3.16.0-rc5+ #13 Not tainted
[ 10.156026] ---------------------------------
[ 10.156026] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 10.156026] swapper/1/0 [HC0[0]:SC1[5]:HE1:SE0] takes:
[ 10.156026] (_xmit_ETHER){?.-...}, at: [<80948b6a>] sch_direct_xmit+0x7a/0x250
[ 10.156026] {IN-HARDIRQ-W} state was registered at:
[ 10.156026] [<804811f0>] __lock_acquire+0x800/0x17a0
[ 10.156026] [<804828ba>] lock_acquire+0x6a/0xf0
[ 10.156026] [<809ed477>] _raw_spin_lock+0x27/0x40
[ 10.156026] [<8088d508>] gether_disconnect+0x68/0x280
[ 10.156026] [<8088e777>] eem_set_alt+0x37/0xc0
[ 10.156026] [<808847ce>] composite_setup+0x30e/0x1240
[ 10.156026] [<8088b8ae>] pch_udc_isr+0xa6e/0xf50
[ 10.156026] [<8048abe8>] handle_irq_event_percpu+0x38/0x1e0
[ 10.156026] [<8048adc1>] handle_irq_event+0x31/0x50
[ 10.156026] [<8048d94b>] handle_fasteoi_irq+0x6b/0x140
[ 10.156026] [<804040a5>] handle_irq+0x65/0x80
[ 10.156026] [<80403cfc>] do_IRQ+0x3c/0xc0
[ 10.156026] [<809ee6ae>] common_interrupt+0x2e/0x34
[ 10.156026] [<804668c5>] finish_task_switch+0x65/0xd0
[ 10.156026] [<809e89df>] __schedule+0x20f/0x7d0
[ 10.156026] [<809e94aa>] schedule_preempt_disabled+0x2a/0x70
[ 10.156026] [<8047bf03>] cpu_startup_entry+0x143/0x410
[ 10.156026] [<809e2e61>] rest_init+0xa1/0xb0
[ 10.156026] [<80ce2a3b>] start_kernel+0x336/0x33b
[ 10.156026] [<80ce22ab>] i386_start_kernel+0x79/0x7d
[ 10.156026] irq event stamp: 52070
[ 10.156026] hardirqs last enabled at (52070): [<809375de>] neigh_resolve_output+0xee/0x2a0
[ 10.156026] hardirqs last disabled at (52069): [<809375a8>] neigh_resolve_output+0xb8/0x2a0
[ 10.156026] softirqs last enabled at (52020): [<8044401f>] _local_bh_enable+0x1f/0x50
[ 10.156026] softirqs last disabled at (52021): [<80404036>] do_softirq_own_stack+0x26/0x30
[ 10.156026]
[ 10.156026] other info that might help us debug this:
[ 10.156026] Possible unsafe locking scenario:
[ 10.156026]
[ 10.156026] CPU0
[ 10.156026] ----
[ 10.156026] lock(_xmit_ETHER);
[ 10.156026] <Interrupt>
[ 10.156026] lock(_xmit_ETHER);
[ 10.156026]
[ 10.156026] *** DEADLOCK ***
[ 10.156026]
[ 10.156026] 4 locks held by swapper/1/0:
[ 10.156026] #0: (((&idev->mc_ifc_timer))){+.-...}, at: [<8044b100>] call_timer_fn+0x0/0x190
[ 10.156026] #1: (rcu_read_lock){......}, at: [<a0577c40>] mld_sendpack+0x0/0x590 [ipv6]
[ 10.156026] #2: (rcu_read_lock_bh){......}, at: [<a055680c>] ip6_finish_output2+0x4c/0x7f0 [ipv6]
[ 10.156026] #3: (rcu_read_lock_bh){......}, at: [<8092e510>] __dev_queue_xmit+0x0/0x5f0
[ 10.156026]
[ 10.156026] stack backtrace:
[ 10.156026] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.16.0-rc5+ #13
[ 10.156026] 811dbb10 00000000 9e919d10 809e6785 9e8b8000 9e919d3c 809e561e 80b95511
[ 10.156026] 80b9545a 80b9543d 80b95450 80b95441 80b957e4 9e8b84e0 00000002 8047f7b0
[ 10.156026] 9e919d5c 8048043b 00000002 00000000 9e8b8000 00000001 00000004 9e8b8000
[ 10.156026] Call Trace:
[ 10.156026] [<809e6785>] dump_stack+0x48/0x69
[ 10.156026] [<809e561e>] print_usage_bug+0x18f/0x19c
[ 10.156026] [<8047f7b0>] ? print_shortest_lock_dependencies+0x170/0x170
[ 10.156026] [<8048043b>] mark_lock+0x53b/0x5f0
[ 10.156026] [<804810cf>] __lock_acquire+0x6df/0x17a0
[ 10.156026] [<804828ba>] lock_acquire+0x6a/0xf0
[ 10.156026] [<80948b6a>] ? sch_direct_xmit+0x7a/0x250
[ 10.156026] [<809ed477>] _raw_spin_lock+0x27/0x40
[ 10.156026] [<80948b6a>] ? sch_direct_xmit+0x7a/0x250
[ 10.156026] [<80948b6a>] sch_direct_xmit+0x7a/0x250
[ 10.156026] [<8092e6bf>] __dev_queue_xmit+0x1af/0x5f0
[ 10.156026] [<80947fc0>] ? ether_setup+0x80/0x80
[ 10.156026] [<8092eb0f>] dev_queue_xmit+0xf/0x20
[ 10.156026] [<8093764c>] neigh_resolve_output+0x15c/0x2a0
[ 10.156026] [<a0556927>] ip6_finish_output2+0x167/0x7f0 [ipv6]
[ 10.156026] [<a0559b05>] ip6_finish_output+0x85/0x1c0 [ipv6]
[ 10.156026] [<a0559cb7>] ip6_output+0x77/0x240 [ipv6]
[ 10.156026] [<a0578163>] mld_sendpack+0x523/0x590 [ipv6]
[ 10.156026] [<80480501>] ? mark_held_locks+0x11/0x90
[ 10.156026] [<a057947d>] mld_ifc_timer_expire+0x15d/0x280 [ipv6]
[ 10.156026] [<8044b168>] call_timer_fn+0x68/0x190
[ 10.156026] [<a0579320>] ? igmp6_group_added+0x150/0x150 [ipv6]
[ 10.156026] [<8044b3fa>] run_timer_softirq+0x16a/0x240
[ 10.156026] [<a0579320>] ? igmp6_group_added+0x150/0x150 [ipv6]
[ 10.156026] [<80444984>] __do_softirq+0xd4/0x2f0
[ 10.156026] [<804448b0>] ? tasklet_action+0x100/0x100
[ 10.156026] [<80404036>] do_softirq_own_stack+0x26/0x30
[ 10.156026] <IRQ> [<80444d05>] irq_exit+0x65/0x70
[ 10.156026] [<8042d758>] smp_apic_timer_interrupt+0x38/0x50
[ 10.156026] [<809ee91f>] apic_timer_interrupt+0x2f/0x34
[ 10.156026] [<8048007b>] ? mark_lock+0x17b/0x5f0
[ 10.156026] [<8040a912>] ? default_idle+0x22/0xf0
[ 10.156026] [<8040b13e>] arch_cpu_idle+0xe/0x10
[ 10.156026] [<8047bfc6>] cpu_startup_entry+0x206/0x410
[ 10.156026] [<8042bfbd>] start_secondary+0x19d/0x1e0
Acked-by: Tony Lindgren <tony@atomide.com>
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jeff Westfahl <jeff.westfahl@ni.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
In case of error, the function devm_ioremap_nocache() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
In case of error, the function memdup_user() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
"ret" should be signed. It's only used for zero and negative error
codes.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The prefix suggests the number should be printed in hex, so use
the %x specifier to do that.
Found by using regex suggested by Joe Perches.
Signed-off-by: Hans Wennborg <hans@hanshq.net>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
As, the interrupt for DMA is counted from 1, so need to checked
the USBA_NR_DMAS, in old way, it only check (USBA_NR_DMAS - 1),
so fix it.
Reported-by: Max Liao <liaops@embest-tech.com>
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Convert a zero return value on error to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
According to the datasheet, PHYPARAM1_PCS_TXDEEMPH is set as
6 bits [5:0]. Thus, the bit mask should be set as 0x3f, instead
of 0x1f.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
After dbgp_bind()-dbgp_unbind() cycle happens, static variable dbgp
contains pointers to already deallocated memory (dbgp.serial and dbgp.req).
If the next dbgp_bind() fails, for example in usb_ep_alloc_request(),
dbgp_bind() calls dbgp_unbind() on failure path,
and dbgp_unbind() frees dbgp.serial that still stores a pointer
to already deallocated memory.
The patch sets pointers to NULL in dbgp_unbind().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Using kfree to free data allocated with devm_kzalloc causes double frees.
The Coccinelle semantic patch that fixes this problem is as follows:
// <smpl>
@@
expression x;
@@
x = devm_kzalloc(...)
...
?-kfree(x);
// </smpl>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
When __usb_find_phy_dev() does not return error and
try_module_get() fails, return -ENODEV.
Signed-off-by: Arjun Sreedharan <arjun024@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Added support to the ftdi_sio driver for ekey Converter USB which
uses an FT232BM chip.
Signed-off-by: Jaša Bartelj <jasa.bartelj@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
This adds a new device id to the pl2303 driver for the ZTEK device.
Reported-by: Mike Chu <Mike-Chu@prolific.com.tw>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Add device id for Basic Micro ATOM Nano USB2Serial adapters.
Reported-by: Nicolas Alt <n.alt@mytum.de>
Tested-by: Nicolas Alt <n.alt@mytum.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Remove dublicate Qualcom PID 0x3197 which is already handled by the
moto-modem driver since commit 6986a978eec7 ("USB: add new moto_modem
driver for some Morotola phones").
Fixes: 799ee9243d89 ("USB: serial: add zte_ev.c driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Remove dublicate Gobi PID 0x9008 which is already handled by the
qcserial driver since commit f05932c0caf4 ("USB: qcserial: Add extra
device IDs").
Fixes: 799ee9243d89 ("USB: serial: add zte_ev.c driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
This reverts commit 73228a0538a7 ("USB: option,zte_ev: move most ZTE
CDMA devices to zte_ev").
Move the IDs of the devices that were previously driven by the option
driver back to that driver.
As several users have reported, the zte_ev driver is causing random
disconnects as well as reconnect failures.
A closer analysis of the zte_ev setup code reveals that it consists of
standard CDC requests (SET/GET_LINE_CODING and SET_CONTROL_LINE_STATE)
but unfortunately fails to get some of those right. In particular, as
reported by Liu Lei, it fails to lower DTR/RTS on close. It also appears
that the control requests lack the interface argument.
Note that the zte_ev driver is based on code (once) distributed by ZTE
that still appears to originally have been reverse-engineered and bolted
onto the generic driver.
Since line control is already handled properly by the option driver, and
the SET/GET_LINE_CODING requests appears to be redundant (amounts to a
SET 9600 8N1), this is a first step in ultimately removing the redundant
zte_ev driver.
Note that AC2726 had already been moved back to option, and that some
IDs were in the device table of both drivers prior to the commit being
reverted.
Reported-by: Lei Liu <liu.lei78@zte.com.cn>
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
This VIA Telecom baseband processor is used is used by by u-blox in both the
FW2770 and FW2760 products and may be used in others as well.
This patch has been tested on both of these modem versions.
Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
