- 05 Jun, 2017 40 commits
-
-
Johan Hovold authored
commit 2d380889 upstream. Make sure to check for short transfers to avoid underflow in a loop condition when parsing the receive buffer. Also fix an off-by-one error in the incomplete sanity check which could lead to invalid data being parsed. Fixes: 8c209e67 ("USB: make actual_length in struct urb field u32") Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Guennadi Liakhovetski authored
commit 17c341ec upstream. Don't mix up UVC_BUF_STATE_* and VB2_BUF_STATE_* codes. Fixes: 6998b6fb ("[media] uvcvideo: Use videobuf2-vmalloc") Signed-off-by:
Guennadi Liakhovetski <guennadi.liakhovetski@intel.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> [bwh: Backported to 3.16: adjust context] Signed-off-by:
-
David Dillow authored
commit f7116e11 upstream. dma_pte_free_level() recurses down the IOMMU page tables and frees directory pages that are entirely contained in the given PFN range. Unfortunately, it incorrectly calculates the starting address covered by the PTE under consideration, which can lead to it clearing an entry that is still in use. This occurs if we have a scatterlist with an entry that has a length greater than 1026 MB and is aligned to 2 MB for both the IOMMU and physical addresses. For example, if __domain_mapping() is asked to map a two-entry scatterlist with 2 MB and 1028 MB segments to PFN 0xffff80000, it will ask if dma_pte_free_pagetable() is asked to PFNs from 0xffff80200 to 0xffffc05ff, it will also incorrectly clear the PFNs from 0xffff80000 to 0xffff801ff because of this issue. The current code will set level_pfn to 0xffff80200, and 0xffff80200-0xffffc01ff fits inside the range being cleared. Properly setting the level_pfn for the current level under consideration catches that this PTE is outside of the range being cleared. This patch also changes the value passed into dma_pte_free_level() when it recurses. This only affects the first PTE of the range being cleared, and is handled by the existing code that ensures we start our cursor no lower than start_pfn. This was found when using dma_map_sg() to map large chunks of contiguous memory, which immediatedly led to faults on the first access of the erroneously-deleted mappings. Fixes: 3269ee0b ("intel-iommu: Fix leaks in pagetable freeing") Reviewed-by:
Benjamin Serebrin <serebrin@google.com> Signed-off-by:
David Dillow <dillow@google.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Randy Dunlap authored
commit e3bb3cdd upstream. Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and CONFIG_DVB_DM1105=y. drivers/built-in.o: In function `dm1105_probe': dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Igor Pylypiv authored
commit 2c474b85 upstream. Conversion macros le16_to_cpu was removed and that caused new sparse warning sparse output: drivers/staging/wlan-ng/p80211netdev.c:241:44: warning: incorrect type in argument 2 (different base types) drivers/staging/wlan-ng/p80211netdev.c:241:44: expected unsigned short [unsigned] [usertype] fc drivers/staging/wlan-ng/p80211netdev.c:241:44: got restricted __le16 [usertype] fc Fixes: 7ad82572 ("staging:wlan-ng:Fix sparse warning") Signed-off-by:
Igor Pylypiv <igor.pylypiv@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
commit a971df0b upstream. This allows tracking device state and e.g. makes devm work as expected. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Lars-Peter Clausen authored
commit da8892d4 upstream. The adv7604 driver platform data contains fields for configuring the drive strength of the output pins. When probing the driver through DT these fields are not explicitly initialized, which means they are left at 0. This is a reserved setting for the drive strength configuration though and can cause signal integrity issues. Whether these signal integrity issues are visible depends on the PCB specifics (e.g. the higher the load capacitance for the output the more visible the issue). But it has been observed on existing solutions at high pixel clock rates. Initialize the drive strength settings to the power-on-reset value of the device when probing through devicetree to avoid this issue. Fixes: 0e158be0162b ("adv7604: Add DT support") Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Marc Zyngier authored
commit 8f36ebaf upstream. When we fault in a page, we flush it to the PoC (Point of Coherency) if the faulting vcpu has its own caches off, so that it can observe the page we just brought it. But if the vcpu has its caches on, we skip that step. Bad things happen when *another* vcpu tries to access that page with its own caches disabled. At that point, there is no garantee that the data has made it to the PoC, and we access stale data. The obvious fix is to always flush to PoC when a page is faulted in, no matter what the state of the vcpu is. Fixes: 2d58b733 ("arm64: KVM: force cache clean on page fault when caches are off") Reviewed-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> [bwh: Backported to 3.16: conditions for flushing were simpler here] Signed-off-by:
-
Jan Kara authored
commit 3b136499 upstream. ext4_journalled_write_end() did not propely handle all the cases when generic_perform_write() did not copy all the data into the target page and could mark buffers with uninitialized contents as uptodate and dirty leading to possible data corruption (which would be quickly fixed by generic_perform_write() retrying the write but still). Fix the problem by carefully handling the case when the page that is written to is not uptodate. Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Theodore Ts'o authored
commit b90197b6 upstream. If there is a error while copying data from userspace into the page cache during a write(2) system call, in data=journal mode, in ext4_journalled_write_end() were using page_zero_new_buffers() from fs/buffer.c. Unfortunately, this sets the buffer dirty flag, which is no good if journalling is enabled. This is a long-standing bug that goes back for years and years in ext3, but a combination of (a) data=journal not being very common, (b) in many case it only results in a warning message. and (c) only very rarely causes the kernel hang, means that we only really noticed this as a problem when commit 998ef75d caused this failure to happen frequently enough to cause generic/208 to fail when run in data=journal mode. The fix is to have our own version of this function that doesn't call mark_dirty_buffer(), since we will end up calling ext4_handle_dirty_metadata() on the buffer head(s) in questions very shortly afterwards in ext4_journalled_write_end(). Thanks to Dave Hansen and Linus Torvalds for helping to identify the root cause of the problem. Signed-off-by:
Jan Kara <jack@suse.com> Signed-off-by:
-
Jan Kara authored
commit cd648b8a upstream. If filesystem groups are artifically small (using parameter -g to mkfs.ext4), ext4_mb_normalize_request() can result in a request that is larger than a block group. Trim the request size to not confuse allocation code. Reported-by:
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Alex Deucher authored
commit a882f5de upstream. The vfct table can contain multiple vbios images if the platform contains multiple GPUs. Noticed by netkas on phoronix forums. This patch fixes those platforms. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> [bwh: Backported to 3.16: adjust context] Signed-off-by:
-
Martin Kaiser authored
commit 02c952c8 upstream. These functions are referencing s3c...._clk_regs[], which are marked as __initdata. When compiling with CONFIG_DEBUG_SECTION_MISMATCH=y, this produces warnings like WARNING: vmlinux.o(.text+0x198350): Section mismatch in reference from the function s3c2410_clk_sleep_init() to the (unknown reference) .init.data:(unknown) Mark the s3c...._clk_sleep_init() functions as __init in order to fix this. Fixes: ca2e90ac ("clk: samsung: add clock controller driver for s3c2412") Signed-off-by:
Martin Kaiser <martin@kaiser.cx> Reviewed-by:
Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Michel Dänzer authored
commit 239ac65f upstream. The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com>. Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Leo Yan authored
commit 55da97e3 upstream. In clock driver initialize phase the spinlock is missed to assignment to struct clkgate_separated, finally there have no locking to protect exclusive accessing for clock registers. This bug introduces the console has no output after enable coresight driver on 96boards Hikey; this is because console using UART3, which has shared the same register with coresight clock enabling bit. After applied this patch it can assign lock properly to protect exclusive accessing, and console can work well after enabled coresight modules. Fixes: 0aa0c95f ("clk: hisilicon: add common clock support") Signed-off-by:
Leo Yan <leo.yan@linaro.org> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Kirtika Ruchandani authored
commit 9d504435 upstream. Commit 5fc0f76c introduced Rx stats from debugfs, the function iwl_mvm_reset_frame_stats from that commit defines and sets mcs but does not use it. Compiling iwlwifi with W=1 gives this warning - iwlwifi/mvm/rs.c: In function ‘iwl_mvm_update_frame_stats’: iwlwifi/mvm/rs.c:3074:14: warning: variable ‘mcs’ set but not used [-Wunused-but-set-variable] Fixes: 5fc0f76c (iwlwifi: mvm: add Rx frames statistics via debugfs) Signed-off-by:
Kirtika Ruchandani <kirtika@google.com> Cc: Eyal Shapira <eyal@wizery.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> [bwh: Backported to 3.16: adjust filename, context] Signed-off-by:
-
Johan Hovold authored
commit c6dce262 upstream. Since commit 557aaa7f ("ft232: support the ASYNC_LOW_LATENCY flag") the FTDI driver has been using a receive latency-timer value of 1 ms instead of the device default of 16 ms. The latency timer is used to periodically empty a non-full receive buffer, but a status header is always sent when the timer expires including when the buffer is empty. This means that a two-byte bulk message is received every millisecond also for an otherwise idle port as long as it is open. Let's restore the pre-2009 behaviour which reduces the rate of the status messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5 Hz) by not setting ASYNC_LOW_LATENCY by default. Anyone willing to pay the price for the minimum-latency behaviour should set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool such as setserial (e.g. setserial /dev/ttyUSB0 low_latency). Note that since commit 0cbd81a9 ("USB: ftdi_sio: remove tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but to set a minimal latency timer. Reported-by:
Antoine Aubert <a.aubert@overkiz.com> Fixes: 557aaa7f ("ft232: support the ASYNC_LOW_LATENCY flag") Signed-off-by:
-
Maciej S. Szmigiero authored
commit d2ce4ea1 upstream. Near the beginning of w1_attach_slave_device() we increment a w1 master reference count. Later, when we are going to exit this function without actually attaching a slave device (due to failure of __w1_attach_slave_device()) we need to decrement this reference count back. Signed-off-by:
Maciej S. Szmigiero <mail@maciej.szmigiero.name> Fixes: 9fcbbac5 ("w1: process w1 netlink commands in w1_process thread") Cc: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
Maciej S. Szmigiero authored
commit 61cd1b4c upstream. ds2490 driver was doing USB transfers from / to buffers on a stack. This is not permitted and made the driver non-working with vmapped stacks. Since all these transfers are done under the same bus_mutex lock we can simply use shared buffers in a device private structure for two most common of them. While we are at it, let's also fix a comparison between int and size_t in ds9490r_search() which made the driver spin in this function if state register get requests were failing. Signed-off-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
Alexander Stein authored
commit d2522152 upstream. Adjust the bulk message timeout to the other ones (1000ms). Otherwise the following dmesg errors can be seen on a Raspberry Pi: [ 31.492386] Failed to read 1-wire data from 0x81: err=-110. [ 31.504168] 0x81: count=-110, status: [ 31.613404] Failed to read 1-wire data from 0x81: err=-110. [ 31.621915] 0x81: count=-110, status: [ 43.260968] Failed to read 1-wire data from 0x81: err=-110. [ 43.270998] 0x81: count=-110, status: [ 43.379959] Failed to read 1-wire data from 0x81: err=-110. [ 43.388854] 0x81: count=-110, status: Signed-off-by:
Alexander Stein <alexanders83@web.de> Acked-by:
-
Arnd Bergmann authored
commit 8c9b23ff upstream. A clean mips64 build produces no output except for two lines: Checking missing-syscalls for N32 Checking missing-syscalls for O32 On other architectures, there is no output at all, so let's do the same here for the sake of build testing. The 'kecho' macro is used to print the message on a normal build but skip it with 'make -s'. Fixes: e48ce6b8 ("[MIPS] Simplify missing-syscalls for N32 and O32") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: Maarten ter Huurne <maarten@treewalker.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/15040/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Krzysztof Opasiak authored
commit 33e4c1a9 upstream. As IN request has to be allocated in set_alt() and released in disable() we cannot use mutex to protect it as we cannot sleep in those funcitons. Let's replace this mutex with a spinlock. Tested-by:
David Lechner <david@lechnology.com> Signed-off-by:
Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> [bwh: Backported to 3.16: adjust filename] Signed-off-by:
-
Krzysztof Opasiak authored
commit aa65d11a upstream. When we unlock our spinlock to copy data to user we may get disabled by USB host and free the whole list of completed out requests including the one from which we are copying the data to user memory. To prevent from this let's remove our working element from the list and place it back only if there is sth left when we finish with it. Fixes: 99c51500 ("usb: gadget: hidg: register OUT INT endpoint for SET_REPORT") Tested-by:
-
Krzysztof Opasiak authored
commit 20d2ca95 upstream. Requests for out endpoint are allocated in bind() function but never released. This commit ensures that all pending requests are released when we disable out endpoint. Fixes: 99c51500 ("usb: gadget: hidg: register OUT INT endpoint for SET_REPORT") Tested-by:
-
Felipe F. Tonello authored
commit 079fe5a6 upstream. This function is shared between gadget functions, so this avoid unnecessary duplicated code and potentially avoid memory leaks. Reviewed-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe F. Tonello <eu@felipetonello.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> [bwh: Backported to 3.16: adjust filenames] Signed-off-by:
-
Felipe Balbi authored
commit ffb80fc6 upstream. At least macOS seems to be sending ClearFeature(ENDPOINT_HALT) to endpoints which aren't Halted. This makes DWC3's CLEARSTALL command time out which causes several issues for the driver. Instead, let's just return 0 and bail out early. Signed-off-by:
-
Liam Breck authored
commit ba52e757 upstream. Reading both fault and status registers and logging any fault should take priority over handling status register update. Fix by moving the status handling to later in interrupt routine. Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by:
Liam Breck <kernel@networkimprov.net> Acked-by:
Mark Greer <mgreer@animalcreek.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Sebastian Reichel <sre@kernel.org> [bwh: Backported to 3.16: adjust filename] Signed-off-by:
-
Liam Breck authored
commit 68abfb80 upstream. Caching the fault register after a single I2C read may not keep an accurate value. Fix by doing two reads in irq_handle_thread() and using the cached value elsewhere. If a safety timer fault later clears itself, we apparently don't get an interrupt (INT), however other interrupts would refresh the register cache. From the data sheet: "When a fault occurs, the charger device sends out INT and keeps the fault state in REG09 until the host reads the fault register. Before the host reads REG09 and all the faults are cleared, the charger device would not send any INT upon new faults. In order to read the current fault status, the host has to read REG09 two times consecutively. The 1st reads fault register status from the last read [1] and the 2nd reads the current fault register status." [1] presumably a typo; should be "last fault" Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by:
-
Liam Breck authored
commit 2d9fee6a upstream. We wrongly get uevents for bq24190-charger and bq24190-battery on every register change. Fix by checking the association with charger and battery before emitting uevent(s). Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by:
-
Thomas Elste authored
commit cd054ee1 upstream. The initial register reset of BQ24190 generates a charger status change whose propagation via power_supply_changed is prevented using a flag. This flag gets never reset so all following events are ignored as well leading for example to userspace not detecting charger connects/disconnects. Therefor change the reset condition of first_time flag, so only the propagation of the first charger status change is prevented. Signed-off-by:
Thomas Elste <thomas.elste@imms.de> Signed-off-by:
-
Liam Breck authored
commit d62acc5e upstream. The device specific data is not fully initialized on request_threaded_irq(). This may cause a crash when the IRQ handler tries to reference them. Fix the issue by installing IRQ handler at the end of the probe. Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by:
-
Liam Breck authored
commit e05ad7e0 upstream. pm_resume() does a register_reset() which clears charger host mode. Fix by calling set_mode_host() after the reset. Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by:
-
Liam Breck authored
commit 767eee36 upstream. The interrupt signal is TRIGGER_FALLING. This is is specified in the data sheet PIN FUNCTIONS: "The INT pin sends active low, 256us pulse to host to report charger device status and fault." Also the direction can be seen in the data sheet Figure 37 "BQ24190 with D+/D- Detection and USB On-The-Go (OTG)" which shows a 10k pull-up resistor installed for the sample configurations. Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by:
-
Omar Sandoval authored
commit 6c0ca7ae upstream. When we resize a struct sbitmap_queue, we update the wakeup batch size, but we don't update the wait count in the struct sbq_wait_states. If we resized down from a size which could use a bigger batch size, these counts could be too large and cause us to miss necessary wakeups. To fix this, update the wait counts when we resize (ensuring some careful memory ordering so that it's safe w.r.t. concurrent clears). This also fixes a theoretical issue where two threads could end up bumping the wait count up by the batch size, which could also potentially lead to hangs. Reported-by:
Martin Raiber <martin@urbackup.org> Fixes: e3a2b3f9 ("blk-mq: allow changing of queue depth through sysfs") Fixes: 2971c35f ("blk-mq: bitmap tag: fix race on blk_mq_bitmap_tags::wake_cnt") Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
Jens Axboe <axboe@fb.com> [bwh: Backported to 3.16: - Adjust filename - Rename almost everything - Use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()] Signed-off-by:
-
Bart Van Assche authored
commit 9d8f0bcc upstream. Eliminate a backwards goto statement from bt_clear_tag(). Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Brian Norris authored
commit 6183468a upstream. Similar to commit fcd2042e ("mwifiex: printk() overflow with 32-byte SSIDs"), we failed to account for the existence of 32-char SSIDs in our debugfs code. Unlike in that case though, we zeroed out the containing struct first, and I'm pretty sure we're guaranteed to have some padding after the 'ssid.ssid' and 'ssid.ssid_len' fields (the struct is 33 bytes long). So, this is the difference between: # cat /sys/kernel/debug/mwifiex/mlan0/info ... essid="0123456789abcdef0123456789abcdef " ... and the correct output: # cat /sys/kernel/debug/mwifiex/mlan0/info ... essid="0123456789abcdef0123456789abcdef" ... Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Michael Petlan authored
commit 5c64f99b upstream. The "--dump-raw-script" is not a valid option, replace it with the valid one, "--dump-raw-trace" Signed-off-by:
Michael Petlan <mpetlan@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 133dc4c3 ("perf: Rename 'perf trace' to 'perf script'") LPU-Reference: 728644547.14560155.1484320012612.JavaMail.zimbra@redhat.com Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
commit 6e017006 upstream. gcc-7 detects that wlanhdr_to_ethhdr() in two drivers calls memcpy() with a destination argument that an earlier function call may have set to NULL: staging/rtl8188eu/core/rtw_recv.c: In function 'wlanhdr_to_ethhdr': staging/rtl8188eu/core/rtw_recv.c:1318:2: warning: argument 1 null where non-null expected [-Wnonnull] staging/rtl8712/rtl871x_recv.c: In function 'r8712_wlanhdr_to_ethhdr': staging/rtl8712/rtl871x_recv.c:649:2: warning: argument 1 null where non-null expected [-Wnonnull] I'm fixing this by adding a NULL pointer check and returning failure from the function, which is hopefully already handled properly. This seems to date back to when the drivers were originally added, so backporting the fix to stable seems appropriate. There are other related realtek drivers in the kernel, but none of them contain a function with a similar name or produce this warning. Fixes: 1cc18a22 ("staging: r8188eu: Add files for new driver - part 5") Fixes: 2865d42c ("staging: r8712u: Add the new driver to the mainline kernel") Signed-off-by:
-
Johan Hovold authored
commit 2eee0502 upstream. The opticon driver used a control request at open to trigger a CTS status notification to be sent over the bulk-in pipe. When the driver was converted to using the generic read implementation, an inverted test prevented this request from being sent, something which could lead to TIOCMGET reporting an incorrect CTS state. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 7a6ee2b0 ("USB: opticon: switch to generic read implementation") Reviewed-by:
-
Johan Hovold authored
commit 39712e8b upstream. Make sure to detect and return an error on zero-length control-message transfers when reading from the device. This addresses a potential failure to detect an empty transmit buffer during close. Also remove a redundant check for short transfer when sending a command. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reviewed-by:
-
