Merge branch 'connectivity-next' of git://git.ti.com/~nsekhar/ti-linux-kernel/nsekhar-ti-linux-kernel into ti-linux-4.19.y-next

TI-Feature: connectivity_next
TI-Tree: git://git.ti.com/~nsekhar/ti-linux-kernel/nsekhar-ti-linux-kernel.git
TI-Branch: connectivity-next

* 'connectivity-next' of git://git.ti.com/~nsekhar/ti-linux-kernel/nsekhar-ti-linux-kernel:
  arm64: dts: ti: k3-am654-base-board: Enable ECAP PWM
  arm64: dts: ti: k3-am65-main: Add ECAP PWM node
  pwm: Enable TI ECAP driver for ARCH_K3
  dt-bindings: pwm: tiecap: Add TI AM654 SoC specific compatible
  dt-bindings: i2c: omap: Add new compatible for AM654 SoCs
  mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929)
  dt-bindings: sdhci-omap: Add note for cpu_thermal
  mmc: sdhci-omap: Add platform specific reset callback
  mmc: sdhci-omap: Remove redundant structure assignments
  mmc: sdhci-omap: Fix DCRC error handling during tuning

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merge branch 'platform-ti-linux-4.19.y-next' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.19.y-next

TI-Feature: platform_next
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.19.y-next

* 'platform-ti-linux-4.19.y-next' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  clk: keystone: sci-clk: add support from parsing clock info from DT
  dt-bindings: clock: ti,sci-clk: Add support for parsing clock info from DT
  soc: ti: Add TI_MESSAGE_MANAGER to default K3 AM65x SoC options

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

arm64: dts: ti: k3-am654-base-board: Enable ECAP PWM

commit e577d79424c07af63d0f19817a425bf4ccf0ec81 upstream.

Enable ECAP PWM which is used for LCD backlight.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

arm64: dts: ti: k3-am65-main: Add ECAP PWM node

commit 07c663b0ee576a33c29f211d2e23484a9aa5ff30 upstream.

Add DT entry for ECAP0 PWM node present in main domain

Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

pwm: Enable TI ECAP driver for ARCH_K3

commit 6f37709fb0a61f09ca96348044c5bb13e333e518 upstream

K3 devices have the same ECAP IP as OMAP SoCs. Enable driver to be built
for K3 devices. Also, drop reference to AM33xx in help text, as IP is
found on multiple TI SoCs.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

dt-bindings: pwm: tiecap: Add TI AM654 SoC specific compatible

commit 3c413e7e39224d171ef697277cd4629b59103101 upstream.

Add a new compatible string "ti,am654-ecap" to support PWM ECAP IP of
TI AM654 SoC.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

dt-bindings: i2c: omap: Add new compatible for AM654 SoCs

commit ab214c48387aaaadcf8246b4b00d8b78286fde1b upstream.

AM654 SoCs have same I2C IP as OMAP SoCs. Add new compatible to
handle AM654 SoCs. While at that reformat the existing compatible list
for older SoCs to list one valid compatible per line.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929)

commit 961de0a856e3a30c0238d1269c0b17f9b179b6c3 upstream.

Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions
(SPRZ426D - November 2014 - Revised February 2018 [1]) mentions
unexpected tuning pattern errors. A small failure band may be present
in the tuning range which may be missed by the current algorithm.
Furthermore, the failure bands vary with temperature leading to
different optimum tuning values for different temperatures.

As suggested in the related Application Report (SPRACA9B - October 2017
- Revised July 2018 [2]), tuning should be done in two stages.
In stage 1, assign the optimum ratio in the maximum pass window for the
current temperature. In stage 2, if the chosen value is close to the
small failure band, move away from it in the appropriate direction.

References:
[1] http://www.ti.com/lit/pdf/sprz426
[2] http://www.ti.com/lit/pdf/SPRACA9

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

dt-bindings: sdhci-omap: Add note for cpu_thermal

commit 58fe8bbacd285af44831f68da1d2d50f0e2fc9a9 upstream.

The driver fetches a thermal zone using the string "cpu_thermal" for
tuning operation. Add a note for the same.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

mmc: sdhci-omap: Add platform specific reset callback

commit 5b0d62108b468b13410533c0ceea3821942bf592 upstream.

The TRM (SPRUIC2C - January 2017 - Revised May 2018 [1]) forbids
assertion of data reset while tuning is happening. Implement a
platform specific callback that takes care of this condition.

[1] http://www.ti.com/lit/pdf/spruic2 Section 25.5.1.2.4

Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

mmc: sdhci-omap: Remove redundant structure assignments

commit 52b5f5cfa2f736f3e478b65490736b62412dc11c upstream.

The sdhci_execute_tuning() function has assignment of
private pointers multiple times. Remove the redundant assignment.

Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

mmc: sdhci-omap: Fix DCRC error handling during tuning

commit db2039fcfd5754d15986340152e4503737f68f8d upstream.

Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
disabled DCRC interrupts during tuning. This write to the interrupt
enable register gets overwritten in sdhci_prepare_data() and the
interrupt is not in fact disabled. Fix this by disabling the interrupt
in the host->ier variable.

Fixes: 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
Cc: <stable@vger.kernel.org>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

Merge branch 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree into ti-linux-4.19.y

TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y

* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
  ti_config_fragments: Add display to audio_display.cfg
  drm/tilcdc: Register cpufreq notifier after we have initialized crtc

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merge branch 'ti/4.19-pull' of https://bitbucket.itg.ti.com/scm/~a0400822/linux into audio_display-ti-linux-4.19.y

4.19 A&D config fragment for omapdrm for 2019.00

* 'ti/4.19-pull' of https://bitbucket.itg.ti.com/scm/~a0400822/linux: (447 commits)
  ti_config_fragments: Add display to audio_display.cfg
  ti_config_fragments: v8_defconfig_map.txt: remove android-base-arm64.config
  ti_config_fragments: defconfig_map.txt: remove android-base-arm.config
  firmware: ti_sci: Add support for processor control
  arm64: dts: ti: k3-am65-mcu: Add the MCU RAM node
  arm64: dts: ti: k3-am65: add MCU SRAM ranges in interconnect nodes
  rpmsg: add a description field
  samples/rpmsg: Introduce a module parameter for message count
  remoteproc: add an api to do pa to da conversion
  remoteproc: add api for retrieving a rproc unique id
  remoteproc: add name in rproc_mem_entry struct
  remoteproc: Check for NULL firmwares in sysfs interface
  Linux 4.19.9
  HID: quirks: fix RetroUSB.com devices
  mac80211: ignore NullFunc frames in the duplicate detection
  mac80211: fix reordering of buffered broadcast packets
  mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext
  mac80211: Clear beacon_int in ieee80211_do_stop
  mac80211: fix GFP_KERNEL under tasklet context
  mac80211_hwsim: Timer should be initialized before device registered
  ...

ti_config_fragments: Add display to audio_display.cfg

Add display related config items to audio_display.cfg, including touch.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

clk: keystone: sci-clk: add support from parsing clock info from DT

Currently the sci-clk driver queries clock data from the firmware, which
can be pretty slow operation in certain cases. Add an option for the
driver to probe the available clocks from DT also, in this case the
number of clocks probed from firmware gets cut down drastically. To
enable the feature, a new flag ti,scan-clocks-from-dt can be added
under the clock provider node.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>

dt-bindings: clock: ti,sci-clk: Add support for parsing clock info from DT

By default, the available clock info is queried from firmware, which can
be quite a lengthy operation if there is a very large amount of clocks
available. Add option for parsing the used clocks from DT instead, and
only register these which can improve the boot time of the device quite
a lot.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

soc: ti: Add TI_MESSAGE_MANAGER to default K3 AM65x SoC options

This fixes the following warning with make allmodconfig:

WARNING: unmet direct dependencies detected for TI_SCI_PROTOCOL
  Depends on [m]: TI_MESSAGE_MANAGER [=m]
  Selected by [y]:
  - ARCH_K3_AM6_SOC [=y] && ARM64 [=y] && ARCH_K3 [=y]

Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

Merge branch 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg into ti-linux-4.19.y

TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.19.y-intg

* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: add a description field
  samples/rpmsg: Introduce a module parameter for message count
  remoteproc: add an api to do pa to da conversion
  remoteproc: add api for retrieving a rproc unique id
  remoteproc: add name in rproc_mem_entry struct
  remoteproc: Check for NULL firmwares in sysfs interface
  ti_config_fragments: v8_rpmsg: Enable OMAP HwSpinlock driver
  arm64: dts: ti: k3-am65-main: Add hwspinlock node
  hwspinlock/omap: Add support for TI K3 SoCs
  dt-bindings: hwlock: Update OMAP binding for TI K3 AM65x SoCs
  hwspinlock/omap: Add a trace during probe
  ti_config_fragments: v8_defconfig_map: Add v8 rpmsg config file
  ti_config_fragments: v8_rpmsg: Add RPMsg domain config fragment file
  ti_config_fragments: defconfig_map: Include RPMsg config fragment
  ti_config_fragments: rpmsg: Add RPMsg domain config fragment file
  rpmsg: char: Migrate to iter versions of read and write

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merge branch 'rpmsg-ti-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y-intg

Signed-off-by: Suman Anna <s-anna@ti.com>

Merge branch 'hwspinlock-linux-4.19.y' of git://git.ti.com/rpmsg/hwspinlock into rpmsg-ti-linux-4.19.y

Pull in the hwspinlock feature tree to bring in the base rpmsg domain
config fragments and the defconfig_builder infrastructure used by TI
Integration kernels. The merge also brings in the support for the
HwSpinlock IP present on K3 AM65x SoCs, including the dependent platform
tree that adds the board support for all the AM65x boards.

* 'hwspinlock-linux-4.19.y' of git://git.ti.com/rpmsg/hwspinlock: (132 commits)
  ti_config_fragments: v8_rpmsg: Enable OMAP HwSpinlock driver
  arm64: dts: ti: k3-am65-main: Add hwspinlock node
  hwspinlock/omap: Add support for TI K3 SoCs
  dt-bindings: hwlock: Update OMAP binding for TI K3 AM65x SoCs
  hwspinlock/omap: Add a trace during probe
  ti_config_fragments: v8_defconfig_map: Add v8 rpmsg config file
  ti_config_fragments: v8_rpmsg: Add RPMsg domain config fragment file
  ti_config_fragments: defconfig_map: Include RPMsg config fragment
  ti_config_fragments: rpmsg: Add RPMsg domain config fragment file
  dmaengine: ti: k3-udma: Try to use the highest TPL channels for MEM_TO_MEM
  dmaengine: ti: k3-udma: Only allow MEM_TO_MEM transfer on the main UDMA
  ti_config_fragments/defconfig_map.txt: add missing baseport.cfg entries
  ti_config_fragments: v8_baseport: Forward port v8_baseport cfg from 4.14
  arm64: dts: ti: k3-am6: Add NAVSS and PDMA nodes
  dmaengine: ti: k3-udma: Add glue layer for non DMAengine users
  dmaengine: ti: New driver for K3 UDMA
  dmaengine: ti: Add cppi5 header for UDMA
  dt-bindings: dma: ti: Add document for K3 UDMA
  dmaengine: Add function to request slave channel from a dma_device
  dmaengine: Add support for reporting DMA cached data amount
  ...

Signed-off-by: Suman Anna <s-anna@ti.com>

Merge branch 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y

Merge the baseline rpmsg and remoteproc patches into the RPMsg domain
integration branch: rpmsg-ti-linux-4.19.y. These are baselined on the
vanilla v4.19 kernel and includes some upstream backports from v4.20
kernel. The patches also include few additional enhancements to
rpmsg/remoteproc cores.

The enhancements to remoteproc core include adding API to allow rpmsg
bus drivers to be able to retrieve a SoC-wide unique rproc id for usage
by some rpmsg drivers/userspace stacks and an API to perform physical
to device address translations. Also included is a minor improvement
that checks for NULL firmwares on the sysfs 'firmware' file interface.

The enhancements to rpmsg core are primarily about adding a new descriptor
field to the rpmsg channel device to allow multiple instances of a rpmsg
client driver, and is an enhanced version of the equivalent feature on
4.14 kernel providing backward compatibility.

Note that the support for rpmsg buffers in HIGHMEM and/or regular
carveouts is already supported in mainline kernel (default CMA pools
in Linux are allocated from HIGHMEM range since 3.18 if the platform
has large enough memory for HIGHMEM).

* 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: add a description field
  samples/rpmsg: Introduce a module parameter for message count
  remoteproc: add an api to do pa to da conversion
  remoteproc: add api for retrieving a rproc unique id
  remoteproc: add name in rproc_mem_entry struct
  remoteproc: Check for NULL firmwares in sysfs interface
  rpmsg: char: Migrate to iter versions of read and write

Signed-off-by: Suman Anna <s-anna@ti.com>

Merge branch 'integration-ti-linux-4.19.y' of git://git.ti.com/ti-linux-kernel/kernel-integration-tree into ti-linux-4.19.y

TI-Feature: integration
TI-Tree: git://git.ti.com/ti-linux-kernel/kernel-integration-tree.git
TI-Branch: integration-ti-linux-4.19.y

* 'integration-ti-linux-4.19.y' of git://git.ti.com/ti-linux-kernel/kernel-integration-tree:
  ti_config_fragments: v8_defconfig_map.txt: remove android-base-arm64.config
  ti_config_fragments: defconfig_map.txt: remove android-base-arm.config

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

ti_config_fragments: v8_defconfig_map.txt: remove android-base-arm64.config

android-base-arm64.config doesn't exist in android kernel configs
project yet.

Hence removing from the v8_defconfig_map file to generate the needed
android defconfig file for TI ARMv8 family of devices.

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>

ti_config_fragments: defconfig_map.txt: remove android-base-arm.config

android-base-arm.config doesn't exist in android kernel configs
project yet.

Hence removing from the defconfig_map file to generate the needed
android defconfig file for am57x family of devices.

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>

Merge branch 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.19.y

TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.19.y

* 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  firmware: ti_sci: Add support for processor control
  arm64: dts: ti: k3-am65-mcu: Add the MCU RAM node
  arm64: dts: ti: k3-am65: add MCU SRAM ranges in interconnect nodes

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

firmware: ti_sci: Add support for processor control

Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used in Texas Instrument's System on Chip (SoC) such as those
in K3 family AM654 SoC to communicate between various compute
processors with a central system controller entity.

The system controller provides various services including the control
of other compute processors within the SoC. Extend the TI-SCI protocol
support to add various TI-SCI commands to invoke services associated
with power and reset control, and boot vector management of the
various compute processors from the Linux kernel.

Signed-off-by: Suman Anna <s-anna@ti.com>

arm64: dts: ti: k3-am65-mcu: Add the MCU RAM node

Add the on-chip SRAM present within the MCU domain as a mmio-sram node.
The K3 AM65x SoCs have 512 KB of such memory. Any specific memory range
within this RAM needed by a software module ought to be reserved using
an appropriate child node.

Signed-off-by: Suman Anna <s-anna@ti.com>

arm64: dts: ti: k3-am65: add MCU SRAM ranges in interconnect nodes

Add the address space for the MCU SRAM memory to the ranges property
of the cbass_mcu interconnect node so that the addresses within the
mcu_sram nodes and its children can be translated properly by the
relevant OF address API.

Signed-off-by: Suman Anna <s-anna@ti.com>

rpmsg: add a description field

Add a new description field to the rpmsg bus infrastructure
that can be passed onto the rpmsg client drivers for additional
information. The current rpmsg bus client drivers need to have
a fixed id_table for proper matching, this new field can allow
flexibility for the client drivers (eg: like creating unique
cdevs).

The description field is published through an enhanced name
service announcement message structure. The name service
message processing logic is updated to maintain backward
compatibility with the previous message structure.

Based on an initial patch from Ohad Ben-Cohen.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: forward port, add sysfs documentation, fixup qcom drivers]
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: reworked to support both rpmsg with/without the desc field]
Signed-off-by: Tero Kristo <t-kristo@ti.com>

samples/rpmsg: Introduce a module parameter for message count

The current rpmsg_client_sample uses a fixed number of messages to
be sent to each instance. This is currently set at 100. Introduce
an optional module parameter 'count' so that the number of messages
to be exchanged can be made flexible.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: add an api to do pa to da conversion

Added an api to provide memory translation from a
physical address to a device virtual address.
Since, carveouts and mappings are stored separately,
we need to traverse both lists.

Also stored the physical addresses for RSC_DEVMEM entries
to enable pa to da conversion for dev mem address spaces too.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: add api for retrieving a rproc unique id

