- 06 May, 2014 40 commits
-
-
Paul Gortmaker authored
commit f76a1cbe upstream. Commit 3e6c6f63 ("Delay creation of khcvd thread") moved the call of hvc_init from being a device_initcall into hvc_alloc, and used a non-null hvc_driver as indication of whether hvc_init had already been called. The problem with this is that hvc_driver is only assigned a value at the bottom of hvc_init, and so there is a window where multiple hvc_alloc calls can be in progress at the same time and hence try and call hvc_init multiple times. Previously the use of device_init guaranteed that hvc_init was only called once. This manifests itself as sporadic instances of two hvc_init calls racing each other, and with the loser of the race getting -EBUSY from tty_register_driver() and hence that virtual console fails: Couldn't register hvc console driver virtio-ports vport0p1: error -16 allocating hvc for port Here we add an atomic_t to guarantee we'll never run hvc_init twice. Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Fixes: 3e6c6f63 ("Delay creation of khcvd thread") Reported-by:
Jim Somerville <Jim.Somerville@windriver.com> Tested-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Felipe Balbi authored
commit 3063a12b upstream. commi 30a70b02 (usb: musb: fix obex in g_nokia.ko causing kernel panic) removed phy_power_on() and phy_power_off() calls from runtime PM callbacks but it failed to note that the driver depended on pm_runtime_get_sync() calls to power up the PHY, thus leaving some platforms without any means to have a working PHY. Fix that by enabling the phy during omap2430_musb_init() and killing it in omap2430_musb_exit(). Fixes: 30a70b02 (usb: musb: fix obex in g_nokia.ko causing kernel panic) Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Reported-by:
Michael Scott <hashcode0f@gmail.com> Tested-by:
Stefan Roese <sr@denx.de> Reported-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Felipe Balbi authored
commit eee3f15d upstream. instead of relying on the otg pointer, which can be NULL in certain cases, we can use the gadget and host pointers we already hold inside struct musb. Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Felipe Balbi authored
commit 61018305 upstream. commit 388e5c51 (usb: dwc3: remove dwc3 dependency on host AND gadget.) created the possibility for host-only and peripheral-only dwc3 builds but left a possible randconfig build error when host-only builds are selected. Reported-by:
Jim Davis <jim.epost@gmail.com> Signed-off-by:
-
Huang Rui authored
commit 06f9b6e5 upstream. Around DWC USB3 2.30a release another bit has been added to the Device-Specific Event (DEVT) Event Information (EvtInfo) bitfield. Because of that, what used to be 8 bits long, has become 9 bits long. Per dwc3 2.30a+ spec in the Device-Specific Event (DEVT), the field of Event Information Bits(EvtInfo) uses [24:16] bits, and it has 9 bits not 8 bits. And the following reserved field uses [31:25] bits not [31:24] bits, and it has 7 bits. So in dwc3_event_devt, the bit mask should be: event_info [24:16] 9 bits reserved31_25 [31:25] 7 bits This patch makes sure that newer core releases will work fine with Linux and that we will decode the event information properly on new core releases. [ balbi@ti.com : improve commit log a bit ] Signed-off-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Wolfram Sang authored
commit 61f03191 upstream. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Florian Vaussard authored
commit 8b57b966 upstream. Commit 3fdfedaa "[media] omap3isp: preview: Lower the crop margins" accidentally changed the previewer's cropping, causing the previewer to miss four pixels on each line, thus corrupting the final image. Restored the removed setting. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
commit 30d65282 upstream. Do not attempt to reload the tuner modules when resuming after a suspend. This triggers a WARN_ON in kernel/kmod.c:148 __request_module. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=69581. This has always been wrong, but it was never noticed until the WARN_ON was added in 3.9. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Antti Palosaari authored
commit 3ec40dcf upstream. Pointer to device state has been moved to different location during some change. PCTV 290e LNA function still uses old pointer, carried over FE priv, and it crash. Reported-by:
Janne Kujanpää <jikuja@iki.fi> Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Malcolm Priestley authored
commit 3c8023a7 upstream. The m88rs2000 frontend is always auto inversion. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Frank Schaefer authored
commit 01ae3b51 upstream. dev->adev.users always needs to be increased when snd_em28xx_capture_open() is called and succeeds. Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Malcolm Priestley authored
commit 8272d0a0 upstream. Add m88rs2000_get_tune_settings, min delay of 2000 ms on symbol rate more than 3000000 and delay of 3000ms less than this. Adding min delay prevents crashing the frontend on continuous transponder scans. Other dvb_frontend_tune_settings remain as default. This makes very little time difference to good channel scans, but slows down the set frontend where lock can never be achieved i.e. DVB-S2. Signed-off-by:
-
Hans Verkuil authored
commit bc826d6e upstream. The wrong ioctl numbers were used due to a copy-and-paste error. Signed-off-by:
-
Hans Verkuil authored
commit c4885ada upstream. I completely forgot to add them when I made this module. Loading this module without it will taint the kernel, which is not intended. Signed-off-by:
-
Antoine Ténart authored
commit 7d3477d8 upstream. If no driver takeover the atmel_lcdfb, the lcd won't be in a working state since atmel_lcdfb_set_par() will never be called. Enabling a driver which does, like fbcon, will call the function and put atmel_lcdfb in a working state. Fixes: b985172b (video: atmel_lcdfb: add device tree suport) Signed-off-by:
Antoine Ténart <antoine.tenart@free-electrons.com> Reported-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Hans Verkuil authored
commit aee786ac upstream. bt->width should be (bt)->width, and same for the other fields. Signed-off-by:
-
Oleksij Rempel authored
commit b1e43f23 upstream. The UVC specification uses alternate setting selection to notify devices of stream start/stop. This breaks when using bulk-based devices, as the video streaming interface has a single alternate setting in that case, making video stream start and video stream stop events to appear identical to the device. Bulk-based devices are thus not well supported by UVC. The webcam built in the Asus Zenbook UX302LA ignores the set interface request and will keep the video stream enabled when the driver tries to stop it. If USB autosuspend is enabled the device will then be suspended and will crash, requiring a cold reboot. USB trace capture showed that Windows sends a CLEAR_FEATURE(HALT) request to the bulk endpoint when stopping the stream instead of selecting alternate setting 0. The camera then behaves correctly, and thus seems to require that behaviour. Replace selection of alternate setting 0 with clearing of the endpoint halt feature at video stream stop for bulk-based devices. Let's refrain from blaming Microsoft this time, as it's not clear whether this Windows-specific but USB-compliant behaviour was specifically developed to handle bulkd-based UVC devices, or if the camera just took advantage of it. Signed-off-by:
Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
-
David Cohen authored
commit 01bb59eb upstream. When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this warning: drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined but not used [-Wunused-function] Instead of creating nested #ifdefs, this patch fixes it by defining the xHCI PCI stubs as inline. This warning has been in since 3.2 kernel and was caused by commit 421aa841 "usb/xhci: hide MSI code behind PCI bars", but wasn't noticed until 3.13 when a configuration with these options was tried Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Igor Gnatenko authored
commit 6db249eb upstream. After suspend another Renesas PCI-X USB 3.0 card doesn't work. [root@fedora-20 ~]# lspci -vmnnd 1912: Device: 03:00.0 Class: USB controller [0c03] Vendor: Renesas Technology Corp. [1912] Device: uPD720202 USB 3.0 Host Controller [0015] SVendor: Renesas Technology Corp. [1912] SDevice: uPD720202 USB 3.0 Host Controller [0015] Rev: 02 ProgIf: 30 This patch should be applied to stable kernel 3.14 that contain the commit 1aa9578c "xhci: Fix resume issues on Renesas chips in Samsung laptops" Reported-and-tested-by:
Anatoly Kharchenko <rfr-bugs@yandex.ru> Reference: http://redmine.russianfedora.pro/issues/1315Signed-off-by:
Igor Gnatenko <i.gnatenko.brain@gmail.com> Signed-off-by:
-
Denis Turischev authored
commit c09ec25d upstream. The same issue like with Panther Point chipsets. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS have work around for this, but not all. One example is Compulab's mini-desktop, the Intense-PC2. The bug can be avoided if the USB ports are switched back to EHCI on shutdown. This patch should be backported to stable kernels as old as 3.12, that contain the commit 638298dc "xhci: Fix spurious wakeups after S5 on Haswell" Signed-off-by:
Denis Turischev <denis@compulab.co.il> Signed-off-by:
-
Mathias Nyman authored
commit bcffae77 upstream. xHCI driver has its own pci probe function that will call usb_hcd_pci_probe to register its usb-2 bus, and then continue to manually register the usb-3 bus. usb_hcd_pci_probe does a pm_runtime_put_noidle at the end and might thus trigger a runtime suspend before the usb-3 bus is ready. Prevent the runtime suspend by increasing the usage count in the beginning of xhci_pci_probe, and decrease it once the usb-3 bus is ready. xhci-platform driver is not using usb_hcd_pci_probe to set up busses and should not need to have it's usage count increased during probe. Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Roger Quadros authored
commit 9c1b7036 upstream. It was impossible to enumerate on a SuperSpeed (XHCI) host with alternate setting = 1 due to the wrongly set 'bMaxBurst' field in the SuperSpeed Endpoint Companion descriptor. Testcase: <host> modprobe -r usbtest; modprobe usbtest alt=1 <device> modprobe g_zero plug device to SuperSpeed port on the host. Without this patch the host always complains like so "usb 12-2: Not enough bandwidth for new device state. usb 12-2: Not enough bandwidth for altsetting 1" Bug was introduced by commit cf9a08ae in v3.9 Fixes: cf9a08ae (usb: gadget: convert source sink and loopback to new function interface) Reviewed-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Gregory CLEMENT authored
commit d8eb6c65 upstream. commit 511f3c53 (usb: gadget: udc-core: fix a regression during gadget driver unbinding) introduced a crash when DEBUG is enabled. The debug trace in the atmel_usba_stop function made the assumption that the driver pointer passed in parameter was not NULL, but since the commit above, such assumption was no longer always true. This commit now uses the driver pointer stored in udc which fixes this issue. [ balbi@ti.com : improved commit log a bit ] Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Kees Cook authored
commit aba37fd9 upstream. This makes sure that the name coming out of configfs cannot be used accidentally as a format string. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Jeff Mahoney authored
commit 01d88857 upstream. jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-2) The -ENOENT is due to readdir calling dir_emit on the same entry twice. If the dir_emit callback sleeps and the tree is changed underneath us, we won't be able to trust deh_offset(deh) anymore. We need to save next_pos before we might sleep so we can find the next entry. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Russell King authored
commit c39b0695 upstream. Loading cursors to the LCD controller's SRAM can be corrupted when the configured pixel clock is relatively slow. This seems to be caused when we write back-to-back to the SRAM registers. There doesn't appear to be any status register we can read to check when an access has completed. Inserting a dummy read between the writes appears to fix the problem. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Miklos Szeredi authored
commit 838977f0 upstream. This fixes commit 6290b53d (arm64: compat: Wire up new AArch32 syscalls) which did not update __NR_compat_syscalls accordingly. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Will Deacon authored
commit ec6931b2 upstream. The asm-generic, big-endian version of zero_bytemask creates a mask of bytes preceding the first zero-byte by left shifting ~0ul based on the position of the first zero byte. Unfortunately, if the first (top) byte is zero, the output of prep_zero_mask has only the top bit set, resulting in undefined C behaviour as we shift left by an amount equal to the width of the type. As it happens, GCC doesn't manage to spot this through the call to fls(), but the issue remains if architectures choose to implement their shift instructions differently. An example would be arch/arm/ (AArch32), where LSL Rd, Rn, #32 results in Rd == 0x0, whilst on arch/arm64 (AArch64) LSL Xd, Xn, #64 results in Xd == Xn. Rather than check explicitly for the problematic shift, this patch adds an extra shift by 1, replacing fls with __fls. Since zero_bytemask is never called with a zero argument (has_zero() is used to check the data first), we don't need to worry about calling __fls(0), which is undefined. Cc: Victor Kamensky <victor.kamensky@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Matt Fleming authored
commit 47514c99 upstream. We're currently passing the file handle for the root file system to efi_file_read() and efi_file_close(), instead of the file handle for the file we wish to read/close. While this has worked up until now, it seems that it has only been by pure luck. Olivier explains, "The issue is the UEFI Fat driver might return the same function for 'fh->read()' and 'h->read()'. While in our case it does not work with a different implementation of EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. In our case, we return a different pointer when reading a directory and reading a file." Fixing this actually clears up the two functions because we can drop one of the arguments, and instead only pass a file 'handle' argument. Reported-by:
Olivier Martin <olivier.martin@arm.com> Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
Matt Fleming authored
commit 7e8213c1 upstream. code32_start should point at the start of the protected mode code, and *not* at the beginning of the bzImage. This is much easier to do in assembly so document that callers of make_boot_params() need to fill out code32_start. The fallout from this bug is that we would end up relocating the image but copying the image at some offset, resulting in what appeared to be memory corruption. Reported-by:
Thomas Bächler <thomas@archlinux.org> Signed-off-by:
-
K. Y. Srinivasan authored
commit 03367ef5 upstream. Only ws2012r2 hosts support the ability to reconnect to the host on VMBUS. This functionality is needed by kexec in Linux. To use this functionality we need to negotiate version 3.0 of the VMBUS protocol. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Andy Grover authored
commit 2c42be2d upstream. ft_del_tpg checks tpg->tport is set before unlinking the tpg from the tport when the tpg is being removed. Set this pointer in ft_tport_create, or the unlinking won't happen in ft_del_tpg and tport->tpg will reference a deleted object. This patch sets tpg->tport in ft_tport_create, because that's what ft_del_tpg checks, and is the only way to get back to the tport to clear tport->tpg. The bug was occuring when: - lport created, tport (our per-lport, per-provider context) is allocated. tport->tpg = NULL - tpg created - a PRLI is received. ft_tport_create is called, tpg is found and tport->tpg is set - tpg removed. ft_tpg is freed in ft_del_tpg. Since tpg->tport was not set, tport->tpg is not cleared and points at freed memory - Future calls to ft_tport_create return tport via first conditional, instead of searching for new tpg by calling ft_lport_find_tpg. tport->tpg is still invalid, and will access freed memory. see https://bugzilla.redhat.com/show_bug.cgi?id=1071340Signed-off-by:
Andy Grover <agrover@redhat.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
commit d84287bc upstream. This patch fixes a double free bug during IBLOCK backend shutdown where bioset_integrity_free() was incorrectly called ahead of bioset_free(), who is already making the same call directly. This bug was introduced with commit ecebbf6c, and will end up triggering a general protection fault in iblock_free_device() Reviewed-by:
Sagi Grimberg <sagig@mellanox.com> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: Quinn Tran <quinn.tran@qlogic.com> Cc: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
-
Martin Svec authored
commit a1e1774c upstream. When compiled with CONFIG_DEBUG_SG set, uninitialized SGL leads to BUG() in compare_and_write_callback(). Signed-off-by:
Martin Svec <martin.svec@zoner.cz> Signed-off-by:
-
Quinn Tran authored
commit 9d2e59f2 upstream. Ram disk is allocating 8x more space than required for diff data. For large RAM disk test, there is small potential for memory starvation. (Use block_size when calculating total_sg_needed - sagi + nab) Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
Quinn Tran <quinn.tran@qlogic.com> Signed-off-by:
-
Nicholas Bellinger authored
commit d444edc6 upstream. This patch fixes a long-standing bug in iscsit_build_conn_drop_async_message() where during ERL=2 connection recovery, a bogus conn_p pointer could end up being used to send the ISCSI_OP_ASYNC_EVENT + DROPPING_CONNECTION notifying the initiator that cmd->logout_cid has failed. The bug was manifesting itself as an OOPs in iscsit_allocate_cmd() with a bogus conn_p pointer in iscsit_build_conn_drop_async_message(). Reported-by:
Arshad Hussain <arshad.hussain@calsoftinc.com> Reported-by:
santosh kulkarni <santosh.kulkarni@calsoftinc.com> Signed-off-by:
-
Dan Carpenter authored
commit e2c70425 upstream. The original code always set the upper 32 bits to zero because it was doing a shift of the wrong variable. Fixes: 1a4f550a ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other fixes') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Dan Carpenter authored
commit b2a72ec3 upstream. qla2x00_mem_alloc() returns 1 on success and -ENOMEM on failure. On the one hand the caller assumes non-zero is success but on the other hand the caller also assumes that it returns an error code. I've fixed it to return zero on success and a negative error code on failure. This matches the documentation as well. [jejb: checkpatch fix] Fixes: e315cd28 ('[SCSI] qla2xxx: Code changes for qla data structure refactoring') Signed-off-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
-
Mike Marciniszyn authored
commit b0768080 upstream. The code was incorrectly using sg_dma_address() and sg_dma_len() instead of ib_sg_dma_address() and ib_sg_dma_len(). This prevents srpt from functioning with the Intel HCA and indeed will corrupt memory badly. Cc: Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Tested-by:
Vinod Kumar <vinod.kumar@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
-
Moni Shoua authored
commit b2853fd6 upstream. The code that resolves the passive side source MAC within the rdma_cm connection request handler was both redundant and buggy, so remove it. It was redundant since later, when an RC QP is modified to RTR state, the resolution will take place in the ib_core module. It was buggy because this callback also deals with UD SIDR exchange, for which we incorrectly looked at the REQ member of the CM event and dereferenced a random value. Fixes: dd5f03be ("IB/core: Ethernet L2 attributes in verbs/cm structures") Signed-off-by:
Moni Shoua <monis@mellanox.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
