linux.git/drivers, branch v4.8.10

usb: gadget: f_fs: stop sleeping in ffs_func_eps_disable

2016-11-21T09:11:38+00:00

commit a9e6f83c2df199187a5248f824f31b6787ae23ae upstream.

ffs_func_eps_disable is called from atomic context so it cannot sleep
thus cannot grab a mutex.  Change the handling of epfile->read_buffer
to use non-sleeping synchronisation method.

Reported-by: Chen Yu 
Signed-off-by: Michał Nazarewicz 
Fixes: 9353afbbfa7b ("buffer data from ‘oversized’ OUT requests")
Tested-by: John Stultz 
Tested-by: Chen Yu 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: edit epfile->ep under lock

2016-11-21T09:11:38+00:00

commit 454915dde06a51133750c6745f0ba57361ba209d upstream.

epfile->ep is protected by ffs->eps_lock (not epfile->mutex) so clear it
while holding the spin lock.

Tested-by: John Stultz 
Tested-by: Chen Yu 
Signed-off-by: Michal Nazarewicz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

net: stmmac: Fix lack of link transition for fixed PHYs

2016-11-21T09:11:36+00:00

[ Upstream commit c51e424dc79e1428afc4d697cdb6a07f7af70cbf ]

Commit 52f95bbfcf72 ("stmmac: fix adjust link call in case of a switch
is attached") added some logic to avoid polling the fixed PHY and
therefore invoking the adjust_link callback more than once, since this
is a fixed PHY and link events won't be generated.

This works fine the first time, because we start with phydev->irq =
PHY_POLL, so we call adjust_link, then we set phydev->irq =
PHY_IGNORE_INTERRUPT and we stop polling the PHY.

Now, if we called ndo_close(), which calls both phy_stop() and does an
explicit netif_carrier_off(), we end up with a link down. Upon calling
ndo_open() again, despite starting the PHY state machine, we have
PHY_IGNORE_INTERRUPT set, and we generate no link event at all, so the
link is permanently down.

Fixes: 52f95bbfcf72 ("stmmac: fix adjust link call in case of a switch is attached")
Signed-off-by: Florian Fainelli 
Acked-by: Giuseppe Cavallaro 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bnx2: Wait for in-flight DMA to complete at probe stage

2016-11-21T09:11:36+00:00

[ Upstream commit 6df77862f63f389df3b1ad879738e04440d7385d ]

In-flight DMA from 1st kernel could continue going in kdump kernel.
New io-page table has been created before bnx2 does reset at open stage.
We have to wait for the in-flight DMA to complete to avoid it look up
into the newly created io-page table at probe stage.

Suggested-by: Michael Chan 
Signed-off-by: Baoquan He 
Acked-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Revert "bnx2: Reset device during driver initialization"

2016-11-21T09:11:36+00:00

[ Upstream commit 5d0d4b91bf627f14f95167b738d524156c9d440b ]

This reverts commit 3e1be7ad2d38c6bd6aeef96df9bd0a7822f4e51c.

When people build bnx2 driver into kernel, it will fail to detect
and load firmware because firmware is contained in initramfs and
initramfs has not been uncompressed yet during do_initcalls. So
revert commit 3e1be7a and work out a new way in the later patch.

Signed-off-by: Baoquan He 
Acked-by: Paul Menzel 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mlxsw: spectrum_router: Correctly dump neighbour activity

2016-11-21T09:11:36+00:00

[ Upstream commit 42cdb338f40a98e6558bae35456fe86b6e90e1ef ]

The device's neighbour table is periodically dumped in order to update
the kernel about active neighbours. A single dump session may span
multiple queries, until the response carries less records than requested
or when a record (can contain up to four neighbour entries) is not full.
Current code stops the session when the number of returned records is
zero, which can result in infinite loop in case of high packet rate.

Fix this by stopping the session according to the above logic.

Fixes: c723c735fa6b ("mlxsw: spectrum_router: Periodically update the kernel's neigh table")
Signed-off-by: Arkadi Sharshevsky 
Signed-off-by: Ido Schimmel 
Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mlxsw: spectrum: Fix refcount bug on span entries

2016-11-21T09:11:36+00:00

[ Upstream commit 2d644d4c7506646f9c4a2afceb7fd5f030bc0c9f ]

When binding port to a newly created span entry, its refcount is
initialized to zero even though it has a bound port. That leads
to unexpected behaviour when the user tries to delete that port
from the span entry.

Fix this by initializing the reference count to 1.

Also add a warning to put function.

Fixes: 763b4b70afcd ("mlxsw: spectrum: Add support in matchall mirror TC offloading")
Signed-off-by: Yotam Gigi 
Reviewed-by: Ido Schimmel 
Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bgmac: stop clearing DMA receive control register right after it is set

2016-11-21T09:11:34+00:00

[ Upstream commit fcdefccac976ee51dd6071832b842d8fb41c479c ]

Current bgmac code initializes some DMA settings in the receive control
register for some hardware and then immediately clears those settings.
Not clearing those settings results in ~420Mbps *improvement* in
throughput; this system can now receive frames at line-rate on Broadcom
5871x hardware compared to ~520Mbps today.  I also tested a few other
values but found there to be no discernible difference in CPU
utilization even if burst size and prefetching values are different.

On the hardware tested there was no need to keep the code that cleared
all but bits 16-17, but since there is a wide variety of hardware that
used this driver (I did not look at all hardware docs for hardware using
this IP block), I find it wise to move this call up and clear bits just
after reading the default value from the hardware rather than completely
removing it.

This is a good candidate for -stable >=3.14 since that is when the code
that was supposed to improve performance (but did not) was introduced.

Signed-off-by: Andy Gospodarek 
Fixes: 56ceecde1f29 ("bgmac: initialize the DMA controller of core...")
Cc: Hauke Mehrtens 
Acked-by: Hauke Mehrtens 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix mismatched INIT power domain disabling during suspend

2016-11-18T09:51:53+00:00

commit fd58753ead86ee289ea89fe26e1842f36e54b36c upstream.

Currently the display INIT power domain disabling/enabling happens in a
mismatched way in the suspend/resume_early hooks respectively. This can
leave display power wells incorrectly disabled in the resume hook if the
suspend sequence is aborted for some reason resulting in the
suspend/resume hooks getting called but the suspend_late/resume_early
hooks being skipped. In particular this change fixes "Unclaimed read
from register 0x1e1204" on BYT/BSW triggered from i915_drm_resume()->
intel_pps_unlock_regs_wa() when suspending with /sys/power/pm_test set
to devices.

Fixes: 85e90679335f ("drm/i915: disable power wells on suspend")
Cc: Ville Syrjälä 
Cc: David Weinehall 
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1476358446-11621-1-git-send-email-imre.deak@intel.com
(cherry picked from commit 4c494a5769cd0de92638b25960ba0158c36088a6)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix a vm_flush fence leak

2016-11-18T09:51:53+00:00

commit 2d7c17be00e0dce3bc1a092a2c277a9f86c69ca9 upstream.

Looks like .last_flush reference is left at teardown.
Leak reported by CONFIG_SLUB_DEBUG.

Fixes: 41d9eb2c5a2a ("drm/amdgpu: add a fence after the VM flush")
Reviewed-by: Chunming Zhou 
Reviewed-by: Christian König 
Signed-off-by: Grazvydas Ignotas 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman