- 17 Apr, 2015 31 commits
-
-
Malcolm Priestley authored
[ Upstream commit 163fe301 ] When the driver sets this rate a power of zero value is set causing data flow stoppage until another rate is tried. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Peter Zijlstra authored
[ Upstream commit d525211f ] Vince reported a watchdog lockup like: [<ffffffff8115e114>] perf_tp_event+0xc4/0x210 [<ffffffff810b4f8a>] perf_trace_lock+0x12a/0x160 [<ffffffff810b7f10>] lock_release+0x130/0x260 [<ffffffff816c7474>] _raw_spin_unlock_irqrestore+0x24/0x40 [<ffffffff8107bb4d>] do_send_sig_info+0x5d/0x80 [<ffffffff811f69df>] send_sigio_to_task+0x12f/0x1a0 [<ffffffff811f71ce>] send_sigio+0xae/0x100 [<ffffffff811f72b7>] kill_fasync+0x97/0xf0 [<ffffffff8115d0b4>] perf_event_wakeup+0xd4/0xf0 [<ffffffff8115d103>] perf_pending_event+0x33/0x60 [<ffffffff8114e3fc>] irq_work_run_list+0x4c/0x80 [<ffffffff8114e448>] irq_work_run+0x18/0x40 [<ffffffff810196af>] smp_trace_irq_work_interrupt+0x3f/0xc0 [<ffffffff816c99bd>] trace_irq_work_interrupt+0x6d/0x80 Which is caused by an irq_work generating new irq_work and therefore not allowing forward progress. This happens because processing the perf irq_work triggers another perf ...
-
Laurent Pinchart authored
[ Upstream commit d7c14605 ] The error code paths that require cleanup use a goto to jump to the cleanup code and return an error code. However, the error code variable res, which is initialized to -EINVAL when declared, is then overwritten with the return value of of_parse_phandle_with_args(), and reused as the return code from of_irq_parse_one(). This leads to an undetermined error being returned instead of the expected -EINVAL value. Fix it. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: stable@vger.kernel.org # 3.13+ Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Gregory CLEMENT authored
[ Upstream commit 43b68879 ] As stated in kernel/cpu_pm.c, "Platform is responsible for ensuring that cpu_pm_enter is not called twice on the same CPU before cpu_pm_exit is called.". In the current code in case of failure when calling mvebu_v7_cpu_suspend, the function cpu_pm_exit() is never called whereas cpu_pm_enter() was called just before. This patch moves the cpu_pm_exit() in order to balance the cpu_pm_enter() calls. Cc: stable@vger.kernel.org Reported-by:
Fulvio Benini <fbf@libero.it> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Larry Finger authored
[ Upstream commit c8f03455 ] Routine rtl_is_special_data() is supposed to identify packets that need to use a low bit rate so that the probability of successful transmission is high. The current version has a bug that causes all IPv6 packets to be labelled as special, with a corresponding low rate of transmission. A complete fix will be quite intrusive, but until that is available, all IPv6 packets are identified as regular. This patch also removes a magic number. Reported-and-tested-by:
Alan Fisher <acf@unixcube.org> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [3.18+] Cc: Alan Fisher <acf@unixcube.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Thierry Reding authored
[ Upstream commit 2f1bce48 ] devm_phy_create() stores the pointer to the new PHY at the address returned by devres_alloc(). The res parameter passed to devm_phy_match() is therefore the location where the pointer to the PHY is stored, hence it needs to be dereferenced before comparing to the match data in order to find the correct match. Cc: <stable@vger.kernel.org> # v3.13+ Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Peter Chen authored
[ Upstream commit a886bd92 ] We should signal connect (pull up dp) after we have already at peripheral mode, otherwise, the dp may be toggled due to we reset controller or do disconnect during the initialization for peripheral, then, the host may be confused during the enumeration, eg, it finds the reset can't succeed, but the device is still there, see below error message. hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: unable to enumerate USB device on port 1 Fixes: the issue existed when the otg fsm code was added. Cc: <stable@vger.kernel.org> # v3.16+ Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Li Jun authored
[ Upstream commit d20f7807 ] This patch adds response to a_alt_hnp_support set feature request from legacy A device, that is, B-device can provide a message to the user indicating that the user needs to connect the B-device to an alternate port on the A-device. A device sets this feature indicates to the B-device that it is connected to an A-device port that is not capable of HNP, but that the A-device does have an alternate port that is capable of HNP. [Peter] Without this patch, the OTG B device can't be enumerated on non-HNP port at A device, see below log: [ 2.287464] usb 1-1: Dual-Role OTG device on non-HNP port [ 2.293105] usb 1-1: can't set HNP mode: -32 [ 2.417422] usb 1-1: new high-speed USB device number 4 using ci_hdrc [ 2.460635] usb 1-1: Dual-Role OTG device on non-HNP port [ 2.466424] usb 1-1: can't set HNP mode: -32 [ 2.587464] usb 1-1: new high-speed USB device number 5 using ci_hdrc [ 2.630649] usb 1-1: Dual-Role OTG device on non-HNP port [ 2.636436] usb 1-1: can't set HNP mode: -32 [ 2.641003] usb usb1-port1: unable to enumerate USB device Cc: stable <stable@vger.kernel.org> Acked-by:
Li Jun <b47624@freescale.com> Signed-off-by:
-
David Dueck authored
[ Upstream commit d0f347d6 ] This fixes a potential null pointer dereference. Cc: <stable@vger.kernel.org> # v3.16+ Fixes: d4332013 ("driver core: dev_get_drvdata: Don't check for NULL dev") Acked-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
David Dueck <davidcdueck@googlemail.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit bda13e35 ] A new uas compatible controller has shown up in some people's devices from the manufacturer Initio Corporation, this controller needs the US_FL_NO_ATA_1X quirk to work properly with uas, so add it to the uas quirks table. Reported-and-tested-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org # 3.16 Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Andrei Otcheretianski authored
[ Upstream commit 0f611d28 ] Since moving the interface combination checks to mac80211, it's broken because it now only considers interfaces with an assigned channel context, so for example any interface that isn't active can still be up, which is clearly an issue; also, in particular P2P-Device wdevs are an issue since they never have a chanctx. Fix this by counting running interfaces instead the ones with a channel context assigned. Cc: stable@vger.kernel.org [3.16+] Fixes: 73de86a3 ("cfg80211/mac80211: move interface counting for combination check to mac80211") Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> [rewrite commit message, dig out the commit it fixes] Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Bob Copeland authored
[ Upstream commit d0c22119 ] The mesh forwarding path was not checking that data frames were protected when running an encrypted network; add the necessary check. Cc: stable@vger.kernel.org Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Michal Kazior authored
[ Upstream commit aa75ebc2 ] Some APs experience problems when working with U-APSD. Decreasing the probability of that happening by using legacy mode for all ACs but VO isn't enough. Cisco 4410N originally forced us to enable VO by default only because it treated non-VO ACs as legacy. However some APs (notably Netgear R7000) silently reclassify packets to different ACs. Since u-APSD ACs require trigger frames for frame retrieval clients would never see some frames (e.g. ARP responses) or would fetch them accidentally after a long time. It makes little sense to enable u-APSD queues by default because it needs userspace applications to be aware of it to actually take advantage of the possible additional powersavings. Implicitly depending on driver autotrigger frame support doesn't make much sense. Cc: stable@vger.kernel.org Signed-off-by:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
-
Johannes Berg authored
[ Upstream commit 496fcc29 ] As HT/VHT depend heavily on QoS/WMM, it's not a good idea to let userspace add clients that have HT/VHT but not QoS/WMM. Since it does so in certain cases we've observed (client is using HT IEs but not QoS/WMM) just ignore the HT/VHT info at this point and don't pass it down to the drivers which might unconditionally use it. Cc: stable@vger.kernel.org Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit b57a7128 ] The board id capability has been added in firmware 7.5. Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit ebc80840 ] The Fimware 8.1 has a bug in which the extra buttons are only sent when the ExtBit is 1. This should be fixed in a future FW update which should have a bump of the minor version. Cc: stable@vger.kernel.org Signed-off-by:
-
Dmitry Torokhov authored
[ Upstream commit dc5465dc ] On the X1 Carbon 3rd gen (with a 2015 broadwell cpu), the physical middle button of the trackstick (attached to the touchpad serio device, of course) seems to get lost. Actually, the touchpads reports 3 extra buttons, which falls in the switch below to the '2' case. Let's handle the case of odd numbers also, so that the middle button finds its way back. Cc: stable@vger.kernel.org Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit 02e07492 ] Post-2013 Lenovo laptops provide correct min/max dimensions, which are different with the ones currently quirked. According to https://bugzilla.kernel.org/show_bug.cgi?id=91541 the following board ids are assigned in the post-2013 touchpads: t440p/t440s: LEN0036 -> 2964/2962 t540p: LEN0034 -> 2964 Using 2961 as the common minimum makes these 3 laptops OK. We may need to update those values later if other pnp_ids has a lower board_id. Cc: stable@vger.kernel.org Signed-off-by:
-
Daniel Martin authored
[ Upstream commit 5b3089dd ] Add a min/max range for board ids to the min/max coordinates quirk. This makes it possible to restrict quirks to specific models based upon their board id. The define ANY_BOARD_ID (0) serves as a wild card. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541 Cc: stable@vger.kernel.org Signed-off-by:
Daniel Martin <daniel.martin@secunet.com> Acked-by:
-
Daniel Martin authored
[ Upstream commit b05f4d1c ] The firmware of the X240 (LEN0035, 2013/12) exposes the same values x [1232..5710], y [1156..4696] as the quirk applies. Cc: stable@vger.kernel.org Signed-off-by:
Daniel Martin <consume.noise@gmail.com> Acked-by:
-
Daniel Martin authored
[ Upstream commit ac097930 ] Query the min dimensions even if the check SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 7 fails, but we know that the firmware version 8.1 is safe. With that we don't need quirks for post-2013 models anymore as they expose correct min and max dimensions. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541 Cc: stable@vger.kernel.org Signed-off-by:
-
Daniel Martin authored
[ Upstream commit 9aff6598 ] Logging the dimension values we queried and the values we use from a quirk to overwrite can be helpful for debugging. This partly relates to bug: https://bugzilla.kernel.org/show_bug.cgi?id=91541 Cc: stable@vger.kernel.org Signed-off-by:
-
Daniel Martin authored
[ Upstream commit 8b04baba ] Split the function synaptics_resolution() into synaptics_resolution() and synaptics_quirks(). synaptics_resolution() will be called before synaptics_quirks() to query dimensions and resolutions before overwriting them with quirks. Cc: stable@vger.kernel.org Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit 75c3d0bf ] This patch fixes the incorrect use of __transport_register_session() in tcm_qla2xxx_check_initiator_node_acl() code, that does not perform explicit se_tpg->session_lock when accessing se_tpg->tpg_sess_list to add new se_sess nodes. Given that tcm_qla2xxx_check_initiator_node_acl() is not called with qla_hw->hardware_lock held for all accesses of ->tpg_sess_list, the code should be using transport_register_session() instead. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Cc: Giridhar Malavali <giridhar.malavali@qlogic.com> Cc: Quinn Tran <quinn.tran@qlogic.com> Cc: <stable@vger.kernel.org> # 3.5+ Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit d556546e ] This patch adds a missing set of conditional check braces in ft_invl_hw_context() originally introduced by commit dcd998cc when handling DDP failures in ft_recv_write_data() code. commit dcd998cc Author: Kiran Patil <kiran.patil@intel.com> Date: Wed Aug 3 09:20:01 2011 +0000 tcm_fc: Handle DDP/SW fc_frame_payload_get failures in ft_recv_write_data Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Kiran Patil <kiran.patil@intel.com> Cc: <stable@vger.kernel.org> # 3.1+ Signed-off-by:
-
Yongbae Park authored
[ Upstream commit 7b8f10da ] The initialisation of the efm32 clocksource first sets up the irq and only after that initialises the data needed for irq handling. In case this initialisation is delayed the irq handler would dereference a NULL pointer. I'm not aware of anything that could delay the process in such a way, but it's better to be safe than sorry, so setup the irq only when the clock event device is ready. Cc: stable@vger.kernel.org Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Yongbae Park <yongbae2@gmail.com> Signed-off-by:
-
Philipp Zabel authored
[ Upstream commit c6b570d9 ] This patch fixes a NULL pointer dereference when enabling regmap event tracing in the presence of a syscon regmap, introduced by commit bdb0066d ("mfd: syscon: Decouple syscon interface from platform devices"). That patch introduced syscon regmaps that have their dev field set to NULL. The regmap trace events expect it to point to a valid struct device and feed it to dev_name(): $ echo 1 > /sys/kernel/debug/tracing/events/regmap/enable Unable to handle kernel NULL pointer dereference at virtual address 0000002c pgd = 80004000 [0000002c] *pgd=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: coda videobuf2_vmalloc CPU: 0 PID: 304 Comm: kworker/0:2 Not tainted 4.0.0-rc2+ #9197 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Workqueue: events_freezable thermal_zone_device_check task: 9f25a200 ti: 9f1ee000 task.ti: 9f1ee000 PC is a...
-
Lars-Peter Clausen authored
[ Upstream commit 328f494d ] When inserting a new register into a block at the lower end the present bitmap is currently shifted into the wrong direction. The effect of this is that the bitmap becomes corrupted and registers which are present might be reported as not present and vice versa. Fix this by shifting left rather than right. Fixes: 472fdec7 ("regmap: rbtree: Reduce number of nodes, take 2") Reported-by:
Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Yongbae Park authored
[ Upstream commit 1096be08 ] The interrupt is enabled before the handler is set. Even this bug did not appear, it is potentially dangerous as it can lead to a NULL pointer dereference. Fix the error by enabling the interrupt after clockevents_config_and_register() is called. Cc: stable@vger.kernel.org Signed-off-by:
-
Michael S. Tsirkin authored
[ Upstream commit 3d2a3774 ] virtio balloon has this code: wait_event_interruptible(vb->config_change, (diff = towards_target(vb)) != 0 || vb->need_stats_update || kthread_should_stop() || freezing(current)); Which is a problem because towards_target() call might block after wait_event_interruptible sets task state to TAST_INTERRUPTIBLE, causing the task_struct::state collision typical of nesting of sleeping primitives See also http://lwn.net/Articles/628628/ or Thomas's bug report http://article.gmane.org/gmane.linux.kernel.virtualization/24846 for a fuller explanation. To fix, rewrite using wait_woken. Cc: stable@vger.kernel.org Reported-by:
Thomas Huth <thuth@linux.vnet.ibm.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Tested-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit 61ada528 ] There are a few places that call blocking primitives from wait loops, provide infrastructure to support this without the typical task_struct::state collision. We record the wakeup in wait_queue_t::flags which leaves task_struct::state free to be used by others. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Oleg Nesterov <oleg@redhat.com> Cc: tglx@linutronix.de Cc: ilya.dryomov@inktank.com Cc: umgwanakikbuti@gmail.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/20140924082242.051202318@infradead.org Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
- 09 Apr, 2015 9 commits
-
-
Michael S. Tsirkin authored
[ Upstream commit 88660f7f ] virtio spec requires that all drivers set DRIVER_OK before using devices. While balloon isn't yet included in the virtio 1 spec, previous spec versions also required this. virtio balloon might violate this rule: probe calls kthread_run before setting DRIVER_OK, which might run immediately and cause balloon to inflate/deflate. To fix, call virtio_device_ready before running the kthread. Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 07892b10 ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 2bf4c1d4 ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 08641d9b ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit eaddf6fd ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 24cc883c ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 00a14c29 ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit bd14016f ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 4c523ef6 ] The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
