- 23 Jun, 2015 40 commits
-
-
Jonas Gorski authored
commit 9dd6f1c1 upstream. Due to a typo the illegal access interrupt is never cleared in by the interupt handler, causing an effective deadlock on the first illegal access. This was broken since the code was introduced in 5433acd8 ("MIPS: ralink: add illegal access driver"), but only exposed when the Kconfig symbol was added, thus enabling the code. Fixes: a7b7aad3 ("MIPS: ralink: add missing symbol for RALINK_ILL_ACC") Signed-off-by:
Jonas Gorski <jogo@openwrt.org> Cc: linux-mips@linux-mips.org Cc: John Crispin <blogic@openwrt.org> Patchwork: https://patchwork.linux-mips.org/patch/10172/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wang Long authored
commit 10802932 upstream. The producer should be used producer_fifo as its sched_priority, so correct it. Link: http://lkml.kernel.org/r/1433923957-67842-1-git-send-email-long.wanglong@huawei.comSigned-off-by:
Wang Long <long.wanglong@huawei.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Andy Lutomirski authored
commit 425be567 upstream. The early_idt_handlers asm code generates an array of entry points spaced nine bytes apart. It's not really clear from that code or from the places that reference it what's going on, and the code only works in the first place because GAS never generates two-byte JMP instructions when jumping to global labels. Clean up the code to generate the correct array stride (member size) explicitly. This should be considerably more robust against screw-ups, as GAS will warn if a .fill directive has a negative count. Using '. =' to advance would have been even more robust (it would generate an actual error if it tried to move backwards), but it would pad with nulls, confusing anyone who tries to disassemble the code. The new scheme should be much clearer to future readers. While we're at it, improve the comments and rename the array and common code. Binutils may start relaxing jumps to non-weak labels. If so, this change will fix our build, and we may need to backport this change. Before, on x86_64: 0000000000000000 <early_idt_handlers>: 0: 6a 00 pushq $0x0 2: 6a 00 pushq $0x0 4: e9 00 00 00 00 jmpq 9 <early_idt_handlers+0x9> 5: R_X86_64_PC32 early_idt_handler-0x4 ... 48: 66 90 xchg %ax,%ax 4a: 6a 08 pushq $0x8 4c: e9 00 00 00 00 jmpq 51 <early_idt_handlers+0x51> 4d: R_X86_64_PC32 early_idt_handler-0x4 ... 117: 6a 00 pushq $0x0 119: 6a 1f pushq $0x1f 11b: e9 00 00 00 00 jmpq 120 <early_idt_handler> 11c: R_X86_64_PC32 early_idt_handler-0x4 After: 0000000000000000 <early_idt_handler_array>: 0: 6a 00 pushq $0x0 2: 6a 00 pushq $0x0 4: e9 14 01 00 00 jmpq 11d <early_idt_handler_common> ... 48: 6a 08 pushq $0x8 4a: e9 d1 00 00 00 jmpq 120 <early_idt_handler_common> 4f: cc int3 50: cc int3 ... 117: 6a 00 pushq $0x0 119: 6a 1f pushq $0x1f 11b: eb 03 jmp 120 <early_idt_handler_common> 11d: cc int3 11e: cc int3 11f: cc int3 Signed-off-by:
Andy Lutomirski <luto@kernel.org> Acked-by:
H. Peter Anvin <hpa@linux.intel.com> Cc: Binutils <binutils@sourceware.org> Cc: Borislav Petkov <bp@alien8.de> Cc: H.J. Lu <hjl.tools@gmail.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/ac027962af343b0c599cbfcf50b945ad2ef3d7a8.1432336324.git.luto@kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Arthur Demchenkov authored
commit b04c846c upstream. Fixed regression. After commit 29e409f0 ("xhci: Allow xHCI drivers to be built as separate modules") the module xhci_hcd became non-removable. That behaviour is not expected and there're no notes about it in commit message. The module should be removable as it blocks PM suspend/resume functions (Debian Bug#666406). Signed-off-by:
Arthur Demchenkov <spinal.by@gmail.com> Reviewed-by:
Andrew Bresticker <abrestic@chromium.org> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Chris Bainbridge authored
commit a00918d0 upstream. Regression in commit 638139eb ("usb: hub: allow to process more usb hub events in parallel") The regression resulted in intermittent failure to initialise a 10-port hub (with three internal VL812 4-port hub controllers) on boot, with a failure rate of around 8%, due to multiple race conditions when accessing addr_dev and slot_id in struct xhci_hcd. This regression also exposed a problem with xhci_setup_device, which "should be protected by the usb_address0_mutex" but no longer is due to commit 6fecd4f2 ("USB: separate usb_address0 mutexes for each bus") With separate buses (and locks) it is no longer the case that a single lock will protect xhci_setup_device from accesses by two parallel threads processing events on the two buses. Fix this by adding a mutex to protect addr_dev and slot_id in struct xhci_hcd, and by making the assignment of slot_id atomic. Fixes multiple boot errors: [ 0.583008] xhci_hcd 0000:00:14.0: Bad Slot ID 2 [ 0.583009] xhci_hcd 0000:00:14.0: Could not allocate xHCI USB device data structures [ 0.583012] usb usb1-port3: couldn't allocate usb_device And: [ 0.637409] xhci_hcd 0000:00:14.0: Error while assigning device slot ID [ 0.637417] xhci_hcd 0000:00:14.0: Max number of devices this xHCI host supports is 32. [ 0.637421] usb usb1-port1: couldn't allocate usb_device And: [ 0.753372] xhci_hcd 0000:00:14.0: ERROR: unexpected setup context command completion code 0x0. [ 0.753373] usb 1-3: hub failed to enable device, error -22 [ 0.753400] xhci_hcd 0000:00:14.0: Error while assigning device slot ID [ 0.753402] xhci_hcd 0000:00:14.0: Max number of devices this xHCI host supports is 32. [ 0.753403] usb usb1-port3: couldn't allocate usb_device And: [ 11.018386] usb 1-3: device descriptor read/all, error -110 And: [ 5.753838] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command Tested with 200 reboots, resulting in no USB hub init related errors. Fixes: 638139eb ("usb: hub: allow to process more usb hub events in parallel") Link: https://lkml.kernel.org/g/CAP-bSRb=A0iEYobdGCLpwynS7pkxpt_9ZnwyZTPVAoy0Y=Zo3Q@mail.gmail.comSigned-off-by:
Chris Bainbridge <chris.bainbridge@gmail.com> [changed git commit description style for checkpatch -Mathias] Signed-off-by:
-
Subbaraya Sundeep Bhatta authored
commit 459e210c upstream. Fixed the incorrect macro definitions correctly as per databook. Signed-off-by:
Subbaraya Sundeep Bhatta <sbhatta@xilinx.com> Fixes: b09bb642 (usb: dwc3: gadget: implement Global Command support) Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Patrick Riphagen authored
commit 1df5b888 upstream. This adds support for new Xsens device, Motion Tracker Development Board, using Xsens' own Vendor ID Signed-off-by:
Patrick Riphagen <patrick.riphagen@xsens.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
John D. Blair authored
commit df72d588 upstream. Added the USB serial device ID for the HubZ dual ZigBee and Z-Wave radio dongle. Signed-off-by:
John D. Blair <johnb@candicontrols.com> Signed-off-by:
-
NeilBrown authored
commit aad653a0 upstream. bdi_unregister() now contains very little functionality. It contains a "WARN_ON" if bdi->dev is NULL. This warning is of no real consequence as bdi->dev isn't needed by anything else in the function, and it triggers if blk_cleanup_queue() -> bdi_destroy() is called before bdi_unregister, which happens since Commit: 6cd18e71 ("block: destroy bdi before blockdev is unregistered.") So this isn't wanted. It also calls bdi_set_min_ratio(). This needs to be called after writes through the bdi have all been flushed, and before the bdi is destroyed. Calling it early is better than calling it late as it frees up a global resource. Calling it immediately after bdi_wb_shutdown() in bdi_destroy() perfectly fits these requirements. So bdi_unregister() can be discarded with the important content moved to bdi_destroy(), as can the writeback_bdi_unregister event which is already not used. Reported-by:
Mike Snitzer <snitzer@redhat.com> Fixes: c4db59d3 ("fs: don't reassign dirty inodes to default_backing_dev_info") Fixes: 6cd18e71 ("block: destroy bdi before blockdev is unregistered.") Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Dan Williams <dan.j.williams@intel.com> Tested-by:
Nicholas Moulin <nicholas.w.moulin@linux.intel.com> Signed-off-by:
NeilBrown <neilb@suse.de> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Dan Williams authored
commit 4d66e5e9 upstream. ================================= [ INFO: inconsistent lock state ] 4.1.0-rc7+ #217 Tainted: G O --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/6/0 [HC0[0]:SC1[1]:HE1:SE0] takes: (ext_devt_lock){+.?...}, at: [<ffffffff8143a60c>] blk_free_devt+0x3c/0x70 {SOFTIRQ-ON-W} state was registered at: [<ffffffff810bf6b1>] __lock_acquire+0x461/0x1e70 [<ffffffff810c1947>] lock_acquire+0xb7/0x290 [<ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50 [<ffffffff8143a07d>] blk_alloc_devt+0x6d/0xd0 <-- take the lock in process context [..] [<ffffffff810bf64e>] __lock_acquire+0x3fe/0x1e70 [<ffffffff810c00ad>] ? __lock_acquire+0xe5d/0x1e70 [<ffffffff810c1947>] lock_acquire+0xb7/0x290 [<ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70 [<ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50 [<ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70 [<ffffffff8143a60c>] blk_free_devt+0x3c/0x70 <-- take the lock in softirq [<ffffffff8143bfec>] part_release+0x1c/0x50 [<ffffffff8158edf6>] device_release+0x36/0xb0 [<ffffffff8145ac2b>] kobject_cleanup+0x7b/0x1a0 [<ffffffff8145aad0>] kobject_put+0x30/0x70 [<ffffffff8158f147>] put_device+0x17/0x20 [<ffffffff8143c29c>] delete_partition_rcu_cb+0x16c/0x180 [<ffffffff8143c130>] ? read_dev_sector+0xa0/0xa0 [<ffffffff810e0e0f>] rcu_process_callbacks+0x2ff/0xa90 [<ffffffff810e0dcf>] ? rcu_process_callbacks+0x2bf/0xa90 [<ffffffff81067e2e>] __do_softirq+0xde/0x600 Neil sees this in his tests and it also triggers on pmem driver unbind for the libnvdimm tests. This fix is on top of an initial fix by Keith for incorrect usage of mutex_lock() in this path: 2da78092 "block: Fix dev_t minor allocation lifetime". Both this and 2da78092 are candidates for -stable. Fixes: 2da78092 ("block: Fix dev_t minor allocation lifetime") Cc: Keith Busch <keith.busch@intel.com> Reported-by:
-
Sam Hung authored
commit 692dd191 upstream. This adds new icbody type to the list recognized by Elantech PS/2 driver. Signed-off-by:
Sam Hung <sam.hung@emc.com.tw> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Hans de Goede authored
commit 5f0ee9d1 upstream. Make the check to skip the rate check more lax, so that it applies to all hw_version 4 models. This fixes the touchpad not being detected properly on Asus PU551LA laptops. Reported-and-tested-by:
David Zafra Gómez <dezeta@klo.es> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Peter Hutterer authored
commit 7f2ca8b5 upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1223051#c2 Tested-by: tommy.gagnes@gmail.com Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
-
Hans de Goede authored
commit 088df2cc upstream. On some v7 devices (e.g. Lenovo-E550) the deltas reported are typically only in the 0-1 range dividing this by 2 results in a range of 0-0. And even for v7 devices where this does not lead to making the trackstick entirely unusable, it makes it twice as slow as before we added v7 support and were using the ps/2 mouse emulation of the dual point setup. If some kind of generic slowdown is actually necessary for some devices, then that belongs in userspace, not in the kernel. Reported-and-tested-by:
Rico Moorman <rico.moorman@gmail.com> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by:
-
Vasily Khoruzhick authored
commit 8d487a43 upstream. Initialize sysreg by default, otherwise driver will crash in suspend callback when not using DT. Signed-off-by:
Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Fixes: a7750c3e ("i2c: s3c2410: Handle i2c sys_cfg register in i2c driver") Signed-off-by:
-
Axel Lin authored
commit 3e59ae4a upstream. Make the modalias match driver name, this is required to make module auto-loading work. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by:
-
Ludovic Desroches authored
commit 4c374fc7 upstream. Using _bh variant for spin locks causes this kind of warning: Starting logging: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3 at /ssd_drive/linux/kernel/softirq.c:151 __local_bh_enable_ip+0xe8/0xf4() Modules linked in: CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.1.0-rc2+ #94 Hardware name: Atmel SAMA5 [<c0013c04>] (unwind_backtrace) from [<c00118a4>] (show_stack+0x10/0x14) [<c00118a4>] (show_stack) from [<c001bbcc>] (warn_slowpath_common+0x80/0xac) [<c001bbcc>] (warn_slowpath_common) from [<c001bc14>] (warn_slowpath_null+0x1c/0x24) [<c001bc14>] (warn_slowpath_null) from [<c001e28c>] (__local_bh_enable_ip+0xe8/0xf4) [<c001e28c>] (__local_bh_enable_ip) from [<c01fdbd0>] (at_xdmac_device_terminate_all+0xf4/0x100) [<c01fdbd0>] (at_xdmac_device_terminate_all) from [<c02221a4>] (atmel_complete_tx_dma+0x34/0xf4) [<c02221a4>] (atmel_complete_tx_dma) from [<c01fe4ac>] (at_xdmac_tasklet+0x14c/0x1ac) [<c01fe4ac>] (at_xdmac_tasklet) from [<c001de58>] (tasklet_action+0x68/0xb4) [<c001de58>] (tasklet_action) from [<c001dfdc>] (__do_softirq+0xfc/0x238) [<c001dfdc>] (__do_softirq) from [<c001e140>] (run_ksoftirqd+0x28/0x34) [<c001e140>] (run_ksoftirqd) from [<c0033a3c>] (smpboot_thread_fn+0x138/0x18c) [<c0033a3c>] (smpboot_thread_fn) from [<c0030e7c>] (kthread+0xdc/0xf0) [<c0030e7c>] (kthread) from [<c000f480>] (ret_from_fork+0x14/0x34) ---[ end trace b57b14a99c1d8812 ]--- It comes from the fact that devices can called some code from the DMA controller with irq disabled. _bh variant is not intended to be used in this case since it can enable irqs. Switch to irqsave/irqrestore variant to avoid this situation. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Ludovic Desroches authored
commit 765c37d8 upstream. Rework slave configuration part in order to more report wrong errors about the configuration. Only maxburst and addr width values are checked when doing the slave configuration. The validity of the channel configuration is done at prepare time. Signed-off-by:
-
Krzysztof Kozlowski authored
commit 88d04643 upstream. Some drivers implement only pause operation (no resuming). Example is pl330 where pause is needed for getting residuum. pl330 does not support resume operation, transfer must be stopped after pause. However for slaves this is exposed always as "pause and resume" which introduces subtle errors on Odroid U3 board (Exynos4412 with pl330). After adding pause function to pl330 driver the audio playback (utilizing DMA) gets choppy after some time (approximately 24 hours). Fix this by exposing "cmd_pause" if and only if pause and resume are implemented. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 88987d2c ("dmaengine: pl330: add DMA_PAUSE feature") Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 81cc6edc upstream. The pl330 device could hang infinitely on certain boards when DMA channels are terminated. It was caused by lack of runtime resume when executing pl330_terminate_all() which calls the _stop() function. _stop() accesses device register and can loop infinitely while checking for device state. The hang was confirmed by Dinh Nguyen on Altera SOCFPGA Cyclone V board during boot. It can be also triggered with: $ echo 1 > /sys/module/dmatest/parameters/iterations $ echo dma1chan0 > /sys/module/dmatest/parameters/channel $ echo 1 > /sys/module/dmatest/parameters/run $ sleep 1 $ cat /sys/module/dmatest/parameters/run Reported-by:
Dinh Nguyen <dinguyen@opensource.altera.com> Signed-off-by:
-
Jurgen Kramer authored
commit 3b7e5c7e upstream. This patch adds native DSD support for the XMOS based JLsounds I2SoverUSB board Signed-off-by:
Jurgen Kramer <gtmkramer@xs4all.nl> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Clemens Ladisch authored
commit ea114fc2 upstream. The driver worked around an error in the MAYA44 USB(+)'s mixer unit descriptor by aborting before parsing the missing field. However, aborting parsing too early prevented parsing of the other units connected to this unit, so the capture mixer controls would be missing. Fix this by moving the check for this descriptor error after the parsing of the unit's input pins. Reported-by:
nightmixes <nightmixes@gmail.com> Tested-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Clemens Ladisch authored
commit 044bddb9 upstream. Add mixer control names for the ESI Maya44 USB+ (which appears to be identical width the AudioTrak Maya44 USB). Reported-by:
-
Eric Wong authored
commit 2f80b295 upstream. This quirk allows us to avoid the noisy: current rate 0 is different from the runtime rate message every time playback starts. While USB DAC in the RR2150 supports reading the sample rate, it never returns a sample rate other than zero in my observation with common sample rates. Signed-off-by:
Eric Wong <normalperson@yhbt.net> Cc: Joe Turner <joe@oampo.co.uk> Signed-off-by:
-
Wolfram Sang authored
commit 1ef9f058 upstream. Fix this from the logs: usb 7-1: New USB device found, idVendor=046d, idProduct=08ca ... usb 7-1: Warning! Unlikely big volume range (=3072), cval->res is probably wrong. usb 7-1: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1 Signed-off-by:
-
Takashi Iwai authored
commit b5d724b1 upstream. Acer Aspire 9420 with ALC883 (1025:0107) needs the fixup for EAPD to make the sound working like other Aspire models. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94111Signed-off-by:
-
David Woodhouse authored
commit 4ed6a540 upstream. When we use 'intel_iommu=igfx_off' to disable translation for the graphics, and when we discover that the BIOS has misconfigured the DMAR setup for I/OAT, we use a special DUMMY_DEVICE_DOMAIN_INFO value in dev->archdata.iommu to indicate that translation is disabled. With passthrough mode, we were attempting to dereference that as a normal pointer to a struct device_domain_info when setting up an identity mapping for the affected device. This fixes the problem by making device_to_iommu() explicitly check for the special value and indicate that no IOMMU was found to handle the devices in question. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
David Woodhouse authored
commit 18436afd upstream. Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains") prevents certain options for devices with RMRRs. This even prevents those devices from getting a 1:1 mapping with 'iommu=pt', because we don't have the code to handle *preserving* the RMRR regions when moving the device between domains. There's already an exclusion for USB devices, because we know the only reason for RMRRs there is a misguided desire to keep legacy keyboard/mouse emulation running in some theoretical OS which doesn't have support for USB in its own right... but which *does* enable the IOMMU. Add an exclusion for graphics devices too, so that 'iommu=pt' works there. We should be able to successfully assign graphics devices to guests too, as long as the initial handling of stolen memory is reconfigured appropriately. This has certainly worked in the past. Signed-off-by:
-
Laura Abbott authored
commit 72586c60 upstream. Commit 32f13521 ("n_tty: Line copy to user buffer in canonical mode") changed cannonical mode copying to use copy_to_user but missed adding the call to the audit framework. Add in the appropriate functions to get audit support. Fixes: 32f13521 ("n_tty: Line copy to user buffer in canonical mode") Reported-by:
Miloslav Trmač <mitr@redhat.com> Signed-off-by:
Laura Abbott <labbott@fedoraproject.org> Reviewed-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Sudeep Holla authored
commit 3370e13a upstream. On some simulators like GEM5, caches may not be simulated. In those cases, the cache levels and leaves will be zero and will result in following exception: Unable to handle kernel NULL pointer dereference at virtual address 0040 pgd = ffffffc0008fa000 [00000040] *pgd=00000009f6807003, *pud=00000009f6807003, *pmd=00000009f6808003, *pte=006000002c010707 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.1.0-rc5 #198 task: ffffffc9768a0000 ti: ffffffc9768a8000 task.ti: ffffffc9768a8000 PC is at detect_cache_attributes+0x98/0x2c8 LR is at detect_cache_attributes+0x88/0x2c8 kcalloc(0) returns a special value ZERO_SIZE_PTR which is non-NULL value but results in fault only on any attempt to dereferencing it. So checking for the non-NULL pointer will not suffice. This patch checks for non-zero cache leaf nodes and returns error if there are no cache leaves in detect_cache_attributes. Cc: Will Deacon <will.deacon@arm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reported-by:
William Wang <william.wang@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit d046ba26 upstream. The adis16448, unlike the other chips in this family, in addition to the hardware channels also sends out the DIAG_STAT register in burst mode before them. Handle that case by skipping over the first 2 bytes before we pass the received data to the buffer. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Fixes: 76ada52f ("iio:adis16400: Add support for the adis16448") Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Paul Cercueil authored
commit 9df56035 upstream. There are a few issues with the burst mode support. For one we don't setup the rx buffer, so the buffer will never be filled and all samples will read as the zero. Furthermore the tx buffer has the wrong type, which means the driver sends the wrong command and not the right data is returned. The final issue is that in burst mode all channels are transferred. Hence the length of the transfer length should be the number of hardware channels * 2 bytes. Currently the driver uses indio_dev->scan_bytes for this. But if the timestamp channel is enabled the scan_bytes will be larger than the burst length. Fix this by just calculating the burst length based on the number of hardware channels. Signed-off-by:
Paul Cercueil <paul.cercueil@analog.com> Signed-off-by:
-
Paul Cercueil authored
commit c2a8b623 upstream. We unfortunately can't use ~0UL for the scan mask to indicate that the only valid scan mask is all channels selected. The IIO core needs the exact mask to work correctly and not a super-set of it. So calculate the masked based on the channels that are available for a particular device. Signed-off-by:
-
Paul Cercueil authored
commit 7323d598 upstream. Previously, the two voltage channels had the same ID, which didn't cause conflicts in sysfs only because one channel is named and the other isn't; this is still violating the spec though, two indexed channels should never have the same index. Signed-off-by:
-
Lars-Peter Clausen authored
commit 69ca2d77 upstream. Add the scale for the pressure channel, which is currently missing. Signed-off-by:
-
Axel Lin authored
commit e5d73218 upstream. Remove extra space between platform prefix and DRIVER_NAME in MODULE_ALIAS. Signed-off-by:
-
Herbert Xu authored
[ Upstream commit: Not applicable ] The current rhashtable rehash code is buggy and can't deal with parallel insertions/removals without corrupting the hash table. This patch disables it by partially reverting c5adde94 ("netlink: eliminate nl_sk_hash_lock"). Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Nikolay Aleksandrov authored
[ Upstream commit c4c832f8 ] br_fdb_update() can be called in process context in the following way: br_fdb_add() -> __br_fdb_add() -> br_fdb_update() (if NTF_USE flag is set) so we need to disable softirqs because there are softirq users of the hash_lock. One easy way to reproduce this is to modify the bridge utility to set NTF_USE, enable stp and then set maxageing to a low value so br_fdb_cleanup() is called frequently and then just add new entries in a loop. This happens because br_fdb_cleanup() is called from timer/softirq context. The spin locks in br_fdb_update were _bh before commit f8ae737d ("[BRIDGE]: forwarding remove unneeded preempt and bh diasables") and at the time that commit was correct because br_fdb_update() couldn't be called from process context, but that changed after commit: 292d1398 ("bridge: add NTF_USE support") Using local_bh_disable/enable around br_fdb_update() allows us to keep using the spin_lock/unlock in br_fdb_update for the fast-path. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Fixes: 292d1398 ("bridge: add NTF_USE support") Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sriharsha Basavapatna authored
[ Upstream commit e51000db ] There are several places in the driver (all in control paths) where coherent dma memory is being allocated using either dma_alloc_coherent() or the deprecated pci_alloc_consistent(). All these calls should be changed to use dma_zalloc_coherent() to avoid uninitialized fields in data structures backed by this memory. Reported-by:
Joerg Roedel <jroedel@suse.de> Tested-by:
Sriharsha Basavapatna <sriharsha.basavapatna@avagotech.com> Signed-off-by:
-
Shawn Bohrer authored
[ Upstream commit 6e540309 ] 421b3885 "udp: ipv4: Add udp early demux" introduced a regression that allowed sockets bound to INADDR_ANY to receive packets from multicast groups that the socket had not joined. For example a socket that had joined 224.168.2.9 could also receive packets from 225.168.2.9 despite not having joined that group if ip_early_demux is enabled. Fix this by calling ip_check_mc_rcu() in udp_v4_early_demux() to verify that the multicast packet is indeed ours. Signed-off-by:
Shawn Bohrer <sbohrer@rgmadvisors.com> Reported-by:
Yurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru> Signed-off-by:
-
