linux-stable.git/drivers, branch v3.18.6 Linux kernel stable tree xen/arm/arm64: introduce xen_arch_need_swiotlb 2015-02-06T06:36:10+00:00 Stefano Stabellini stefano.stabellini@eu.citrix.com 2014-11-21T11:07:39+00:00 a6df13631781815752638547a49222610929f89e commit a4dba130891271084344c12537731542ec77cb85 upstream. Introduce an arch specific function to find out whether a particular dma mapping operation needs to bounce on the swiotlb buffer. On ARM and ARM64, if the page involved is a foreign page and the device is not coherent, we need to bounce because at unmap time we cannot execute any required cache maintenance operations (we don't know how to find the pfn from the mfn). No change of behaviour for x86. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a4dba130891271084344c12537731542ec77cb85 upstream.

Introduce an arch specific function to find out whether a particular dma
mapping operation needs to bounce on the swiotlb buffer.

On ARM and ARM64, if the page involved is a foreign page and the device
is not coherent, we need to bounce because at unmap time we cannot
execute any required cache maintenance operations (we don't know how to
find the pfn from the mfn).

No change of behaviour for x86.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
clocksource: arch_timer: Only use the virtual counter (CNTVCT) on arm64 2015-02-06T06:36:09+00:00 Catalin Marinas catalin.marinas@arm.com 2014-12-10T11:02:09+00:00 b2f21d1b7bc80150f2b7d1fecae5f64c9ead26fa commit d6ad36913083d683aad4e02e53580c995f1a6ede upstream. Commit 0b46b8a718c6 (clocksource: arch_timer: Fix code to use physical timers when requested) introduces the use of physical counters in the ARM architected timer driver. However, he arm64 kernel uses CNTVCT in VDSO. When booting in EL2, the kernel switches to the physical timers to make things easier for KVM but it continues to use the virtual counter both in user and kernel. While in such scenario CNTVCT == CNTPCT (since CNTVOFF is initialised by the kernel to 0), we want to spot firmware bugs corrupting CNTVOFF early (which would affect CNTVCT). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Yingjoe Chen <yingjoe.chen@mediatek.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 0b46b8a718c6 ("clocksource: arch_timer: Fix code to use physical timers when requested") Cc: Ian Campbell <ijc@hellion.org.uk> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d6ad36913083d683aad4e02e53580c995f1a6ede upstream.

Commit 0b46b8a718c6 (clocksource: arch_timer: Fix code to use physical
timers when requested) introduces the use of physical counters in the
ARM architected timer driver. However, he arm64 kernel uses CNTVCT in
VDSO. When booting in EL2, the kernel switches to the physical timers to
make things easier for KVM but it continues to use the virtual counter
both in user and kernel. While in such scenario CNTVCT == CNTPCT (since
CNTVOFF is initialised by the kernel to 0), we want to spot firmware
bugs corrupting CNTVOFF early (which would affect CNTVCT).

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 0b46b8a718c6 ("clocksource: arch_timer: Fix code to use physical
timers when requested")
Cc: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
can: c_can: end pending transmission on network stop (ifdown) 2015-02-06T06:36:09+00:00 Viktor Babrian babrian.viktor@renyi.mta.hu 2015-01-18T19:01:40+00:00 793332a4439c431437b26ebcdef7833f46464d06 commit 7ffd7b4e169d619e66928fe5d997723f2c6f1056 upstream. Put controller into init mode in network stop to end pending transmissions. The issue is observed in cases when transmitted frame is not acked. Signed-off-by: Viktor Babrian <babrian.viktor@renyi.mta.hu> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7ffd7b4e169d619e66928fe5d997723f2c6f1056 upstream.

Put controller into init mode in network stop to end pending transmissions. The
issue is observed in cases when transmitted frame is not acked.

Signed-off-by: Viktor Babrian <babrian.viktor@renyi.mta.hu>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
HID: rmi: Check for additional ACM registers appended to F11 data report 2015-02-06T06:36:09+00:00 Andrew Duggan aduggan@synaptics.com 2014-12-08T23:01:59+00:00 427a5746b4215b154efb85b07781799b79f8958c commit 8414947a2018a98cf3adc975dc279f41ba30ab11 upstream. If a touchpad reports the F11 data40 register then this indicates that the touchpad reports additional ACM (Accidental Contact Mitigation) data after the F11 data in the HID attention report. These additional bytes shift the position of the F30 button data causing the driver to incorrectly report button state when this functionality is present. This patch accounts for the additional data in the report. Fixes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398533 Signed-off-by: Andrew Duggan <aduggan@synaptics.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Cc: Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8414947a2018a98cf3adc975dc279f41ba30ab11 upstream.

If a touchpad reports the F11 data40 register then this indicates that the touchpad reports
additional ACM (Accidental Contact Mitigation) data after the F11 data in the HID attention
report. These additional bytes shift the position of the F30 button data causing the driver
to incorrectly report button state when this functionality is present. This patch accounts
for the additional data in the report.

Fixes:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398533

Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: Joseph Salisbury <joseph.salisbury@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/i915: fix inconsistent brightness after resume 2015-02-06T06:36:08+00:00 Jeremiah Mahler jmmahler@gmail.com 2015-01-12T19:01:03+00:00 77ca136e76732ec03cc71c8b802c5fef8a70e0dd commit 13f3fbe827d09e3182023c8c54058cbf97aa146e upstream. commit 6dda730e55f412a6dfb181cae6784822ba463847 Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Jun 24 18:27:40 2014 +0300 drm/i915: respect the VBT minimum backlight brightness introduced a bug which resulted in inconsistent brightness levels on different machines. If a suspended was entered with the screen off some machines would resume with the screen at minimum brightness and others at maximum brightness. The following commands can be used to produce this behavior. xset dpms force off sleep 1 sudo systemctl suspend (resume ...) The root cause of this problem is a comparison which checks to see if the backlight level is zero when the panel is enabled. If it is zero, it is set to the maximum level. Unfortunately, not all machines have a minimum level of zero. On those machines the level is left at the minimum instead of begin set to the maximum. Fix the bug by updating the comparison to check for the minimum backlight level instead of zero. Also, expand the comparison for the possible case when the level is less than the minimum. Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness") Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 13f3fbe827d09e3182023c8c54058cbf97aa146e upstream.

commit 6dda730e55f412a6dfb181cae6784822ba463847
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Jun 24 18:27:40 2014 +0300

    drm/i915: respect the VBT minimum backlight brightness

introduced a bug which resulted in inconsistent brightness levels on
different machines. If a suspended was entered with the screen off some
machines would resume with the screen at minimum brightness and others
at maximum brightness.

The following commands can be used to produce this behavior.

  xset dpms force off
  sleep 1
  sudo systemctl suspend
  (resume ...)

The root cause of this problem is a comparison which checks to see if
the backlight level is zero when the panel is enabled.  If it is zero,
it is set to the maximum level.  Unfortunately, not all machines have a
minimum level of zero. On those machines the level is left at the
minimum instead of begin set to the maximum.

Fix the bug by updating the comparison to check for the minimum
backlight level instead of zero.  Also, expand the comparison for
the possible case when the level is less than the minimum.

Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness")
Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/i915: Init PPGTT before context enable 2015-02-06T06:36:08+00:00 David Woodhouse dwmw2@infradead.org 2015-01-20T17:21:42+00:00 50a466845fafb078ff44be9389ac767347ff8bc6 commit f48a01651b1758550c4d3ee65ec726dfa0658780 upstream. Commit 82460d972 ("drm/i915: Rework ppgtt init to no require an aliasing ppgtt") introduced a regression on Broadwell, triggering the following IOMMU fault at startup: vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem dmar: DRHD: handling fault status reg 2 dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 880000 DMAR:[fault reason 23] Unknown fbcon: inteldrmfb (fb0) is primary device Further commentary from Daniel: I sugggested this change to David after staring at the offending patch for a while. I have no idea and theory whatsoever why this would upset the gpu less than the other way round. But it seems to work. David promised to chase hw people a bit more to get a more meaningful answer. Wrt the comment that this deletes: I've done some digging and afaict loading context before ppgtt enable was once required before our recent restructuring of the context/ppgtt init code: Before that context sw setup (i.e. allocating the default context) and hw setup was smashed together. Also the setup of the default context was the bit that actually allocated the aliasing ppgtt structures. Which is the reason for the context before ppgtt depency. Or was, since with all the untangling there's no no real depency any more (functional, who knows what the hw is doing), so the comment is just stale. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f48a01651b1758550c4d3ee65ec726dfa0658780 upstream.

Commit 82460d972 ("drm/i915: Rework ppgtt init to no require an aliasing
ppgtt") introduced a regression on Broadwell, triggering the following
IOMMU fault at startup:

  vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
  dmar: DRHD: handling fault status reg 2
  dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 880000
  DMAR:[fault reason 23] Unknown
  fbcon: inteldrmfb (fb0) is primary device

Further commentary from Daniel:

I sugggested this change to David after staring at the offending patch
for a while. I have no idea and theory whatsoever why this would upset
the gpu less than the other way round. But it seems to work. David
promised to chase hw people a bit more to get a more meaningful answer.

Wrt the comment that this deletes: I've done some digging and afaict
loading context before ppgtt enable was once required before our recent
restructuring of the context/ppgtt init code: Before that context sw
setup (i.e. allocating the default context) and hw setup was smashed
together.  Also the setup of the default context was the bit that
actually allocated the aliasing ppgtt structures. Which is the reason
for the context before ppgtt depency.

Or was, since with all the untangling there's no no real depency any
more (functional, who knows what the hw is doing), so the comment is
just stale.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/i915: BDW Fix Halo PCI IDs marked as ULT. 2015-02-06T06:36:08+00:00 Rodrigo Vivi rodrigo.vivi@intel.com 2015-01-20T00:16:15+00:00 bcee607f44722b338e65f62ac5ff426894c704b8 commit 6b96d705f3cf435b0b8835b12c9742513c77fed6 upstream. BDW with PCI-IDs ended in "2" aren't ULT, but HALO. Let's fix it and at least allow VGA to work on this units. v2: forgot ammend and v1 doesn't compile Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220 Cc: Xion Zhang <xiong.y.zhang@intel.com> Cc: Guo Jinxian <jinxianx.guo@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6b96d705f3cf435b0b8835b12c9742513c77fed6 upstream.

BDW with PCI-IDs ended in "2" aren't ULT, but HALO.
Let's fix it and at least allow VGA to work on this units.

v2: forgot ammend and v1 doesn't compile

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220
Cc: Xion Zhang <xiong.y.zhang@intel.com>
Cc: Guo Jinxian <jinxianx.guo@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/i915: Only fence tiled region of object. 2015-02-06T06:36:08+00:00 Bob Paauwe bob.j.paauwe@intel.com 2014-12-18T17:51:26+00:00 817697b83f3c399018c7c6bc25be68c5453b14c8 commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream. When creating a fence for a tiled object, only fence the area that makes up the actual tiles. The object may be larger than the tiled area and if we allow those extra addresses to be fenced, they'll get converted to addresses beyond where the object is mapped. This opens up the possiblity of writes beyond the end of object. To prevent this, we adjust the size of the fence to only encompass the area that makes up the actual tiles. The extra space is considered un-tiled and now behaves as if it was a linear object. Testcase: igt/gem_tiled_fence_overflow Reported-by: Dan Hettena <danh@ghs.com> Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream.

When creating a fence for a tiled object, only fence the area that
makes up the actual tiles.  The object may be larger than the tiled
area and if we allow those extra addresses to be fenced, they'll
get converted to addresses beyond where the object is mapped. This
opens up the possiblity of writes beyond the end of object.

To prevent this, we adjust the size of the fence to only encompass
the area that makes up the actual tiles.  The extra space is considered
un-tiled and now behaves as if it was a linear object.

Testcase: igt/gem_tiled_fence_overflow
Reported-by: Dan Hettena <danh@ghs.com>
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm: fix fb-helper vs MST dangling connector ptrs (v2) 2015-02-06T06:36:08+00:00 Rob Clark robdclark@gmail.com 2015-01-26T15:11:08+00:00 e63fea163319d9784abc0c82aeaef451cc80116e commit 2148f18fdb45f31ca269a7787fbc24053cd42e70 upstream. VT switch back/forth from console to xserver (for example) has potential to go horribly wrong if a dynamic DP MST connector ends up in the saved modeset that is restored when switching back to fbcon. When removing a dynamic connector, don't forget to clean up the saved state. v1: original v2: null out set->fb if no more connectors to avoid making i915 cranky Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1184968 Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2148f18fdb45f31ca269a7787fbc24053cd42e70 upstream.

VT switch back/forth from console to xserver (for example) has potential
to go horribly wrong if a dynamic DP MST connector ends up in the saved
modeset that is restored when switching back to fbcon.

When removing a dynamic connector, don't forget to clean up the saved
state.

v1: original
v2: null out set->fb if no more connectors to avoid making i915 cranky

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1184968
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers: net: cpsw: discard dual emac default vlan configuration 2015-02-06T06:36:07+00:00 Mugunthan V N mugunthanvnm@ti.com 2015-01-22T09:49:22+00:00 f1d5aa46638effd121eeccf5fbffc65c55df9403 commit 02a54164c52ed6eca3089a0d402170fbf34d6cf5 upstream. In Dual EMAC, the default VLANs are used to segregate Rx packets between the ports, so adding the same default VLAN to the switch will affect the normal packet transfers. So returning error on addition of dual EMAC default VLANs. Even if EMAC 0 default port VLAN is added to EMAC 1, it will lead to break dual EMAC port separations. Fixes: d9ba8f9e6298 (driver: net: ethernet: cpsw: dual emac interface implementation) Reported-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 02a54164c52ed6eca3089a0d402170fbf34d6cf5 upstream.

In Dual EMAC, the default VLANs are used to segregate Rx packets between
the ports, so adding the same default VLAN to the switch will affect the
normal packet transfers. So returning error on addition of dual EMAC
default VLANs.

Even if EMAC 0 default port VLAN is added to EMAC 1, it will lead to
break dual EMAC port separations.

Fixes: d9ba8f9e6298 (driver: net: ethernet: cpsw: dual emac interface implementation)
Reported-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>