Merge branch 'ti-linux-4.14.y-next' of git.ti.com:ti-linux-kernel/ti-linux-kernel-next into ti-rt-linux-4.14.y-next

TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel-next.git
TI-Branch: ti-linux-4.14.y-next

* 'ti-linux-4.14.y-next' of git.ti.com:ti-linux-kernel/ti-linux-kernel-next:
  remoteproc/pruss: configure different internal ICSSG source clocks
  remoteproc/pruss: extend pruss_get() to scale for RTU cores
  remoteproc/pru: extend pru_rproc API to scale for RTU cores
  arm64: dts: ti: k3-am6: Add PRU system events for virtio
  arm64: dts: ti: k3-am6: Add ICSSG MDIO nodes
  arm64: dts: ti: k3-am6: Add ICSSG nodes
  ti_config_fragments: v8_rpmsg: Enable PRUSS remoteproc support
  remoteproc/pruss: enable support for ICSSG subsystems on K3 AM6x SoCs
  remoteproc/pru: add support for various PRU cores on K3 AM6x SoCs
  remoteproc/pru: introduce new custom interrupt resource for K3 AM6x SoCs
  remoteproc/pruss_intc: add support for ICSSG INTC on K3 AM6x SoCs
  dt-bindings: remoteproc: ti-pruss: Update bindings for K3 AM6x SoCs
  remoteproc/pru: use macros and types from omap mailbox
  remoteproc/pruss: select MFD_SYSCON for PRUSS

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

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

TI-Feature: suman_next
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.14.y-next

* 'rpmsg-ti-linux-4.14.y-next' of git://git.ti.com/rpmsg/rpmsg:
  remoteproc/pruss: configure different internal ICSSG source clocks
  remoteproc/pruss: extend pruss_get() to scale for RTU cores
  remoteproc/pru: extend pru_rproc API to scale for RTU cores
  arm64: dts: ti: k3-am6: Add PRU system events for virtio
  arm64: dts: ti: k3-am6: Add ICSSG MDIO nodes
  arm64: dts: ti: k3-am6: Add ICSSG nodes
  ti_config_fragments: v8_rpmsg: Enable PRUSS remoteproc support
  remoteproc/pruss: enable support for ICSSG subsystems on K3 AM6x SoCs
  remoteproc/pru: add support for various PRU cores on K3 AM6x SoCs
  remoteproc/pru: introduce new custom interrupt resource for K3 AM6x SoCs
  remoteproc/pruss_intc: add support for ICSSG INTC on K3 AM6x SoCs
  dt-bindings: remoteproc: ti-pruss: Update bindings for K3 AM6x SoCs
  remoteproc/pru: use macros and types from omap mailbox
  remoteproc/pruss: select MFD_SYSCON for PRUSS

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

remoteproc/pruss: configure different internal ICSSG source clocks

The ICSSG processor subsystems has multiple functional and interface
clock inputs like CORE_CLK, IEP_CLK, UART_CLK, ICLK etc that are sourced
from different PLLs and run at different frequences. Some of these
input clocks are configurable through external muxes, while further
muxing can be achieved on the actual internal ICSSG Core and IEP clocks
used by the ICSSG sub-modules through registers in the CFG space to
choose between the different IP-level input clocks.

The default functional source clock for IEP module within ICSSG
instances on K3 AM6x SoCs is CPSWHWDIV_CLKOUT2, which runs at a
frequency of 200 MHz. The default CORE_CLK is derived from
PER1HSDIV_CLKOUT1 and runs at a frequency of 225 MHz. The ICLK
is derived from the SYSCLK0 and runs at a frequency of 250 MHz.

Configure the internal clock muxes so that both the internal ICSSG
Core Clock and the IEP functional clock are sourced from the ICLK
(VBUSP Clock) clock input so that they run at identical speeds and
at the highest frequency of 250 MHz. This one-time configuration is
performed during the probe (resetting would require a hardware reset
of the ICSSG). This is required to get the lowest latency and achieve
high speed for various ICSSG functionalities (eg: mandatory for
achieving 1G speeds on the ICSSG Ethernet ports).

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

remoteproc/pruss: extend pruss_get() to scale for RTU cores

The pruss_get() API is used to retrieve a pruss handle from a
PRU remoteproc instance. The ICSSG IP within K3 AM6x SoCs has
two additional auxiliary PRU cores called RTUs. Extend the
rudimentary device check within pruss_get() to include the
RTU cores, so that the API works for the RTU cores as well.

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

remoteproc/pru: extend pru_rproc API to scale for RTU cores

The pru_rproc_get(), pru_rproc_put() and pru_rproc_get_id() functions
are provided for PRU clients to be able to perform various operations
on a PRU remoteproc instance. The ICSSG IP within K3 AM6x SoCs has
two additional auxiliary PRU cores called RTUs. Extend the crude
device checks performed in the above functions to include the RTU
cores, so that these API work for the RTU cores as well.

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

arm64: dts: ti: k3-am6: Add PRU system events for virtio

Two PRU system events "vring" and "kick" have been added to each
PRU and RTU node in each of the ICSSG0, ICSSG1 and ICSSG2 remote
processor subsystems to enable the virtio/rpmsg communication
between MPU and that PRU/RTU core. The additions are done in the
base k3-am6.dtsi, and so are inherited by all the K3 AM6x boards.

The PRU system events is the preferred approach over using TI
mailboxes, as it eliminates an external peripheral access from
the PRU/RTU-side, and keeps the interrupt generation internal to
the ICSSG. The difference from MPU would be minimal in using one
versus the other.

Mailboxes can still be used if desired, but currently there is
no support on firmware-side for K3 SoCs to use mailboxes. Either
approach would require that an appropriate firmware image is
loaded/booted on the PRU.

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

arm64: dts: ti: k3-am6: Add ICSSG MDIO nodes

The ICSSGs on K3 AM6x SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each ICSSG instance. The MDIO module
used within the ICSSG is similar to the MDIO Controller used
in TI Davinci SoCs. A bus frequency of 1 MHz is chosen for the
MDIO operations.

The nodes are added to the common k3-am6 dtsi file and are
disabled. These need to be enabled in the respective board files
supporting AM654 SoCs and where the ethernet is pinned out and
connected properly.

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

arm64: dts: ti: k3-am6: Add ICSSG nodes

Add the DT nodes for the ICSSG0, ICSSG1 and ICSSG2 processor subsystems
that are present on the K3 AM6x SoCs. The three ICSSGs are identical
to each other for the most part, with the ICSSG2 supporting slightly
enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance
is represented by a pruss-soc-bus node and a child PRUSS subsystem node.
These nodes are enabled by default.

The ICSSGs on K3 AM6x SoCs are super-sets of the PRUSS on the AM57xx/
6AK2G SoCs except for larger Shared Data RAM and the lack of a PRU-ICSS
crossbar. They include two auxiliary PRU cores called RTUs and few other
additional sub-modules. The interrupt integration is also different on
the K3 AM6x SoCs and are propagated through various SoC-level Interrupt
Router and Interrupt Aggregator blocks.

The ICSSG subsystem node contains the entire address space and the
various interrupts generated towards the main MPU. The various
sub-modules of the ICSSG are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child
node of its own named 'memories' without any compatible.

The DT nodes use all standard properties. The regs property in the
PRU/RTU nodes define the addresses for the Instruction RAM, the Debug
and Control sub-modules for that PRU core. The firmware for each
PRU/RTU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU and RTU core
are defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
  ICSSG0 PRU0 Core: am6x-pru0_0-fw ; ICSSG0 RTU0 Core: am6x-rtu0_0-fw
  ICSSG0 PRU1 Core: am6x-pru0_1-fw ; ICSSG0 RTU1 Core: am6x-rtu0_1-fw
  ICSSG1 PRU0 Core: am6x-pru1_0-fw ; ICSSG1 RTU0 Core: am6x-rtu1_0-fw
  ICSSG1 PRU1 Core: am6x-pru1_1-fw ; ICSSG1 RTU1 Core: am6x-rtu1_1-fw
  ICSSG2 PRU0 Core: am6x-pru2_0-fw ; ICSSG2 RTU0 Core: am6x-rtu2_0-fw
  ICSSG2 PRU1 Core: am6x-pru2_1-fw ; ICSSG2 RTU1 Core: am6x-rtu2_1-fw

TODO:
Add sub-nodes for new additional sub-modules like IEP2, MII_G_RT,
MII_RT2 etc.

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

ti_config_fragments: v8_rpmsg: Enable PRUSS remoteproc support

The PRUSS platform/remoteproc drivers are enhanced to support the newer
PRUSS IPs called ICSSG on the K3 family of SoCs. Add support to build
these PRUSS platform/remoteproc drivers including the remoteproc core
to enable the ICSSG instances. The PRU RPMsg driver and the dependent
virtio/rpmsg modules are also explicitly enabled as these are needed
to showcase the remoteproc/rpmsg communication with the PRU/RTU cores
within the ICSSG instances. All of these drivers will be built as
modules by default.

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

remoteproc/pruss: enable support for ICSSG subsystems on K3 AM6x SoCs