A new api, rproc_get_id(), is added to allow remoteproc/rpmsg clients
to be able to retrieve a fixed unique id associated with a rproc
device. Each of the rprocs is given an ida index as well, but this
is dynamic depending on the order rproc_alloc is called (probe order),
and also depends on what remote processor devices are instantiated.
This unique id needs to be supported for both DT and non-DT devices.
The platform device id or the remoteproc alias id are therefore
chosen for non-DT and DT devices respectively, with the assumption
that the remoteproc devices are created with known platform device
ids or alias ids in DT.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: add name in rproc_mem_entry struct

[ Upstream commit 3265230c5b05fe919291d09e266a8aedc85ebad0 ]

Add name field in struct rproc_mem_entry.
This new field will be used to match memory area
requested in resource table with pre-registered carveout.

Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '3265230c5b05' from v4.20]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: Check for NULL firmwares in sysfs interface

[ Upstream commit faeadbb64094757150a8c2a3175ca418dbdd472c ]

The remoteproc framework provides a sysfs file 'firmware'
for modifying the firmware image name from userspace. Add
an additional check to ensure NULL firmwares are errored
out right away, rather than getting a delayed error while
requesting a firmware during the start of a remoteproc
later on.

Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'faeadbb64094' from v4.20]

Merge branch 'linux-4.19.y' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-4.19.y

* 'linux-4.19.y' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (408 commits)
  Linux 4.19.9
  HID: quirks: fix RetroUSB.com devices
  mac80211: ignore NullFunc frames in the duplicate detection
  mac80211: fix reordering of buffered broadcast packets
  mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext
  mac80211: Clear beacon_int in ieee80211_do_stop
  mac80211: fix GFP_KERNEL under tasklet context
  mac80211_hwsim: Timer should be initialized before device registered
  cfg80211: Fix busy loop regression in ieee80211_ie_split_ric()
  libnvdimm, pfn: Pad pfn namespaces relative to other regions
  kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var()
  gnss: sirf: fix activation retry handling
  tty: do not set TTY_IO_ERROR flag if console port
  tty: serial: 8250_mtk: always resume the device in probe.
  Drivers: hv: vmbus: Offload the handling of channels to two workqueues
  x86/efi: Allocate e820 buffer before calling efi_exit_boot_service
  kprobes/x86: Fix instruction patching corruption when copying more than one RIP-relative instruction
  drm/i915: Downgrade Gen9 Plane WM latency error
  drm/amdgpu/gmc8: always load MC firmware in the driver
  drm/amdgpu/gmc8: update MC firmware for polaris
  ...

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merge branch 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.19.y

TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.19.y

* 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  kbuild: dtbinst: Install overlays
  dmaengine: ti: k3-udma: Fix compiler warning in udma_get_chan_pair
  clk: keystone: sci-clk: add slack to clk-set-rate passed to firmware
  clk: keystone: sci-clk: increase the max gap size to 50 for clk ids
  HACK: firmware: ti_sci: increase timeout to 10000ms
  arm64: dts: ti: am6: Add the trng node
  char: hwrng: Kconfig: Or ARCH_K3 dependency for HW_RANDOM_OMAP
  arm64: dts: k3-am6: Add crypto accelarator node
  sa2ul: Add 3DES ECB & CBC Mode support
  crypto: sa2ul: Add hmac(sha256) HMAC algorithm support
  crypto: sa2ul: Add hmac(sha1) HMAC algorithm support
  crypto: sa2ul: Add hmac(sha256)cbc(aes) AEAD Algo support
  crypto: sha256_generic: Export the Transform function
  crypto: sa2ul: Add aead support for hmac(sha1)cbc(aes) algorithm
  crypto: sa2ul: Add AES ECB Mode support
  crypto: sa2ul: Add crypto driver
  dt-bindings: crypto: k3: Add sa2ul bindings documentation

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Linux 4.19.9

HID: quirks: fix RetroUSB.com devices

commit 868613f1c0ccf7b832f38b48b18cca31cdeb3d26 upstream.

SNES RetroPort and RetroPad register only 4 gamepad buttons
when they should register all 8 buttons. This is described here:

https://ask.fedoraproject.org/en/question/128102

This is happening because of:

Commit 190d7f02ce8e ("HID: input: do not increment usages when
    duplicate is found")

Here, I add the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
(created for backward compatibility with the change in 190d7f02ce8e)
for the two products.

Tested with both RetroPort and RetroPad.

Cc: stable@vger.kernel.org # v4.18+
Signed-off-by: Nic Soudée <nsoudee@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mac80211: ignore NullFunc frames in the duplicate detection

commit 990d71846a0b7281bd933c34d734e6afc7408e7e upstream.

NullFunc packets should never be duplicate just like
QoS-NullFunc packets.

We saw a client that enters / exits power save with
NullFunc frames (and not with QoS-NullFunc) despite the
fact that the association supports HT.
This specific client also re-uses a non-zero sequence number
for different NullFunc frames.
At some point, the client had to send a retransmission of
the NullFunc frame and we dropped it, leading to a
misalignment in the power save state.
Fix this by never consider a NullFunc frame as duplicate,
just like we do for QoS NullFunc frames.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449

CC: <stable@vger.kernel.org>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mac80211: fix reordering of buffered broadcast packets

commit 9ec1190d065998650fd9260dea8cf3e1f56c0e8c upstream.

If the buffered broadcast queue contains packets, letting new packets bypass
that queue can lead to heavy reordering, since the driver is probably throttling
transmission of buffered multicast packets after beacons.

Keep buffering packets until the buffer has been cleared (and no client
is in powersave mode).

Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext

commit a317e65face482371de30246b6494feb093ff7f9 upstream.

Make it behave like regular ieee80211_tx_status calls, except for the lack of
filtered frame processing.
This fixes spurious low-ack triggered disconnections with powersave clients
connected to an AP.

Fixes: f027c2aca0cf4 ("mac80211: add ieee80211_tx_status_noskb")
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mac80211: Clear beacon_int in ieee80211_do_stop

commit 5c21e8100dfd57c806e833ae905e26efbb87840f upstream.

This fixes stale beacon-int values that would keep a netdev
from going up.

To reproduce:

Create two VAP on one radio.
vap1 has beacon-int 100, start it.
vap2 has beacon-int 240, start it (and it will fail
  because beacon-int mismatch).
reconfigure vap2 to have beacon-int 100 and start it.
  It will fail because the stale beacon-int 240 will be used
  in the ifup path and hostapd never gets a chance to set the
  new beacon interval.

Cc: stable@vger.kernel.org
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mac80211: fix GFP_KERNEL under tasklet context

commit c752cac9db1b0c469db7ba9d17af4ba708984db5 upstream.

cfg80211_sta_opmode_change_notify needs a gfp_t flag to hint the nl80211
stack when allocating new skb, but it is called under tasklet context
here with GFP_KERNEL and kernel will yield a warning about it.

Cc: stable@vger.kernel.org
Fixes: ff84e7bfe176 ("mac80211: Add support to notify ht/vht opmode modification.")
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
ACKed-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mac80211_hwsim: Timer should be initialized before device registered

commit a1881c9b8a1edef0a5ae1d5c1b61406fe3402114 upstream.

Otherwise if network manager starts configuring Wi-Fi interface
immidiatelly after getting notification of its creation, we will get
NULL pointer dereference:

  BUG: unable to handle kernel NULL pointer dereference at           (null)
  IP: [<ffffffff95ae94c8>] hrtimer_active+0x28/0x50
  ...
  Call Trace:
   [<ffffffff95ae9997>] ? hrtimer_try_to_cancel+0x27/0x110
   [<ffffffff95ae9a95>] ? hrtimer_cancel+0x15/0x20
   [<ffffffffc0803bf0>] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim]

Cc: stable@vger.kernel.org
Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@globallogic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cfg80211: Fix busy loop regression in ieee80211_ie_split_ric()

commit 312ca38ddda64bac6513ec68e0ac3789b4eb44dc upstream.

This function was modified to support the information element extension
case (WLAN_EID_EXTENSION) in a manner that would result in an infinite
loop when going through set of IEs that include WLAN_EID_RIC_DATA and
contain an IE that is in the after_ric array. The only place where this
can currently happen is in mac80211 ieee80211_send_assoc() where
ieee80211_ie_split_ric() is called with after_ric[].

