summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2014-05-20drm/radeon: fix DCE83 check for mullinsAlex Deucher1-1/+2
Mullins is DCE83 just like Kabini. Set the proper number of endpoints on mullins. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2014-05-20drm/radeon: check VCE relocation buffer range v3Leo Liu2-31/+102
v2 (chk): fix image size storage v3 (chk): fix UV size calculation Signed-off-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2014-05-20drm/radeon: also try GART for CPU accessed buffersChristian König1-15/+23
Placing them exclusively into VRAM might not work all the time. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=78297 Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-05-20clk: new basic clk type for fractional dividerHeikki Krogerus2-0/+136
Fractional divider clocks are fairly common. This adds basic type for them. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mike Turquette <mturquette@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-20ACPI / PM: Export rest of the subsys PM callbacksHeikki Krogerus1-1/+4
No reason for excluding the remaining ones. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Rebased and exported the new acpi_subsys_complete() too.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-20ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspendRafael J. Wysocki2-7/+40
Rework the ACPI PM domain's PM callbacks to avoid resuming devices during system suspend (in order to modify their wakeup settings etc.) if that isn't necessary. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-20Merge branch 'pm-sleep' into acpi-pmRafael J. Wysocki3-36/+102
2014-05-20Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds1-2/+2
Pull MIPS fixes from Ralf Baechle: "MIPS fixes for various loose ends: - Fix workarounds for R4000 erratum. - Patch up DEC, Siemens-Nixdorf and Loongson hardware support. - Wire up renameat2 syscall. - Delete unused file - it was causing false warnings from maintenance scripts. - Revert a patch because it's functionality is now implemented twice which causes superfluous /proc/cpuinfo output. - Fix a microMIPS regression" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: mm: Fix broken microMIPS kernel regression. MIPS: Add new AUDIT_ARCH token for the N32 ABI on MIPS64 MIPS: Wire up renameat2 syscall. MIPS: inst.h: Rename BITFIELD_FIELD to __BITFIELD_FIELD. MIPS: Remove file missed when removing rm9k support a while ago. MIPS/loongson2_cpufreq: Fix CPU clock rate setting MIPS: Loongson: No need to select GENERIC_HARDIRQS_NO__DO_IRQ MIPS: csum_partial.S CPU_DADDI_WORKAROUNDS bug fix MIPS: __strncpy_from_user_asm CPU_DADDI_WORKAROUNDS bug fix MIPS: __delay CPU_DADDI_WORKAROUNDS bug fix MIPS: DEC/SNI: O32 wrapper stack switching fixes MIPS: DEC: Bus error handler <asm/cpu-type.h> fixes MAINTAINERS: TURBOchannel: Update entry Revert "MIPS: MT: proc: Add support for printing VPE and TC ids"
2014-05-20drm/gf119-/disp: fix nasty bug which can clobber SOR0's clock setupBen Skeggs1-1/+1
Fixes a LVDS bleed issue on Lenovo W530 that can occur under a number of circumstances. Cc: <stable@vger.kernel.org > # v3.9+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-05-20drm/nvd9/therm: handle another kind of PWM fanMartin Peres1-0/+1
Signed-off-by: Martin Peres <martin.peres@free.fr> Tested-by: SaveTheRobots <john.rowley08@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-05-20Merge tag 'drm-intel-fixes-2014-05-16' of ↵Dave Airlie7-29/+141
git://anongit.freedesktop.org/drm-intel into drm-fixes Intel fixes for regressions, black screens and hangs, for 3.15. * tag 'drm-intel-fixes-2014-05-16' of git://anongit.freedesktop.org/drm-intel: drm/i915: Increase WM memory latency values on SNB drm/i915: restore backlight precision when converting from ACPI drm/i915: Use the first mode if there is no preferred mode in the EDID drm/i915/dp: force eDP lane count to max available lanes on BDW drm/i915/vlv: reset VLV media force wake request register drm/i915/SDVO: For sysfs link put directory and target in correct order drm/i915: use lane count and link rate from VBT as minimums for eDP drm/i915: clean up VBT eDP link param decoding drm/i915: consider the source max DP lane count too
2014-05-19ahci: imx: PLL clock needs 100us to settle downShawn Guo1-0/+2
The commit e783c51 (ahci: imx: software workaround for phy reset issue in resume) calls imx_sata_phy_reset() to reset phy immediately after SATA MPLL is enabled. It seems working fine mostly, but fails in some case as below. ... ahci-imx 2200000.sata: failed to reset phy: -110 ahci-imx: probe of 2200000.sata failed with error -110 After talking to the designer, we learnt that when enabling i.MX6Q SATA MPLL, we need to wait 100us for it to settle down for safety. Add this required delay to fix above failure. Signed-off-by: Shawn Guo <shawn.guo@freescale.com> Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2014-05-19PCI: Wrong register used to check pending trafficGavin Shan1-2/+3
The incorrect register offset is passed to pci_wait_for_pending(), which is caused by commit 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())"). Fixes: 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction()) Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alex Williamson <alex.williamson@gmail.com> CC: stable@vger.kernel.org # v3.14+
2014-05-19can: c_can: remove obsolete STRICT_FRAME_ORDERING Kconfig optionOliver Hartkopp2-43/+0
In 2b9aecdce2 ("can: c_can: Disable rx split as workaround") a new Kconfig option was introduced as a workaround. The tests performed by Alexander Stein confirmed this option to be obsolete with all the other cleanups and fixes that had been discussed that time: http://marc.info/?l=linux-can&m=139746476821294&w=2 Both (author and tester) agreed to remove this Kconfig option again: http://marc.info/?l=linux-can&m=139883820714229&w=2 As some more cleanups took place since then a simple revert is not possible. This patch removes the entire option as it would behave when disabled. Further beautification’s can be done later. Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-05-18bnx2x: Convert return 0 to return rcJoe Perches2-2/+2
These "return 0;" uses seem wrong as there are rc variables where error return values are set but unused. Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Dmitry Kravkov <Dmitry.Kravkov@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-17target: fix memory leak on XCOPYMikulas Patocka1-1/+1
On each processed XCOPY command, two "kmalloc-512" memory objects are leaked. These represent two allocations of struct xcopy_pt_cmd in target_core_xcopy.c. The reason for the memory leak is that the cmd_kref field is not initialized (thus, it is zero because the allocations were done with kzalloc). When we decrement zero kref in target_put_sess_cmd, the result is not zero, thus target_release_cmd_kref is not called. This patch fixes the bug by moving kref initialization from target_get_sess_cmd to transport_init_se_cmd (this function is called from target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be easily verified that all code that calls target_get_sess_cmd also calls transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce any new problems. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org # 3.12+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2014-05-16bonding: Fix alb mode to only use first level vlans.Vlad Yasevich1-1/+1
ALB/TLB learning packets use all vlans configured on top of the bond. This ends up being incorrect if we have a stack of vlans on top of the bond. ALB/TLB should only use first level/outer most vlans in its announcements. Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16bonding: Fix stacked device detection in arp monitoringVlad Yasevich2-69/+66
Prior to commit fbd929f2dce460456807a51e18d623db3db9f077 bonding: support QinQ for bond arp interval the arp monitoring code allowed for proper detection of devices stacked on top of vlans. Since the above commit, the code can still detect a device stacked on top of single vlan, but not a device stacked on top of Q-in-Q configuration. The search will only set the inner vlan tag if the route device is the vlan device. However, this is not always the case, as it is possible to extend the stacked configuration. With this patch it is possible to provision devices on top Q-in-Q vlan configuration that should be used as a source of ARP monitoring information. For example: ip link add link bond0 vlan10 type vlan proto 802.1q id 10 ip link add link vlan10 vlan100 type vlan proto 802.1q id 100 ip link add link vlan100 type macvlan Note: This patch limites the number of stacked VLANs to 2, just like before. The original, however had another issue in that if we had more then 2 levels of VLANs, we would end up generating incorrectly tagged traffic. This is no longer possible. Fixes: fbd929f2dce460456807a51e18d623db3db9f077 (bonding: support QinQ for bond arp interval) CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@redhat.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: Ding Tianhong <dingtianhong@huawei.com> CC: Patric McHardy <kaber@trash.net> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16random: fix BUG_ON caused by accounting simplificationTheodore Ts'o1-2/+5
Commit ee1de406ba6eb1 ("random: simplify accounting logic") simplified things too much, in that it allows the following to trigger an overflow that results in a BUG_ON crash: dd if=/dev/urandom of=/dev/zero bs=67108707 count=1 Thanks to Peter Zihlstra for discovering the crash, and Hannes Frederic for analyizing the root cause. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Reported-by: Peter Zijlstra <peterz@infradead.org> Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: Greg Price <price@mit.edu>
2014-05-16macvlan: Fix lockdep warnings with stacked macvlan devicesVlad Yasevich1-2/+10
Macvlan devices try to avoid stacking, but that's not always successfull or even desired. As an example, the following configuration is perefectly legal and valid: eth0 <--- macvlan0 <---- vlan0.10 <--- macvlan1 However, this configuration produces the following lockdep trace: [ 115.620418] ====================================================== [ 115.620477] [ INFO: possible circular locking dependency detected ] [ 115.620516] 3.15.0-rc1+ #24 Not tainted [ 115.620540] ------------------------------------------------------- [ 115.620577] ip/1704 is trying to acquire lock: [ 115.620604] (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80 [ 115.620686] but task is already holding lock: [ 115.620723] (&macvlan_netdev_addr_lock_key){+.....}, at: [<ffffffff815da5be>] dev_set_rx_mode+0x1e/0x40 [ 115.620795] which lock already depends on the new lock. [ 115.620853] the existing dependency chain (in reverse order) is: [ 115.620894] -> #1 (&macvlan_netdev_addr_lock_key){+.....}: [ 115.620935] [<ffffffff810d57f2>] lock_acquire+0xa2/0x130 [ 115.620974] [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50 [ 115.621019] [<ffffffffa07296c3>] vlan_dev_set_rx_mode+0x53/0x110 [8021q] [ 115.621066] [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0 [ 115.621105] [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40 [ 115.621143] [<ffffffff815da6be>] __dev_open+0xde/0x140 [ 115.621174] [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170 [ 115.621174] [<ffffffff815daaa9>] dev_change_flags+0x29/0x60 [ 115.621174] [<ffffffff815e7f11>] do_setlink+0x321/0x9a0 [ 115.621174] [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730 [ 115.621174] [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250 [ 115.621174] [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0 [ 115.621174] [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40 [ 115.621174] [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0 [ 115.621174] [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740 [ 115.621174] [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0 [ 115.621174] [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380 [ 115.621174] [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80 [ 115.621174] [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20 [ 115.621174] [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b [ 115.621174] -> #0 (&vlan_netdev_addr_lock_key/1){+.....}: [ 115.621174] [<ffffffff810d4d43>] __lock_acquire+0x1773/0x1a60 [ 115.621174] [<ffffffff810d57f2>] lock_acquire+0xa2/0x130 [ 115.621174] [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50 [ 115.621174] [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80 [ 115.621174] [<ffffffffa0696d2a>] macvlan_set_mac_lists+0xca/0x110 [macvlan] [ 115.621174] [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0 [ 115.621174] [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40 [ 115.621174] [<ffffffff815da6be>] __dev_open+0xde/0x140 [ 115.621174] [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170 [ 115.621174] [<ffffffff815daaa9>] dev_change_flags+0x29/0x60 [ 115.621174] [<ffffffff815e7f11>] do_setlink+0x321/0x9a0 [ 115.621174] [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730 [ 115.621174] [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250 [ 115.621174] [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0 [ 115.621174] [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40 [ 115.621174] [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0 [ 115.621174] [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740 [ 115.621174] [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0 [ 115.621174] [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380 [ 115.621174] [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80 [ 115.621174] [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20 [ 115.621174] [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b [ 115.621174] other info that might help us debug this: [ 115.621174] Possible unsafe locking scenario: [ 115.621174] CPU0 CPU1 [ 115.621174] ---- ---- [ 115.621174] lock(&macvlan_netdev_addr_lock_key); [ 115.621174] lock(&vlan_netdev_addr_lock_key/1); [ 115.621174] lock(&macvlan_netdev_addr_lock_key); [ 115.621174] lock(&vlan_netdev_addr_lock_key/1); [ 115.621174] *** DEADLOCK *** [ 115.621174] 2 locks held by ip/1704: [ 115.621174] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff815e6dbb>] rtnetlink_rcv+0x1b/0x40 [ 115.621174] #1: (&macvlan_netdev_addr_lock_key){+.....}, at: [<ffffffff815da5be>] dev_set_rx_mode+0x1e/0x40 [ 115.621174] stack backtrace: [ 115.621174] CPU: 3 PID: 1704 Comm: ip Not tainted 3.15.0-rc1+ #24 [ 115.621174] Hardware name: Hewlett-Packard HP xw8400 Workstation/0A08h, BIOS 786D5 v02.38 10/25/2010 [ 115.621174] ffffffff82339ae0 ffff880465f79568 ffffffff816ee20c ffffffff82339ae0 [ 115.621174] ffff880465f795a8 ffffffff816e9e1b ffff880465f79600 ffff880465b019c8 [ 115.621174] 0000000000000001 0000000000000002 ffff880465b019c8 ffff880465b01230 [ 115.621174] Call Trace: [ 115.621174] [<ffffffff816ee20c>] dump_stack+0x4d/0x66 [ 115.621174] [<ffffffff816e9e1b>] print_circular_bug+0x200/0x20e [ 115.621174] [<ffffffff810d4d43>] __lock_acquire+0x1773/0x1a60 [ 115.621174] [<ffffffff810d3172>] ? trace_hardirqs_on_caller+0xb2/0x1d0 [ 115.621174] [<ffffffff810d57f2>] lock_acquire+0xa2/0x130 [ 115.621174] [<ffffffff815df49c>] ? dev_uc_sync+0x3c/0x80 [ 115.621174] [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50 [ 115.621174] [<ffffffff815df49c>] ? dev_uc_sync+0x3c/0x80 [ 115.621174] [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80 [ 115.621174] [<ffffffffa0696d2a>] macvlan_set_mac_lists+0xca/0x110 [macvlan] [ 115.621174] [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0 [ 115.621174] [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40 [ 115.621174] [<ffffffff815da6be>] __dev_open+0xde/0x140 [ 115.621174] [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170 [ 115.621174] [<ffffffff815daaa9>] dev_change_flags+0x29/0x60 [ 115.621174] [<ffffffff811e1db1>] ? mem_cgroup_bad_page_check+0x21/0x30 [ 115.621174] [<ffffffff815e7f11>] do_setlink+0x321/0x9a0 [ 115.621174] [<ffffffff810d394c>] ? __lock_acquire+0x37c/0x1a60 [ 115.621174] [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730 [ 115.621174] [<ffffffff815ea169>] ? rtnl_newlink+0xe9/0x730 [ 115.621174] [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250 [ 115.621174] [<ffffffff810d329d>] ? trace_hardirqs_on+0xd/0x10 [ 115.621174] [<ffffffff815e6dbb>] ? rtnetlink_rcv+0x1b/0x40 [ 115.621174] [<ffffffff815e6de0>] ? rtnetlink_rcv+0x40/0x40 [ 115.621174] [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0 [ 115.621174] [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40 [ 115.621174] [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0 [ 115.621174] [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740 [ 115.621174] [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0 [ 115.621174] [<ffffffff8119d4af>] ? might_fault+0x5f/0xb0 [ 115.621174] [<ffffffff8119d4f8>] ? might_fault+0xa8/0xb0 [ 115.621174] [<ffffffff8119d4af>] ? might_fault+0x5f/0xb0 [ 115.621174] [<ffffffff815cb51e>] ? verify_iovec+0x5e/0xe0 [ 115.621174] [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380 [ 115.621174] [<ffffffff816faa0d>] ? __do_page_fault+0x11d/0x570 [ 115.621174] [<ffffffff810cfe9f>] ? up_read+0x1f/0x40 [ 115.621174] [<ffffffff816fab04>] ? __do_page_fault+0x214/0x570 [ 115.621174] [<ffffffff8120a10b>] ? mntput_no_expire+0x6b/0x1c0 [ 115.621174] [<ffffffff8120a0b7>] ? mntput_no_expire+0x17/0x1c0 [ 115.621174] [<ffffffff8120a284>] ? mntput+0x24/0x40 [ 115.621174] [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80 [ 115.621174] [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20 [ 115.621174] [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b Fix this by correctly providing macvlan lockdep class. Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16clk: tegra: Fix wrong value written to PLLE_AUXTuomas Tynkkynen1-1/+1
The value written to PLLE_AUX was incorrect due to a wrong variable being used. Without this fix SATA does not work. Cc: stable@vger.kernel.org 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]
2014-05-16staging: rtl8723au: Do not reset wdev->iftype in netdev_close()Jes Sorensen1-2/+0
wdev->ifdev should be set by .change_virtual_intf(). This solves the problem of WARN() messages on module unload. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-16Merge branch 'acpi-video'Rafael J. Wysocki1-8/+0
* acpi-video: ACPI / video: Revert native brightness quirk for ThinkPad T530
2014-05-16PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarilyRafael J. Wysocki1-15/+51
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to resume all runtime-suspended devices during system suspend, mostly because those devices may need to be reprogrammed due to different wakeup settings for system sleep and for runtime PM. For some devices, though, it's OK to remain in runtime suspend throughout a complete system suspend/resume cycle (if the device was in runtime suspend at the start of the cycle). We would like to do this whenever possible, to avoid the overhead of extra power-up and power-down events. However, problems may arise because the device's descendants may require it to be at full power at various points during the cycle. Therefore the most straightforward way to do this safely is if the device and all its descendants can remain runtime suspended until the complete stage of system resume. To this end, introduce a new device PM flag, power.direct_complete and modify the PM core to use that flag as follows. If the ->prepare() callback of a device returns a positive number, the PM core will regard that as an indication that it may leave the device runtime-suspended. It will then check if the system power transition in progress is a suspend (and not hibernation in particular) and if the device is, indeed, runtime-suspended. In that case, the PM core will set the device's power.direct_complete flag. Otherwise it will clear power.direct_complete for the device and it also will later clear it for the device's parent (if there's one). Next, the PM core will not invoke the ->suspend() ->suspend_late(), ->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume() callbacks for all devices having power.direct_complete set. It will invoke their ->complete() callbacks, however, and those callbacks are then responsible for resuming the devices as appropriate, if necessary. For example, in some cases they may need to queue up runtime resume requests for the devices using pm_request_resume(). Changelog partly based on an Alan Stern's description of the idea (http://marc.info/?l=linux-pm&m=139940466625569&w=2). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16xen-netback: fix race between napi_complete() and interrupt handlerDavid Vrabel3-30/+6
When the NAPI budget was not all used, xenvif_poll() would call napi_complete() /after/ enabling the interrupt. This resulted in a race between the napi_complete() and the napi_schedule() in the interrupt handler. The use of local_irq_save/restore() avoided by race iff the handler is running on the same CPU but not if it was running on a different CPU. Fix this properly by calling napi_complete() before reenabling interrupts (in the xenvif_napi_schedule_or_enable_irq() call). Signed-off-by: David Vrabel <david.vrabel@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16ACPI / video: Revert native brightness quirk for ThinkPad T530Hans de Goede1-8/+0
Seems it helps some users, but causes issues for other users: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 So lets drop it for now until we've figured out a better fix. Fixes: 43d949024425 (ACPI / video: Add use_native_backlight quirks for more systems) References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-16Merge branch 'for-davem' of ↵David S. Miller10-58/+61
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless John W. Linville says: ==================== pull request: wireless 2014-05-15 Please pull this batch of fixes for the 3.15 stream... For the mac80211 bits, Johannes says: "One fix is to get better VHT performance and the other fixes tracing garbage or other potential issues with the interface name tracing." And... "This has a fix from Emmanuel for a problem I failed to fix - when association is in progress then it needs to be cancelled while suspending (I had fixed the same for authentication). Also included a fix from myself for a userspace API problem that hit the iw tool and a fix to the remain-on-channel framework." For the iwlwifi bits, Emmanuel says: "Alex fixes the scan by disabling the fragmented scan. David prevents scan offload while associated, the firmware seems not to like it. I fix a stupid bug I made in BT Coex, and fix a bad #ifdef clause in rate scaling. Along with that there is a fix for a NULL pointer exception that can happen if we load the driver and our ISR gets called because the interrupt line is shared. The fix has been tested by the reporter." And... "We have here a fix from David Spinadel that makes a previous fix more complete, and an off-by-one issue fixed by Eliad in the same area. I fix the monitor that broke on the way." Beyond that... Daniel Kim's one-liner fixes a brcmfmac regression caused by a typo in an earlier commit.. Rajkumar Manoharan fixes an ath9k oops reported by David Herrmann. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16net: phy: resume phydev when going to RESUMINGZhangfei Gao1-7/+9
With commit be9dad1f9f26604fb ("net: phy: suspend phydev when going to HALTED"), an unused PHY device will be put in a low-power mode using BMCR_PDOWN. Some Ethernet drivers might be calling phy_start() and phy_stop() from ndo_open and ndo_close() respectively, while calling phy_connect() and phy_disconnect() from probe and remove. In such a case, the PHY will be powered down during the phy_stop() call, but will fail to be powered up in phy_start(). This patch fixes this scenario. Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16IB/mlx4: Invoke UPDATE_QP for proxy QP1 on MAC changesMatan Barak3-3/+75
When we receive a netdev event indicating a netdev change and/or a netdev address change, we must change the MAC index used by the proxy QP1 (in the QP context), otherwise RoCE CM packets sent by the VF will not carry the same source MAC address as the non-CM packets. We use the UPDATE_QP command to perform this change. In order to avoid modifying a QP context based on netdev event, while the driver attempts to destroy this QP (e.g either the mlx4_ib or ib_mad modules are unloaded), we use mutex locking in both flows. Since the relevant mlx4 proxy GSI QP is created indirectly by the mad module when they create their GSI QP, the mlx4 didn't need to keep track on that QP prior to this change. Now, when QP modifications are needed to this QP from within the driver, we added refernece to it. Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16net/mlx4_core: Add UPDATE_QP SRIOV wrapper supportMatan Barak4-2/+97
This patch adds UPDATE_QP SRIOV wrapper support. The mechanism is a general one, but currently only source MAC index changes are allowed for VFs. Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16staging: rtl8723au: Use correct pipe type for USB interruptsJes Sorensen1-1/+1
Use a correct pipe type when filling un interrupt urbs. This should finally take care of the WARN() messages on the console when USB urbs are submitted. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-16ACPI / platform: add IDs for Broadcom Bluetooth and GPS chipsHeikki Krogerus1-0/+4
These IDs are used on Baytrail boards such as Lenovo Miix 2 and Asus Transformer Book T100TA. On lenovo Miix 2 8", BCM4752 is called LNV4752. All the rest of the IDs are for Broadcom BCM43241 module with the ID referring to different revision number. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-16ACPI / PM: Hold ACPI scan lock over the "freeze" sleep stateRafael J. Wysocki1-0/+18
The "freeze" sleep state suffers from the same issue that was addressed by commit ad07277e82de (ACPI / PM: Hold acpi_scan_lock over system PM transitions) for ACPI sleep states, that is, things break if ->remove() is called for devices whose system resume callbacks haven't been executed yet. It also can be addressed in the same way, by holding the ACPI scan lock over the "freeze" sleep state and PM transitions to and from that state, but ->begin() and ->end() platform operations for the "freeze" sleep state are needed for this purpose. This change has been tested on Acer Aspire S5 with Thunderbolt. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-15bonding: fix out of range parameters for bond_intmax_tblNikolay Aleksandrov1-0/+1
I've missed to add a NULL entry to the bond_intmax_tbl when I introduced it with the conversion of arp_interval so add it now. CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> Fixes: 7bdb04ed0dbf ("bonding: convert arp_interval to use the new option API") Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com> Acked-by: Veaceslav Falico <vfalico@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-15xen-netback: Fix grant ref resolution in RX pathZoltan Kiss1-18/+80
The original series for reintroducing grant mapping for netback had a patch [1] to handle receiving of packets from an another VIF. Grant copy on the receiving side needs the grant ref of the page to set up the op. The original patch assumed (wrongly) that the frags array haven't changed. In the case reported by Sander, the sending guest sent a packet where the linear buffer and the first frag were under PKT_PROT_LEN (=128) bytes. xenvif_tx_submit() then pulled up the linear area to 128 bytes, and ditched the first frag. The receiving side had an off-by-one problem when gathered the grant refs. This patch fixes that by checking whether the actual frag's page pointer is the same as the page in the original frag list. It can handle any kind of changes on the original frags array, like: - removing granted frags from the array at any point - adding local pages to the frags list anywhere - reordering the frags It's optimized to the most common case, when there is 1:1 relation between the frags and the list, plus works optimal when frags are removed from the end or the beginning. [1]: 3e2234: xen-netback: Handle foreign mapped pages on the guest RX path Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-15net: phy: Don't call phy_resume if phy_init_hw failedGuenter Roeck1-2/+2
After the call to phy_init_hw failed in phy_attach_direct, phy_detach is called to detach the phy device from its network device. If the attached driver is a generic phy driver, this also detaches the driver. Subsequently phy_resume is called, which assumes without checking that a driver is attached to the device. This will result in a crash such as Unable to handle kernel paging request for data at address 0xffffffffffffff90 Faulting instruction address: 0xc0000000003a0e18 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0000000003a0e18] .phy_attach_direct+0x68/0x17c LR [c0000000003a0e6c] .phy_attach_direct+0xbc/0x17c Call Trace: [c0000003fc0475d0] [c0000000003a0e6c] .phy_attach_direct+0xbc/0x17c (unreliable) [c0000003fc047670] [c0000000003a0ff8] .phy_connect_direct+0x28/0x98 [c0000003fc047700] [c0000000003f0074] .of_phy_connect+0x4c/0xa4 Only call phy_resume if phy_init_hw was successful. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-15target: Don't allow setting WC emulation if device doesn't supportAndy Grover1-4/+4
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> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2014-05-15iscsi-target: Disable Immediate + Unsolicited Data with ISER ProtectionNicholas Bellinger1-1/+26
This patch explicitly disables Immediate + Unsolicited Data for ISER connections during login in iscsi_login_zero_tsih_s2() when protection has been enabled for the session by the underlying hardware. This is currently required because protection / signature memory regions (MRs) expect T10 PI to occur on RDMA READs + RDMA WRITEs transfers, and not on a immediate data payload associated with ISCSI_OP_SCSI_CMD, or unsolicited data-out associated with a ISCSI_OP_SCSI_DATA_OUT. v2 changes: - Add TARGET_PROT_DOUT_INSERT check (Sagi) - Add pr_debug noisemaker (Sagi) - Add goto to avoid early return from MRDSL check (nab) Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2014-05-15tcm_fc: Fix free-after-use regression in ft_free_cmdNicholas Bellinger1-4/+4
This patch fixes a free-after-use regression in ft_free_cmd(), where ft_sess_put() is called with cmd->sess after percpu_ida_free() has already released the tag. Fix this bug by saving the ft_sess pointer ahead of percpu_ida_free(), and pass it directly to ft_sess_put(). The regression was originally introduced in v3.13-rc1 commit: commit 5f544cfac956971099e906f94568bc3fd1a7108a Author: Nicholas Bellinger <nab@daterainc.com> Date: Mon Sep 23 12:12:42 2013 -0700 tcm_fc: Convert to per-cpu command map pre-allocation of ft_cmd Reported-by: Jun Wu <jwu@stormojo.com> Cc: Mark Rustad <mark.d.rustad@intel.com> Cc: Robert Love <robert.w.love@intel.com> Cc: <stable@vger.kernel.org> #3.13+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2014-05-15iscsi-target: Change BUG_ON to REJECT in iscsit_process_nop_outNicholas Bellinger1-1/+3
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> Cc: stable@vger.kernel.org # 3.11+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2014-05-15Target/iscsi,iser: Avoid accepting transport connections during stop stageSagi Grimberg4-1/+13
When the target is in stop stage, iSER transport initiates RDMA disconnects. The iSER initiator may wish to establish a new connection over the still existing network portal. In this case iSER transport should not accept and resume new RDMA connections. In order to learn that, iscsi_np is added with enabled flag so the iSER transport can check when deciding weather to accept and resume a new connection request. The iscsi_np is enabled after successful transport setup, and disabled before iscsi_np login threads are cleaned up. Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2014-05-15Target/iser: Fix iscsit_accept_np and rdma_cm racy flowSagi Grimberg2-20/+7
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> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2014-05-15Target/iser: Fix wrong connection requests list additionSagi Grimberg1-1/+1
Should be adding list_add_tail($new, $head) and not the other way around. Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2014-05-15target: Allow non-supporting backends to set pi_prot_type to 0Andy Grover1-0/+4
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> Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2014-05-15Altera TSE: Disable Multicast filtering to workaround problemVince Bridgers1-0/+5
This patch disables multicast hash filtering if present in the hardware and uses promiscuous mode instead until the problem with multicast filtering has been debugged, integrated and tested. Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-15Altera TSE: Fix sparse errors and warningsVince Bridgers10-275/+367
This patch fixes the many sparse errors and warnings contained in the initial submission of the Altera Triple Speed Ethernet driver, and a few minor cppcheck warnings. Changes are tested on ARM and NIOS2 example designs, and compile tested against multiple architectures. Typical issues addressed were as follows: altera_tse_ethtool.c:136:19: warning: incorrect type in argument 1 (different address spaces) altera_tse_ethtool.c:136:19: expected void const volatile [noderef] <asn:2>*addr altera_tse_ethtool.c:136:19: got unsigned int *<noident> ... altera_sgdma.c:129:31: warning: cast removes address space of expression Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-15PCI: shpchp: Check bridge's secondary (not primary) bus speedMarcel Apfelbaum1-2/+2
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> CC: stable@vger.kernel.org # v2.6.34+
2014-05-15Merge branch 'master' of ↵John W. Linville10-58/+61
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
2014-05-15Merge branch 'pm-cpufreq'Rafael J. Wysocki1-18/+16
* pm-cpufreq: intel_pstate: remove setting P state to MAX on init intel_pstate: Set turbo VID for BayTrail
2014-05-15Merge branches 'acpi-video' and 'acpi-blacklist'Rafael J. Wysocki2-3/+40
* acpi-video: ACPI / video: correct DMI tag for Dell Inspiron 7520 ACPI / video: Add use_native_backlight quirks for more systems * acpi-blacklist: ACPI / blacklist: Add dmi_enable_osi_linux quirk for Asus EEE PC 1015PX ACPI: blacklist win8 OSI for Dell Inspiron 7737
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 10:59:09 +0000