The K3 AM6x family of SoCs have the next generation of the PRU-ICSS
processor subsystem capable of supporting Gigabit Ethernet, and is
commonly referred to as ICSSG. These SoCs contain typically three
ICSSG instances named ICSSG0, ICSSG1 and ICSSG2. The three ICSSGs are
identical to each other for the most part with minor SoC integration
differences and capabilities. The ICSSG2 supports slightly enhanced
features like SGMII mode Ethernet, while the ICSS0 and ICSSG1 instances
are limited to MII mode only.

The ICSSGs on K3 AM6x SoCs are in general super-sets of the PRUSS on the
AM57xx/66AK2G SoCs. They include two additional auxiliary PRU cores called
RTUs and few other additional sub-modules. The interrupt integration is
also different on the K3 AM6x SoCs and are propagated through various
SoC-level Interrupt Router and Interrupt Aggregator blocks. Other IP level
differences include different constant tables, differences in system event
interrupt input sources etc. They also do not have a programmable module
reset line like those present on AM33xx/AM43xx SoCs. The modules are reset
just like any other IP with the SoC's global cold/warm resets.

The existing pruss_soc_bus and pruss platform drivers have been updated
to support these new ICSSG instances through new AM6x specific compatibles.
A build dependency with ARCH_K3 is added to enable building all the
existing PRUSS platform drivers for this ARMv8 platform. Also, select
building the OMAP Mailbox driver automatically for ARCH_K3 builds.

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

remoteproc/pru: add support for various PRU cores on K3 AM6x SoCs

The K3 AM6x family of SoCs have the next generation of the PRU-ICSS
processor subsystem, commonly referred to as ICSSG. Each ICSSG processor
subsystem contain two primary PRU cores and two new auxiliary PRU cores
called RTUs. Each RTU core has its own dedicated IRAM (smaller than a
PRU), Control and debug feature sets, but is different in terms of
sub-modules integrated around it and does not have the full capabilities
associated with a PRU core. The RTU core is typically used to aid a
PRU core in accelerating data transfers, but can also be used to run
independent applications. The RTU cores though share the same Data RAMs
as the PRU cores, so the memories have to be partitioned carefully
between different applications. The new cores also support a new
sub-module called Task Manager to support two different context thread
executions.

Enhance the existing PRU remoteproc driver to support these new PRU
and RTU cores by using specific compatibles. The initial names for the
firmware images for each PRU core are retrieved from DT nodes, and can
be adjusted through sysfs if required.

The PRU remoteproc driver has to be specifically modified to use a
custom ELF loader implementation for these new cores in order to
overcome a limitation with copying data into each of the core's IRAM
memories. These memory ports support only 4-byte writes, and any
sub-word order byte writes clear out the remaining bytes other than
the bytes being written within the containing word. The default ARM64
memcpy also cannot be used as it throws an exception when the preferred
8-byte copy operation is attempted.

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

remoteproc/pru: introduce new custom interrupt resource for K3 AM6x SoCs

The PRU-ICSS IP present within K3 AM6x SoCs, commonly called ICSSG,
has an INTC that supports more System Events (160 vs 64), more
Interrupt Channels and Host Interrupts (20 vs 10) compared to the
current generation PRUSS INTC instances. The current custom vendor
interrupt resource configuration used by the pru_rproc driver is not
adequate to support this ICSSG INTC.

Add a new version of the custom vendor interrupt resource named
fw_rsc_custom_intrmap_k3 and enhance the pru_handle_vendor_intrmap()
function to add support for configuring this newer INTC sub-module.
This new resource structure is a revised version of the existing
fw_rsc_custom_intrmap resource, with additional fields for the
increased number of channels. Support for both resource types is
provided through the PRUSS_RSC_INTRS vendor resource type and
distinguished using a version field in the sub_type. The pointer
field event_chnl_map in the existing resource type also has to
be converted into a u32 field due to the differences in the
pointer size on ARM64 and ARM32 platforms.

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

remoteproc/pruss_intc: add support for ICSSG INTC on K3 AM6x SoCs

The K3 AM6x SoCs have the next generation of the PRU-ICSS IP, commonly
called ICSSG. The PRUSS INTC present within the ICSSG supports more
System Events (160 vs 64), more Interrupt Channels and Host Interrupts
(20 vs 10) compared to the current generation PRUSS INTC instances.

Enhance the PRUSS INTC driver to add support for this ICSSG INTC
instance. This support is adding using SoC-specific data and updating
the code to use this data instead of the current hard-coded macros.
The INTC config structure is updated to use the higher events and
channels on all SoCs, while limiting the actual processing to only
the relevant number of events/channels/interrupts.

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

dt-bindings: remoteproc: ti-pruss: Update bindings for K3 AM6x SoCs

The K3 AM6x SoCs have the next generation of the PRU-ICSS IP, commonly
called ICSSG. Update the PRUSS bindings for these newer ICSSG instances.

TODO:
- Update bindings for the two IEP sub-modules, two MII_RT sub-modules
  and the new MII_G_RT sub-module present on ICSSG instances

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

remoteproc/pru: use macros and types from omap mailbox

The actual payload size for OMAP Mailboxes is 32-bits, and the type
to use with the OMAP Mailbox driver is mbox_msg_t. This type can vary
in size (32-bits or 64-bits) depending on the platform the driver is
being built for. Update the PRU remoteproc driver to use the types and
macros provided by the OMAP Mailbox driver to always convert safely
between the mailbox payload size and the pointers the data is exchanged
between the OMAP Mailbox implementation driver and its client drivers.

The OMAP Mailbox driver is built only for OMAP2+ and K3 builds. The PRU
remoteproc driver uses the OMAP mailbox types and macros unconditionally
though and do not require the OMAP Mailbox driver to be enabled. So,
define the mbox_type_t additionally for ARCH_KEYSTONE as well so that
there are no build errors seen with PRU remoteproc driver on Keystone 2
platforms.

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

remoteproc/pruss: select MFD_SYSCON for PRUSS

The PRUSS platform driver uses syscon nodes for couple of sub-modules
like IEP, MII_RT etc and relies on the syscon driver being enabled to
probe properly. So, make sure the MFD_SYSCON Kconfig option is enabled
whenever the PRUSS remoteproc driver is enabled.

The MFD_SYSCON is a boolean option, and the select dependency option
is chosen following the majority usage style within the kernel, as well
as to align with similar usage in couple of other remoteproc drivers.

Reported-by: Roger Quadros <rogerq@ti.com>
Fixes: ac0852d14216 ("remoteproc/pruss: parse various syscon nodes and store their regmaps")
Signed-off-by: Suman Anna <s-anna@ti.com>

Merge branch 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel into ti-rt-linux-4.14.y

TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y

* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel: (37 commits)
  Linux 4.14.50
  crypto: omap-sham - fix memleak
  crypto: vmx - Remove overly verbose printk from AES XTS init
  crypto: vmx - Remove overly verbose printk from AES init routines
  crypto: cavium - Limit result reading attempts
  crypto: cavium - Fix fallout from CONFIG_VMAP_STACK
  crypto: caam - fix size of RSA prime factor q
  crypto: caam/qi - fix IV DMA mapping and updating
  crypto: caam - fix IV DMA mapping and updating
  crypto: caam - fix DMA mapping dir for generated IV
  crypto: caam - strip input zeros from RSA input buffer
  Input: elan_i2c - add ELAN0612 (Lenovo v330 14IKB) ACPI ID
  Input: goodix - add new ACPI id for GPD Win 2 touch screen
  kvm: x86: use correct privilege level for sgdt/sidt/fxsave/fxrstor access
  tty: pl011: Avoid spuriously stuck-off interrupts
  vmw_balloon: fixing double free when batching mode is off
  serial: 8250: omap: Fix idling of clocks for unused uarts
  serial: samsung: fix maxburst parameter for DMA transactions
  tty/serial: atmel: use port->name as name in request_irq()
  serial: sh-sci: Stop using printk format %pCr
  ...

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

Merge tag 'v4.14.50' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-4.14.y

This is the 4.14.50 stable release

* tag 'v4.14.50' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (37 commits)
  Linux 4.14.50
  crypto: omap-sham - fix memleak
  crypto: vmx - Remove overly verbose printk from AES XTS init
  crypto: vmx - Remove overly verbose printk from AES init routines
  crypto: cavium - Limit result reading attempts
  crypto: cavium - Fix fallout from CONFIG_VMAP_STACK
  crypto: caam - fix size of RSA prime factor q
  crypto: caam/qi - fix IV DMA mapping and updating
  crypto: caam - fix IV DMA mapping and updating
  crypto: caam - fix DMA mapping dir for generated IV
  crypto: caam - strip input zeros from RSA input buffer
  Input: elan_i2c - add ELAN0612 (Lenovo v330 14IKB) ACPI ID
  Input: goodix - add new ACPI id for GPD Win 2 touch screen
  kvm: x86: use correct privilege level for sgdt/sidt/fxsave/fxrstor access
  tty: pl011: Avoid spuriously stuck-off interrupts
  vmw_balloon: fixing double free when batching mode is off
  serial: 8250: omap: Fix idling of clocks for unused uarts
  serial: samsung: fix maxburst parameter for DMA transactions
  tty/serial: atmel: use port->name as name in request_irq()
  serial: sh-sci: Stop using printk format %pCr
  ...

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

Linux 4.14.50

crypto: omap-sham - fix memleak

commit 9dbc8a0328efa485a6f5b68b867f9f523a3fbeff upstream.