This can be triggered by valid data from user space nl80211
association/connect request (i.e., requiring GENL_UNS_ADMIN_PERM). The
only known application having an option to include WLAN_EID_RIC_DATA in
these requests is wpa_supplicant and it had a bug that prevented this
specific contents from being used (and because of that, not triggering
this kernel bug in an automated test case ap_ft_ric) and now that this
bug is fixed, it has a workaround to avoid this kernel issue.
WLAN_EID_RIC_DATA is currently used only for testing purposes, so this
does not cause significant harm for production use cases.

Fixes: 2512b1b18d07 ("mac80211: extend ieee80211_ie_split to support EXTENSION")
Cc: stable@vger.kernel.org
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

libnvdimm, pfn: Pad pfn namespaces relative to other regions

commit ae86cbfef3818300f1972e52f67a93211acb0e24 upstream.

Commit cfe30b872058 "libnvdimm, pmem: adjust for section collisions with
'System RAM'" enabled Linux to workaround occasions where platform
firmware arranges for "System RAM" and "Persistent Memory" to collide
within a single section boundary. Unfortunately, as reported in this
issue [1], platform firmware can inflict the same collision between
persistent memory regions.

The approach of interrogating iomem_resource does not work in this
case because platform firmware may merge multiple regions into a single
iomem_resource range. Instead provide a method to interrogate regions
that share the same parent bus.

This is a stop-gap until the core-MM can grow support for hotplug on
sub-section boundaries.

[1]: https://github.com/pmem/ndctl/issues/76

Fixes: cfe30b872058 ("libnvdimm, pmem: adjust for section collisions with...")
Cc: <stable@vger.kernel.org>
Reported-by: Patrick Geary <patrickg@supermicro.com>
Tested-by: Patrick Geary <patrickg@supermicro.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var()

commit dada6a43b0402eba438a17ac86fdc64ac56a4607 upstream.

This patch is trying to fix KE issue due to
"BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198"
reported by Syzkaller scan."

