- 26 Jan, 2012 28 commits
-
-
David Herrmann authored
commit ef6f4115 upstream. We depend on memless force-feedback support, therefore correctly select the related config options. Reported-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
David Herrmann <dh.herrmann@googlemail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Chase Douglas authored
commit e46e927b upstream. This allows the latest N-Trig devices to function properly. BugLink: https://bugs.launchpad.net/bugs/724831Signed-off-by:
Chase Douglas <chase.douglas@canonical.com> Signed-off-by:
-
Jeff Layton authored
commit 8a0d551a upstream. Setting the security context of a NFSv4 mount via the context= mount option is currently broken. The NFSv4 codepath allocates a parsed options struct, and then parses the mount options to fill it. It eventually calls nfs4_remote_mount which calls security_init_mnt_opts. That clobbers the lsm_opts struct that was populated earlier. This bug also looks like it causes a small memory leak on each v4 mount where context= is used. Fix this by moving the initialization of the lsm_opts into nfs_alloc_parsed_mount_data. Also, add a destructor for nfs_parsed_mount_data to make it easier to free all of the allocations hanging off of it, and to ensure that the security_free_mnt_opts is called whenever security_init_mnt_opts is. I believe this regression was introduced quite some time ago, probably by commit c02d7adf. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Andy Adamson authored
commit bf118a34 upstream. The NFSv4 bitmap size is unbounded: a server can return an arbitrary sized bitmap in an FATTR4_WORD0_ACL request. Replace using the nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data xdr length to the (cached) acl page data. This is a general solution to commit e5012d1f "NFSv4.1: update nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead when getting ACLs. Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved. Signed-off-by:
Andy Adamson <andros@netapp.com> Signed-off-by:
-
NeilBrown authored
commit 2edb6bc3 upstream. From c6d615d2b97fe305cbf123a8751ced859dca1d5e Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb@suse.de> Date: Wed, 16 Nov 2011 09:39:05 +1100 Subject: NFS - fix recent breakage to NFS error handling. commit 02c24a82 made a small and presumably unintended change to write error handling in NFS. Previously an error from filemap_write_and_wait_range would only be of interest if nfs_file_fsync did not return an error. After this commit, an error from filemap_write_and_wait_range would mean that (the rest of) nfs_file_fsync would not even be called. This means that: 1/ you are more likely to see EIO than e.g. EDQUOT or ENOSPC. 2/ NFS_CONTEXT_ERROR_WRITE remains set for longer so more writes are synchronous. This patch restores previous behaviour. Cc: Josef Bacik <josef@redhat.com> Cc: Jan Kara <jack@suse.cz> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Andy Adamson authored
commit 61f2e510 upstream. Signed-off-by:
-
Chuck Lever authored
commit 43717c7d upstream. Lukas Razik <linux@razik.name> reports that on his SPARC system, booting with an NFS root file system stopped working after commit 56463e50 "NFS: Use super.c for NFSROOT mount option parsing." We found that the network switch to which Lukas' client was attached was delaying access to the LAN after the client's NIC driver reported that its link was up. The delay was longer than the timeouts used in the NFS client during mounting. NFSROOT worked for Lukas before commit 56463e50 because in those kernels, the client's first operation was an rpcbind request to determine which port the NFS server was listening on. When that request failed after a long timeout, the client simply selected the default NFS port (2049). By that time the switch was allowing access to the LAN, and the mount succeeded. Neither of these client behaviors is desirable, so reverting 56463e50 is really not a choice. Instead, introduce a mechanism that retries the NFSROOT mount request several times. This is the same tactic that normal user space NFS mounts employ to overcome server and network delays. Signed-off-by:
Lukas Razik <linux@razik.name> [ cel: match kernel coding style, add proper patch description ] [ cel: add exponential back-off ] Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Tested-by:
-
Boaz Harrosh authored
commit fe0fe835 upstream. As mandated by the standard. In case of an IO error, a pNFS objects layout driver must return it's layout. This is because all device errors are reported to the server as part of the layout return buffer. This is implemented the same way PNFS_LAYOUTRET_ON_SETATTR is done, through a bit flag on the pnfs_layoutdriver_type->flags member. The flag is set by the layout driver that wants a layout_return preformed at pnfs_ld_{write,read}_done in case of an error. (Though I have not defined a wrapper like pnfs_ld_layoutret_on_setattr because this code is never called outside of pnfs.c and pnfs IO paths) Without this patch 3.[0-2] Kernels leak memory and have an annoying WARN_ON after every IO error utilizing the pnfs-obj driver. Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
Boaz Harrosh authored
commit 5c0b4129 upstream. Some time along the way pNFS IO errors were switched to communicate with a special iodata->pnfs_error member instead of the regular RPC members. But objlayout was not switched over. Fix that! Without this fix any IO error is hanged, because IO is not switched to MDS and pages are never cleared or read. [Applies to 3.2.0. Same bug different patch for 3.1/0 Kernels] Signed-off-by:
-
Michel Dänzer authored
commit 3df96909 upstream. It would previously write basically random bits to PCI configuration space... Not very surprising that the GPU tended to stop responding completely. The resulting MCE even froze the whole machine sometimes. Now resetting the GPU after a lockup has at least a fighting chance of succeeding. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 28eebb70 upstream. We often end up missing fences on older asics with writeback enabled which leads to delays in the userspace accel code, so just disable it by default on those asics. Reported-by:
Helge Deller <deller@gmx.de> Reported-by:
-
Rafał Miłecki authored
commit 92db7f6c upstream. This change was verified to fix both issues with no video I've investigated. I've also checked checksum calculation with fglrx on: RV620, HD54xx, HD5450, HD6310, HD6320. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit f2cbba76 upstream. When multiple headphone or other detectable output pins are present, the power-map has to be updated after resume appropriately, but the current driver doesn't check all pins but only the first pin (since it's enough to check it for the mute-behavior). This resulted in the silent output from the secondary outputs after PM resume. This patch fixes the problem by checking all pins at (re-)init time. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740347Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 4808d12d upstream. Currently the driver checks only the out_mix_path[] for the primary output route for judging whether to create the loopback-mixing control or not. But, there are cases where aamix-routing is available only on headphone or speaker paths but not on the primary output path. So, the driver ignores such cases inappropriately. This patch fixes the check of the loopback-mixing control by testing all mix-routing paths. Signed-off-by:
-
Takashi Iwai authored
commit 3a90274d upstream. When an invalid NID is given, get_wcaps() returns zero as the error, but get_wcaps_type() takes it as the normal value and returns a bogus AC_WID_AUD_OUT value. This confuses the parser. With this patch, get_wcaps_type() returns -1 when value 0 is given, i.e. an invalid NID is passed to get_wcaps(). Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740118Signed-off-by:
-
Takashi Iwai authored
commit de4da59e upstream. These laptops can work well with the auto-parser and their BIOS setups, and in addition, the auto-parser fixes the problem with S3/S4 where the unsol event handling is killed after resume due to fallback to the single-cmd mode. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740115Signed-off-by:
-
Takashi Iwai authored
commit 80c8a2a3 upstream. With some buggy devices, the usb-audio driver may give "frame xxx active" kernel messages too often. Better to keep it as debug-only using snd_printdd(), and also add the rate-limit for avoiding floods. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=738681Signed-off-by:
-
Pavel Hofman authored
commit e7848163 upstream. Cards with identical PCI ids but no AC97 config in EEPROM do not have the ac97 field initialized. We must check for this case to avoid kernel oops. Signed-off-by:
Pavel Hofman <pavel.hofman@ivitera.com> Signed-off-by:
-
David Henningsson authored
commit 78e2a928 upstream. There was a bug in the automute logic causing speakers not to mute when headphones were plugged in. Tested-by:
Hsin-Yi Chen <hychen@canonical.com> Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
David Henningsson authored
commit 40d03e63 upstream. The control name "HP/Speakers" is non-standard, and since there is only one DAC on this chip there is no need for a virtual master anyway. Signed-off-by:
-
Karsten Wiese authored
commit d0f3a2eb upstream. They are not needed here. Signed-off-by:
Karsten Wiese <fzu@wemgehoertderstaat.de> Signed-off-by:
-
Xi Wang authored
commit d50f2ab6 upstream. Commit 503358ae ("ext4: avoid divide by zero when trying to mount a corrupted file system") fixes CVE-2009-4307 by performing a sanity check on s_log_groups_per_flex, since it can be set to a bogus value by an attacker. sbi->s_log_groups_per_flex = sbi->s_es->s_log_groups_per_flex; groups_per_flex = 1 << sbi->s_log_groups_per_flex; if (groups_per_flex < 2) { ... } This patch fixes two potential issues in the previous commit. 1) The sanity check might only work on architectures like PowerPC. On x86, 5 bits are used for the shifting amount. That means, given a large s_log_groups_per_flex value like 36, groups_per_flex = 1 << 36 is essentially 1 << 4 = 16, rather than 0. This will bypass the check, leaving s_log_groups_per_flex and groups_per_flex inconsistent. 2) The sanity check relies on undefined behavior, i.e., oversized shift. A standard-confirming C compiler could rewrite the check in unexpected ways. Consider the following equivalent form, assuming groups_per_flex is unsigned for simplicity. groups_per_flex = 1 << sbi->s_log_groups_per_flex; if (groups_per_flex == 0 || groups_per_flex == 1) { We compile the code snippet using Clang 3.0 and GCC 4.6. Clang will completely optimize away the check groups_per_flex == 0, leaving the patched code as vulnerable as the original. GCC keeps the check, but there is no guarantee that future versions will do the same. Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Djalal Harouni authored
commit 014a1770 upstream. Online resize ioctls 'EXT4_IOC_GROUP_EXTEND' and 'EXT4_IOC_GROUP_ADD' call ext4_resize_begin() to check permissions and to set the EXT4_RESIZING bit lock, they do their work and they must finish with ext4_resize_end() which calls clear_bit_unlock() to unlock and to avoid -EBUSY errors for the next resize operations. This patch adds the missing ext4_resize_end() calls on error paths. Patch tested. Signed-off-by:
Djalal Harouni <tixxdz@opendz.org> Signed-off-by:
-
Ben Hutchings authored
commit e74a8f2e upstream. Commit f44f7f96 ("RTC: Initialize kernel state from RTC") introduced a potential infinite loop. If an alarm time contains a wildcard month and an invalid day (> 31), or a wildcard year and an invalid month (>= 12), the loop searching for the next matching date will never terminate. Treat the invalid values as wildcards. Fixes <http://bugs.debian.org/646429>, <http://bugs.debian.org/653331> Reported-by:
leo weppelman <leoweppelman@googlemail.com> Reported-by:
"P. van Gaans" <mailme667@yahoo.co.uk> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <john.stultz@linaro.org> Acked-by:
Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Wolfram Sang authored
commit 2f4478cc upstream. stresstest needs at least two eraseblocks. Bail out gracefully if that condition is not met. Fixes the following 'division by zero' OOPS: [ 619.100000] mtd_stresstest: MTD device size 131072, eraseblock size 131072, page size 2048, count of eraseblocks 1, pages per eraseblock 64, OOB size 64 [ 619.120000] mtd_stresstest: scanning for bad eraseblocks [ 619.120000] mtd_stresstest: scanned 1 eraseblocks, 0 are bad [ 619.130000] mtd_stresstest: doing operations [ 619.130000] mtd_stresstest: 0 operations done [ 619.140000] Division by zero in kernel. ... caused by /* Read or write up 2 eraseblocks at a time - hence 'ebcnt - 1' */ eb %= (ebcnt - 1); Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Brian Norris authored
commit 342ff28f upstream. Some error paths in mtd_blkdevs were fixed in the following commit: commit 94735ec4 mtd: mtd_blkdevs: fix error path in blktrans_open But on these error paths, the block device's `dev->open' count is already incremented before we check for errors. This meant that, while the error path was handled correctly on the first time through blktrans_open(), the device is erroneously considered already open on the second time through. This problem can be seen, for instance, when a UBI volume is simultaneously mounted as a UBIFS partition and read through its corresponding gluebi mtdblockX device. This results in blktrans_open() passing its error checks (with `dev->open > 0') without actually having a handle on the device. Here's a summarized log of the actions and results with nandsim: # modprobe nandsim # modprobe mtdblock # modprobe gluebi # modprobe ubifs # ubiattach /dev/ubi_ctrl -m 0 ... # ubimkvol /dev/ubi0 -N test -s 16MiB ... # mount -t ubifs ubi0:test /mnt # ls /dev/mtdblock* /dev/mtdblock0 /dev/mtdblock1 # cat /dev/mtdblock1 > /dev/null cat: can't open '/dev/mtdblock4': Device or resource busy # cat /dev/mtdblock1 > /dev/null CPU 0 Unable to handle kernel paging request at virtual address fffffff0, epc == 8031536c, ra == 8031f280 Oops[#1]: ... Call Trace: [<8031536c>] ubi_leb_read+0x14/0x164 [<8031f280>] gluebi_read+0xf0/0x148 [<802edba8>] mtdblock_readsect+0x64/0x198 [<802ecfe4>] mtd_blktrans_thread+0x330/0x3f4 [<8005be98>] kthread+0x88/0x90 [<8000bc04>] kernel_thread_helper+0x10/0x18 Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Roman Tereshonkov authored
commit 3538c563 upstream. Use block_isbad to check and skip the bad blocks reading. This will allow to get rid of the read errors if bad blocks are present initially. Signed-off-by:
Roman Tereshonkov <roman.tereshonkov@nokia.com> Signed-off-by:
-
Roman Tereshonkov authored
commit 556f0635 upstream. The array of unsigned long pointed by oops_page_used is allocated by vmalloc which requires the size to be in bytes. BITS_PER_LONG is equal to 32. If we want to allocate memory for 32 pages with one bit per page then 32 / BITS_PER_LONG is equal to 1 byte that is 8 bits. To fix it we need to multiply the result by sizeof(unsigned long) equal to 4. Signed-off-by:
-
- 12 Jan, 2012 12 commits
-
-
Greg Kroah-Hartman authored
-
Xi Wang authored
commit 093019cf upstream. Commit fa8b18ed didn't prevent the integer overflow and possible memory corruption. "count" can go negative and bypass the check. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
-
Thilo-Alexander Ginkel authored
[Not upstream as it was fixed differently for 3.3 with a much more "intrusive" rework of the driver - gregkh] There is a race condition involving acm_tty_hangup() and acm_tty_close() where hangup() would attempt to access tty->driver_data without proper locking and NULL checking after close() has potentially already set it to NULL. One possibility to (sporadically) trigger this behavior is to perform a suspend/resume cycle with a running WWAN data connection. This patch addresses the issue by introducing a NULL check for tty->driver_data in acm_tty_hangup() protected by open_mutex and exiting gracefully when hangup() is invoked on a device that has already been closed. Signed-off-by:
Thilo-Alexander Ginkel <thilo@ginkel.com> Signed-off-by:
-
stephen hemminger authored
commit f7d9821a upstream. If slave device already has a receive handler registered, then the error unwind of bonding device enslave function is broken. The following will leave a pointer to freed memory in the slave device list, causing a later kernel panic. # modprobe dummy # ip li add dummy0-1 link dummy0 type macvlan # modprobe bonding # echo +dummy0 >/sys/class/net/bond0/bonding/slaves The fix is to detach the slave (which removes it from the list) in the unwind path. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Reviewed-by:
Nicolas de Pesloüan <nicolas.2p.debian@free.fr> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Aurelien Jacobs authored
commit 6c15d74d upstream. At this point if skb->len happens to be 2, the subsequant skb_pull(skb, 4) call won't work and the skb->len won't be decreased and won't ever reach 0, resulting in an infinite loop. With an ASIX 88772 under heavy load, without this patch, rx_fixup() reaches an infinite loop in less than a minute. With this patch applied, no infinite loop even after hours of heavy load. Signed-off-by:
Aurelien Jacobs <aurel@gnuage.org> Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
-
Ben Hutchings authored
commit a8c1f65c upstream. Commit 5b7c8406 ('ipv4: correct IGMP behavior on v3 query during v2-compatibility mode') added yet another case for query parsing, which can result in max_delay = 0. Substitute a value of 1, as in the usual v3 case. Reported-by:
Simon McVittie <smcv@debian.org> References: http://bugs.debian.org/654876Signed-off-by:
-
Felipe Balbi authored
commit 18b7ede5 upstream. [ removed the dwc3 portion of the patch as it didn't apply to older kernels - gregkh] According to USB 3.0 Specification Table 9-22, if bmAttributes [4:0] are set to zero, it means "no streams supported", but the way this helper was defined on Linux, we will *always* have one stream which might cause several problems. For example on DWC3, we would tell the controller endpoint has streams enabled and yet start transfers with Stream ID set to 0, which would goof up the host side. While doing that, convert the macro to an inline function due to the different checks we now need. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Hans de Goede authored
commit 71d85724 upstream. I encountered a result of COMP_2ND_BW_ERR while improving how the pwc webcam driver handles not having the full usb1 bandwidth available to itself. I created the following test setup, a NEC xhci controller with a single TT USB 2 hub plugged into it, with a usb keyboard and a pwc webcam plugged into the usb2 hub. This caused the following to show up in dmesg when trying to stream from the pwc camera at its highest alt setting: xhci_hcd 0000:01:00.0: ERROR: unexpected command completion code 0x23. usb 6-2.1: Not enough bandwidth for altsetting 9 And usb_set_interface returned -EINVAL, which caused my pwc code to not do the right thing as it expected -ENOSPC. This patch makes the xhci driver properly handle COMP_2ND_BW_ERR and makes usb_set_interface return -ENOSPC as expected. This should be backported to stable kernels as old as 2.6.32. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Clemens Ladisch authored
commit bc677d5b upstream. Add a new field num_mapped_sgs to struct urb so that we have a place to store the number of mapped entries and can also retain the original value of entries in num_sgs. Previously, usb_hcd_map_urb_for_dma() would overwrite this with the number of mapped entries, which would break dma_unmap_sg() because it requires the original number of entries. This fixes warnings like the following when using USB storage devices: ------------[ cut here ]------------ WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695() ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1] Modules linked in: ohci_hcd ehci_hcd Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319 Call Trace: <IRQ> [<ffffffff81036d3b>] warn_slowpath_common+0x80/0x98 [<ffffffff81036de7>] warn_slowpath_fmt+0x41/0x43 [<ffffffff811fa5ae>] check_unmap+0x4e4/0x695 [<ffffffff8105e92c>] ? trace_hardirqs_off+0xd/0xf [<ffffffff8147208b>] ? _raw_spin_unlock_irqrestore+0x33/0x50 [<ffffffff811fa84a>] debug_dma_unmap_sg+0xeb/0x117 [<ffffffff8137b02f>] usb_hcd_unmap_urb_for_dma+0x71/0x188 [<ffffffff8137b166>] unmap_urb_for_dma+0x20/0x22 [<ffffffff8137b1c5>] usb_hcd_giveback_urb+0x5d/0xc0 [<ffffffffa0000d02>] ehci_urb_done+0xf7/0x10c [ehci_hcd] [<ffffffffa0001140>] qh_completions+0x429/0x4bd [ehci_hcd] [<ffffffffa000340a>] ehci_work+0x95/0x9c0 [ehci_hcd] ... ---[ end trace f29ac88a5a48c580 ]--- Mapped at: [<ffffffff811faac4>] debug_dma_map_sg+0x45/0x139 [<ffffffff8137bc0b>] usb_hcd_map_urb_for_dma+0x22e/0x478 [<ffffffff8137c494>] usb_hcd_submit_urb+0x63f/0x6fa [<ffffffff8137d01c>] usb_submit_urb+0x2c7/0x2de [<ffffffff8137dcd4>] usb_sg_wait+0x55/0x161 Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Malte Schröder authored
commit 08e87d0d upstream. Hi, below patch adds the USB-ID of the serial adapters sold by Multiplex RC (www.multiplex-rc.de). Signed-off-by:
Malte Schröder <maltesch@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Janne Snabb authored
commit 3c8c9316 upstream. Add support for Chinese Noname HSPA USB modem which is apparently manufactured by a company called ZD Incorporated (based on texts in the Windows drivers). This product is available at least from Dealextreme (SKU 80032) and possibly in India with name Olive V-MW250. It is based on Qualcomm MSM6280 chip. I needed to also add "options usb-storage quirks=0685:7000:i" in modprobe configuration because udevd or the kernel keeps poking the embedded fake-cd-rom which fails and causes the device to reset. There might be a better way to accomplish the same. usb_modeswitch is not needed with this device. Signed-off-by:
Janne Snabb <snabb@epipe.com> Signed-off-by:
-
Johan Hovold authored
commit 694c6301 upstream. Fix regression introduced by commit 507ca9bc ([PATCH] USB: add ability for usb-serial drivers to determine if their write urb is currently being used.) which inverted the logic in write_room so that it returns zero when the write urb is actually free. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