Fixes: 8043bb1ae03cb ("crypto: omap-sham - convert driver logic to use sgs for data xmit")
The memory pages freed in omap_sham_finish_req() were less than those
allocated in omap_sham_copy_sgs().

Cc: stable@vger.kernel.org
Signed-off-by: Bin Liu <b-liu@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: vmx - Remove overly verbose printk from AES XTS init

commit 730f23b66095a700e2f0786abda6bca011b31558 upstream.

In p8_aes_xts_init() we do a printk(KERN_INFO ...) to report the
fallback implementation we're using. However with a slow console this
can significantly affect the speed of crypto operations. So remove it.

Fixes: c07f5d3da643 ("crypto: vmx - Adding support for XTS")
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: vmx - Remove overly verbose printk from AES init routines

commit 1411b5218adbcf1d45ddb260db5553c52e8d917c upstream.

In the vmx AES init routines we do a printk(KERN_INFO ...) to report
the fallback implementation we're using.

However with a slow console this can significantly affect the speed of
crypto operations. Using 'cryptsetup benchmark' the removal of the
printk() leads to a ~5x speedup for aes-cbc decryption.

So remove them.

Fixes: 8676590a1593 ("crypto: vmx - Adding AES routines for VMX module")
Fixes: 8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module")
Fixes: 4f7f60d312b3 ("crypto: vmx - Adding CTR routines for VMX module")
Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: cavium - Limit result reading attempts

commit c782a8c43e94ba6c09e9de2d69b5e3a5840ce61c upstream.

After issuing a request an endless loop was used to read the
completion state from memory which is asynchronously updated
by the ZIP coprocessor.

Add an upper bound to the retry attempts to prevent a CPU getting stuck
forever in case of an error. Additionally, add a read memory barrier
and a small delay between the reading attempts.

Signed-off-by: Jan Glauber <jglauber@cavium.com>
Reviewed-by: Robert Richter <rrichter@cavium.com>
Cc: stable <stable@vger.kernel.org> # 4.14
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: cavium - Fix fallout from CONFIG_VMAP_STACK

commit 37ff02acaa3d7be87ecb89f198a549ffd3ae2403 upstream.

Enabling virtual mapped kernel stacks breaks the thunderx_zip
driver. On compression or decompression the executing CPU hangs
in an endless loop. The reason for this is the usage of __pa
by the driver which does no longer work for an address that is
not part of the 1:1 mapping.

The zip driver allocates a result struct on the stack and needs
to tell the hardware the physical address within this struct
that is used to signal the completion of the request.

As the hardware gets the wrong address after the broken __pa
conversion it writes to an arbitrary address. The zip driver then
waits forever for the completion byte to contain a non-zero value.

Allocating the result struct from 1:1 mapped memory resolves this
bug.

Signed-off-by: Jan Glauber <jglauber@cavium.com>
Reviewed-by: Robert Richter <rrichter@cavium.com>
Cc: stable <stable@vger.kernel.org> # 4.14
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: caam - fix size of RSA prime factor q

commit 4bffaab373d9afaf862f3924442c33340bd26736 upstream.

Fix a typo where size of RSA prime factor q is using the size of
prime factor p.

Cc: <stable@vger.kernel.org> # 4.13+
Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2")
Fixes: 4a651b122adb ("crypto: caam - add support for RSA key form 3")
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: caam/qi - fix IV DMA mapping and updating

commit 3a488aaec6f343b5dc6d94529847a840bbeaf009 upstream.

There are two IV-related issues:
(1) crypto API does not guarantee to provide an IV buffer that is DMAable,
thus it's incorrect to DMA map it
(2) for in-place decryption, since ciphertext is overwritten with
plaintext, updated IV (req->info) will contain the last block of plaintext
(instead of the last block of ciphertext)

While these two issues could be fixed separately, it's straightforward
to fix both in the same time - by using the {ablkcipher,aead}_edesc
extended descriptor to store the IV that will be fed to the crypto engine;
this allows for fixing (2) by saving req->src[last_block] in req->info
directly, i.e. without allocating yet another temporary buffer.

A side effect of the fix is that it's no longer possible to have the IV
contiguous with req->src or req->dst.
Code checking for this case is removed.

Cc: <stable@vger.kernel.org> # 4.14+
Fixes: a68a19380522 ("crypto: caam/qi - properly set IV after {en,de}crypt")
Link: http://lkml.kernel.org/r/20170113084620.GF22022@gondor.apana.org.au
Reported-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: caam - fix IV DMA mapping and updating

commit 115957bb3e59fcb226ce76b97af14533f239e0ac upstream.

There are two IV-related issues:
(1) crypto API does not guarantee to provide an IV buffer that is DMAable,
thus it's incorrect to DMA map it
(2) for in-place decryption, since ciphertext is overwritten with
plaintext, updated req->info will contain the last block of plaintext
(instead of the last block of ciphertext)

While these two issues could be fixed separately, it's straightforward
to fix both in the same time - by allocating extra space in the
ablkcipher_edesc for the IV that will be fed to the crypto engine;
this allows for fixing (2) by saving req->src[last_block] in req->info
directly, i.e. without allocating another temporary buffer.

A side effect of the fix is that it's no longer possible to have the IV
and req->src contiguous. Code checking for this case is removed.

Cc: <stable@vger.kernel.org> # 4.13+
Fixes: 854b06f76879 ("crypto: caam - properly set IV after {en,de}crypt")
Link: http://lkml.kernel.org/r/20170113084620.GF22022@gondor.apana.org.au
Reported-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: caam - fix DMA mapping dir for generated IV

commit a38acd236cac914aafffd80af79b9556fc2c3934 upstream.

In case of GIVCIPHER, IV is generated by the device.
Fix the DMA mapping direction.

Cc: <stable@vger.kernel.org> # 3.19+
Fixes: 7222d1a34103 ("crypto: caam - add support for givencrypt cbc(aes) and rfc3686(ctr(aes))")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: caam - strip input zeros from RSA input buffer

commit 8a2a0dd35f2e54c023d9041a5428b6c5639af86c upstream.

Sometimes the provided RSA input buffer provided is not stripped
of leading zeros. This could cause its size to be bigger than that
of the modulus, making the HW complain:

caam_jr 2142000.jr1: 40000789: DECO: desc idx 7:
Protocol Size Error - A protocol has seen an error in size. When
running RSA, pdb size N < (size of F) when no formatting is used; or
pdb size N < (F + 11) when formatting is used.

Fix the problem by stripping off the leading zero from input data
before feeding it to the CAAM accelerator.

Fixes: 8c419778ab57e ("crypto: caam - add support for RSA algorithm")
Cc: <stable@vger.kernel.org> # 4.8+
Reported-by: Martin Townsend <mtownsend1973@gmail.com>
Link: https://lkml.kernel.org/r/CABatt_ytYORYKtApcB4izhNanEKkGFi9XAQMjHi_n-8YWoCRiw@mail.gmail.com
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: elan_i2c - add ELAN0612 (Lenovo v330 14IKB) ACPI ID

commit e6e7e9cd8eed0e18217c899843bffbe8c7dae564 upstream.

Add ELAN0612 to the list of supported touchpads; this ID is used in Lenovo
v330 14IKB devices.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199253
Signed-off-by: Johannes Wienke <languitar@semipol.de>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: goodix - add new ACPI id for GPD Win 2 touch screen

commit 5ca4d1ae9bad0f59bd6f851c39b19f5366953666 upstream.

GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp

Tested on a unit from the first production run sent to Indiegogo backers

Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kvm: x86: use correct privilege level for sgdt/sidt/fxsave/fxrstor access

commit 3c9fa24ca7c9c47605672916491f79e8ccacb9e6 upstream.

The functions that were used in the emulation of fxrstor, fxsave, sgdt and
sidt were originally meant for task switching, and as such they did not
check privilege levels.  This is very bad when the same functions are used
in the emulation of unprivileged instructions.  This is CVE-2018-10853.

The obvious fix is to add a new argument to ops->read_std and ops->write_std,
which decides whether the access is a "system" access or should use the
processor's CPL.

Fixes: 129a72a0d3c8 ("KVM: x86: Introduce segmented_write_std", 2017-01-12)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: pl011: Avoid spuriously stuck-off interrupts

commit 4a7e625ce50412a7711efa0f2ef0b96ce3826759 upstream.

Commit 9b96fbacda34 ("serial: PL011: clear pending interrupts")
clears the RX and receive timeout interrupts on pl011 startup, to
avoid a screaming-interrupt scenario that can occur when the
firmware or bootloader leaves these interrupts asserted.

This has been noted as an issue when running Linux on qemu [1].

Unfortunately, the above fix seems to lead to potential
misbehaviour if the RX FIFO interrupt is asserted _non_ spuriously
on driver startup, if the RX FIFO is also already full to the
trigger level.

Clearing the RX FIFO interrupt does not change the FIFO fill level.
In this scenario, because the interrupt is now clear and because
the FIFO is already full to the trigger level, no new assertion of
the RX FIFO interrupt can occur unless the FIFO is drained back
below the trigger level.  This never occurs because the pl011
driver is waiting for an RX FIFO interrupt to tell it that there is
something to read, and does not read the FIFO at all until that
interrupt occurs.

