- 05 Oct, 2014 40 commits
-
-
Thierry Reding authored
commit 9ce9ec95 upstream. The PHY configuration is stored in an opaque "config" field, but when allocating the structure, its proper size needs to be known. In the case of UTMI, the proper structure is tegra_utmip_config of which a local variable already exists, so we can use that to obtain the size from. Fixes the following warning from the sparse checker: drivers/usb/phy/phy-tegra-usb.c:882:17: warning: expression using sizeof(void) Fixes: 81d5dfe6 (usb: phy: tegra: Read UTMIP parameters from device tree) Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bjørn Mork authored
commit 5b3da692 upstream. This VID:PID is used for some Direct IP devices behaving identical to the already supported 0F3D:68AA devices. Reported-by:
Lars Melin <larsm17@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Bjørn Mork authored
commit 049255f5 upstream. Sierra Wireless Direct IP devices using the 68A3 product ID can be configured for modes including a CDC ECM class function. The known example uses interface numbers 12 and 13 for the ECM control and data interfaces respectively, consistent with CDC MBIM function interface numbering on other Sierra devices. It seems cleaner to restrict this driver to the ff/ff/ff vendor specific interfaces rather than increasing the already long interface number blacklist. This should be more future proof if Sierra adds more class functions using interface numbers not yet in the blacklist. Signed-off-by:
-
Karol Lewandowski authored
Applicable for 3.14-stable only, as this revertes a previous commit that was incorrect. This commit drops duplicate declaration of struct usb_functionfs_descs_head erronousely added in commit 28c5980b ("usb: gadget: f_fs: resurect usb_functionfs_descs_head structure"). Fix from 28c5980b is applicable only for v3.15-rc1 and newer kernels. This fixes error in uapi: /src/linux$ make -C tools usb make: Entering directory '/src/linux/tools' DESCEND usb make[1]: Entering directory '/src/linux/tools/usb' gcc -Wall -Wextra -g -I../include -o testusb testusb.c -lpthread gcc -Wall -Wextra -g -I../include -o ffs-test ffs-test.c -lpthread In file included from ffs-test.c:41:0: ../../include/uapi/linux/usb/functionfs.h:42:8: error: redefinition of ‘struct usb_functionfs_descs_head’ struct usb_functionfs_descs_head { ^ ../../include/uapi/linux/usb/functionfs.h:31:8: note: originally defined here struct usb_functionfs_descs_head { ^ Cc: Michal Nazarewicz <mina86@mina86.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by:
Karol Lewandowski <k.lewandowsk@samsung.com> Signed-off-by:
-
Johan Hovold authored
commit 754eb21c upstream. Remove dublicate Qualcom PID 0x3197 which is already handled by the moto-modem driver since commit 6986a978 ("USB: add new moto_modem driver for some Morotola phones"). Fixes: 799ee924 ("USB: serial: add zte_ev.c driver") Signed-off-by:
-
Johan Hovold authored
commit 95be5739 upstream. Remove dublicate Gobi PID 0x9008 which is already handled by the qcserial driver since commit f05932c0 ("USB: qcserial: Add extra device IDs"). Fixes: 799ee924 ("USB: serial: add zte_ev.c driver") Signed-off-by:
-
Johan Hovold authored
commit 63a901c0 upstream. This reverts commit 73228a05 ("USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"). Move the IDs of the devices that were previously driven by the option driver back to that driver. As several users have reported, the zte_ev driver is causing random disconnects as well as reconnect failures. A closer analysis of the zte_ev setup code reveals that it consists of standard CDC requests (SET/GET_LINE_CODING and SET_CONTROL_LINE_STATE) but unfortunately fails to get some of those right. In particular, as reported by Liu Lei, it fails to lower DTR/RTS on close. It also appears that the control requests lack the interface argument. Note that the zte_ev driver is based on code (once) distributed by ZTE that still appears to originally have been reverse-engineered and bolted onto the generic driver. Since line control is already handled properly by the option driver, and the SET/GET_LINE_CODING requests appears to be redundant (amounts to a SET 9600 8N1), this is a first step in ultimately removing the redundant zte_ev driver. Note that AC2726 had already been moved back to option, and that some IDs were in the device table of both drivers prior to the commit being reverted. Reported-by:
Lei Liu <liu.lei78@zte.com.cn> Signed-off-by:
-
Brennan Ashton authored
commit d7730273 upstream. This VIA Telecom baseband processor is used is used by by u-blox in both the FW2770 and FW2760 products and may be used in others as well. This patch has been tested on both of these modem versions. Signed-off-by:
Brennan Ashton <bashton@brennanashton.com> Signed-off-by:
-
Johan Hovold authored
commit f0e4cba2 upstream. Do not log normal interrupt-urb shutdowns as errors. The option driver has always been logging any nonzero interrupt-urb status as an error, including when the urb is killed during normal operation. Commit 9096f1fb ("USB: usb_wwan: fix potential NULL-deref at resume") moved the interrupt urb submission from port probe and release to open and close, thus potentially increasing the number of these false-positive error messages dramatically. Reported-by:
Ed Butler <ressy66@ausics.net> Tested-by:
-
Johan Hovold authored
commit 5654699f upstream. Make sure to verify the number of ports requested by subdriver to avoid writing beyond the end of fixed-size array in interface data. The current usb-serial implementation is limited to eight ports per interface but failed to verify that the number of ports requested by a subdriver (which could have been determined from device descriptors) did not exceed this limit. Signed-off-by:
-
Stephen Hemminger authored
commit 5b6b80ae upstream. I have a j5 create (JUA210) USB 2 video device and adding it device id to SIS USB video gets it to work. Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Johan Hovold authored
commit d979e9f9 upstream. Make sure to verify the maximum number of endpoints per type to avoid writing beyond the end of a stack-allocated array. The current usb-serial implementation is limited to eight ports per interface but failed to verify that the number of endpoints of a certain type reported by a device did not exceed this limit. Signed-off-by:
-
Greg KH authored
commit 91fcb1ce upstream. This adds a new device id to the pl2303 driver for the ZTEK device. Reported-by:
Mike Chu <Mike-Chu@prolific.com.tw> Signed-off-by:
-
Max Filippov authored
commit d1b6ba82 upstream. Remove restoring a6 on some return paths and instead modify and restore it in a single place, using symbolic name. Correctly restore a7 from PT_AREG7 in case of illegal a6 value. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Max Filippov authored
commit 7128039f upstream. Current definition of TLBTEMP_BASE_2 is always 32K above the TLBTEMP_BASE_1, whereas fast_second_level_miss handler for the TLBTEMP region analyzes virtual address bit (PAGE_SHIFT + DCACHE_ALIAS_ORDER) to determine TLBTEMP region where the fault happened. The size of the TLBTEMP region is also checked incorrectly: not 64K, but twice data cache way size (whicht may as well be less than the instruction cache way size). Fix TLBTEMP_BASE_2 to be TLBTEMP_BASE_1 + data cache way size. Provide TLBTEMP_SIZE that is a greater of doubled data cache way size or the instruction cache way size, and use it to determine if the second level TLB miss occured in the TLBTEMP region. Practical occurence of page faults in the TLBTEMP area is extremely rare, this code can be tested by deletion of all w[di]tlb instructions in the tlbtemp_mapping region. Signed-off-by:
-
Max Filippov authored
commit 52247123 upstream. With SMP and a lot of debug options enabled task_struct::thread gets out of reach of s32i/l32i instructions with base pointing at task_struct, breaking build with the following messages: arch/xtensa/kernel/entry.S: Assembler messages: arch/xtensa/kernel/entry.S:1002: Error: operand 3 of 'l32i.n' has invalid value '1048' arch/xtensa/kernel/entry.S:1831: Error: operand 3 of 's32i.n' has invalid value '1040' arch/xtensa/kernel/entry.S:1832: Error: operand 3 of 's32i.n' has invalid value '1044' Change base to point to task_struct::thread in such cases. Don't use a10 in _switch_to to save/restore prev pointer as a2 is not clobbered. Signed-off-by:
-
Alan Douglas authored
commit 1ca49463 upstream. Virtual address is translated to the XCHAL_KSEG_CACHED region in the dma_free_coherent, but is checked to be in the 0...XCHAL_KSEG_SIZE range. Change check for end of the range from 'addr >= X' to 'addr > X - 1' to handle the case of X == 0. Replace 'if (C) BUG();' construct with 'BUG_ON(C);'. Signed-off-by:
Alan Douglas <adouglas@cadence.com> Signed-off-by:
-
Max Filippov authored
commit f61bf8e7 upstream. This fixes userspace code that builds on other architectures but fails on xtensa due to references to structures that other architectures don't refer to. E.g. this fixes the following issue with python-2.7.8: python-2.7.8/Modules/termios.c:861:25: error: invalid application of 'sizeof' to incomplete type 'struct serial_multiport_struct' {"TIOCSERGETMULTI", TIOCSERGETMULTI}, python-2.7.8/Modules/termios.c:870:25: error: invalid application of 'sizeof' to incomplete type 'struct serial_multiport_struct' {"TIOCSERSETMULTI", TIOCSERSETMULTI}, python-2.7.8/Modules/termios.c:900:24: error: invalid application of 'sizeof' to incomplete type 'struct tty_struct' {"TIOCTTYGSTRUCT", TIOCTTYGSTRUCT}, Signed-off-by:
-
Alex Deucher authored
commit 370ce45b upstream. Otherwise we may fail to init the second compute ring. Noticed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit c1789a2e upstream. Otherwise we may lose the DMA golden settings which can lead to hangs, etc. Reviewed-by:
-
Alex Deucher authored
commit 799028d5 upstream. Otherwise we may lose the DMA golden settings which can lead to hangs, etc. Reviewed-by:
-
Alex Deucher authored
commit 31a25e2c upstream. Otherwise we may lose the DMA golden settings which can lead to hangs, etc. bug: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=83500Reviewed-by:
-
Alex Deucher authored
commit 1952f24d upstream. Vbios connector table lists non-existent VGA port. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83184Signed-off-by:
-
Alex Deucher authored
commit ff437792 upstream. On systems with special thermal configurations make sure we make note of the thermal setup. This is required for proper firmware configuration on these systems. Signed-off-by:
-
Christian König authored
commit f229407d upstream. Semaphore values have 64 bits, not 32. This fixes a very subtle bug that disables synchronization when the upper 32bits wasn't zero. Signed-off-by:
Grigori Goronzy <greg@chown.ath.cx> Signed-off-by:
-
Alex Deucher authored
commit c940b447 upstream. pm_suspend is handled in the radeon_suspend callbacks. pm_resume has special handling depending on whether dpm or legacy pm is enabled. Change radeon_gpu_reset to mirror the behavior in the suspend and resume pathes. Signed-off-by:
-
Oleg Chernovskiy authored
commit 6bce8d97 upstream. Properly set the thermal min and max temp on CI. Otherwise, we end up setting the thermal ranges to 0 on resume and end up in the lowest power state. Signed-off-by:
Oleg Chernovskiy <algonkvel@gmail.com> Signed-off-by:
-
Pali Rohár authored
commit b07a657e upstream. This fixing commit 4f2f2039 bug: https://bugzilla.kernel.org/show_bug.cgi?id=76321Signed-off-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
-
Thomas Hellstrom authored
commit f01ea0c3 upstream. The code waiting for fifo idle was incorrect and could possibly spin forever under certain circumstances. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reported-by:
Mark Sheldon <markshel@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> Reivewed-by:
-
Russell King authored
commit 3a44a205 upstream. When unbinding imx-drm, the following oops was observed: Unable to handle kernel NULL pointer dereference at virtual address 00000004 pgd = e995c000 [00000004] *pgd=4fea5831 Internal error: Oops: 817 [#1] SMP ARM Modules linked in: bnep rfcomm bluetooth nfsd exportfs hid_cypress brcmfmac brcmutil snd_soc_fsl_ssi snd_soc_fsl_spdif imx_pcm_fiq imx_pcm_dma snd_soc_sgtl5000 imx_sdma imx2_wdt imx_ldb(C) imx_thermal snd_soc_imx_sgtl5000 snd_soc_imx_spdif snd_soc_imx_audmux CPU: 1 PID: 779 Comm: bash Tainted: G C 3.16.0-rc2+ #1230 task: ea9eb180 ti: ea378000 task.ti: ea378000 PC is at ipu_dp_put+0x10/0x18 LR is at ipu_plane_dpms+0x60/0x8c pc : [<c0350d20>] lr : [<c04bd9e8>] psr: 200f0013 sp : ea379d80 ip : ea379d90 fp : ea379d8c r10: 00100100 r9 : 00000000 r8 : 00200200 r7 : e9ba0264 r6 : e9ba01f8 r5 : 00000000 r4 : ea34b800 r3 : 00000000 r2 : 00000000 r1 : 0000009b r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 3995c04a DAC: 00000015 Process bash (pid: 779, stack limit = 0xea378240) Stack: (0xea379d80 to 0xea37a000) ... Backtrace: [<c0350d10>] (ipu_dp_put) from [<c04bd9e8>] (ipu_plane_dpms+0x60/0x8c) [<c04bd988>] (ipu_plane_dpms) from [<c04bda40>] (ipu_disable_plane+0x2c/0x60) [<c04bda14>] (ipu_disable_plane) from [<c04bda9c>] (ipu_plane_destroy+0x28/0x60) [<c04bda74>] (ipu_plane_destroy) from [<c033ff84>] (drm_mode_config_cleanup+0x1b8/0x250) [<c033fdcc>] (drm_mode_config_cleanup) from [<c04bc234>] (imx_drm_driver_unload+0x44/0x4c) [<c04bc1f0>] (imx_drm_driver_unload) from [<c03394a4>] (drm_dev_unregister+0x2c/0xa0) [<c0339478>] (drm_dev_unregister) from [<c0339f8c>] (drm_put_dev+0x30/0x6c) [<c0339f5c>] (drm_put_dev) from [<c04bc1cc>] (imx_drm_unbind+0x14/0x18) [<c04bc1b8>] (imx_drm_unbind) from [<c03530b4>] (component_master_del+0xbc/0xd8) ... Code: e1a0c00d e92dd800 e24cb004 e3a03000 (e5c03004) This is caused by a missing check in ipu_plane_dpms for a NULL pointer. Fixes: b8d181e4 ("staging: drm/imx: add drm plane support") Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Y.C. Chen authored
commit 83502a5d upstream. Type error and cause AST2000 cannot be detected correctly Signed-off-by:
Y.C. Chen <yc_chen@aspeedtech.com> Reviewed-by:
Egbert Eich <eich@suse.de> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
commit 7a98948f upstream. The vblank waits in intel_tv_detect_type() are timing out for some reason. This is a regression caused removing seemingly useless vblank waits from the modeset seqeuence in: commit 56ef52ca Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu May 8 19:23:15 2014 +0300 drm/i915: Kill vblank waits after pipe enable on gmch platforms So it turns out they weren't all entirely useless. Apparently the pipe has to go through one full frame before we enable the TV port. Add a vblank wait to intel_enable_tv() to make sure that happens. Another approach was attempted by placing the vblank wait just after enabling the port. The theory behind that attempt was that we need to let the port stay enabled for one full frame before disabling it again during load detection. But that didn't work, and we definitely must have the vblank wait before enabling the port. Cc: Alan Bartlett <ajb@elrepo.org> Tested-by:
Alan Bartlett <ajb@elrepo.org> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79311Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Daniel Vetter authored
commit 2232f031 upstream. In commit 1f83fee0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Nov 15 17:17:22 2012 +0100 drm/i915: clear up wedged transitions I've accidentally inverted the EIO/wedged handling in the fault handler: We want to return the EIO as a SIGBUS only if it's not because of the gpu having died, to prevent userspace from unduly dying. In my defence the comment right above is completely misleading, so fix both. v2: Drop the WARN_ON, it's not actually a bug to e.g. receive an -EIO when swap-in fails. v3: Don't remove too much ... oops. Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
-
Mathias Krause authored
commit bbe1c274 upstream. The __init annotations for the DMI callback functions are wrong as this code can be called even after the module has been initialized, e.g. like this: # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove # modprobe i915 # echo 1 > /sys/bus/pci/rescan The first command will remove the PCI device from the kernel's device list so the second command won't see it right away. But as it registers a PCI driver it'll see it on the third command. If the system happens to match one of the DMI table entries we'll try to call a function in long released memory and generate an Oops, at best. Fix this by removing the bogus annotation. Modpost should have caught that one but it ignores section reference mismatches from the .rodata section. :/ Fixes: 25e341cf ("drm/i915: quirk away broken OpRegion VBT") Fixes: 8ca4013d ("CHROMIUM: i915: Add DMI override to skip CRT...") Fixes: 425d244c ("drm/i915: ignore LVDS on intel graphics systems...") Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Jarod Wilson <jarod@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> # Can modpost be fixed? Signed-off-by:
-
Filipe Brandenburger authored
commit bfcfd44c upstream. The guard was introduced in commit ea1a8217 ("xattr: guard against simultaneous glibc header inclusion") but it is using #ifdef to check for a define that is either set to 1 or 0. Fix it to use #if instead. * Without this patch: $ { echo "#include <sys/xattr.h>"; echo "#include <linux/xattr.h>"; } | gcc -E -Iinclude/uapi - >/dev/null include/uapi/linux/xattr.h:19:0: warning: "XATTR_CREATE" redefined [enabled by default] #define XATTR_CREATE 0x1 /* set value, fail if attr already exists */ ^ /usr/include/x86_64-linux-gnu/sys/xattr.h:32:0: note: this is the location of the previous definition #define XATTR_CREATE XATTR_CREATE ^ * With this patch: $ { echo "#include <sys/xattr.h>"; echo "#include <linux/xattr.h>"; } | gcc -E -Iinclude/uapi - >/dev/null (no warnings) Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Acked-by:
Serge E. Hallyn <serge.hallyn@ubuntu.com> Cc: Allan McRae <allan@archlinux.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Benjamin Tissoires authored
commit 5abfe85c upstream. Commit "HID: logitech: perform bounds checking on device_id early enough" unfortunately leaks some errors to dmesg which are not real ones: - if the report is not a DJ one, then there is not point in checking the device_id - the receiver (index 0) can also receive some notifications which can be safely ignored given the current implementation Move out the test regarding the report_id and also discards printing errors when the receiver got notified. Fixes: ad3e14d7Reported-and-tested-by:
Markus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Jiri Kosina authored
commit c54def7b upstream. The report passed to us from transport driver could potentially be arbitrarily large, therefore we better sanity-check it so that magicmouse_emit_touch() gets only valid values of raw_id. Reported-by:
Steven Vittitoe <scvitti@google.com> Signed-off-by:
-
Jiri Kosina authored
commit 844817e4 upstream. The report passed to us from transport driver could potentially be arbitrarily large, therefore we better sanity-check it so that raw_data that we hold in picolcd_pending structure are always kept within proper bounds. Reported-by:
-
Toshiaki Makita authored
commit e15693ef upstream. cfq_group_service_tree_add() is applying new_weight at the beginning of the function via cfq_update_group_weight(). This actually allows weight to change between adding it to and subtracting it from children_weight, and triggers WARN_ON_ONCE() in cfq_group_service_tree_del(), or even causes oops by divide error during vfr calculation in cfq_group_service_tree_add(). The detailed scenario is as follows: 1. Create blkio cgroups X and Y as a child of X. Set X's weight to 500 and perform some I/O to apply new_weight. This X's I/O completes before starting Y's I/O. 2. Y starts I/O and cfq_group_service_tree_add() is called with Y. 3. cfq_group_service_tree_add() walks up the tree during children_weight calculation and adds parent X's weight (500) to children_weight of root. children_weight becomes 500. 4. Set X's weight to 1000. 5. X starts I/O and cfq_group_service_tree_add() is called with X. 6. cfq_group_service_tree_add() applies its new_weight (1000). 7. I/O of Y completes and cfq_group_service_tree_del() is called with Y. 8. I/O of X completes and cfq_group_service_tree_del() is called with X. 9. cfq_group_service_tree_del() subtracts X's weight (1000) from children_weight of root. children_weight becomes -500. This triggers WARN_ON_ONCE(). 10. Set X's weight to 500. 11. X starts I/O and cfq_group_service_tree_add() is called with X. 12. cfq_group_service_tree_add() applies its new_weight (500) and adds it to children_weight of root. children_weight becomes 0. Calcularion of vfr triggers oops by divide error. weight should be updated right before adding it to children_weight. Reported-by:
Ruki Sekiya <sekiya.ruki@lab.ntt.co.jp> Signed-off-by:
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Clemens Ladisch authored
commit a9960e6a upstream. The calculated frame size was wrong because snd_pcm_format_physical_width() actually returns the number of bits, not bytes. Use snd_pcm_format_size() instead, which not only returns bytes, but also simplifies the calculation. Fixes: 8bea869c ("ALSA: PCM midlevel: improve fifo_size handling") Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
