aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2014-06-07target: Don't allow setting WC emulation if device doesn't supportAndy Grover
commit 07b8dae38b09bcfede7e726f172e39b5ce8390d9 upstream. Just like for pSCSI, if the transport sets get_write_cache, then it is not valid to enable write cache emulation for it. Return an error. see https://bugzilla.redhat.com/show_bug.cgi?id=1082675 Reviewed-by: Chris Leech <cleech@redhat.com> Signed-off-by: Andy Grover <agrover@redhat.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07iscsi-target: Change BUG_ON to REJECT in iscsit_process_nop_outNicholas Bellinger
commit 7cbfcc953789ff864c2bf8365a82a3fba4869649 upstream. This patch changes an incorrect use of BUG_ON to instead generate a REJECT + PROTOCOL_ERROR in iscsit_process_nop_out() code. This case can occur with traditional TCP where a flood of zeros in the data stream can reach this block for what is presumed to be a NOP-OUT with a solicited reply, but without a valid iscsi_cmd pointer. This incorrect BUG_ON was introduced during the v3.11-rc timeframe with the following commit: commit 778de368964c5b7e8100cde9f549992d521e9c89 Author: Nicholas Bellinger <nab@linux-iscsi.org> Date: Fri Jun 14 16:07:47 2013 -0700 iscsi/isert-target: Refactor ISCSI_OP_NOOP RX handling Reported-by: Arshad Hussain <arshad.hussain@calsoftinc.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Target/iser: Fix iscsit_accept_np and rdma_cm racy flowSagi Grimberg
commit 531b7bf4bd795d9a09eac92504322a472c010bc8 upstream. RDMA CM and iSCSI target flows are asynchronous and completely uncorrelated. Relying on the fact that iscsi_accept_np will be called after CM connection request event and will wait for it is a mistake. When attempting to login to a few targets this flow is racy and unpredictable, but for parallel login to dozens of targets will race and hang every time. The correct synchronizing mechanism in this case is pending on a semaphore rather than a wait_for_event. We keep the pending interruptible for iscsi_np cleanup stage. (Squash patch to remove dead code into parent - nab) Reported-by: Slava Shwartsman <valyushash@gmail.com> Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Target/iser: Fix wrong connection requests list additionSagi Grimberg
commit 9fe63c88b1d59f1ce054d6948ccd3096496ecedb upstream. Should be adding list_add_tail($new, $head) and not the other way around. Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07target: Allow non-supporting backends to set pi_prot_type to 0Andy Grover
commit 448ba904160f9d8f69217c28a1692cee5afbff88 upstream. Userspace tools assume if a value is read from configfs, it is valid and will not cause an error if the same value is written back. The only valid value for pi_prot_type for backends not supporting DIF is 0, so allow this particular value to be set without returning an error. Reported-by: Krzysztof Chojnowski <frirajder@gmail.com> Signed-off-by: Andy Grover <agrover@redhat.com> Reviewed-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07PCI: shpchp: Check bridge's secondary (not primary) bus speedMarcel Apfelbaum
commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc upstream. When a new device is added below a hotplug bridge, the bridge's secondary bus speed and the device's bus speed must match. The shpchp driver previously checked the bridge's *primary* bus speed, not the secondary bus speed. This caused hot-add errors like: shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch Check the secondary bus speed instead. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251 Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core") Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07iwlwifi: mvm: fix setting channel in monitor modeEmmanuel Grumbach
commit 1c4abec0baf25ffb92a28cc99d4231feeaa4d3f3 upstream. There was a deadlock in monitor mode when we were setting the channel if the channel was not 1. ====================================================== [ INFO: possible circular locking dependency detected ] 3.14.3 #4 Not tainted ------------------------------------------------------- iw/3323 is trying to acquire lock: (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211] but task is already holding lock: (&local->iflist_mtx){+.+...}, at: [<ffffffffa0609e0a>] ieee80211_set_monitor_channel+0x5a/0x1b0 [mac80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&local->iflist_mtx){+.+...}: [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0 [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0 [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0 [<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [<ffffffffa0518189>] iwl_mvm_recalc_multicast+0x49/0xa0 [iwlmvm] [<ffffffffa051822e>] iwl_mvm_configure_filter+0x4e/0x70 [iwlmvm] [<ffffffffa05e6d43>] ieee80211_configure_filter+0x153/0x5f0 [mac80211] [<ffffffffa05e71f5>] ieee80211_reconfig_filter+0x15/0x20 [mac80211] [snip] -> #1 (&mvm->mutex){+.+.+.}: [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0 [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0 [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0 [<ffffffffa0517246>] iwl_mvm_add_chanctx+0x56/0xe0 [iwlmvm] [<ffffffffa062ca1e>] ieee80211_new_chanctx+0x13e/0x410 [mac80211] [<ffffffffa062d953>] ieee80211_vif_use_channel+0x1c3/0x5a0 [mac80211] [<ffffffffa06035ab>] ieee80211_add_virtual_monitor+0x1ab/0x6b0 [mac80211] [<ffffffffa06052ea>] ieee80211_do_open+0xe6a/0x15a0 [mac80211] [<ffffffffa0605a79>] ieee80211_open+0x59/0x60 [mac80211] [snip] -> #0 (&local->chanctx_mtx){+.+.+.}: [<ffffffff810d6cb7>] check_prevs_add+0x977/0x980 [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0 [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0 [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0 [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211] [<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211] [<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211] [<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211] [<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211] [snip] other info that might help us debug this: Chain exists of: &local->chanctx_mtx --> &mvm->mutex --> &local->iflist_mtx Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&local->iflist_mtx); lock(&mvm->mutex); lock(&local->iflist_mtx); lock(&local->chanctx_mtx); *** DEADLOCK *** This deadlock actually occurs: INFO: task iw:3323 blocked for more than 120 seconds. Not tainted 3.14.3 #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. iw D ffff8800c8afcd80 4192 3323 3322 0x00000000 ffff880078fdb7e0 0000000000000046 ffff8800c8afcd80 ffff880078fdbfd8 00000000001d5540 00000000001d5540 ffff8801141b0000 ffff8800c8afcd80 ffff880078ff9e38 ffff880078ff9e38 ffff880078ff9e40 0000000000000246 Call Trace: [<ffffffff817ea841>] schedule_preempt_disabled+0x31/0x80 [<ffffffff817ebaed>] mutex_lock_nested+0x19d/0x4f0 [<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [<ffffffffa052a680>] ? iwl_mvm_power_mac_update_mode+0xc0/0xc0 [iwlmvm] [<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [<ffffffffa0529357>] _iwl_mvm_power_update_binding+0x27/0x80 [iwlmvm] [<ffffffffa0516eb1>] iwl_mvm_unassign_vif_chanctx+0x81/0xc0 [iwlmvm] [<ffffffffa062d3ff>] __ieee80211_vif_release_channel+0xdf/0x470 [mac80211] [<ffffffffa062e2fa>] ieee80211_vif_release_channel+0x4a/0xb0 [mac80211] [<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211] [<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211] [<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211] [<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211] This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75541 Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07iwlwifi: pcie: disable interrupts upon PCIe allocEmmanuel Grumbach
commit 83f7a85f1134c6e914453f5747435415a23d516b upstream. In case RFKILL is in KILL position, the NIC will issue an interrupt straight away. This interrupt won't be sent because it is masked in the hardware. But if our interrupt service routine is called for another reason (SHARED_IRQ), then we'll look at the interrupt cause and service it. This can cause bad things if we are not ready yet. Explicitly clean the interrupt cause register to make sure we won't service anything before we are ready to. Reported-and-tested-by: Alexander Monakov <amonakov@gmail.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07PCI: mvebu: split PCIe BARs into multiple MBus windows when neededThomas Petazzoni
commit 398f5d5e10b6b917cd9d35ef21d545b0afbada22 upstream. MBus windows are used on Marvell platforms to map certain peripherals in the physical address space. In the PCIe context, MBus windows are needed to map PCIe I/O and memory regions in the physical address. However, those MBus windows can only have power of two sizes, while PCIe BAR do not necessarily guarantee this. For this reason, the current pci-mvebu breaks on platforms where PCIe devices have BARs that don't sum up to a power of two size at the emulated bridge level. This commit fixes this by allowing the pci-mvebu driver to create multiple contiguous MBus windows (each having a power of two size) to cover a given PCIe BAR. To achieve this, two functions are added: mvebu_pcie_add_windows() and mvebu_pcie_del_windows() to respectively add and remove all the MBus windows that are needed to map the provided PCIe region base and size. The emulated PCI bridge code now calls those functions, instead of directly calling the mvebu-mbus driver functions. Fixes: 45361a4fe446 ('pci: PCIe driver for Marvell Armada 370/XP systems') Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-8-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <neil@fatboyfat.co.uk> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07bus: mvebu-mbus: allow several windows with the same target/attributeThomas Petazzoni
commit b566e782be32145664d96ada3e389f17d32742e5 upstream. Having multiple windows with the same target and attribute is actually legal, and can be useful for PCIe windows, when PCIe BARs have a size that isn't a power of two, and we therefore need to create several MBus windows to cover the PCIe BAR for a given PCIe interface. Fixes: fddddb52a6c4 ('bus: introduce an Marvell EBU MBus driver') Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-7-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <neil@fatboyfat.co.uk> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07PCI: mvebu: fix off-by-one in the computed size of the mbus windowsWilly Tarreau
commit b6d07e0273d3296cfbdc88145b8a00ddbefb310a upstream. mvebu_pcie_handle_membase_change() and mvebu_pcie_handle_iobase_change() do not correctly compute the window size. PCI uses an inclusive start/end address pair, which requires a +1 when converting to size. This only worked because a bug in the mbus driver allowed it to silently accept and round up bogus sizes. Fix this by adding one to the computed size. Fixes: 45361a4fe446 ('PCIe driver for Marvell Armada 370/XP systems') Signed-off-by: Willy Tarreau <w@1wt.eu> Reviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-5-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <neil@fatboyfat.co.uk> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07memory: mvebu-devbus: fix the conversion of the bus widthThomas Petazzoni
commit ce965c3d2e68c5325dd5624eb101d70423022fef upstream. According to the Armada 370 and Armada XP datasheets, the part of the Device Bus register that configure the bus width should contain 0 for a 8 bits bus width, and 1 for a 16 bits bus width (other values are unsupported/reserved). However, the current conversion done in the driver to convert from a bus width in bits to the value expected by the register leads to setting the register to 1 for a 8 bits bus, and 2 for a 16 bits bus. This mistake was compensated by a mistake in the existing Device Tree files for Armada 370/XP platforms: they were declaring a 8 bits bus width, while the hardware in fact uses a 16 bits bus width. This commit fixes that by adjusting the conversion logic. This patch fixes a bug that was introduced in 3edad321b1bd2e6c8b5f38146c115c8982438f06 ('drivers: memory: Introduce Marvell EBU Device Bus driver'), which was merged in v3.11. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397489361-5833-2-git-send-email-thomas.petazzoni@free-electrons.com Fixes: 3edad321b1bd ('drivers: memory: Introduce Marvell EBU Device Bus driver') Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Input: synaptics - change min/max quirk table to pnp-id matchingHans de Goede
commit 0f68f39c393bc06ac5ccc8794f0e2ed841e41c3e upstream. Most of the affected models share pnp-ids for the touchpad. So switching to pnp-ids give us 2 advantages: 1) It shrinks the quirk list 2) It will lower the new quirk addition frequency, ie the recently added W540 quirk would not have been necessary since it uses the same LEN0034 pnp ids as other models already added before it As an added bonus it actually puts the quirk on the actual psmouse, rather then on the machine, which is technically more correct. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Input: synaptics - add a matches_pnp_id helper functionHans de Goede
commit e2f611029b370bb7a04236215ad4b36aa8cb98cd upstream. This is a preparation patch for simplifying the min/max quirk table. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Input: synaptics - T540p - unify with other LEN0034 modelsHans de Goede
commit 6d396ede224dc596d92d7cab433713536e68916c upstream. The T540p has a touchpad with pnp-id LEN0034, all the models with this pnp-id have the same min/max values, except the T540p where the values are slightly off. Fix them to be identical. This is a preparation patch for simplifying the quirk table. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Input: synaptics - add min/max quirk for the ThinkPad W540Hans de Goede
commit 0b5fe736fe923f1f5e05413878d5990e92ffbdf5 upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1096436 Tested-and-reported-by: ajayr@bigfoot.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Input: elantech - fix touchpad initialization on Gigabyte U2442Hans de Goede
commit 36189cc3cd57ab0f1cd75241f93fe01de928ac06 upstream. The hw_version 3 Elantech touchpad on the Gigabyte U2442 does not accept 0x0b as initialization value for r10, this stand-alone version of the driver: http://planet76.com/drivers/elantech/psmouse-elantech-v6.tar.bz2 Uses 0x03 which does work, so this means not setting bit 3 of r10 which sets: "Enable Real H/W Resolution In Absolute mode" Which will result in half the x and y resolution we get with that bit set, so simply not setting it everywhere is not a solution. We've been unable to find a way to identify touchpads where setting the bit will fail, so this patch uses a dmi based blacklist for this. https://bugzilla.kernel.org/show_bug.cgi?id=61151 Reported-by: Philipp Wolfer <ph.wolfer@gmail.com> Tested-by: Philipp Wolfer <ph.wolfer@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Input: atkbd - fix keyboard not working on some LG laptopsSheng-Liang Song
commit 3d725caa9dcc78c3dc9e7ea0c04f626468edd9c9 upstream. After issuing ATKBD_CMD_RESET_DIS, keyboard on some LG laptops stops working. The workaround is to stop issuing ATKBD_CMD_RESET_DIS commands. In order to keep changes in atkbd driver to the minimum we check DMI signature and only skip ATKBD_CMD_RESET_DIS if we are running on LG LW25-B7HV or P1-J273B. Signed-off-by: Sheng-Liang Song <ssl@chromium.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07e1000e: Fix no connectivity when driver loaded with cable outDavid Ertman
commit b20a774495671f037e7160ea2ce8789af6b61533 upstream. In commit da1e2046e5, the flow for enabling/disabling an Si errata workaround (e1000_lv_jumbo_workaround_ich8lan) was changed to fix a problem with iAMT connections dropping on interface down with jumbo frames set. Part of this change was to move the function call disabling the workaround to e1000e_down() from the e1000_setup_rctl() function. The mechanic for disabling of this workaround involves writing several MAC and PHY registers back to hardware defaults. After this commit, when the driver is loaded with the cable out, the PHY registers are not programmed with the correct default values. This causes the device to be capable of transmitting packets, but is unable to recieve them until this workaround is called. The flow of e1000e's open code relies upon calling the above workaround to expicitly program these registers either with jumbo frame appropriate settings or h/w defaults on 82579 and newer hardware. Fix this issue by adding logic to e1000_setup_rctl() that not only calls e1000_lv_jumbo_workaround_ich8lan() when jumbo frames are set, to enable the workaround, but also calls this function to explicitly disable the workaround in the case that jumbo frames are not set. Signed-off-by: Dave Ertman <davidx.m.ertman@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Input: synaptics - report INPUT_PROP_TOPBUTTONPAD propertyHans de Goede
commit 43e19888b1fe2a3e8a5543030c5b286cde38b3f5 upstream. Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD property for for touchpads with top button areas. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Input: i8042 - add firmware_id supportHans de Goede
commit a7c5868c3482127cb308c779b8a6460a3353c17f upstream. Fill in the new serio firmware_id sysfs attribute for pnp instantiated 8042 serio ports. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Input: serio - add firmware_id sysfs attributeHans de Goede
commit 0456c66f4e905e1ca839318219c770988b47975c upstream. serio devices exposed via platform firmware interfaces such as ACPI may provide additional identifying information of use to userspace. We don't associate the serio devices with the firmware device (we don't set it as parent), so there's no way for userspace to make use of this information. We cannot change the parent for serio devices instantiated though a firmware interface as that would break suspend / resume ordering. Therefore this patch adds a new firmware_id sysfs attribute so that userspace can get a string from there with any additional identifying information the firmware interface may provide. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07i2c: i801: enable Intel BayTrail SMBUSChew, Kean ho
commit 1b31e9b76ef8c62291e698dfdb973499986a7f68 upstream. Add Device ID of Intel BayTrail SMBus Controller. Signed-off-by: Chew, Kean ho <kean.ho.chew@intel.com> Signed-off-by: Chew, Chiau Ee <chiau.ee.chew@intel.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: "Chang, Rebecca Swee Fun" <rebecca.swee.fun.chang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07media: media-device: fix infoleak in ioctl media_enum_entities()Salva Peiró
commit e6a623460e5fc960ac3ee9f946d3106233fd28d8 upstream. This fixes CVE-2014-1739. Signed-off-by: Salva Peiró <speiro@ai2.upv.es> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07clk: vexpress: NULL dereference on error pathDan Carpenter
commit 6b4ed8b00e93bd31f24a25f59ed8d1b808d0cc00 upstream. If the allocation fails then we dereference the NULL in the error path. Just return directly. Fixes: ed27ff1db869 ('clk: Versatile Express clock generators ("osc") driver') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07brcmsmac: fix deadlock on missing firmwareEmil Goode
commit 8fc1e8c240aab968db658b2d8d079b4391207a36 upstream. When brcm80211 firmware is not installed networking hangs. A deadlock happens because we call ieee80211_unregister_hw() from the .start callback of struct ieee80211_ops. When .start is called we are under rtnl lock and ieee80211_unregister_hw() tries to take it again. Function call stack: dev_change_flags() __dev_change_flags() __dev_open() ASSERT_RTNL() <-- Assert rtnl lock ops->ndo_open() .ndo_open = ieee80211_open, ieee80211_open() ieee80211_do_open() drv_start() local->ops->start() .start = brcms_ops_start, brcms_ops_start() brcms_remove() ieee80211_unregister_hw() rtnl_lock() <-- Here we deadlock Introduced by: commit 25b5632fb35ca61b8ae3eee235edcdc2883f7a5e ("brcmsmac: request firmware in .start() callback") This patch fixes the bug by removing the call to brcms_remove() and moves the brcms_request_fw() call to the top of the .start callback to not initiate anything unless firmware is installed. Signed-off-by: Emil Goode <emilgoode@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07leds: leds-pwm: properly clean up after probe failureRussell King
commit 392369019eb96e914234ea21eda806cb51a1073e upstream. When probing with DT, we add each LED one at a time. If we find a LED without a PWM device (because it is not available yet) we fail the initialisation, unregister previous LEDs, and then by way of managed resources, we free the structure. The problem with this is we may have a scheduled and active work_struct in this structure, and this results in a nasty kernel oops. We need to cancel this work_struct properly upon cleanup - and the cleanup we require is the same cleanup as we do when the LED platform device is removed. Rather than writing this same code three times, move it into a separate function and use it in all three places. Fixes: c971ff185f64 ("leds: leds-pwm: Defer led_pwm_set() if PWM can sleep") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07drm/nouveau/pm/fan: drop the fan lock in fan_update() before reschedulingMartin Peres
commit 61679fe153b2b9ea5b5e2ab93305419e85e99a9d upstream. This should fix a deadlock that has been reported to us where fan_update() would hold the fan lock and try to grab the alarm_program_lock to reschedule an update. On an other CPU, the alarm_program_lock would have been taken before calling fan_update(), leading to a deadlock. We should Cc: <stable@vger.kernel.org> # 3.9+ Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com> Tested-by: Timothée Ravier <tim@siosm.fr> Tested-by: Boris Fersing (IRC nick fersingb, no public email address) Signed-off-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07igb: Unset IGB_FLAG_HAS_MSIX-flag when falling back to msi-onlyChristoph Paasch
commit b709323d2477614823a38c2f2a9a206e087e28fc upstream. Prior to cd14ef54d25 (igb: Change to use statically allocated array for MSIx entries), having msix_entries different from NULL was an indicator that MSIX is enabled. In igb_set_interrupt_capabiliy we may fall back to MSI-only. Prior to the above patch msix_entries was set to NULL by igb_reset_interrupt_capability. However, now we are checking the flag for IGB_FLAG_HAS_MSIX and so the stack gets completly confused: [ 42.659791] ------------[ cut here ]------------ [ 42.715032] WARNING: CPU: 7 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x15c/0x1fb() [ 42.848263] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out [ 42.923253] Modules linked in: [ 42.959875] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.14.0-rc2-mptcp #437 [ 43.043184] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011 [ 43.119215] 0000000000000108 ffff88023fdc3da8 ffffffff81487847 0000000000000108 [ 43.208165] ffff88023fdc3df8 ffff88023fdc3de8 ffffffff81034e7d ffff88023fdc3dd8 [ 43.297120] ffffffff813fff10 ffff880236018000 ffff880236b178c0 0000000000000008 [ 43.386071] Call Trace: [ 43.415303] <IRQ> [<ffffffff81487847>] dump_stack+0x49/0x62 [ 43.484174] [<ffffffff81034e7d>] warn_slowpath_common+0x77/0x91 [ 43.556049] [<ffffffff813fff10>] ? dev_watchdog+0x15c/0x1fb [ 43.623759] [<ffffffff81034f2b>] warn_slowpath_fmt+0x41/0x43 [ 43.692511] [<ffffffff813fff10>] dev_watchdog+0x15c/0x1fb [ 43.758141] [<ffffffff813ffdb4>] ? __netdev_watchdog_up+0x64/0x64 [ 43.832091] [<ffffffff8103cd04>] call_timer_fn+0x17/0x6f [ 43.896682] [<ffffffff8103cebe>] run_timer_softirq+0x162/0x1a2 [ 43.967511] [<ffffffff81038520>] __do_softirq+0xcd/0x1cc [ 44.032104] [<ffffffff81038689>] irq_exit+0x3a/0x48 [ 44.091492] [<ffffffff81026d43>] smp_apic_timer_interrupt+0x43/0x50 [ 44.167525] [<ffffffff8148c24a>] apic_timer_interrupt+0x6a/0x70 [ 44.239392] <EOI> [<ffffffff8100992c>] ? default_idle+0x6/0x8 [ 44.310343] [<ffffffff81009b31>] arch_cpu_idle+0x13/0x18 [ 44.374934] [<ffffffff81066126>] cpu_startup_entry+0xa7/0x101 [ 44.444724] [<ffffffff81025660>] start_secondary+0x1b2/0x1b7 [ 44.513472] ---[ end trace a5a075fd4e7f854f ]--- [ 44.568753] igb 0000:04:00.0 eth0: Reset adapter [ 46.206945] random: nonblocking pool is initialized [ 46.465670] irq 44: nobody cared (try booting with the "irqpoll" option) [ 46.545862] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G W 3.14.0-rc2-mptcp #437 [ 46.640610] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011 [ 46.716641] ffff8802363f8c84 ffff88023fdc3e38 ffffffff81487847 00000000a03cdb6d [ 46.805598] ffff8802363f8c00 ffff88023fdc3e68 ffffffff81068489 0000007f81825400 [ 46.894539] ffff8802363f8c00 0000000000000000 0000000000000000 ffff88023fdc3ea8 [ 46.983484] Call Trace: [ 47.012714] <IRQ> [<ffffffff81487847>] dump_stack+0x49/0x62 [ 47.081585] [<ffffffff81068489>] __report_bad_irq+0x35/0xc1 [ 47.149295] [<ffffffff81068683>] note_interrupt+0x16e/0x1ea [ 47.217006] [<ffffffff8106679e>] handle_irq_event_percpu+0x116/0x12e [ 47.294075] [<ffffffff810667e9>] handle_irq_event+0x33/0x4f [ 47.361787] [<ffffffff81068c95>] handle_fasteoi_irq+0x83/0xd1 [ 47.431577] [<ffffffff81003d5b>] handle_irq+0x1f/0x28 [ 47.493047] [<ffffffff81003567>] do_IRQ+0x4e/0xd4 [ 47.550358] [<ffffffff8148b06a>] common_interrupt+0x6a/0x6a [ 47.618066] <EOI> [<ffffffff8100992c>] ? default_idle+0x6/0x8 [ 47.689016] [<ffffffff81009b31>] arch_cpu_idle+0x13/0x18 [ 47.753605] [<ffffffff81066126>] cpu_startup_entry+0xa7/0x101 [ 47.823397] [<ffffffff81025660>] start_secondary+0x1b2/0x1b7 [ 47.892146] handlers: [ 47.919301] [<ffffffff812fbd7d>] igb_intr So, this patch unsets the flag to indicate that we are not using MSIX. This patch does exactly this: Unsetting the flag when falling back to MSI. Fixes: cd14ef54d25b (igb: Change to use statically allocated array for MSIx entries) Cc: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07igb: Fix Null-pointer dereference in igb_reset_q_vectorChristoph Paasch
commit cb06d102327eadcd1bdc480bfd9f8876251d1007 upstream. When igb_set_interrupt_capability() calls igb_reset_interrupt_capability() (e.g., because CONFIG_PCI_MSI is unset), num_q_vectors has been set but no vector has yet been allocated. igb_reset_interrupt_capability() will then call igb_reset_q_vector, which assumes that the vector is allocated. As this is not the case, we are accessing a NULL-pointer. This patch fixes it by checking that q_vector is indeed different from NULL. Fixes: 02ef6e1d0b0023 (igb: Fix queue allocation method to accommodate changing during runtime) Cc: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07i40e: potential array underflow in i40e_vc_process_vf_msg()Dan Carpenter
commit c243e96335c56e56dcf6a00593104554fb06b689 upstream. If "vf_id" is smaller than hw->func_caps.vf_base_id then it leads to an array underflow of the pf->vf[] array. This is unlikely to happen unless the hardware is bad, but it's a small change and it silences a static checker warning. Fixes: 7efa84b7abc1 ('i40e: support VFs on PFs other than 0') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Tested-by: Sibai Li <sibai.li@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07drm/i915: restore backlight precision when converting from ACPIAaron Lu
commit 721e82c08c1afd6b47367b0e0c4a62140b0667f3 upstream. When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491 Reported-by: Nico Schottelius <nico-bugzilla.kernel.org@schottelius.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07drm/i915/vlv: reset VLV media force wake request registerJani Nikula
commit 05adaf1f101f25f40f12c29403e6488f0e45f6b6 upstream. Media force wake get hangs the machine when the system is booted without displays attached. The assumption is that (at least some versions of) the firmware has skipped some initialization in that case. Empirical evidence suggests we need to reset the media force wake request register in addition to the render one to avoid hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75895 Reported-by: Imre Deak <imre.deak@intel.com> Reported-by: Darren Hart <dvhart@linux.intel.com> Tested-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07drm/nouveau: fix another lock unbalance in nouveau_crtc_page_flipMaarten Lankhorst
commit 806cbc5026933a781b66adecf6d1658fde9138e6 upstream. Fixes a regression introduced by 060810d7abaabca "drm/nouveau: fix locking issues in page flipping paths". chan->cli->mutex is unlocked a second time in the fail_unreserve path, fix this by moving mutex_unlock down. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07drm/nouveau/acpi: allow non-optimus setups to load vbios from acpiIlia Mirkin
commit a3d0b1218d351c6e6f3cea36abe22236a08cb246 upstream. There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()Ben Hutchings
commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream. Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs') Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Revert "Bluetooth: Enable autosuspend for Intel Bluetooth device"Marcel Holtmann
commit 3c49aa852e00978ba2f1a4d1e4598a0c669a5347 upstream. This reverts commit d2bee8fb6e18f6116aada39851918473761f7ab1. Enabling autosuspend for Intel Bluetooth devices has been shown to not work reliable. It does work for some people with certain combinations of USB host controllers, but for others it puts the device to sleep and it will not wake up for any event. These events can be important ones like HCI Inquiry Complete or HCI Connection Request. The events will arrive as soon as you poke the device with a new command, but that is not something we can do in these cases. Initially there were patches to the xHCI USB controller that fixed this for some people, but not for all. This could be well a problem somewhere in the USB subsystem or in the USB host controllers or just plain a hardware issue somewhere. At this moment we just do not know and the only safe action is to revert this patch. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07Bluetooth: Add support for Lite-on [04ca:3007]Mohammed Habibulla
commit 1fb4e09a7e780b915dbd172592ae7e2a4c071065 upstream. Add support for the AR9462 chip T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3007 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Mohammed Habibulla <moch@chromium.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07rt2x00: fix beaconing on USBStanislaw Gruszka
commit 8834d3608cc516f13e2e510f4057c263f3d2ce42 upstream. When disable beaconing we clear register with beacon and newer set it back, what make we stop send beacons infinitely. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07USB: Nokia 5300 should be treated as unusual devDaniele Forsi
commit 6ed07d45d09bc2aa60e27b845543db9972e22a38 upstream. Signed-off-by: Daniele Forsi <dforsi@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07USB: Nokia 305 should be treated as unusual devVictor A. Santos
commit f0ef5d41792a46a1085dead9dfb0bdb2c574638e upstream. Signed-off-by: Victor A. Santos <victoraur.santos@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07usb: storage: shuttle_usbat: fix discs being detected twiceDaniele Forsi
commit df602c2d2358f02c6e49cffc5b49b9daa16db033 upstream. Even if the USB-to-ATAPI converter supported multiple LUNs, this driver would always detect the same physical device or media because it doesn't use srb->device->lun in any way. Tested with an Hewlett-Packard CD-Writer Plus 8200e. Signed-off-by: Daniele Forsi <dforsi@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07usb: qcserial: add a number of Dell devicesBjørn Mork
commit 4d7c0136a54f62501f8a34c4d08a5e0258d3d3ca upstream. Dan writes: "The Dell drivers use the same configuration for PIDs: 81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card 81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card 81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card 81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card 81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card These devices are all clearly Sierra devices, but are also definitely Gobi-based. The A8 might be the MC7700/7710 and A9 is likely a MC7750. >From DellGobi5kSetup.exe from the Dell drivers: usbif0: serial/firmware loader? usbif2: nmea usbif3: modem/ppp usbif8: net/QMI" Reported-by: AceLan Kao <acelan.kao@canonical.com> Reported-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07USB: OHCI: fix problem with global suspend on ATI controllersAlan Stern
commit c1db30a2a79eb59997b13b8cabf2a50bea9f04e1 upstream. Some OHCI controllers from ATI/AMD seem to have difficulty with "global" USB suspend, that is, suspending an entire USB bus without setting the suspend feature for each port connected to a device. When we try to resume the child devices, the controller gives timeout errors on the unsuspended ports, requiring resets, and can even cause ohci-hcd to hang; see http://marc.info/?l=linux-usb&m=139514332820398&w=2 and the following messages. This patch fixes the problem by adding a new quirk flag to ohci-hcd. The flag causes the ohci_rh_suspend() routine to suspend each unsuspended, enabled port before suspending the root hub. This effectively converts the "global" suspend to an ordinary root-hub suspend. There is no need to unsuspend these ports when the root hub is resumed, because the child devices will be resumed anyway in the course of a normal system resume ("global" suspend is never used for runtime PM). This patch should be applied to all stable kernels which include commit 0aa2832dd0d9 (USB: use "global suspend" for system sleep on USB-2 buses) or a backported version thereof. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Peter Münster <pmlists@free.fr> Tested-by: Peter Münster <pmlists@free.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07usb: gadget: at91-udc: fix irq and iomem resource retrievalJean-Jacques Hiblot
commit 886c7c426d465732ec9d1b2bbdda5642fc2e7e05 upstream. When using dt resources retrieval (interrupts and reg properties) there is no predefined order for these resources in the platform dev resource table. Also don't expect the number of resource to be always 2. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Acked-by: Boris BREZILLON <b.brezillon@overkiz.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07fsl-usb: do not test for PHY_CLK_VALID bit on controller version 1.6Nikita Yushchenko
commit d183c81929beeba842b74422f754446ef2b8b49c upstream. Per reference manuals of Freescale P1020 and P2020 SoCs, USB controller present in these SoCs has bit 17 of USBx_CONTROL register marked as Reserved - there is no PHY_CLK_VALID bit there. Testing for this bit in ehci_fsl_setup_phy() behaves differently on two P1020RDB boards available here - on one board test passes and fsl-usb init succeeds, but on other board test fails, causing fsl-usb init to fail. This patch changes ehci_fsl_setup_phy() not to test PHY_CLK_VALID on controller version 1.6 that (per manual) does not have this bit. Signed-off-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07iio:imu:mpu6050: Fixed segfault in Invensens MPU driver due to null dereferenceAtilla Filiz
commit b9b3a41893c3f1be67b5aacfa525969914bea0e9 upstream. The driver segfaults when the kernel boots with device tree as the platform data is then not present and the pointer is deferenced without checking it is not null. This patch introduces such a check avoiding the crash. Signed-off-by: Atilla Filiz <atilla.filiz@essensium.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07clk: tegra: Fix wrong value written to PLLE_AUXTuomas Tynkkynen
commit d2c834abe2b39a2d5a6c38ef44de87c97cbb34b4 upstream. The value written to PLLE_AUX was incorrect due to a wrong variable being used. Without this fix SATA does not work. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Tested-by: Mikko Perttunen <mperttunen@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Mike Turquette <mturquette@linaro.org> [mturquette@linaro.org: improved changelog] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07drm/radeon: check buffer relocation offsetLeo Liu
commit 695daf1a8e731a4b5b89de89a61f32a4d7ad7094 upstream. Signed-off-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07drm/radeon: use pflip irq on R600+ v2Christian König
commit f5d636d2a74b755879feec35e14a259de52ccc07 upstream. Testing the update pending bit directly after issuing an update is nonsense cause depending on the pixel clock the CRTC needs a bit of time to execute the flip even when we are in the VBLANK period. This is just a non invasive patch to solve the problem at hand, a more complete and cleaner solution should follow in the next merge window. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76564 v2: fix source IDs for CRTC2-6 Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2025-01-05 00:23:50 +0000