Thus, simply clearing "spurious" interrupts on startup may be
misguided, since there is no way to be sure that the interrupts are
truly spurious, and things can go wrong if they are not.

This patch instead clears the interrupt condition by draining the
RX FIFO during UART startup, after clearing any potentially
spurious interrupt.  This should ensure that an interrupt will
definitely be asserted if the RX FIFO subsequently becomes
sufficiently full.

The drain is done at the point of enabling interrupts only.  This
means that it will occur any time the UART is newly opened through
the tty layer.  It will not apply to polled-mode use of the UART by
kgdboc: since that scenario cannot use interrupts by design, this
should not matter.  kgdboc will interact badly with "normal" use of
the UART in any case: this patch makes no attempt to paper over
such issues.

This patch does not attempt to address the case where the RX FIFO
fills faster than it can be drained: that is a pathological
hardware design problem that is beyond the scope of the driver to
work around.  As a failsafe, the number of poll iterations for
draining the FIFO is limited to twice the FIFO size.  This will
ensure that the kernel at least boots even if it is impossible to
drain the FIFO for some reason.

[1] [Qemu-devel] [Qemu-arm] [PATCH] pl011: do not put into fifo
before enabled the interruption
https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg06446.html

Reported-by: Wei Xu <xuwei5@hisilicon.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>
Fixes: 9b96fbacda34 ("serial: PL011: clear pending interrupts")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: stable <stable@vger.kernel.org>
Tested-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vmw_balloon: fixing double free when batching mode is off

commit b23220fe054e92f616b82450fae8cd3ab176cc60 upstream.

The balloon.page field is used for two different purposes if batching is
on or off. If batching is on, the field point to the page which is used
to communicate with with the hypervisor. If it is off, balloon.page
points to the page that is about to be (un)locked.

Unfortunately, this dual-purpose of the field introduced a bug: when the
balloon is popped (e.g., when the machine is reset or the balloon driver
is explicitly removed), the balloon driver frees, unconditionally, the
page that is held in balloon.page.  As a result, if batching is
disabled, this leads to double freeing the last page that is sent to the
hypervisor.

The following error occurs during rmmod when kernel checkers are on, and
the balloon is not empty:

[   42.307653] ------------[ cut here ]------------
[   42.307657] Kernel BUG at ffffffffba1e4b28 [verbose debug info unavailable]
[   42.307720] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
[   42.312512] Modules linked in: vmw_vsock_vmci_transport vsock ppdev joydev vmw_balloon(-) input_leds serio_raw vmw_vmci parport_pc shpchp parport i2c_piix4 nfit mac_hid autofs4 vmwgfx drm_kms_helper hid_generic syscopyarea sysfillrect usbhid sysimgblt fb_sys_fops hid ttm mptspi scsi_transport_spi ahci mptscsih drm psmouse vmxnet3 libahci mptbase pata_acpi
[   42.312766] CPU: 10 PID: 1527 Comm: rmmod Not tainted 4.12.0+ #5
[   42.312803] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2016
[   42.313042] task: ffff9bf9680f8000 task.stack: ffffbfefc1638000
[   42.313290] RIP: 0010:__free_pages+0x38/0x40
[   42.313510] RSP: 0018:ffffbfefc163be98 EFLAGS: 00010246
[   42.313731] RAX: 000000000000003e RBX: ffffffffc02b9720 RCX: 0000000000000006
[   42.313972] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9bf97e08e0a0
[   42.314201] RBP: ffffbfefc163be98 R08: 0000000000000000 R09: 0000000000000000
[   42.314435] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffc02b97e4
[   42.314505] R13: ffffffffc02b9748 R14: ffffffffc02b9728 R15: 0000000000000200
[   42.314550] FS:  00007f3af5fec700(0000) GS:ffff9bf97e080000(0000) knlGS:0000000000000000
[   42.314599] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   42.314635] CR2: 00007f44f6f4ab24 CR3: 00000003a7d12000 CR4: 00000000000006e0
[   42.314864] Call Trace:
[   42.315774]  vmballoon_pop+0x102/0x130 [vmw_balloon]
[   42.315816]  vmballoon_exit+0x42/0xd64 [vmw_balloon]
[   42.315853]  SyS_delete_module+0x1e2/0x250
[   42.315891]  entry_SYSCALL_64_fastpath+0x23/0xc2
[   42.315924] RIP: 0033:0x7f3af5b0e8e7
[   42.315949] RSP: 002b:00007fffe6ce0148 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[   42.315996] RAX: ffffffffffffffda RBX: 000055be676401e0 RCX: 00007f3af5b0e8e7
[   42.316951] RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055be67640248
[   42.317887] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999
[   42.318845] R10: 0000000000000883 R11: 0000000000000206 R12: 00007fffe6cdf130
[   42.319755] R13: 0000000000000000 R14: 0000000000000000 R15: 000055be676401e0
[   42.320606] Code: c0 74 1c f0 ff 4f 1c 74 02 5d c3 85 f6 74 07 e8 0f d8 ff ff 5d c3 31 f6 e8 c6 fb ff ff 5d c3 48 c7 c6 c8 0f c5 ba e8 58 be 02 00 <0f> 0b 66 0f 1f 44 00 00 66 66 66 66 90 48 85 ff 75 01 c3 55 48
[   42.323462] RIP: __free_pages+0x38/0x40 RSP: ffffbfefc163be98
[   42.325735] ---[ end trace 872e008e33f81508 ]---

To solve the bug, we eliminate the dual purpose of balloon.page.

Fixes: f220a80f0c2e ("VMware balloon: add batching to the vmw_balloon.")
Cc: stable@vger.kernel.org
Reported-by: Oleksandr Natalenko <onatalen@redhat.com>
Signed-off-by: Gil Kupfer <gilkup@gmail.com>
Signed-off-by: Nadav Amit <namit@vmware.com>
Reviewed-by: Xavier Deguillard <xdeguillard@vmware.com>
Tested-by: Oleksandr Natalenko <oleksandr@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8250: omap: Fix idling of clocks for unused uarts

commit 13dc04d0e5fdc25c8f713ad23fdce51cf2bf96ba upstream.

I noticed that unused UARTs won't necessarily idle properly always
unless at least one byte tx transfer is done first.

After some debugging I narrowed down the problem to the scr register
dma configuration bits that need to be set before softreset for the
clocks to idle. Unless we do this, the module clkctrl idlest bits
may be set to 1 instead of 3 meaning the clock will never idle and
is blocking deeper idle states for the whole domain.

This might be related to the configuration done by the bootloader
or kexec booting where certain configurations cause the 8250 or
the clkctrl clock to jam in a way where setting of the scr bits
and reset is needed to clear it. I've tried diffing the 8250
registers for the various modes, but did not see anything specific.
So far I've only seen this on omap4 but I'm suspecting this might
also happen on the other clkctrl using SoCs considering they
already have a quirk enabled for UART_ERRATA_CLOCK_DISABLE.

Let's fix the issue by configuring scr before reset for basic dma
even if we don't use it. The scr register will be reset when we do
softreset few lines after, and we restore scr on resume. We should
do this for all the SoCs with UART_ERRATA_CLOCK_DISABLE quirk flag
set since the ones with UART_ERRATA_CLOCK_DISABLE are all based
using clkctrl similar to omap4.

Looks like both OMAP_UART_SCR_DMAMODE_1 | OMAP_UART_SCR_DMAMODE_CTL
bits are needed for the clkctrl to idle after a softreset.

And we need to add omap4 to also use the UART_ERRATA_CLOCK_DISABLE
for the related workaround to be enabled. This same compatible
value will also be used for omap5.

Fixes: cdb929e4452a ("serial: 8250_omap: workaround errata around idling UART after using DMA")
Cc: Keerthy <j-keerthy@ti.com>
Cc: Matthijs van Duin <matthijsvanduin@gmail.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: samsung: fix maxburst parameter for DMA transactions

commit aa2f80e752c75e593b3820f42c416ed9458fa73e upstream.

The best granularity of residue that DMA engine can report is in the BURST
units, so the serial driver must use MAXBURST = 1 and DMA_SLAVE_BUSWIDTH_1_BYTE
if it relies on exact number of bytes transferred by DMA engine.

Fixes: 62c37eedb74c ("serial: samsung: add dma reqest/release functions")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty/serial: atmel: use port->name as name in request_irq()

commit 9594b5be7ec110ed11acec58fa94f3f293668c85 upstream.

I was puzzled while looking at /proc/interrupts and random things showed
up between reboots. This occurred more often but I realised it later. The
"correct" output should be:
|38:      11861  atmel-aic5   2 Level     ttyS0

but I saw sometimes
|38:       6426  atmel-aic5   2 Level     tty1

and accounted it wrongly as correct. This is use after free and the
former example randomly got the "old" pointer which pointed to the same
content. With SLAB_FREELIST_RANDOM and HARDENED I even got
|38:       7067  atmel-aic5   2 Level     E=Started User Manager for UID 0

or other nonsense.
As it turns out the tty, pointer that is accessed in atmel_startup(), is
freed() before atmel_shutdown(). It seems to happen quite often that the
tty for ttyS0 is allocated and freed while ->shutdown is not invoked. I
don't do anything special - just a systemd boot :)

Use dev_name(&pdev->dev) as the IRQ name for request_irq(). This exists
as long as the driver is loaded so no use-after-free here.