[26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198
[26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364
[26364:syz-executor0][name:report&]
[26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0
[26364:syz-executor0]Call trace:
[26364:syz-executor0][<ffffff9008095cf8>] dump_bacIctrace+Ox0/0x470
[26364:syz-executor0][<ffffff9008096de0>] show_stack+0x20/0x30
[26364:syz-executor0][<ffffff90089cc9c8>] dump_stack+Oxd8/0x128
[26364:syz-executor0][<ffffff90084edb38>] print_address_description +0x80/0x4a8
[26364:syz-executor0][<ffffff90084ee270>] kasan_report+Ox178/0x390
[26364:syz-executor0][<ffffff90084ee4a0>] _asan_report_loadi_noabort+Ox18/0x20
[26364:syz-executor0][<ffffff9008b092ac>] param_set_kgdboc_var+Ox194/0x198
[26364:syz-executor0][<ffffff900813af64>] param_attr_store+Ox14c/0x270
[26364:syz-executor0][<ffffff90081394c8>] module_attr_store+0x60/0x90
[26364:syz-executor0][<ffffff90086690c0>] sysfs_kl_write+Ox100/0x158
[26364:syz-executor0][<ffffff9008666d84>] kernfs_fop_write+0x27c/0x3a8
[26364:syz-executor0][<ffffff9008508264>] do_loop_readv_writev+0x114/0x1b0
[26364:syz-executor0][<ffffff9008509ac8>] do_readv_writev+0x4f8/0x5e0
[26364:syz-executor0][<ffffff9008509ce4>] vfs_writev+0x7c/Oxb8
[26364:syz-executor0][<ffffff900850ba64>] SyS_writev+Oxcc/0x208
[26364:syz-executor0][<ffffff90080883f0>] elO_svc_naked +0x24/0x28
[26364:syz-executor0][name:report&]
[26364:syz-executor0][name:report&]The buggy address belongs to the variable:
[26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40
[26364:syz-executor0][name:report&]
[26364:syz-executor0][name:report&]Memory state around the buggy address:
[26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa
[26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
[26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
[26364:syz-executor0][name:report&]                                       ^
[26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
[26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa
[26364:syz-executor0][name:report&]
[26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint
[26364:syz-executor0]------------[cut here]------------

After checking the source code, we've found there might be an out-of-bounds
access to "config[len - 1]" array when the variable "len" is zero.

Signed-off-by: Macpaul Lin <macpaul@gmail.com>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

gnss: sirf: fix activation retry handling

commit 06fd9ab12b804451b14d538adbf98a57c2d6846b upstream.

Fix activation helper which would return -ETIMEDOUT even if the last
retry attempt was successful.

Also change the semantics of the retries variable so that it actually
holds the number of retries (rather than tries).

Fixes: d2efbbd18b1e ("gnss: add driver for sirfstar-based receivers")
Cc: stable <stable@vger.kernel.org> # 4.19
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: do not set TTY_IO_ERROR flag if console port

commit 2a48602615e0a2f563549c7d5c8d507f904cf96e upstream.

Since Commit 761ed4a94582 ('tty: serial_core: convert uart_close to use
tty_port_close') and Commit 4dda864d7307 ('tty: serial_core: Fix serial
console crash on port shutdown), a serial port which is used as
console can be stuck when logging out if there is a remained process.
After logged out, agetty will try to grab the serial port but it will
be failed because the previous process did not release the port
correctly. To fix this, TTY_IO_ERROR bit should not be enabled of
tty_port_close if the port is console port.

Reproduce step:
- Run background processes from serial console
$ while true; do sleep 10; done &

- Log out
$ logout
-> Stuck

- Read journal log by journalctl | tail
Jan 28 16:07:01 ubuntu systemd[1]: Stopped Serial Getty on ttyAMA0.
Jan 28 16:07:01 ubuntu systemd[1]: Started Serial Getty on ttyAMA0.
Jan 28 16:07:02 ubuntu agetty[1643]: /dev/ttyAMA0: not a tty

Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close")
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Rob Herring <robh@kernel.org>
Cc: Jiri Slaby <jslaby@suse.com>
Signed-off-by: Chanho Park <parkch98@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: serial: 8250_mtk: always resume the device in probe.

commit 100bc3e2bebf95506da57cbdf5f26b25f6da4c81 upstream.

serial8250_register_8250_port calls uart_config_port, which calls
config_port on the port before it tries to power on the port. So we need
the port to be on before calling serial8250_register_8250_port. Change
the code to always do a runtime resume in probe before registering port,
and always do a runtime suspend in remove.

This basically reverts the change in commit 68e5fc4a255a ("tty: serial:
8250_mtk: use pm_runtime callbacks for enabling"), but still use
pm_runtime callbacks.

Fixes: 68e5fc4a255a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling")
Signed-off-by: Peter Shih <pihsun@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Drivers: hv: vmbus: Offload the handling of channels to two workqueues

commit 37c2578c0c40e286bc0d30bdc05290b2058cf66e upstream.

vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.

The above is also true for primary channels, if the related device
drivers use sync probing mode by default.

And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.

The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).

The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.

So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.

Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/efi: Allocate e820 buffer before calling efi_exit_boot_service

commit b84a64fad40637b1c9fa4f4dbf847a23e29e672b upstream.

The following commit:

  d64934019f6c ("x86/efi: Use efi_exit_boot_services()")

introduced a regression on systems with large memory maps causing them
to hang on boot. The first "goto get_map" that was removed from
exit_boot() ensured there was enough room for the memory map when
efi_call_early(exit_boot_services) was called. This happens when
(nr_desc > ARRAY_SIZE(params->e820_table).

Chain of events:

  exit_boot()
    efi_exit_boot_services()
      efi_get_memory_map                  <- at this point the mm can't grow over 8 desc
      priv_func()
        exit_boot_func()
          allocate_e820ext()              <- new mm grows over 8 desc from e820 alloc
      efi_call_early(exit_boot_services)  <- mm key doesn't match so retry
      efi_call_early(get_memory_map)      <- not enough room for new mm
      system hangs

This patch allocates the e820 buffer before calling efi_exit_boot_services()
and fixes the regression.

 [ mingo: minor cleanliness edits. ]

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: <stable@vger.kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Joe Perches <joe@perches.com>
Cc: Jon Hunter <jonathanh@nvidia.com>
Cc: Julien Thierry <julien.thierry@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: YiFei Zhu <zhuyifei1999@gmail.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kprobes/x86: Fix instruction patching corruption when copying more than one RIP-relative instruction

commit 43a1b0cb4cd6dbfd3cd9c10da663368394d299d8 upstream.

After copy_optimized_instructions() copies several instructions
to the working buffer it tries to fix up the real RIP address, but it
adjusts the RIP-relative instruction with an incorrect RIP address
for the 2nd and subsequent instructions due to a bug in the logic.

This will break the kernel pretty badly (with likely outcomes such as
a kernel freeze, a crash, or worse) because probed instructions can refer
to the wrong data.

For example putting kprobes on cpumask_next() typically hits this bug.

cpumask_next() is normally like below if CONFIG_CPUMASK_OFFSTACK=y
(in this case nr_cpumask_bits is an alias of nr_cpu_ids):

 <cpumask_next>:
48 89 f0 mov    %rsi,%rax
8b 35 7b fb e2 00 mov    0xe2fb7b(%rip),%esi # ffffffff82db9e64 <nr_cpu_ids>
55 push   %rbp
...

If we put a kprobe on it and it gets jump-optimized, it gets
patched by the kprobes code like this:

 <cpumask_next>:
e9 95 7d 07 1e jmpq   0xffffffffa000207a
7b fb jnp    0xffffffff81f8a2e2 <cpumask_next+2>
e2 00 loop   0xffffffff81f8a2e9 <cpumask_next+9>
55 push   %rbp

This shows that the first two MOV instructions were copied to a
trampoline buffer at 0xffffffffa000207a.

Here is the disassembled result of the trampoline, skipping
the optprobe template instructions:

# Dump of assembly code from 0xffffffffa000207a to 0xffffffffa00020ea:

54 push   %rsp
...
48 83 c4 08 add    $0x8,%rsp
9d popfq
48 89 f0 mov    %rsi,%rax
8b 35 82 7d db e2 mov    -0x1d24827e(%rip),%esi # 0xffffffff82db9e67 <nr_cpu_ids+3>

This dump shows that the second MOV accesses *(nr_cpu_ids+3) instead of
the original *nr_cpu_ids. This leads to a kernel freeze because
cpumask_next() always returns 0 and for_each_cpu() never ends.

Fix this by adding 'len' correctly to the real RIP address while
copying.

[ mingo: Improved the changelog. ]

Reported-by: Michael Rodin <michael@rodin.online>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org # v4.15+
Fixes: 63fef14fc98a ("kprobes/x86: Make insn buffer always ROX and use text_poke()")
Link: http://lkml.kernel.org/r/153504457253.22602.1314289671019919596.stgit@devbox
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Downgrade Gen9 Plane WM latency error

commit 86c1c87d0e6241cbe35bd52badfc84b154e1b959 upstream.

According to intel_read_wm_latency() it is perfectly legal for one WM
and all subsequent levels to be 0 (and the deeper powersaving states
disabled), so don't shout *ERROR*, over and over again.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180726161527.10516-1-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/gmc8: always load MC firmware in the driver

commit b52b6738cc2d50d2a8f4d0095bcb5a86716008a5 upstream.

Some power features rely on the driver loaded version so always
load the MC firmware from the driver even if the vbios loaded
a version already.

Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/gmc8: update MC firmware for polaris

commit a81a7c9c9ea3042ab02d66ac35def74abf091c15 upstream.

Some variants require different MC firmware images.

Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/msm: Move fence put to where failure occurs

commit 2189463dba3eac10d7264a40ede12fc1a3c06fb1 upstream.

If dma_fence_wait fails to wait for a supplied in-fence in
msm_ioctl_gem_submit, make sure we release that in-fence.

Also remove this dma_fence_put() from the 'out' label.

Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/lease: Send a distinct uevent

commit ce85882860f0e756f7066cbda1c43e8b50b73ab6 upstream.

Sending the exact same hotplug event is not great uapi. Luckily the
only already merged implementation of leases (in the -modesetting
driver) doesn't care about what kind of uevent it gets, and
unconditionally processes both hotplug and lease changes. So we can
still adjust the uapi here.

But e.g. weston tries to filter stuff, and I guess others might want
to do that too. Try to make that possible. Cc: stable since it's uapi
adjustement that we want to roll out everywhere.

Michel Dänzer mentioned on irc that -amdgpu also has lease support. It
has the same code flow as -modesetting though, so we can still go
ahead.

v2: Mention -amdgpu (Michel)

Cc: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181129094226.30591-1-daniel.vetter@ffwll.ch
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: update mc firmware image for polaris12 variants

commit d7fd67653f847327e545bdb198b901ee124afd7c upstream.

Some new variants require updated firmware.

Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: do not free algorithm before using

commit e5bde04ccce64d808f8b00a489a1fe5825d285cb upstream.

In multiple functions, the algorithm fields are read after its reference
is dropped through crypto_mod_put. In this case, the algorithm memory
may be freed, resulting in use-after-free bugs. This patch delays the
put operation until the algorithm is never used.

Fixes: 79c65d179a40 ("crypto: cbc - Convert to skcipher")
Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack mode")
Fixes: 043a44001b9e ("crypto: pcbc - Convert to skcipher")
Cc: <stable@vger.kernel.org>
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert commit ef9209b642f "staging: rtl8723bs: Fix indenting errors and an off-by-one mistake in core/rtw_mlme_ext.c"

commit 87e4a5405f087427fbf8b437d2796283dce2b38f upstream.

pstapriv->max_num_sta is always <= NUM_STA, since max_num_sta is either
set in _rtw_init_sta_priv() or rtw_set_beacon().

Fixes: ef9209b642f1 ("staging: rtl8723bs: Fix indenting errors and an off-by-one mistake in core/rtw_mlme_ext.c")
Signed-off-by: Young Xiao <YangX92@hotmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: rtl8712: Fix possible buffer overrun

commit 300cd664865bed5d50ae0a42fb4e3a6f415e8a10 upstream.

In commit 8b7a13c3f404 ("staging: r8712u: Fix possible buffer
overrun") we fix a potential off by one by making the limit smaller.
The better fix is to make the buffer larger.  This makes it match up
with the similar code in other drivers.

Fixes: 8b7a13c3f404 ("staging: r8712u: Fix possible buffer overrun")
Signed-off-by: Young Xiao <YangX92@hotmail.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cifs: Fix separator when building path from dentry

commit c988de29ca161823db6a7125e803d597ef75b49c upstream.

Make sure to use the CIFS_DIR_SEP(cifs_sb) as path separator for
prefixpath too. Fixes a bug with smb1 UNIX extensions.

Fixes: a6b5058fafdf ("fs/cifs: make share unaccessible at root level mountable")
Signed-off-by: Paulo Alcantara <palcantara@suse.com>
Reviewed-by: Aurelien Aptel <aaptel@suse.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "x86/e820: put !E820_TYPE_RAM regions into memblock.reserved"

[ Upstream commit 9fd61bc95130d4971568b89c9548b5e0a4e18e0e ]

commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into
memblock.reserved") breaks movable_node kernel option because it changed
the memory gap range to reserved memblock.  So, the node is marked as
Normal zone even if the SRAT has Hot pluggable affinity.

    =====================================================================
    kernel: BIOS-e820: [mem 0x0000180000000000-0x0000180fffffffff] usable
    kernel: BIOS-e820: [mem 0x00001c0000000000-0x00001c0fffffffff] usable
    ...
    kernel: reserved[0x12]#011[0x0000181000000000-0x00001bffffffffff], 0x000003f000000000 bytes flags: 0x0
    ...
    kernel: ACPI: SRAT: Node 2 PXM 6 [mem 0x180000000000-0x1bffffffffff] hotplug
    kernel: ACPI: SRAT: Node 3 PXM 7 [mem 0x1c0000000000-0x1fffffffffff] hotplug
    ...
    kernel: Movable zone start for each node
    kernel:  Node 3: 0x00001c0000000000
    kernel: Early memory node ranges
    ...
    =====================================================================

The original issue is fixed by the former patches, so let's revert commit
124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into
memblock.reserved").

Link: http://lkml.kernel.org/r/20181002143821.5112-4-msys.mizuma@gmail.com
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Pavel Tatashin <pavel.tatashin@microsoft.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: remove vdd_log from rock960 to fix a stability issues

[ Upstream commit 13682e524167cbd7e2a26c5e91bec765f0f96273 ]

When the performance governor is set as default, the rock960 hangs
around one minute after booting, whatever the activity is (idle, key
pressed, loaded, ...).

Based on the commit log found at https://patchwork.kernel.org/patch/10092377/

"vdd_log has no consumer and therefore will not be set to a specific
voltage. Still the PWM output pin gets configured and thence the vdd_log
output voltage will changed from it's default. Depending on the idle
state of the PWM this will slightly over or undervoltage the logic supply
of the RK3399 and cause instability with GbE (undervoltage) and PCIe
(overvoltage). Since the default value set by a voltage divider is the
correct supply voltage and we don't need to change it during runtime we
remove the rail from the devicetree completely so the PWM pin will not
be configured."

After removing the vdd-log from the rock960's specific DT, the board
does no longer hang and shows a stable behavior.

Apply the same change for the rock960 by removing the vdd-log from the
DT.

Fixes: 874846f1fccd ("arm64: dts: rockchip: add 96boards RK3399 Ficus board")
Cc: stable@vger.kernel.org
Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[sl: adjust filename for 4.19]
Signed-off-by: Sasha Levin <sashal@kernel.org>

xhci: Prevent U1/U2 link pm states if exit latency is too long

commit 0472bf06c6fd33c1a18aaead4c8f91e5a03d8d7b upstream.

Don't allow USB3 U1 or U2 if the latency to wake up from the U-state
reaches the service interval for a periodic endpoint.

This is according to xhci 1.1 specification section 4.23.5.2 extra note:

"Software shall ensure that a device is prevented from entering a U-state
 where its worst case exit latency approaches the ESIT."

Allowing too long exit latencies for periodic endpoint confuses xHC
internal scheduling, and new devices may fail to enumerate with a
"Not enough bandwidth for new device state" error from the host.

Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: workaround CSS timeout on AMD SNPS 3.0 xHC

commit a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d upstream.

Occasionally AMD SNPS 3.0 xHC does not respond to
CSS when set, also it does not flag anything on SRE and HCE
to point the internal xHC errors on USBSTS register. This stalls
the entire system wide suspend and there is no point in stalling
just because of xHC CSS is not responding.

To work around this problem, if the xHC does not flag
anything on SRE and HCE, we can skip the CSS
timeout and allow the system to continue the suspend. Once the
system resume happens we can internally reset the controller
using XHCI_RESET_ON_RESUME quirk

Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Sandeep Singh <Sandeep.Singh@amd.com>
cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
Cc: <stable@vger.kernel.org>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE

commit e46daee53bb50bde38805f1823a182979724c229 upstream.

The arm compiler internally interprets an inline assembly label
as an unsigned long value, not a pointer. As a result, under
CONFIG_FORTIFY_SOURCE, the address of a label has a size of 4 bytes,
which was tripping the runtime checks. Instead, we can just cast the label
(as done with the size calculations earlier).

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1639397

Reported-by: William Cohen <wcohen@redhat.com>
Fixes: 6974f0c4555e ("include/linux/string.h: add the option of fortified string.h functions")
Cc: stable@vger.kernel.org
Acked-by: Laura Abbott <labbott@redhat.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: William Cohen <wcohen@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: cppi41: delete channel from pending list when stop channel

commit 59861547ec9a9736e7882f6fb0c096a720ff811a upstream.

The driver defines three states for a cppi channel.
- idle: .chan_busy == 0 && not in .pending list
- pending: .chan_busy == 0 && in .pending list
- busy: .chan_busy == 1 && not in .pending list

There are cases in which the cppi channel could be in the pending state
when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend()
is called.

cppi41_stop_chan() has a bug for these cases to set channels to idle state.
It only checks the .chan_busy flag, but not the .pending list, then later
when cppi41_runtime_resume() is called the channels in .pending list will
be transitioned to busy state.

Removing channels from the .pending list solves the problem.

Fixes: 975faaeb9985 ("dma: cppi41: start tear down only if channel is busy")
Cc: stable@vger.kernel.org # v3.15+
Signed-off-by: Bin Liu <b-liu@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: imx-sdma: use GFP_NOWAIT for dma descriptor allocations

commit 64068853bc77786d1a28abb4087d6a3e93aedbe2 upstream.

DMA buffer descriptors aren't allocated from atomic context, so they
can use the less heavyweigth GFP_NOWAIT.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: imx-sdma: implement channel termination via worker

commit b8603d2a5795c42f78998e70dc792336e0dc20c9 upstream.

The dmaengine documentation states that device_terminate_all may be
asynchronous and need not wait for the active transfers to stop.

This allows us to move most of the functionality currently implemented
in the sdma channel termination function to run in a worker, outside
of any atomic context. Moving this out of atomic context has two
benefits: we can now sleep while waiting for the channel to terminate,
instead of busy waiting and the freeing of the dma descriptors happens
with IRQs enabled, getting rid of a warning in the dma mapping code.

As the termination is now async, we need to implement the
device_synchronize dma engine function which simply waits for the
worker to finish its execution.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "dmaengine: imx-sdma: alloclate bd memory from dma pool"

commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0 upstream.

This reverts commit fe5b85c656bc. The SDMA engine needs the descriptors to
be contiguous in memory. As the dma pool API is only able to provide a
single descriptor per alloc invocation there is no guarantee that multiple
descriptors satisfy this requirement. Also the code in question is broken
as it only allocates memory for a single descriptor, without looking at the
number of descriptors required for the transfer, leading to out-of-bounds
accesses when the descriptors are written.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "dmaengine: imx-sdma: Use GFP_NOWAIT for dma allocations"

commit c06abca69218ac42fa58d1ba7a7b0d9bab5f1b18 upstream.

This reverts commit c1199875d327, as this depends on another commit
that is going to be reverted.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: dw: Fix FIFO size for Intel Merrifield

commit ffe843b18211301ad25893eba09f402c19d12304 upstream.

Intel Merrifield has a reduced size of FIFO used in iDMA 32-bit controller,
i.e. 512 bytes instead of 1024.

Fix this by partitioning it as 64 bytes per channel.

Note, in the future we might switch to 'fifo-size' property instead of
hard coded value.

Fixes: 199244d69458 ("dmaengine: dw: add support of iDMA 32-bit hardware")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

SUNRPC: Fix leak of krb5p encode pages

commit 8dae5398ab1ac107b1517e8195ed043d5f422bd0 upstream.

call_encode can be invoked more than once per RPC call. Ensure that
each call to gss_wrap_req_priv does not overwrite pointers to
previously allocated memory.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Cc: stable@kernel.org
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: hibernate: Avoid sending cross-calling with interrupts disabled

commit b4aecf78083d8c6424657c1746c7c3de6e61669f upstream.

Since commit 3b8c9f1cdfc50 ("arm64: IPI each CPU after invalidating the
I-cache for kernel mappings"), a call to flush_icache_range() will use
an IPI to cross-call other online CPUs so that any stale instructions
are flushed from their pipelines. This triggers a WARN during the
hibernation resume path, where flush_icache_range() is called with
interrupts disabled and is therefore prone to deadlock:

  | Disabling non-boot CPUs ...
  | CPU1: shutdown
  | psci: CPU1 killed.
  | CPU2: shutdown
  | psci: CPU2 killed.
  | CPU3: shutdown
  | psci: CPU3 killed.
  | WARNING: CPU: 0 PID: 1 at ../kernel/smp.c:416 smp_call_function_many+0xd4/0x350
  | Modules linked in:
  | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc4 #1

Since all secondary CPUs have been taken offline prior to invalidating
the I-cache, there's actually no need for an IPI and we can simply call
__flush_icache_range() instead.

Cc: <stable@vger.kernel.org>
Fixes: 3b8c9f1cdfc50 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings")
Reported-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Tested-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Tested-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vhost/vsock: fix use-after-free in network stack callers

commit 834e772c8db0c6a275d75315d90aba4ebbb1e249 upstream.

If the network stack calls .send_pkt()/.cancel_pkt() during .release(),
a struct vhost_vsock use-after-free is possible.  This occurs because
.release() does not wait for other CPUs to stop using struct
vhost_vsock.

Switch to an RCU-enabled hashtable (indexed by guest CID) so that
.release() can wait for other CPUs by calling synchronize_rcu().  This
also eliminates vhost_vsock_lock acquisition in the data path so it
could have a positive effect on performance.

This is CVE-2018-14625 "kernel: use-after-free Read in vhost_transport_send_pkt".

Cc: stable@vger.kernel.org
Reported-and-tested-by: syzbot+bd391451452fb0b93039@syzkaller.appspotmail.com
Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
Reported-by: syzbot+d5a0a170c5069658b141@syzkaller.appspotmail.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

virtio/s390: fix race in ccw_io_helper()

commit 78b1a52e05c9db11d293342e8d6d8a230a04b4e7 upstream.

While ccw_io_helper() seems like intended to be exclusive in a sense that
it is supposed to facilitate I/O for at most one thread at any given
time, there is actually nothing ensuring that threads won't pile up at
vcdev->wait_q. If they do, all threads get woken up and see the status
that belongs to some other request than their own. This can lead to bugs.
For an example see:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432

This race normally does not cause any problems. The operations provided
by struct virtio_config_ops are usually invoked in a well defined
sequence, normally don't fail, and are normally used quite infrequent
too.

Yet, if some of the these operations are directly triggered via sysfs
attributes, like in the case described by the referenced bug, userspace
is given an opportunity to force races by increasing the frequency of the
given operations.

Let us fix the problem by ensuring, that for each device, we finish
processing the previous request before starting with a new one.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Reported-by: Colin Ian King <colin.king@canonical.com>
Cc: stable@vger.kernel.org
Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

virtio/s390: avoid race on vcdev->config

commit 2448a299ec416a80f699940a86f4a6d9a4f643b1 upstream.

Currently we have a race on vcdev->config in virtio_ccw_get_config() and
in virtio_ccw_set_config().

This normally does not cause problems, as these are usually infrequent
operations. However, for some devices writing to/reading from the config
space can be triggered through sysfs attributes. For these, userspace can
force the race by increasing the frequency.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Cc: stable@vger.kernel.org
Message-Id: <20180925121309.58524-2-pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parisc: Enable -ffunction-sections for modules on 32-bit kernel

commit 1e8249b8a4e960018e4baca6b523b8a4500af600 upstream.

Frank Schreiner reported, that since kernel 4.18 he faces sysfs-warnings
when loading modules on a 32-bit kernel. Here is one such example:

 sysfs: cannot create duplicate filename '/module/nfs/sections/.text'
 CPU: 0 PID: 98 Comm: modprobe Not tainted 4.18.0-2-parisc #1 Debian 4.18.10-2
 Backtrace:
  [<1017ce2c>] show_stack+0x3c/0x50
  [<107a7210>] dump_stack+0x28/0x38
  [<103f900c>] sysfs_warn_dup+0x88/0xac
  [<103f8b1c>] sysfs_add_file_mode_ns+0x164/0x1d0
  [<103f9e70>] internal_create_group+0x11c/0x304
  [<103fa0a0>] sysfs_create_group+0x48/0x60
  [<1022abe8>] load_module.constprop.35+0x1f9c/0x23b8
  [<1022b278>] sys_finit_module+0xd0/0x11c
  [<101831dc>] syscall_exit+0x0/0x14

This warning gets triggered by the fact, that due to commit 24b6c22504a2
("parisc: Build kernel without -ffunction-sections") we now get multiple .text
sections in the kernel modules for which sysfs_create_group() can't create
multiple virtual files.

This patch works around the problem by re-enabling the -ffunction-sections
compiler option for modules, while keeping it disabled for the non-module
kernel code.

Reported-by: Frank Scheiner <frank.scheiner@web.de>
Fixes: 24b6c22504a2 ("parisc: Build kernel without -ffunction-sections")
Cc: <stable@vger.kernel.org> # v4.18+
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "mfd: cros_ec: Use devm_kzalloc for private data"

commit 48a2ca0ee3994df53da230c7079a18a70ec914f9 upstream.

This reverts commit 3aa2177e47878f7e7616da8a2050c44f22301b6e.

That commit triggered a new WARN when unloading the module (see at the
end of the commit message). When a class_dev is embedded in a structure
then that class_dev is the thing that controls the lifetime of that
structure, for that reason device managed allocations can't be used here.
See Documentation/kobject.txt.

Revert the above patch, so the struct is allocated using kzalloc and we
have a release function for it that frees the allocated memory, otherwise
it is broken.

 ------------[ cut here ]------------
 Device 'cros_ec' does not have a release() function, it is broken and must be fixed.
 WARNING: CPU: 3 PID: 3675 at drivers/base/core.c:895 device_release+0x80/0x90
 Modules linked in: btusb btrtl btintel btbcm bluetooth ...
 CPU: 3 PID: 3675 Comm: rmmod Not tainted 4.20.0-rc4 #76
 Hardware name: Google Kevin (DT)
 pstate: 40000005 (nZcv daif -PAN -UAO)
 pc : device_release+0x80/0x90
 lr : device_release+0x80/0x90
 sp : ffff00000c47bc70
 x29: ffff00000c47bc70 x28: ffff8000e86b0d40
 x27: 0000000000000000 x26: 0000000000000000
 x25: 0000000056000000 x24: 0000000000000015
 x23: ffff8000f0bbf860 x22: ffff000000d320a0
 x21: ffff8000ee93e100 x20: ffff8000ed931428
 x19: ffff8000ed931418 x18: 0000000000000020
 x17: 0000000000000000 x16: 0000000000000000
 x15: 0000000000000400 x14: 0000000000000143
 x13: 0000000000000000 x12: 0000000000000400
 x11: 0000000000000157 x10: 0000000000000960
 x9 : ffff00000c47b9b0 x8 : ffff8000e86b1700
 x7 : 0000000000000000 x6 : ffff8000f7d520b8
 x5 : ffff8000f7d520b8 x4 : 0000000000000000
 x3 : ffff8000f7d58e68 x2 : ffff8000e86b0d40
 x1 : 37d859939c964800 x0 : 0000000000000000
 Call trace:
  device_release+0x80/0x90
  kobject_put+0x74/0xe8
  device_unregister+0x20/0x30
  ec_device_remove+0x34/0x48 [cros_ec_dev]
  platform_drv_remove+0x28/0x48
  device_release_driver_internal+0x1a8/0x240
  driver_detach+0x40/0x80
  bus_remove_driver+0x54/0xa8
  driver_unregister+0x2c/0x58
  platform_driver_unregister+0x10/0x18
  cros_ec_dev_exit+0x1c/0x2d8 [cros_ec_dev]
  __arm64_sys_delete_module+0x16c/0x1f8
  el0_svc_common+0x84/0xd8
  el0_svc_handler+0x2c/0x80
  el0_svc+0x8/0xc
 ---[ end trace a57c4625f3c60ae8 ]---

Cc: stable@vger.kernel.org
Fixes: 3aa2177e4787 ("mfd: cros_ec: Use devm_kzalloc for private data")
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: dvb-pll: don't re-validate tuner frequencies

commit 3420f65cbbd0555049bd02394bed33a0ef74d860 upstream.

The dvb_frontend core already checks for the frequencies. No
need for any additional check inside the driver.

It is part of the fixes for the following bug:
  https://bugzilla.opensuse.org/show_bug.cgi?id=1116374

Fixes: a3f90c75b833 ("media: dvb: convert tuner_info frequencies to Hz")
Reported-by: Stakanov Schufter <stakanov@eclipso.eu>
Reported-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@vger.kernel.org # For 4.19
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: dvb-pll: fix tuner frequency ranges

commit 3d8e450f517cdb33da77827ec75929354753e9c0 upstream.

Tuners should report frequencies in Hz. That works fine on most
drivers, but, in the case of dvb-pll, some settings are for
satellite tuners, while others are for terrestrial/cable ones.

The code was trying to solve it at probing time, but that doesn't
work, as, when _attach is called, the delivery system may be wrong.

Fix it by ensuring that all frequencies are in Hz at the per-tuner
max/min values.

While here, add a debug message, as this would help to debug any
issues there.

It partially fixes the following bug:
  https://bugzilla.opensuse.org/show_bug.cgi?id=1116374

Fixes: a3f90c75b833 ("media: dvb: convert tuner_info frequencies to Hz")
Reported-by: Stakanov Schufter <stakanov@eclipso.eu>
Reported-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@vger.kernel.org # For 4.19
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: vicodec: fix memchr() kernel oops

commit cb3b2ffb757e75fef40fb94bc093cbbf49a6bf6e upstream.

The size passed to memchr is too large as it assumes the search
starts at the start of the buffer, but it can start at an offset.

Cc: <stable@vger.kernel.org> # for v4.19 and up
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: gspca: fix frame overflow error

commit f96d84488f7d5f9123428c700cea82a292bca53e upstream.

When converting gspca to vb2 I missed that fact that the buffer sizes
were rounded up to the next page size. As a result some gspca drivers
(spca561 being one of them) reported frame overflows.

Modify the code to align the buffer sizes to the next page size, just
as the original code did.

Fixes: 1f5965c4dfd7 ("media: gspca: convert to vb2")
Tested-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: softwarebugs <softwarebugs@protonmail.com>
Cc: <stable@vger.kernel.org> # for v4.18 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G

commit b72f936f6b325f4fde06b02e4b6ab682f6f2e73f upstream.

Acer AIO Veriton Z4860G/Z6860G with the same ALC286 codec has issues
with the input from external microphone. The issue can be fixed by
the fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE for Veriton Z4660G.

Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G

commit 9f8aefed9623a91dec54eab8908f3810b7f8d73a upstream.

Acer AIO Veriton Z4660G with ALC286 codec has issue with the input
from external microphones connecting via 'Front Mic' jack. The fixup
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE enables the jack sensing of
the headset and fix the audio input issue of external microphone.

Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek - Add support for Acer Aspire C24-860 headset mic

commit 705b65f107470499442240ff7afee5021a7002a6 upstream.

The Acer AIO Aspire C24-860 with ALC286 can't detect the headset
microphone. Just like another Acer AIO U27-880, it needs a different
pin value for 0x18 and the headset fixup to make headset mic work.

Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880

commit 33aaebd48ae2d2c78fef5063a0381e17db19b060 upstream.

Acer Aspire U27-880(AIO) with ALC286 codec can not detect headset mic
and internal mic not working either. It needs the similar quirk like
Sony laptops to fix headphone jack sensing and enables use of the
internal microphone.

Unfortunately jack sensing for the headset mic is still not working.

Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570

commit 54947cd64c1b8290f64bb2958e343c07270e3a58 upstream.

We've got a regression report for some Thinkpad models (at least
T570s) which shows the too low speaker output volume.  The bisection
leaded to the commit 61fcf8ece9b6 ("ALSA: hda/realtek - Enable Thinkpad
Dock device for ALC298 platform"), and it's basically adding the two
pin configurations for the dock, and looks harmless.

The real culprit seems, though, that the DAC assignment for the
speaker pin is implicitly assumed on these devices, i.e. pin NID 0x14
to be coupled with DAC NID 0x03.  When more pins are configured by the
commit above, the auto-parser changes the DAC assignment, and this
resulted in the regression.

As a workaround, just provide the fixed pin / DAC mapping table for
this Thinkpad fixup function.  It's no generic solution, but the
problem itself is pretty much device-specific, so must be good
enough.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1554304
Fixes: 61fcf8ece9b6 ("ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform")
Cc: <stable@vger.kernel.org>
Reported-and-tested-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: pcm: Fix interval evaluation with openmin/max

commit 5363857b916c1f48027e9b96ee8be8376bf20811 upstream.

As addressed in alsa-lib (commit b420056604f0), we need to fix the
case where the evaluation of PCM interval "(x x+1]" leading to
-EINVAL.  After applying rules, such an interval may be translated as
"(x x+1)".

Fixes: ff2d6acdf6f1 ("ALSA: pcm: Fix snd_interval_refine first/last with open min/max")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: pcm: Call snd_pcm_unlink() conditionally at closing

commit b51abed8355e5556886623b2772fa6b7598d2282 upstream.

Currently the PCM core calls snd_pcm_unlink() always unconditionally
at closing a stream.  However, since snd_pcm_unlink() invokes the
global rwsem down, the lock can be easily contended.  More badly, when
a thread runs in a high priority RT-FIFO, it may stall at spinning.

Basically the call of snd_pcm_unlink() is required only for the linked
streams that are already rare occasion.  For normal use cases, this
code path is fairly superfluous.

As an optimization (and also as a workaround for the RT problem
above in normal situations without linked streams), this patch adds a
check before calling snd_pcm_unlink() and calls it only when needed.

Reported-by: Chanho Min <chanho.min@lge.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: pcm: Fix starvation on down_write_nonblock()

commit b888a5f713e4d17faaaff24316585a4eb07f35b7 upstream.

Commit 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM
stream") fixes deadlock for non-atomic PCM stream. But, This patch
causes antother stuck.
If writer is RT thread and reader is a normal thread, the reader
thread will be difficult to get scheduled. It may not give chance to
release readlocks and writer gets stuck for a long time if they are
pinned to single cpu.

The deadlock described in the previous commit is because the linux
rwsem queues like a FIFO. So, we might need non-FIFO writelock, not
non-block one.

My suggestion is that the writer gives reader a chance to be scheduled
by using the minimum msleep() instaed of spinning without blocking by
writer. Also, The *_nonblock may be changed to *_nonfifo appropriately
to this concept.
In terms of performance, when trylock is failed, this minimum periodic
msleep will have the same performance as the tick-based
schedule()/wake_up_q().

[ Although this has a fairly high performance penalty, the relevant
  code path became already rare due to the previous commit ("ALSA:
  pcm: Call snd_pcm_unlink() conditionally at closing").  That is, now
  this unconditional msleep appears only when using linked streams,
  and this must be a rare case.  So we accept this as a quick
  workaround until finding a more suitable one -- tiwai ]

Fixes: 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream")
Suggested-by: Wonmin Jung <wonmin.jung@lge.com>
Signed-off-by: Chanho Min <chanho.min@lge.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda: Add support for AMD Stoney Ridge

commit 3deef52ce10514ccdebba8e8ab85f9cebd0eb3f7 upstream.

It's similar to other AMD audio devices, it also supports D3, which can
save some power drain.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Fix UAF decrement if card has no live interfaces in card.c

commit 5f8cf712582617d523120df67d392059eaf2fc4b upstream.

If a USB sound card reports 0 interfaces, an error condition is triggered
and the function usb_audio_probe errors out. In the error path, there was a
use-after-free vulnerability where the memory object of the card was first
freed, followed by a decrement of the number of active chips. Moving the
decrement above the atomic_dec fixes the UAF.

[ The original problem was introduced in 3.1 kernel, while it was
  developed in a different form.  The Fixes tag below indicates the
  original commit but it doesn't mean that the patch is applicable
  cleanly. -- tiwai ]

Fixes: 362e4e49abe5 ("ALSA: usb-audio - clear chip->probing on error exit")
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Signed-off-by: Hui Peng <benquike@gmail.com>
Signed-off-by: Mathias Payer <mathias.payer@nebelwelt.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Add SMSL D1 to quirks for native DSD support

commit 44ff57e685f96d0cb9540004cc9d1d880e7a4315 upstream.

This patch adds quirk VID/PID IDs for the SMSL D1 in order to enable
Native DSD support.

[ Moved the added entry in numerical order -- tiwai ]

Signed-off-by: Tony Das <tdas444@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: console: fix reported terminal settings

commit f51ccf46217c28758b1f3b5bc0ccfc00eca658b2 upstream.

The USB-serial console implementation has never reported the actual
terminal settings used. Despite storing the corresponding cflags in its
struct console, these were never honoured on later tty open() where the
tty termios would be left initialised to the driver defaults.

Unlike the serial console implementation, the USB-serial code calls
subdriver open() already at console setup. While calling set_termios()
and write() before open() looks like it could work for some USB-serial
drivers, others definitely do not expect this, so modelling this after
serial core is going to be intrusive, if at all possible.

Instead, use a (renamed) tty helper to save the termios data used at
console setup so that the tty termios reflects the actual terminal
settings after a subsequent tty open().

Note that the calls to tty_init_termios() (tty_driver_install()) and
tty_save_termios() are serialised using the disconnect mutex.

This specifically fixes a regression that was triggered by a recent
change adding software flow control to the pl2303 driver: a getty trying
to disable flow control while leaving the baud rate unchanged would now
also set the baud rate to the driver default (prior to the flow-control
change this had been a noop).

Fixes: 7041d9c3f01b ("USB: serial: pl2303: add support for tx xon/xoff flow control")
Cc: stable <stable@vger.kernel.org> # 4.18
Cc: Florian Zumbiehl <florz@florz.de>
Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: check usb_get_extra_descriptor for proper size

commit 704620afc70cf47abb9d6a1a57f3825d2bca49cf upstream.

When reading an extra descriptor, we need to properly check the minimum
and maximum size allowed, to prevent from invalid data being sent by a
device.

Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Hui Peng <benquike@gmail.com>
Signed-off-by: Mathias Payer <mathias.payer@nebelwelt.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: appledisplay: Add 27" Apple Cinema Display

commit d7859905301880ad3e16272399d26900af3ac496 upstream.

Add another Apple Cinema Display to the list of supported displays.

Signed-off-by: Alexander Theissen <alex.theissen@me.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>