Cc: stable@vger.kernel.org
Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close")
Acked-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: sh-sci: Stop using printk format %pCr

commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.

Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.

Replace it by open-coding the operation.  This is safe here, as the code
runs in task context.

Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas@glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable@vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

commit bd6bce004d78b867ba0c6d3712f1c5b50398af9a upstream.

This patch fixes an issue that reconnection is possible to fail
because unexpected state handling happens by the irqs. To fix the issue,
the driver disables the controller's irqs when disconnected.

Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc: <stable@vger.kernel.org> # v4.5+
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: function: printer: avoid wrong list handling in printer_write()

commit 4a014a7339f441b0851ce012f469c0fadac61c81 upstream.

When printer_write() calls usb_ep_queue(), a udc driver (e.g.
renesas_usbhs driver) may call usb_gadget_giveback_request() in
the udc .queue ops immediately. Then, printer_write() calls
list_add(&req->list, &dev->tx_reqs_active) wrongly. After that,
if we do unbind the printer driver, WARN_ON() happens in
printer_func_unbind() because the list entry is not removed.

So, this patch moves list_add(&req->list, &dev->tx_reqs_active)
calling before usb_ep_queue().

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

phy: qcom-qusb2: Fix crash if nvmem cell not specified

commit 0b4555e776ba0712c6fafb98b226b21fd05d2427 upstream.

Driver currently crashes due to NULL pointer deference
while updating PHY tune register if nvmem cell is NULL.
Since, fused value for Tune1/2 register is optional,
we'd rather bail out.

Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips")
Reviewed-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Cc: stable <stable@vger.kernel.org> # 4.14+
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: xpad - add GPD Win 2 Controller USB IDs

commit c1ba08390a8bb13c927e699330896adc15b78205 upstream.

GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp

Tested on a unit from the first production run sent to Indiegogo backers

Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb-storage: Add compatibility quirk flags for G-Technologies G-Drive

commit ca7d9515d0e6825351ce106066cea1f60e40b1c8 upstream.

The "G-Drive" (sold by G-Technology) external USB 3.0 drive
 hangs on write access under UAS and usb-storage:

[  136.079121] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  136.079144] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current]
[  136.079152] sd 15:0:0:0: [sdi] tag#0 Add. Sense: Invalid field in cdb
[  136.079176] sd 15:0:0:0: [sdi] tag#0 CDB: Write(16) 8a 08 00 00 00 00 00 00 00 00 00 00 00 08 00 00
[  136.079180] print_req_error: critical target error, dev sdi, sector 0
[  136.079183] Buffer I/O error on dev sdi, logical block 0, lost sync page write
[  136.173148] EXT4-fs (sdi): mounted filesystem with ordered data mode. Opts: (null)
[  140.583998] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  140.584010] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current]
[  140.584016] sd 15:0:0:0: [sdi] tag#0 Add. Sense: Invalid field in cdb
[  140.584022] sd 15:0:0:0: [sdi] tag#0 CDB: Write(16) 8a 08 00 00 00 00 e8 c4 00 18 00 00 00 08 00 00
[  140.584025] print_req_error: critical target error, dev sdi, sector 3905159192
[  140.584044] print_req_error: critical target error, dev sdi, sector 3905159192
[  140.584052] Aborting journal on device sdi-8.

The proposed patch adds compatibility quirks. Because the drive requires two
quirks (one to work with UAS, and another to work with usb-storage), adding this
under unusual_devs.h and not just unusual_uas.h so kernels compiled without UAS
receive the quirk. With the patch, the drive works reliably on UAS and usb-
storage.
(tested on NEC Corporation uPD720200 USB 3.0 host controller).

Signed-off-by: Alexander Kappner <agk@godking.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb-storage: Add support for FL_ALWAYS_SYNC flag in the UAS driver

commit 8c4e97ddfe73a0958bb0abf7e6a3bc4cc3e04936 upstream.

The ALWAYS_SYNC flag is currently honored by the usb-storage driver but not UAS
and is required to work around devices that become unstable upon being
queried for cache. This code is taken straight from:
drivers/usb/storage/scsiglue.c:284

Signed-off-by: Alexander Kappner <agk@godking.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbip: vhci_sysfs: fix potential Spectre v1

commit a0d6ec88090d7b1b008429c44532a388e29bb1bd upstream.

pdev_nr and rhport can be controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:
drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis'
drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential spectre issue 'vhcis'
drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_ss->vdev'
drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_hs->vdev'

Fix this by sanitizing pdev_nr and rhport before using them to index
vhcis and vhci->vhci_hcd_ss->vdev respectively.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

NFC: pn533: don't send USB data off of the stack

commit dbafc28955fa6779dc23d1607a0fee5e509a278b upstream.

It's amazing that this driver ever worked, but now that x86 doesn't
allow USB data to be sent off of the stack, it really does not work at
all.  Fix this up by properly allocating the data for the small
"commands" that get sent to the device off of the stack.

We do this for one command by having a whole urb just for ack messages,
as they can be submitted in interrupt context, so we can not use
usb_bulk_msg().  But the poweron command can sleep (and does), so use
usb_bulk_msg() for that transfer.

Reported-by: Carlos Manuel Santos <cmmpsantos@gmail.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: android: ion: Switch to pr_warn_once in ion_buffer_destroy

commit 45ad559a29629cb1c64ee636563c69b71524f077 upstream.

Syzbot reported yet another warning with Ion:

WARNING: CPU: 0 PID: 1467 at drivers/staging/android/ion/ion.c:122
ion_buffer_destroy+0xd4/0x190 drivers/staging/android/ion/ion.c:122
Kernel panic - not syncing: panic_on_warn set ...

This is catching that a buffer was freed with an existing kernel mapping
still present. This can be easily be triggered from userspace by calling
DMA_BUF_SYNC_START without calling DMA_BUF_SYNC_END. Switch to a single
pr_warn_once to indicate the error without being disruptive.

Reported-by: syzbot+cd8bcd40cb049efa2770@syzkaller.appspotmail.com
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: pass kvm_vcpu to kvm_read_guest_virt and kvm_write_guest_virt_system

commit ce14e868a54edeb2e30cb7a7b104a2fc4b9d76ca upstream.

Int the next patch the emulator's .read_std and .write_std callbacks will
grow another argument, which is not needed in kvm_read_guest_virt and
kvm_write_guest_virt_system's callers.  Since we have to make separate
functions, let's give the currently existing names a nicer interface, too.

Fixes: 129a72a0d3c8 ("KVM: x86: Introduce segmented_write_std", 2017-01-12)
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kvm: nVMX: Enforce cpl=0 for VMX instructions

commit 727ba748e110b4de50d142edca9d6a9b7e6111d8 upstream.

VMX instructions executed inside a L1 VM will always trigger a VM exit
even when executed with cpl 3. This means we must perform the
privilege check in software.

Fixes: 70f3aac964ae("kvm: nVMX: Remove superfluous VMX instruction fault checks")
Cc: stable@vger.kernel.org
Signed-off-by: Felix Wilhelm <fwilhelm@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: introduce linear_{read,write}_system

commit 79367a65743975e5cac8d24d08eccc7fdae832b0 upstream.

Wrap the common invocation of ctxt->ops->read_std and ctxt->ops->write_std, so
as to have a smaller patch when the functions grow another argument.

Fixes: 129a72a0d3c8 ("KVM: x86: Introduce segmented_write_std", 2017-01-12)
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: X86: Fix reserved bits check for MOV to CR3

commit a780a3ea628268b2ad0ed43d7f28d90db0ff18be upstream.

MSB of CR3 is a reserved bit if the PCIDE bit is not set in CR4.
It should be checked when PCIDE bit is not set, however commit
'd1cd3ce900441 ("KVM: MMU: check guest CR3 reserved bits based on
its physical address width")' removes the bit 63 checking
unconditionally. This patch fixes it by checking bit 63 of CR3
when PCIDE bit is not set in CR4.

Fixes: d1cd3ce900441 (KVM: MMU: check guest CR3 reserved bits based on its physical address width)
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Liran Alon <liran.alon@oracle.com>
Cc: stable@vger.kernel.org
Reviewed-by: Junaid Shahid <junaids@google.com>
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

gpio: No NULL owner

commit 7d18f0a14aa6a0d6bad39111c1fb655f07f71d59 upstream.

Sometimes a GPIO is fetched with NULL as parent device, and
that is just fine. So under these circumstances, avoid using
dev_name() to provide a name for the GPIO line.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

af_key: Always verify length of provided sadb_key

commit 4b66af2d6356a00e94bcdea3e7fea324e8b5c6f4 upstream.

Key extensions (struct sadb_key) include a user-specified number of key
bits.  The kernel uses that number to determine how much key data to copy
out of the message in pfkey_msg2xfrm_state().

The length of the sadb_key message must be verified to be long enough,
even in the case of SADB_X_AALG_NULL.  Furthermore, the sadb_key_len value
must be long enough to include both the key data and the struct sadb_key
itself.

Introduce a helper function verify_key_len(), and call it from
parse_exthdrs() where other exthdr types are similarly checked for
correctness.

Signed-off-by: Kevin Easton <kevin@guarana.org>
Reported-by: syzbot+5022a34ca5a3d49b84223653fab632dfb7b4cf37@syzkaller.appspotmail.com
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Zubin Mithra <zsm@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

blkdev_report_zones_ioctl(): Use vmalloc() to allocate large buffers

commit 327ea4adcfa37194739f1ec7c70568944d292281 upstream.

Avoid that complaints similar to the following appear in the kernel log
if the number of zones is sufficiently large:

  fio: page allocation failure: order:9, mode:0x140c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null)
  Call Trace:
  dump_stack+0x63/0x88
  warn_alloc+0xf5/0x190
  __alloc_pages_slowpath+0x8f0/0xb0d
  __alloc_pages_nodemask+0x242/0x260
  alloc_pages_current+0x6a/0xb0
  kmalloc_order+0x18/0x50
  kmalloc_order_trace+0x26/0xb0
  __kmalloc+0x20e/0x220
  blkdev_report_zones_ioctl+0xa5/0x1a0
  blkdev_ioctl+0x1ba/0x930
  block_ioctl+0x41/0x50
  do_vfs_ioctl+0xaa/0x610
  SyS_ioctl+0x79/0x90
  do_syscall_64+0x79/0x1b0
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

Fixes: 3ed05a987e0f ("blk-zoned: implement ioctls")
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
Cc: Shaun Tancheff <shaun.tancheff@seagate.com>
Cc: Damien Le Moal <damien.lemoal@hgst.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: fix NULL pointer dereference on nft_ct_helper_obj_dump()

commit b71534583f22d08c3e3563bf5100aeb5f5c9fbe5 upstream.

In the nft_ct_helper_obj_dump(), always priv->helper4 is dereferenced.
But if family is ipv6, priv->helper6 should be dereferenced.

Steps to reproduces:

   #test.nft
   table ip6 filter {
   ct helper ftp {
   type "ftp" protocol tcp
   }
   chain input {
   type filter hook input priority 4;
   ct helper set "ftp"
   }
   }

   %nft -f test.nft
   %nft list ruleset

we can see the below messages:

[  916.286233] kasan: GPF could be caused by NULL-ptr deref or user memory access
[  916.294777] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[  916.302613] Modules linked in: nft_objref nf_conntrack_sip nf_conntrack_snmp nf_conntrack_broadcast nf_conntrack_ftp nft_ct nf_conntrack nf_tables nfnetlink [last unloaded: nfnetlink]
[  916.318758] CPU: 1 PID: 2093 Comm: nft Not tainted 4.17.0-rc4+ #181
[  916.326772] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
[  916.338773] RIP: 0010:strlen+0x1a/0x90
[  916.342781] RSP: 0018:ffff88010ff0f2f8 EFLAGS: 00010292
[  916.346773] RAX: dffffc0000000000 RBX: ffff880119b26ee8 RCX: ffff88010c150038
[  916.354777] RDX: 0000000000000002 RSI: ffff880119b26ee8 RDI: 0000000000000010
[  916.362773] RBP: 0000000000000010 R08: 0000000000007e88 R09: ffff88010c15003c
[  916.370773] R10: ffff88010c150037 R11: ffffed002182a007 R12: ffff88010ff04040
[  916.378779] R13: 0000000000000010 R14: ffff880119b26f30 R15: ffff88010ff04110
[  916.387265] FS:  00007f57a1997700(0000) GS:ffff88011b800000(0000) knlGS:0000000000000000
[  916.394785] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  916.402778] CR2: 00007f57a0ac80f0 CR3: 000000010ff02000 CR4: 00000000001006e0
[  916.410772] Call Trace:
[  916.414787]  nft_ct_helper_obj_dump+0x94/0x200 [nft_ct]
[  916.418779]  ? nft_ct_set_eval+0x560/0x560 [nft_ct]
[  916.426771]  ? memset+0x1f/0x40
[  916.426771]  ? __nla_reserve+0x92/0xb0
[  916.434774]  ? memcpy+0x34/0x50
[  916.434774]  nf_tables_fill_obj_info+0x484/0x860 [nf_tables]
[  916.442773]  ? __nft_release_basechain+0x600/0x600 [nf_tables]
[  916.450779]  ? lock_acquire+0x193/0x380
[  916.454771]  ? lock_acquire+0x193/0x380
[  916.458789]  ? nf_tables_dump_obj+0x148/0xcb0 [nf_tables]
[  916.462777]  nf_tables_dump_obj+0x5f0/0xcb0 [nf_tables]
[  916.470769]  ? __alloc_skb+0x30b/0x500
[  916.474779]  netlink_dump+0x752/0xb50
[  916.478775]  __netlink_dump_start+0x4d3/0x750
[  916.482784]  nf_tables_getobj+0x27a/0x930 [nf_tables]
[  916.490774]  ? nft_obj_notify+0x100/0x100 [nf_tables]
[  916.494772]  ? nf_tables_getobj+0x930/0x930 [nf_tables]
[  916.502579]  ? nf_tables_dump_flowtable_done+0x70/0x70 [nf_tables]
[  916.506774]  ? nft_obj_notify+0x100/0x100 [nf_tables]
[  916.514808]  nfnetlink_rcv_msg+0x8ab/0xa86 [nfnetlink]
[  916.518771]  ? nfnetlink_rcv_msg+0x550/0xa86 [nfnetlink]
[  916.526782]  netlink_rcv_skb+0x23e/0x360
[  916.530773]  ? nfnetlink_bind+0x200/0x200 [nfnetlink]
[  916.534778]  ? debug_check_no_locks_freed+0x280/0x280
[  916.542770]  ? netlink_ack+0x870/0x870
[  916.546786]  ? ns_capable_common+0xf4/0x130
[  916.550765]  nfnetlink_rcv+0x172/0x16c0 [nfnetlink]
[  916.554771]  ? sched_clock_local+0xe2/0x150
[  916.558774]  ? sched_clock_cpu+0x144/0x180
[  916.566575]  ? lock_acquire+0x380/0x380
[  916.570775]  ? sched_clock_local+0xe2/0x150
[  916.574765]  ? nfnetlink_net_init+0x130/0x130 [nfnetlink]
[  916.578763]  ? sched_clock_cpu+0x144/0x180
[  916.582770]  ? lock_acquire+0x193/0x380
[  916.590771]  ? lock_acquire+0x193/0x380
[  916.594766]  ? lock_acquire+0x380/0x380
[  916.598760]  ? netlink_deliver_tap+0x262/0xa60
[  916.602766]  ? lock_acquire+0x193/0x380
[  916.606766]  netlink_unicast+0x3ef/0x5a0
[  916.610771]  ? netlink_attachskb+0x630/0x630
[  916.614763]  netlink_sendmsg+0x72a/0xb00
[  916.618769]  ? netlink_unicast+0x5a0/0x5a0
[  916.626766]  ? _copy_from_user+0x92/0xc0
[  916.630773]  __sys_sendto+0x202/0x300
[  916.634772]  ? __ia32_sys_getpeername+0xb0/0xb0
[  916.638759]  ? lock_acquire+0x380/0x380
[  916.642769]  ? lock_acquire+0x193/0x380
[  916.646761]  ? finish_task_switch+0xf4/0x560
[  916.650763]  ? __schedule+0x582/0x19a0
[  916.655301]  ? __sched_text_start+0x8/0x8
[  916.655301]  ? up_read+0x1c/0x110
[  916.655301]  ? __do_page_fault+0x48b/0xaa0
[  916.655301]  ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[  916.655301]  __x64_sys_sendto+0xdd/0x1b0
[  916.655301]  do_syscall_64+0x96/0x3d0
[  916.655301]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  916.655301] RIP: 0033:0x7f57a0ff5e03
[  916.655301] RSP: 002b:00007fff6367e0a8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[  916.655301] RAX: ffffffffffffffda RBX: 00007fff6367f1e0 RCX: 00007f57a0ff5e03
[  916.655301] RDX: 0000000000000020 RSI: 00007fff6367e110 RDI: 0000000000000003
[  916.655301] RBP: 00007fff6367e100 R08: 00007f57a0ce9160 R09: 000000000000000c
[  916.655301] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff6367e110
[  916.655301] R13: 0000000000000020 R14: 00007f57a153c610 R15: 0000562417258de0
[  916.655301] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 fa 53 48 c1 ea 03 48 b8 00 00 00 00 00 fc ff df 48 89 fd 48 83 ec 08 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f
[  916.655301] RIP: strlen+0x1a/0x90 RSP: ffff88010ff0f2f8
[  916.771929] ---[ end trace 1065e048e72479fe ]---
[  916.777204] Kernel panic - not syncing: Fatal exception
[  916.778158] Kernel Offset: 0x14000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel into ti-rt-linux-4.14.y

TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y

* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
  ARM64: dts: k3-am6: Add Main System Control Module node
  ti_config_fragments: v8_baseport: Enable NAVSS drivers
  arm64: dts: ti: k3-am6: Add mcasp nodes
  arm64: dts: ti: k3-am6: Add nodes for pdma_main0 and pdma_main1
  arm64: dts: ti: k3-am6: add navss nodes
  dmaengine: ti: New driver for K3 UDMA
  dt-bindings: dma: ti: Add document for K3 NAVSS UDMAP
  dmaengine: ti: New directory for Texas Instruments DMA drivers
  dmaengine: Add metadat_ops for dma_async_tx_descriptor
  dmaengine: Add function to request slave channel from a dma_device
  dmaengine: Add callback to set per descriptor metadata
  dmaengine: Add support for reporting DMA cached data amount
  soc: ti: k3: navss: add initial PSI-L management driver
  bindings: soc: ti: Add documentation for k3 psilcfg
  soc: ti: k3: add dma descs pool
  soc: ti: k3: add CPPI5 description and helpers
  soc: ti: k3: add navss ringacc driver
  bindings: soc: ti: add documentation for k3 ringacc
  firmware: ti_sci: Update the UDMAP related comments

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

Merge branch 'platform-ti-linux-4.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.14.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.14.y

* 'platform-ti-linux-4.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  ARM64: dts: k3-am6: Add Main System Control Module node
  ti_config_fragments: v8_baseport: Enable NAVSS drivers
  arm64: dts: ti: k3-am6: Add mcasp nodes
  arm64: dts: ti: k3-am6: Add nodes for pdma_main0 and pdma_main1
  arm64: dts: ti: k3-am6: add navss nodes
  dmaengine: ti: New driver for K3 UDMA
  dt-bindings: dma: ti: Add document for K3 NAVSS UDMAP
  dmaengine: ti: New directory for Texas Instruments DMA drivers
  dmaengine: Add metadat_ops for dma_async_tx_descriptor
  dmaengine: Add function to request slave channel from a dma_device
  dmaengine: Add callback to set per descriptor metadata
  dmaengine: Add support for reporting DMA cached data amount
  soc: ti: k3: navss: add initial PSI-L management driver
  bindings: soc: ti: Add documentation for k3 psilcfg
  soc: ti: k3: add dma descs pool
  soc: ti: k3: add CPPI5 description and helpers
  soc: ti: k3: add navss ringacc driver
  bindings: soc: ti: add documentation for k3 ringacc
  firmware: ti_sci: Update the UDMAP related comments

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

ARM64: dts: k3-am6: Add Main System Control Module node

Main System control module support is added to the device tree to allow
driver to access to their control module registers.

Signed-off-by: Benoit Parrot <bparrot@ti.com>

ti_config_fragments: v8_baseport: Enable NAVSS drivers

Enable PSI-L, Ring Accelerator and DMA drivers.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

arm64: dts: ti: k3-am6: Add mcasp nodes

In am6xx we have 3 McASP instances.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

arm64: dts: ti: k3-am6: Add nodes for pdma_main0 and pdma_main1

The PDMAs are servicing legacy peripherals (ones that does not have native
PSI-L support), like McASP, USART, etc.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

arm64: dts: ti: k3-am6: add navss nodes

AM6xx SoC has two navss modules in Main (navss256) and MCU domains, add
corresponding nodes. Each navss module contains:
- Ring accelerator HW block
- Unified DMA Channel Controller
- Packet Streaming Interface Link (PSI-L)

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

dmaengine: ti: New driver for K3 UDMA

Supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet / TR mode)
- MEM_TO_DEV (Packet / TR mode)
- Cyclic (Packet / TR mode)
- Metadata for descriptors

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

dt-bindings: dma: ti: Add document for K3 NAVSS UDMAP

New binding document for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P).

UDMA-P is introduced as part of the K3 architecture and can be found on
AM65x SoC.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

dmaengine: ti: New directory for Texas Instruments DMA drivers

Move the DMA drivers for Texas Instruments under drivers/dma/ti/

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

dmaengine: Add metadat_ops for dma_async_tx_descriptor

If the DMA supports per descriptor metadata it can implement the attach,
get_ptr/set_len callbacks.

Client drivers must only use either attach or get_ptr/set_len to avoid
miss configuration.

Wrappers are also added for the metadata_ops:
dmaengine_desc_attach_metadata()
dmaengine_desc_get_metadata_ptr()
dmaengine_desc_set_metadata_len()

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

dmaengine: Add function to request slave channel from a dma_device

dma_get_any_slave_channel() would skip using the filter function, which
in some cases needed to be executed before the alloc_chan_resources
callback to make sure that all parameters are provided for the slave
channel.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

dmaengine: Add callback to set per descriptor metadata

Some DMA engines can send and receive side band information, commands or
parameters which is not transferred within the data stream itself. In such
case clients can set the metadata to the given descriptor and it is going
to be sent to the peripheral, or in case of DEV_TO_MEM the provided buffer
will receive the metadata.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

dmaengine: Add support for reporting DMA cached data amount

A DMA hardware can have big cache or FIFO and the amount of data sitting in
the DMA fabric can be an interest for the clients.

For example in audio we want to know the delay in the data flow and in case
the DMA have significantly large FIFO/cache, it can affect the latenc/delay

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

soc: ti: k3: navss: add initial PSI-L management driver

Simple driver to handle PSI-L configuration via tisci protocol.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

bindings: soc: ti: Add documentation for k3 psilcfg

The PSI-L is used to transfer words of packet data and control information
between two peer entities via direct connection.
The PSI-L config module can be found as part of the NAVSS module of AM65x
SoCs.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

soc: ti: k3: add dma descs pool

changes:
- k3: navss: dma-descs-pool: add k3_knav_pool_avail api
 Add new API k3_knav_pool_avail() to get number of available descs.
- k3: navss: dma-descs-pool: fix desc pool create
  Fix mem chank size allocated for pool. it should use
  desc_size aligned to the minimal ^2.
  Allow create named pools which is required by genpool if
  driver whant to have more than one.

Squashed commits (PU):
k3: navss: add dma descs pool (initial)
soc: ti: k3: desc-pool: switch to SPDX Licensing

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

soc: ti: k3: add CPPI5 description and helpers

Add TI Communications Port Programming Interface (CPPI) 5
descriptor's description and helpers functions.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

soc: ti: k3: add navss ringacc driver

The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
enable straightforward passing of work between a producer and a consumer.
There is one RINGACC module per NAVSS on TI AM65x SoCs.

The RINGACC converts constant-address read and write accesses to equivalent
read or write accesses to a circular data structure in memory. The RINGACC
eliminates the need for each DMA controller which needs to access ring
elements from having to know the current state of the ring (base address,
current offset). The DMA controller performs a read or write access to a
specific address range (which maps to the source interface on the RINGACC)
and the RINGACC replaces the address for the transaction with a new address
which corresponds to the head or tail element of the ring (head for reads,
tail for writes). Since the RINGACC maintains the state, multiple DMA
controllers or channels are allowed to coherently share the same rings as
applicable. The RINGACC is able to place data which is destined towards
software into cached memory directly.

Supported ring modes:
- Ring Mode
- Messaging Mode
- Credentials Mode
- Queue Manager Mode

TI-SCI integration:

Texas Instrument's System Control Interface (TI-SCI) Message Protocol now
has control over Ringacc module resources management (RM) and Rings
configuration.

The corresponding support of TI-SCI Ringacc module RM protocol
introduced as option through DT parameters:
  - ti,sci: phandle on TI-SCI firmware controller DT node
  - ti,sci-dev-id: TI-SCI device identifier as per TI-SCI firmware spec

if both parameters present - Ringacc driver will configure/free/reset Rings
using TI-SCI Message Ringacc RM Protocol.

The Ringacc driver manages Rings allocation by itself now and requests
TI-SCI firmware to allocate and configure specific Rings only. It's done
this way because, Linux driver implements two stage Rings allocation and
configuration (allocate ring and configure ring) while I-SCI Message
Protocol supports only one combined operation (allocate+configure).

Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

bindings: soc: ti: add documentation for k3 ringacc

The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
enable straightforward passing of work between a producer and a consumer.
There is one RINGACC module per NAVSS on TI AM65x SoCs.

This patch introduces RINGACC device tree bindings.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

firmware: ti_sci: Update the UDMAP related comments

Add missing comments in the ti_sci.h and correct the comment section in
ti_sci_protocol.h for UDMAP.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

Merge branch 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel into ti-rt-linux-4.14.y

TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y

* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
  arm64: dts: ti: k3-am6: Add IPC sub-mailbox nodes for R5Fs
  arm64: dts: ti: k3-am6: Add mailbox cluster nodes
  ti_config_fragments: v8_rpmsg: Enable OMAP Mailbox support
  mailbox/omap: add support for TI K3 SoCs
  dt-bindings: mailbox: omap: Update bindings for TI K3 SoCs
  mailbox/omap: use of_device_get_match_data() to get match data
  ti_config_fragments: v8_rpmsg: Enable OMAP HwSpinlock driver
  arm64: dts: ti: k3-am6: Add hwspinlock node
  hwspinlock/omap: Add support for TI K3 SoCs
  hwspinlock/omap: Add a trace during probe
  ti_config_fragments: v8_defconfig_map: Add v8 rpmsg config file
  ti_config_fragments: rpmsg: Add RPMsg domain config fragment file

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

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

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

* 'rpmsg-ti-linux-4.14.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  arm64: dts: ti: k3-am6: Add IPC sub-mailbox nodes for R5Fs
  arm64: dts: ti: k3-am6: Add mailbox cluster nodes
  ti_config_fragments: v8_rpmsg: Enable OMAP Mailbox support
  mailbox/omap: add support for TI K3 SoCs
  dt-bindings: mailbox: omap: Update bindings for TI K3 SoCs
  mailbox/omap: use of_device_get_match_data() to get match data
  ti_config_fragments: v8_rpmsg: Enable OMAP HwSpinlock driver
  arm64: dts: ti: k3-am6: Add hwspinlock node
  hwspinlock/omap: Add support for TI K3 SoCs
  hwspinlock/omap: Add a trace during probe
  ti_config_fragments: v8_defconfig_map: Add v8 rpmsg config file
  ti_config_fragments: rpmsg: Add RPMsg domain config fragment file

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

arm64: dts: ti: k3-am6: Add IPC sub-mailbox nodes for R5Fs

Add the sub-mailbox nodes that are used to communicate between
MPU and the two R5F remote processors present in the MCU domain.
The parent mailbox cluster nodes are enabled and the interrupts
associated with the Mailbox Cluster User interrupt used by the
sub-mailbox nodes are also added. The GIC_SPI interrupt to be
used is dynamically allocated and managed by the System Firmware
through the ti-sci-irqchip driver.

The sub-mailbox nodes utilize the System Mailbox clusters 1 and 2.
These sub-mailbox nodes are added to match the hard-coded mailbox
configuration used within the TI IPC 3.x software package. The
Cortex R5F processor sub-system is assumed to be running in Split
mode, so a sub-mailbox node is used by each of the R5F cores. The
sub-mailbox node from cluster 1 is used in case of Lockstep mode.

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

arm64: dts: ti: k3-am6: Add mailbox cluster nodes

The AM6x Main NavSS block contains a Mailbox IP instance with
multiple clusters. Each cluster is equivalent to an Mailbox IP
instance on OMAP platforms.

Add all the Mailbox clusters as their own nodes under the soc
node instead of creating an almost empty parent node for the
new K3 mailbox IP and the clusters as its child nodes. All these
nodes are marked as disabled, and they need to be enabled along
with the appropriate child nodes on a need basis.

NOTE:
The NavSS only has a limited number of interrupts, so all the
interrupts generated by a Mailbox IP are not added by default.
Only the needed interrupts that are targeted towards the A53
GIC will need to be be added later on when some sub-mailbox
child nodes are added.

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

ti_config_fragments: v8_rpmsg: Enable OMAP Mailbox support

Add support to build the OMAP Mailbox driver, required for remote
processor messaging with the R5F remoteprocs on the K3 AM6x family
of SoCs. The Mailbox driver is chosen to be built-in by default.

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

mailbox/omap: add support for TI K3 SoCs

The TI K3 AM6x family of SoCs have a new Mailbox IP that is based
on the existing Mailbox IP present in OMAP architecture based SoCs.
Each instance of the legacy OMAP Mailbox IP is now a single cluster
within the newer Mailbox IP instance on K3 architecture based SoCs.
A single K3 Mailbox IP instance has multiple clusters with each
cluster providing the exact same functionality as the existing
OMAP Mailbox IP.

Reuse the existing OMAP Mailbox driver to extend the support for
the newer IP present within the Main NavSS block on K3 SoCs. The
K3 family of SoCs use a 64-bit ARMv8 processors for running Linux,
so the driver is also enhanced to deal with the differences between
the 32-bit message payloads and the 64-bit pointers used by the
client drivers.

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

dt-bindings: mailbox: omap: Update bindings for TI K3 SoCs

The TI K3 AM6x family of SoCs have a new Mailbox IP that is based
on the existing Mailbox IP present in OMAP architecture based SoCs.
Update the existing OMAP Mailbox bindings for this new IP present
on TI K3 SoCs.

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

mailbox/omap: use of_device_get_match_data() to get match data

The OMAP Mailbox driver is directly using an integer value as
match data for distinguishing the interrupt register layout
between OMAP2 and OMAP4+ SoCs. Introduce a dedicated structure
for storing this match data, and simplify the probe function by
using the of_device_get_match_data() function. This allows the
driver to scale for 64-bit platforms by eliminating the unnecessary
type-casting between a u32 and a void pointer types.

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

ti_config_fragments: v8_rpmsg: Enable OMAP HwSpinlock driver

The OMAP HwSpinlock driver is reused for supporting the HwSpinlock
IP within K3 platforms. So, enable both the HwSpinlock core and the
OMAP HwSpinlock driver in the rpmsg config file. There are currently
no direct users of the HwSpinlock IP, but the built-in is the
preferred choice for this driver.

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

arm64: dts: ti: k3-am6: Add hwspinlock node

The Main NavSS block on AM6x SoCs contains a HwSpinlock IP instance
that is similar to the IP on some OMAP SoCs. Add the DT node for
this on AM6x SoCs. The node is present within the NavSS block, and
is added as a child node under the soc0 node following the current
flat hierarchy representation of the devices.

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

hwspinlock/omap: Add support for TI K3 SoCs

The HwSpinlock IP is also present on the newer TI K3 AM6x family of
SoCs. Reuse the existing OMAP Hwspinlock driver to extend the support
for this IP on K3 AM6x SoCs as well.

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

hwspinlock/omap: Add a trace during probe

Add a debug level trace statement in the OMAP HwSpinlock driver
probe function to print a successful registration.

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

ti_config_fragments: v8_defconfig_map: Add v8 rpmsg config file

Add the RPMsg domain config fragment file v8_ipc.cfg file for
all the defconfigs in the v8 defconfig map file, so that the
various RPMsg related drivers can be enabled and built using
the defconfig builder tool for K3 platforms.

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

ti_config_fragments: rpmsg: Add RPMsg domain config fragment file

Add an initial IPC/RPMsg domain config fragment file. This will
form the foundation for adding all the RPMsg related module
configurations for K3 platforms.

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

Merge branch 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel into ti-rt-linux-4.14.y

TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y

* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
  ti_config_fragments: v8_baseport: Enable TI_SCI_IRQCHIP
  arm64: dts: ti: k3-am6: Add TI SCI irqchip node
  irqchip: tisci: Add the TI SCI irqchip driver
  dt-bindings: irqchip: Introduce TI SCI irqchip bindings
  irqchip: Add Kconfig menu
  ti_config_fragments: v8_baseport: Enable GPIO_DAVINCI
  arm64: dts: ti: AM6: Add gpio nodes
  gpio: davinci: Fix the compiler warning with ARM64 config enabled
  gpio: davinci: Do not assume continuous IRQ numbering
  gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe
  gpio: Davinci: Add K3 Specific dependencies

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

Merge branch 'platform-ti-linux-4.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.14.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.14.y

* 'platform-ti-linux-4.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  ti_config_fragments: v8_baseport: Enable TI_SCI_IRQCHIP
  arm64: dts: ti: k3-am6: Add TI SCI irqchip node
  irqchip: tisci: Add the TI SCI irqchip driver
  dt-bindings: irqchip: Introduce TI SCI irqchip bindings
  irqchip: Add Kconfig menu
  ti_config_fragments: v8_baseport: Enable GPIO_DAVINCI
  arm64: dts: ti: AM6: Add gpio nodes
  gpio: davinci: Fix the compiler warning with ARM64 config enabled
  gpio: davinci: Do not assume continuous IRQ numbering
  gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe
  gpio: Davinci: Add K3 Specific dependencies

Signed-off-by: Dan Murphy <dmurphy@ti.com>

ti_config_fragments: v8_baseport: Enable TI_SCI_IRQCHIP

Enable TI SCI irqchip support for K3 platforms.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

arm64: dts: ti: k3-am6: Add TI SCI irqchip node

Add an irqchip node for configuring IRQ routes between peripherals
and host processors over TI SCI protocol.

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

irqchip: tisci: Add the TI SCI irqchip driver

Some TI SoCs contain a system controller (like the Device Memory and
Security Controller on K3 AM654 SoC) that are responsible for configuring
the SoC IRQ routes between peripherals and host processors and
coprocessors. Communication between the host processor running an OS
and the system controller happens through a protocol called TI System
Control Interface (TI-SCI protocol).

This patch adds an irqchip driver that communicates to the system
controller over the TI SCI protocol for IRQ routes between peripherals and
host processors and coprocessors.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

dt-bindings: irqchip: Introduce TI SCI irqchip bindings

Add TI SCI irqchip binding. This describes the DT binding
details for an irq controller node that supports IRQ route
programming from devices to host using the Texas Instrument's System
Control Interface (TI SCI) protocol to communicate to a system controller
block present on the SoC.

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

irqchip: Add Kconfig menu

commit c94fb639d5462027004ed8f5f71288955688a4ae upstream.

Add a menu for IRQ chip drivers. This makes the Device drivers menu be more
consistent (listing "subsystems" instead of specific options) and makes the
IRQCHIP options be listed in expected places for 'make menu|xconfig'.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jason Cooper <jason@lakedaemon.net>
Link: https://lkml.kernel.org/r/3db7385a-c6a1-5c93-0797-6f4b6b2b2cde@infradead.org
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

ti_config_fragments: v8_baseport: Enable GPIO_DAVINCI

Enable GPIO_DAVINCI for K3 platforms.

Signed-off-by: Keerthy <j-keerthy@ti.com>

arm64: dts: ti: AM6: Add gpio nodes

Add gpio0 and gpio1 nodes under MAIN domain and gpio2
under WAKEUP domain.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

gpio: davinci: Fix the compiler warning with ARM64 config enabled

Fix the compiler warning with ARM64 config enabled

Signed-off-by: Keerthy <j-keerthy@ti.com>