remoteproc: add infrastructure support to allow pre-loaded remoteprocs

The remoteproc infrastructure is enhanced to allow remoteproc drivers to
be able to connect to already loaded and/or booted remote processors. The
added infrastructure is designed to allow multiple different scenarios:
 - Support userspace driven loading, with the actual boot triggered
   through the kernel.
 - Support remote processors loaded and booted by bootloaders, with
   resource table either directly provided by the remoteproc driver or
   by remoteproc core by requesting the firmware and processing only
   the resource table.

Support for these features are provided through two new fields in the
rproc structure - 'skip_firmware_request' and 'skip_load'. These fields
are expected to be set to true as per the mode/need required by the
remoteproc drivers before a rproc_add() call. The remoteproc core skips
looking for firmware and/or loading any firmware segments using these two
state flags. The default behavior is unchanged.

The interface and implementation details for either of the above scenarios
is left to the individual remoteproc drivers. This design will be used
to achieve the following different usecases on TI SoCs:
 - Allow the TI Keystone remoteproc driver to support a userspace based
   loader. The remoteproc driver is expected to invoke rproc_boot() and
   rproc_shutdown() for triggering the boot and shutdown of the remote
   processor after the loading is completed and the resource table
   information is published to the remoteproc driver. The resource
   table is processed in-line during the rproc_boot() invocation.
 - Allow the K3 R5F remoteproc driver to be invoked in an IPC-only mode
   (No load, boot or error recovery functionality, but only establish
   IPC mechanism). The driver relies on still using the regular state
   machine flow for creating the virtio devices. The rproc .start() and
   .stop() ops are not bypassed, and the actual boot bypass is implemented
   within the driver.

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

TEMP: samples/rpmsg: add compatible to support PDK IPC firmware images

Add a specific compatible "ti.ipc4.ping-pong" to the rpmsg client device
list so that the rpmsg client sample device published and used by the
PDK IPC sample firmware images can properly probe the rpmsg_client_sample
driver and provide a means to unit-test the rpmsg communication with the
various remote processors on both AM65x and J721E SoCs.

This is needed because the current firmwares do not have support for the
enhanced name service announcement mechanism, and are not using the
standard "rpmsg-client-sample" device.

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

arm64: dts: ti: k3-j721e: Add aliases for R5F rproc nodes

Add aliases for all the R5F remoteproc processor cores present
within the MCU domain and MAIN domains and common to all the K3
J721E boards. The aliases uses the stem "rproc". Note that each
of the R5F1 cores and their corresponding aliases are uniquely
identified and used only if the corresponding R5F cluster/subsystem
is running in Split (non-LockStep) mode.

The aliases can be overridden, if needed, in the respective
derivative board dts files.

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

arm64: dts: ti: k3-j721e-som-p0: Reserve memory for IPC between RTOS cores

Add a reserved memory node to reserve a portion of the DDR memory to be
used for performing inter-processor communication between all the remote
processors running RTOS on the TI J721E EVM boards. 28 MB of memory is
reserved for this purpose, and this accounts for all the vrings and vring
buffers between all the possible pairs of remote processors.

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

arm64: dts: ti: k3-j721e-som-p0: Add DDR carveout memory nodes for R5Fs

Two carveout reserved memory nodes each have been added for each of the
R5F remote processor devices within both the MCU and MAIN domains on the
TI J721E EVM boards. These nodes are assigned to the respective rproc
device nodes as well. The first region will be used as the DMA pool for
the rproc devices, and the second region will furnish the static carveout
regions for the firmware memory.

The current carveout addresses and sizes are defined statically for each
device. The R5F processors do not have an MMU, and as such require the
exact memory used by the firmwares to be set-aside. The firmware images
do not require any RSC_CARVEOUT entries in their resource tables to
allocate the memory for firmware memory segments.

Note that the R5F1 carveouts are needed only if the R5F cluster is running
in Split (non-LockStep) mode. The reserved memory nodes can be disabled
later on if there is no use-case defined to use the corresponding
remote processor.

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

arm64: dts: ti: k3-j721e-common-proc-board: Add mailboxes to R5Fs

Add the required 'mboxes' property to all the R5F processors on the
TI J721E common processor board. The mailboxes and some shared memory
are required for running the Remote Processor Messaging (RPMsg) stack
between the host processor and each of the R5Fs. The chosen sub-mailboxes
match the values used in the current firmware images. This can be changed,
if needed, as per the system integration needs after making appropriate
changes on the firmware side as well.

Note that any R5F Core1 resources are needed and used only when that
R5F cluster is configured for Split-mode.

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

arm64: dts: ti: k3-j721e-main: Configure MAIN R5FSS0 for Split-mode

Switch the MAIN R5FSS0 cluster to be configured for Split-mode as the
default so that two different applications can be run on each of the
R5F cores in performance mode.

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

arm64: dts: ti: k3-j721e-main: Add MAIN domain R5F cluster nodes

The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.

Add the DT nodes for these two MAIN domain R5F cluster/subsystems,
the two R5F cores are each added as child nodes to the corresponding
main cluster node. Both the clusters are configured to run in LockStep
mode by default, with the ATCMs enabled to allow the R5 cores to execute
code from DDR with boot-strapping code from ATCM. The inter-processor
communication between the main A72 cores and these processors is
achieved through shared memory and Mailboxes.

The following firmware names are used by default for these cores, and
can be overridden in a board dts file if needed:
    MAIN R5FSS0 Core0: j7-main-r5f0_0-fw (both in LockStep and Split modes)
    MAIN R5FSS0 Core1: j7-main-r5f0_1-fw (needed only in Split mode)
    MAIN R5FSS1 Core0: j7-main-r5f1_0-fw (both in LockStep and Split modes)
    MAIN R5FSS1 Core1: j7-main-r5f1_1-fw (needed only in Split mode)

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

arm64: dts: ti: k3-j721e-mcu: Add MCU domain R5F cluster node

The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.

Add the DT node for the MCU domain R5F cluster/subsystem, the two
R5F cores are added as child nodes to the main cluster/subsystem node.
The cluster is configured to run in LockStep mode by default, with the
ATCMs enabled to allow the R5 cores to execute code from DDR with
boot-strapping code from ATCM. The inter-processor communication
between the main A72 cores and these processors is achieved through
shared memory and Mailboxes.

The following firmware names are used by default for these cores, and
can be overridden in a board dts file if needed:
    MCU R5FSS0 Core0: j7-mcu-r5f0_0-fw (both in LockStep and Split modes)
    MCU R5FSS0 Core1: j7-mcu-r5f0_1-fw (needed only in Split mode)

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

arm64: dts: ti: k3-am65-mcu: Reserve some MCU SRAM for MCU R5F0

Add a child SRAM node to reserve a portion of the MCU domain on-chip
SRAM memory for use by the MCU domain R5F Core0. A preliminary size
of 256 KB (half of the current SRAM) is reserved to begin with and
can be adjusted as per need.

This memory is also added to the R5F0 remoteproc node using the
sram property.

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

arm64: dts: ti: k3-am65: Add aliases for R5F rproc nodes

Add aliases for both the R5F remoteproc processor cores present
within the MCU domain and common to all K3 AM65x boards. The aliases
uses the stem "rproc". Note that the R5F1 core and it's alias is
uniquely identified and used only if the R5F cluster/subsystem is
running in Split (non-LockStep) mode.

The aliases can be overridden, if needed, in the respective
derivative board dts files.

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

TEMP: arm64: dts: ti: k3-am654-base-board: Increase reserve memory for RTOS IPC

A 1 MB of carveout memory at 0xa2000000 is reserved currently for achieving
IPC between the two MCU R5F cores when running in split-mode. The PDK IPC
RTOS code though is currently accessing some memory beyond this 1 MB, used
to also achieve IPC with the A53 cores running RTOS (Linux uses a separate
1 MB region per core as part of the overall 16 MB region). Reserve an
additional 1 MB of memory temporarily until the RTOS code logic is fixed
up to avoid memory corruptions with the linux kernel.

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

arm64: dts: ti: k3-am654-base-board: Reserve memory for IPC between R5F cores

Add a reserved memory node to reserve a portion of the DDR memory to be
used for performing inter-processor communication between all the MCU R5F
remote processors running RTOS on all the TI AM654 boards. This memory
shall be exercised only if the MCU R5FSS cluster is configured for Split
mode.  A single 1 MB of memory at 0xa2000000 is reserved for this purpose,
and this accounts for all the vrings and vring buffers between pair of
these R5F remote processors.

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

arm64: dts: ti: k3-am654-base-board: Add DDR carveout memory nodes for R5Fs

The R5F processors do not have an MMU, and as such require the exact memory
used by the firmwares to be set-aside. Four carveout reserved memory nodes
have been added with two each (1 MB and 15 MB in size) used for each of the
MCU R5F remote processor devices on all the K3 AM65x boards. These nodes
are assigned to the respective rproc device nodes as well.

The current carveout addresses and sizes are defined statically for each
device. The first region will be used as the DMA pool for the rproc
devices, and the second region will furnish the static carveout regions
for the firmware memory.

Note that the R5F1 carveouts are needed only if the corresponding R5F
cluster is running in Split (non-LockStep) mode. The corresponding
reserved memory nodes can be disabled later on if there is no use-case
defined to use the corresponding remote processor.

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

arm64: dts: ti: k3-am654-base-board: Add mailboxes to R5Fs

Add the required 'mboxes' property to both the R5F processors on all
the K3 AM65x boards. The mailboxes and some shared memory are required
for running the Remote Processor Messaging (RPMsg) stack between the
host processor and each of the R5Fs. The chosen sub-mailboxes match the
values used in the current firmware images. This can be changed, if
needed, as per the system integration needs after making appropriate
changes on the firmware side as well.

Note that the R5F Core1 resources are needed and used only when the
R5F cluster is configured for Split-mode.

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

arm64: dts: ti: k3-am65-mcu: Add MCU domain R5F cluster node

The AM65x SoCs have a single dual-core Arm Cortex-R5F processor (R5FSS)
subsystem/cluster. This R5F cluster (MCU_R5FSS0) is present within the
MCU domain, and can be configured at boot time to be either run in a
LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in
Split-mode. This subsystem has 64 KB each Tightly-Coupled Memory (TCM)
internal memories for each core split between two banks - TCMA and TCMB
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5F clusters such as the absence of an ACP
port, presence of an additional TI-specific Region Address Translater
(RAT) module for translating 32-bit CPU addresses into larger system
bus addresses etc.

Add the DT node for this R5F cluster/subsystem, the two R5F cores are
added as child nodes to the main cluster node. The cluster is configured
to run in LockStep mode by default, with the ATCMs enabled to allow the
R5 cores to execute code from DDR with boot-strapping code from ATCM.
The inter-processor communication between the main A53 cores and these
processors is achieved through shared memory and Mailboxes.

The following firmware names are used by default for these cores, and
can be overridden in a board dts file if needed:
    am65x-mcu-r5f0_0-fw (LockStep mode and for Core0 in Split mode)
    am65x-mcu-r5f0_1-fw (Core1 in Split mode)

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

remoteproc/k3-r5: add a trace to print missing ids

The remoteproc fixed ids for TI K3 R5F remoteprocs are required
by some rpmsg client drivers to identify a remote processor in
a fixed manner to userspace. Add a trace during probe to warn
developers if this unique id (alias id for DT devices) is not
defined for the TI K3 R5F remoteproc devices.

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

remoteproc/k3-r5: Add loading support for on-chip SRAM regions

The K3 SoCs has various internal on-chip SRAM memories like the SRAM
within the MCU domain or the shared MSMC RAM within NavSS that can be
used for multiple purposes. One such purpose is to have the R5F cores
use a portion of such on-chip SRAM for fast-access data or to directly
execute code.

Add support to the K3 R5 remoteproc driver to parse and support
loading into such memories. The SRAM regions need to be mapped as
normal non-cacheable memory to avoid kernel crashes when the remoteproc
loader code uses the Arm64 memset library function (the "DC ZVA"
instruction throws a alignment fault on device type memory).

These SRAM regions are completely optional as not all firmware images
require these memories, and any such memory has to be reserved as such
in the DTS files.

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

remoteproc/k3-r5: Initialize TCM memories for ECC

The R5F processors on K3 SoCs all have two TCMs (ATCM and BTCM) that
support 32-bit ECC. The TCMs are typically loaded with some boot-up
code to initialize the R5 MPUs to further execute code out of DDR.
The ECC for the TCMs is enabled by default on K3 SoCs due to internal
default tie-off values, but the TCM memories are not initialized on
device power up. Any read access without the corresponding TCM memory
location initialized will generate an ECC error, and any such access
from a A72 or A53 core will trigger a SError.

So, zero initialize both the TCM memories before loading any firmware
onto a R5F in remoteproc mode. Any R5F booted from U-Boot/SPL would
require a similar initialization in the bootloader. Note that both
the TCMs are initialized unconditionally as the TCM enable config bits
only manage the access and visibility from R5. The Core1 TCMs are not
used and accessible in LockStep mode, so they are only initialized
in Split-mode.

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

remoteproc/k3-r5: Add a remoteproc driver for R5F subsystem

The TI K3 family of SoCs typically have one or more dual-core Arm Cortex
R5F processor clusters/subsystems (R5FSS). This R5F subsystem/cluster
can be configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. This subsystem
has 64 KB each Tightly-Coupled Memory (TCM) internal memories for each
core split between two banks - TCMA and TCMB (further interleaved into
two banks). The subsystem does not have an MMU, but has a Region Address
Translater (RAT) module that is accessible only from the R5Fs for providing
translations between 32-bit CPU addresses into larger system bus addresses.

Add a remoteproc driver to support this subsystem to be able to load and
boot the R5F cores primarily in LockStep mode. The code also includes the
base support for Split mode. Error Recovery and Power Management features
are not currently supported. Loading support includes the internal TCMs
and DDR. RAT support is left for a future patch, and as such the reserved
memory carveout regions are all expected to be using memory regions within
the first 2 GB.

The R5F remote processors do not have an MMU, and so require fixed memory
carveout regions matching the firmware image addresses. Support for this
is provided by mandating multiple memory regions to be attached to the
remoteproc device. The first memory region will be used to serve as the
DMA pool for all dynamic allocations like the vrings and vring buffers.
The remaining memory regions are mapped into the kernel at device probe
time, and are used to provide address translations for firmware image
segments without the need for any RSC_CARVEOUT entries. Any firmware
image using memory outside of the supplied reserved memory carveout
regions will be errored out.

The R5F processors on TI K3 SoCs require a specific sequence for booting
and shutting down the processors. This sequence is also dependent on the
mode (LockStep or Split) the R5F cluster is configured for. The R5F cores
have a Memory Protection Unit (MPU) that has a default configuration that
does not allow the cores to run out of DDR out of reset. This is resolved
by using the TCMs for boot-strapping code that applies the appropriate
executable permissions on desired DDR memory. The loading into the TCMs
requires that the resets be released first with the cores in halted state.
The Power Sleep Controller (PSC) module on K3 SoCs requires that the cores
be in WFI/WFE states with no active bus transactions before the cores can
be put back into reset. Support for this is provided by using the newly
introduced .prepare() and .unprepare() ops in the remoteproc core. The
.prepare() ops is invoked before any loading, and the .unprepare() ops
is invoked after the remoteproc resource cleanup. The R5F core resets
are deasserted in .prepare() and asserted in .unprepare(), and the cores
themselves are started and halted in .start() and .stop() ops. This
ensures symmetric usage and allows the R5F cores state machine to be
maintained properly between using the sysfs 'state' variable, bind/unbind
and regular module load/unload flows.

The subsystem is represented as a single remoteproc in LockStep mode, and
as two remoteprocs in Split mode. The driver uses various TI-SCI interfaces
to talk to the System Controller (DMSC) for managing configuration, power
and reset management of these cores. IPC between the A53 cores and the R5
cores is supported through the virtio rpmsg stack using shared memory and
OMAP Mailboxes.

The AM65x SoCs typically have a single R5FSS in the MCU voltage domain. The
J721E SoCs uses a slightly revised IP and typically have three R5FSSs, with
one cluster present within the MCU voltage domain (MCU_R5FSS0), and the
remaining two clusters present in the MAIN voltage domain (MAIN_R5FSS0 and
MAIN_R5FSS1). The integration of these clusters on J721E SoC is also
slightly different in that these IPs do support an actual local reset line,
while they are a no-op on AM65x SoCs.

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

remoteproc/k3-r5: Add TI-SCI processor control helper functions

Texas Instruments' K3 generation SoCs have specific modules/register
spaces used for configuring the various aspects of a remote processor.
These include power, reset, boot vector and other configuration features
specific to each compute processor present on the SoC. These registers
are managed by the System Controller such as DMSC on K3 AM65x SoCs.

The Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used to communicate to the System Controller from various compute
processors to invoke specific services provided by the firmware running
on the System Controller.

Add a common processor control interface header file that can be used by
multiple remoteproc drivers. The helper functions within this header file
abstract the various TI SCI protocol ops for the remoteproc drivers, and
allow them to request the System Controller to be able to program and
manage various remote processors on the SoC. The remoteproc drivers are
expected to manage the life-cycle of their ti_sci_proc_dev local
structures.

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

dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs

The Texas Instruments K3 family of SoCs have one or more dual-core
Arm Cortex R5F processor subsystems/clusters (R5FSS). The clusters
can be split between multiple voltage domains as well. Add the device
tree bindings document for these R5F subsystem devices. These R5F
processors do not have an MMU, and so require fixed memory carveout
regions matching the firmware image addresses. The nodes require more
than one memory region, with the first memory region used for DMA
allocations at runtime. The remaining memory regions are reserved
and are used for the loading and running of the R5F remote processors.
The R5F processors can also optionally use any internal on-chip SRAM
memories either for executing code or using it as fast-access data.

The added example illustrates the DT nodes for the single R5FSS device
present on K3 AM65x family of SoCs.

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

remoteproc: use a local copy for the name field

The current name field used in the remoteproc structure is simply
a pointer to a name field supplied during the rproc_alloc() call.
The pointer passed in by remoteproc drivers during registration is
typically a dev_name pointer, but it is possible that the pointer
will no longer remain valid if the devices themselves were created
at runtime like in the case of of_platform_populate(), and were
deleted upon any failures within the respective remoteproc driver
probe function.

So, allocate and maintain a local copy for this name field to
keep it agnostic of the logic used in the remoteproc drivers.

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

remoteproc: add prepare and unprepare ops

On some SoC architecture, it is needed to enable HW like
clock, bus, regulator, memory region... before loading
co-processor firmware.

This patch introduces prepare and unprepare ops to execute
platform specific function before firmware loading and after
stop execution.

Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
[s-anna@ti.com: cherry-pick linux-remoteproc patchwork id '10251897']
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/omap: Check for undefined mailbox messages

Add some checks in the mailbox callback function to limit
any processing in the mailbox callback function to only
certain currently valid messages, and drop all the remaining
messages. A debug message is added to print any such invalid
messages when the appropriate trace control is enabled.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

Merge branch 'mailbox-linux-5.4.y' of git://git.ti.com/rpmsg/mailbox into rproc-linux-5.4.y

Pull in the mailbox feature branch into the remoteproc tree, for adding
remoteproc support patches for booting the various remote processors
present on TI K3 SoCs. The merge primarily includes all backported
patches from upstream - one a minor fix in the OMAP Mailbox driver,
and others adding the sub-mailboxes used to communicate with the R5F
and DSP processors on K3 AM65x and J721E SoCs.

The sub-mailboxes required to communicate with various IPU and DSP
processors on OMAP4+ SoCs on applicable TI boards are all upstream.

* 'mailbox-linux-5.4.y' of git://git.ti.com/rpmsg/mailbox:
  arm64: dts: ti: k3-j721e-common-proc-board: Add IPC sub-mailbox nodes
  arm64: dts: ti: k3-j721e-main: Add mailbox cluster nodes
  arm64: dts: ti: k3-am65-base-board: Add IPC sub-mailbox nodes for R5Fs
  arm64: dts: ti: k3-am65-main: Add mailbox cluster nodes
  mailbox/omap: Handle if CONFIG_PM is disabled

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

ARM: dts: da850: Add alias for DSP node

Add alias for the lone DSP remoteproc processor node present
on the OMAP-L13x/DA8xx SoCs. The alias uses the stem "rproc".
The alias is added to assign a fixed remoteproc id to the DSP
processor.

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

remoteproc/davinci: Add a trace to print missing ids

The remoteproc fixed ids for Davinci remoteprocs are required
by some rpmsg client drivers to identify a remote processor in
a fixed manner to userspace. Add a trace during probe to warn
developers if this unique id (alias id for DT devices and platform
device id for non-DT devices) is not defined for the DSP remoteproc
device.

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

remoteproc/davinci: Switch a debug trace statement to use %pK

Modify a debug trace statement to use %pK instead of %p for printing
the kernel virtual address for the mapped DSP internal memory regions.
The latter always prints a hashed address, and switching to %pK allows
the actual mapped address to be printed under proper conditions (by
writing a proper value to /proc/sys/kernel/kptr_restrict). The default
behavior is unchanged.

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

remoteproc: fall back to using parent memory pool if no dedicated available

In some cases, like with OMAP remoteproc, we are not creating dedicated
memory pool for the virtio device. Instead, we use the same memory pool
for all shared memories. The current virtio memory pool handling forces
a split between these two, as a separate device is created for it,
causing memory to be allocated from bad location if the dedicated pool
is not available. Fix this by falling back to using the parent device
memory pool if dedicated is not available.

Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Tero Kristo <t-kristo@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]
[s-anna@ti.com: cherry-pick https://patchwork.kernel.org/patch/11096599/ ]
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>

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: Fix and restore the parenting hierarchy for vdev

The commit 086d08725d34 ("remoteproc: create vdev subdevice with specific
dma memory pool") has introduced a new vdev subdevice for each vdev
declared in the firmware resource table and made it as the parent for the
created virtio rpmsg devices instead of the previous remoteproc device.
This changed the overall parenting hierarchy for the rpmsg devices, which
were children of virtio devices, and does not allow the corresponding
rpmsg drivers to retrieve the parent rproc device through the
rproc_get_by_child() API.

Fix this by restoring the remoteproc device as the parent. The new vdev
subdevice can continue to inherit the DMA attributes from the remoteproc's
parent device (actual platform device).

Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Suman Anna <s-anna@ti.com>

rpmsg: Fix Kconfig indentation

[ Upstream commit 8cf9b615653e40debdcf3b6f1d69e6b580d71173 ]

Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^        /\t/' -i */Kconfig

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191120133945.13938-1-krzk@kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '8cf9b615653e' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>

rpmsg: char: Simplify 'rpmsg_eptdev_release()'

[ Upstream commit bb06a5ce88fd3489d2415470b20ab949550a62ec ]

Use 'skb_queue_purge()' instead of re-implementing it.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'bb06a5ce88fd' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>

rpmsg: char: release allocated memory

[ Upstream commit bbe692e349e2a1edf3fe0a29a0e05899c9c94d51 ]

In rpmsg_eptdev_write_iter, if copy_from_iter_full fails the allocated
buffer needs to be released.

Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'bbe692e349e2' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: Fix wrong rvring index computation

[ Upstream commit 00a0eec59ddbb1ce966b19097d8a8d2f777e726a ]

Index of rvring is computed using pointer arithmetic. However, since
rvring->rvdev->vring is the base of the vring array, computation
of rvring idx should be reversed. It previously lead to writing at negative
indices in the resource table.

Signed-off-by: Clement Leger <cleger@kalray.eu>
Link: https://lore.kernel.org/r/20191004073736.8327-1-cleger@kalray.eu
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '00a0eec59ddb' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: fix argument 2 of rproc_mem_entry_init

[ Upstream commit 99cf0361e7af29511309804bbedd240bf939cebd ]

The rproc_mem_entry_init() call takes a pointer to a vm
as the second argument. The code is currently using a
plain 0 as "NULL". Change to using NULL to fix the
following sparse warnings:

drivers/remoteproc/remoteproc_core.c:339:49: warning: Using plain integer as NULL pointer
drivers/remoteproc/remoteproc_core.c:916:46: warning: Using plain integer as NULL pointer

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '99cf0361e7af' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: debug: Remove unneeded NULL check

[ Upstream commit 0ad82e3a2234dfa38ec835d1772e8c9af176d458 ]

debugfs_remove_recursive will do NULL check, so remove
the redundant null check

Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '0ad82e3a2234' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: remove useless typedef

[ Upstream commit 006d72da28db06a0762b1f536458ac1a9a4ba8d1 ]

rproc_handle_resources_t is not used anymore, remove it.

Signed-off-by: Clement Leger <cleger@kalray.eu>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '006d72da28db' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>

arm64: dts: ti: k3-j721e-common-proc-board: Add IPC sub-mailbox nodes

[ Upstream commit eb9f9173d01f8983d16b3cf4f0798f6381812779 ]

Add the sub-mailbox nodes that are used to communicate between MPU and
various remote processors present in the J721E SoCs to the J721E common
processor board. These include the R5F remote processors in the dual-R5F
cluster (MCU_R5FSS0) in the MCU domain and the two dual-R5F clusters
(MAIN_R5FSS0 & MAIN_R5FSS1) in the MAIN domain; the two C66x DSP remote
processors and the single C71x DSP remote processor in the MAIN domain.
These sub-mailbox nodes utilize the System Mailbox clusters 0 through 4.
All the remaining mailbox clusters are currently not used on A72 core,
and so are disabled.

The sub-mailbox nodes added match the hard-coded mailbox configuration
used within the TI RTOS IPC software packages. The R5F processor
sub-systems are assumed to be running in Split mode, so a sub-mailbox
node is used by each of the R5F cores. Only the sub-mailbox node for
the first R5F core in each cluster is used in case of a Lockstep mode
for that R5F cluster.

NOTE:
The GIC_SPI interrupts to be used are dynamically allocated and managed
by the System Firmware through the ti-sci-intr irqchip driver. So, only
valid interrupts (each cluster's User 0 IRQ output) that are used by the
sub-mailbox devices are enabled. This is done to minimize the number of
NavSS Interrupt Router outputs utilized.

[s-anna@ti.com: cherry-pick commit 'eb9f9173d01f' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm64: dts: ti: k3-j721e-main: Add mailbox cluster nodes

[ Upstream commit 56f185826db242dcd2831e5432045821a114366a ]

The J721E 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 MAIN
NavSS cbass_main_navss interconnect 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 enabled by default in the
base dtsi file, but any cluster that does not define any child
sub-mailbox nodes should be disabled in the corresponding board
dts files.

NOTE:
The NavSS only has a limited number of interrupts, so none of the
interrupts generated by a Mailbox IP are added by default. Only
the needed interrupts that are targeted towards the A72 GIC will
have to be added later on in the board dts files alongside the
corresponding sub-mailbox child nodes.

[s-anna@ti.com: cherry-pick commit '56f185826db2' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm64: dts: ti: k3-am65-base-board: Add IPC sub-mailbox nodes for R5Fs

[ Upstream commit 43570f78a25ca18d09a1455a764ca198e9af9060 ]

Add the sub-mailbox nodes that are used to communicate between MPU and
the two R5F remote processors present in the MCU domain to the AM654
EVM base board. These sub-mailbox nodes utilize the System Mailbox
clusters 0 and 1. 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-intr irqchip driver. All the remaining
mailbox clusters are currently not used on A53 core, and so are disabled.

The sub-mailbox nodes added match the hard-coded mailbox configuration
used within the TI RTOS IPC software packages. 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. Only the sub-mailbox node from cluster 0
is used in case of Lockstep mode.

[s-anna@ti.com: cherry-pick commit '43570f78a25c' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm64: dts: ti: k3-am65-main: Add mailbox cluster nodes

[ Upstream commit 500f1ff97af9c23bce87dcc7c0e882ee074d33a1 ]

The AM65x 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 MAIN
NavSS cbass_main_navss interconnect 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 enabled by default in the
base dtsi file, but any cluster that does not define any child
sub-mailbox nodes should be disabled in the corresponding board
dts files.

NOTE:
The NavSS only has a limited number of interrupts, so none of the
interrupts generated by a Mailbox IP are added by default. Only
the needed interrupts that are targeted towards the A53 GIC will
have to be added later on in the board dts files alongside the
corresponding sub-mailbox child nodes.

[s-anna@ti.com: cherry-pick commit '500f1ff97af9' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

mailbox/omap: Handle if CONFIG_PM is disabled

[ Upstream commit 0434d3f4525af32bc29f858f71300351041f552d ]

If CONFIG_PM is disabled, pm_runtime_put_sync() returns -ENOSYS.

Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
[s-anna@ti.com: cherry-pick commit '0434d3f4525a' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>

Linux 5.4

Merge branch 'fixes' of git://git./linux/kernel/git/viro/vfs

Pull cramfs fix from Al Viro:
 "Regression fix, fallen through the cracks"

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  cramfs: fix usage on non-MTD device

cramfs: fix usage on non-MTD device

When both CONFIG_CRAMFS_MTD and CONFIG_CRAMFS_BLOCKDEV are enabled, if
we fail to mount on MTD, we don't try on block device.

Note: this relies upon cramfs_mtd_fill_super() leaving no side
effects on fc state in case of failure; in general, failing
get_tree_...() does *not* mean "fine to try again"; e.g. parsed
options might've been consumed by fill_super callback and freed
on failure.

Fixes: 74f78fc5ef43 ("vfs: Convert cramfs to use the new mount API")

Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge tag 'for_linus' of git://git./linux/kernel/git/mst/vhost

Pull last minute virtio bugfixes from Michael Tsirkin:
 "Minor bugfixes all over the place"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  virtio_balloon: fix shrinker count
  virtio_balloon: fix shrinker scan number of pages
  virtio_console: allocate inbufs in add_port() only if it is needed
  virtio_ring: fix return code on DMA mapping fails

Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

Pull input fix from Dmitry Torokhov:
 "Just a single revert as RMI mode should not have been enabled for this
  model [yet?]"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Revert "Input: synaptics - enable RMI mode for X1 Extreme 2nd Generation"

Revert "Input: synaptics - enable RMI mode for X1 Extreme 2nd Generation"

This reverts commit 68b9c5066e39af41d3448abfc887c77ce22dd64d.

Ugh, I really dropped the ball on this one :\. So as it turns out RMI4
works perfectly fine on the X1 Extreme Gen 2 except for one thing I
didn't notice because I usually use the trackpoint: clicking with the
touchpad. Somehow this is broken, in fact we don't even seem to indicate
BTN_LEFT as a valid event type for the RMI4 touchpad. And, I don't even
see any RMI4 events coming from the touchpad when I press down on it.
This only seems to work for PS/2 mode.

Since that means we have a regression, and PS/2 mode seems to work fine
for the time being - revert this for now. We'll have to do a more
thorough investigation on this.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://lore.kernel.org/r/20191119234534.10725-1-lyude@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge git://git./linux/kernel/git/netdev/net

Pull networking fixes from David Miller:

 1) Validate tunnel options length in act_tunnel_key, from Xin Long.

 2) Fix DMA sync bug in gve driver, from Adi Suresh.

 3) TSO kills performance on some r8169 chips due to HW issues, disable
    by default in that case, from Corinna Vinschen.

 4) Fix clock disable mismatch in fec driver, from Chubong Yuan.

 5) Fix interrupt status bits define in hns3 driver, from Huazhong Tan.

 6) Fix workqueue deadlocks in qeth driver, from Julian Wiedmann.

 7) Don't napi_disable() twice in r8152 driver, from Hayes Wang.

 8) Fix SKB extension memory leak, from Florian Westphal.

* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (54 commits)
  r8152: avoid to call napi_disable twice
  MAINTAINERS: Add myself as maintainer of virtio-vsock
  udp: drop skb extensions before marking skb stateless
  net: rtnetlink: prevent underflows in do_setvfinfo()
  can: m_can_platform: remove unnecessary m_can_class_resume() call
  can: m_can_platform: set net_device structure as driver data
  hv_netvsc: Fix send_table offset in case of a host bug
  hv_netvsc: Fix offset usage in netvsc_send_table()
  net-ipv6: IPV6_TRANSPARENT - check NET_RAW prior to NET_ADMIN
  sfc: Only cancel the PPS workqueue if it exists
  nfc: port100: handle command failure cleanly
  net-sysfs: fix netdev_queue_add_kobject() breakage
  r8152: Re-order napi_disable in rtl8152_close
  net: qca_spi: Move reset_count to struct qcaspi
  net: qca_spi: fix receive buffer size check
  net/ibmvnic: Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode
  Revert "net/ibmvnic: Fix EOI when running in XIVE mode"
  net/mlxfw: Verify FSM error code translation doesn't exceed array size
  net/mlx5: Update the list of the PCI supported devices
  net/mlx5: Fix auto group size calculation
  ...

afs: Fix large file support

By default s_maxbytes is set to MAX_NON_LFS, which limits the usable
file size to 2GB, enforced by the vfs.

Commit b9b1f8d5930a ("AFS: write support fixes") added support for the
64-bit fetch and store server operations, but did not change this value.
As a result, attempts to write past the 2G mark result in EFBIG errors:

 $ dd if=/dev/zero of=foo bs=1M count=1 seek=2048
 dd: error writing 'foo': File too large

Set s_maxbytes to MAX_LFS_FILESIZE.

Fixes: b9b1f8d5930a ("AFS: write support fixes")
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

afs: Fix possible assert with callbacks from yfs servers

Servers sending callback breaks to the YFS_CM_SERVICE service may
send up to YFSCBMAX (1024) fids in a single RPC.  Anything over
AFSCBMAX (50) will cause the assert in afs_break_callbacks to trigger.

Remove the assert, as the count has already been checked against
the appropriate max values in afs_deliver_cb_callback and
afs_deliver_yfs_cb_callback.

Fixes: 35dbfba3111a ("afs: Implement the YFS cache manager service")
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

r8152: avoid to call napi_disable twice

Call napi_disable() twice would cause dead lock. There are three situations
may result in the issue.

1. rtl8152_pre_reset() and set_carrier() are run at the same time.
2. Call rtl8152_set_tunable() after rtl8152_close().
3. Call rtl8152_set_ringparam() after rtl8152_close().

For #1, use the same solution as commit 84811412464d ("r8152: Re-order
napi_disable in rtl8152_close"). For #2 and #3, add checking the flag
of IFF_UP and using napi_disable/napi_enable during mutex.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'akpm' (patches from Andrew)

Merge misc fixes from Andrew Morton:
 "Three fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  mm/ksm.c: don't WARN if page is still mapped in remove_stable_node()
  mm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span()
  Revert "fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()"

Merge tag 'linux-can-fixes-for-5.4-20191122' of git://git./linux/kernel/git/mkl/linux-can

Marc Kleine-Budde says:

====================
pull-request: can 2019-11-22

this is a pull request of 2 patches for net/master, if possible for the
current release cycle. Otherwise these patches should hit v5.4 via the
stable tree.

Both patches of this pull request target the m_can driver. Pankaj Sharma
fixes the fallout in the m_can_platform part, which appeared with the
introduction of the m_can platform framework.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

MAINTAINERS: Add myself as maintainer of virtio-vsock

Since I'm actively working on vsock and virtio/vhost transports,
Stefan suggested to help him to maintain it.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

udp: drop skb extensions before marking skb stateless

Once udp stack has set the UDP_SKB_IS_STATELESS flag, later skb free
assumes all skb head state has been dropped already.

This will leak the extension memory in case the skb has extensions other
than the ipsec secpath, e.g. bridge nf data.

To fix this, set the UDP_SKB_IS_STATELESS flag only if we don't have
extensions or if the extension space can be free'd.

Fixes: 895b5c9f206eb7d25dc1360a ("netfilter: drop bridge nf reset from nf_reset")
Cc: Paolo Abeni <pabeni@redhat.com>
Reported-by: Byron Stanoszek <gandalf@winds.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: rtnetlink: prevent underflows in do_setvfinfo()

The "ivm->vf" variable is a u32, but the problem is that a number of
drivers cast it to an int and then forget to check for negatives.  An
example of this is in the cxgb4 driver.

drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
  2890  static int cxgb4_mgmt_get_vf_config(struct net_device *dev,
  2891                                      int vf, struct ifla_vf_info *ivi)
                                            ^^^^^^
  2892  {
  2893          struct port_info *pi = netdev_priv(dev);
  2894          struct adapter *adap = pi->adapter;
  2895          struct vf_info *vfinfo;
  2896
  2897          if (vf >= adap->num_vfs)
                    ^^^^^^^^^^^^^^^^^^^
  2898                  return -EINVAL;
  2899          vfinfo = &adap->vfinfo[vf];
                ^^^^^^^^^^^^^^^^^^^^^^^^^^

There are 48 functions affected.

drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c:8435 hclge_set_vf_vlan_filter() warn: can 'vfid' underflow 's32min-2147483646'
drivers/net/ethernet/freescale/enetc/enetc_pf.c:377 enetc_pf_set_vf_mac() warn: can 'vf' underflow 's32min-2147483646'
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2899 cxgb4_mgmt_get_vf_config() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2960 cxgb4_mgmt_set_vf_rate() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3019 cxgb4_mgmt_set_vf_rate() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3038 cxgb4_mgmt_set_vf_vlan() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3086 cxgb4_mgmt_set_vf_link_state() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/chelsio/cxgb/cxgb2.c:791 get_eeprom() warn: can 'i' underflow 's32min-(-4),0,4-s32max'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:82 bnxt_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:164 bnxt_set_vf_trust() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:186 bnxt_get_vf_config() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:228 bnxt_set_vf_mac() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:264 bnxt_set_vf_vlan() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:293 bnxt_set_vf_bw() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:333 bnxt_set_vf_link_state() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2595 bnx2x_vf_op_prep() warn: can 'vfidx' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2595 bnx2x_vf_op_prep() warn: can 'vfidx' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2281 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2285 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2286 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2292 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2297 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1832 qlcnic_sriov_set_vf_mac() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1864 qlcnic_sriov_set_vf_tx_rate() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1937 qlcnic_sriov_set_vf_vlan() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:2005 qlcnic_sriov_get_vf_config() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:2036 qlcnic_sriov_set_vf_spoofchk() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/emulex/benet/be_main.c:1914 be_get_vf_config() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/emulex/benet/be_main.c:1915 be_get_vf_config() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/emulex/benet/be_main.c:1922 be_set_vf_tvt() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/emulex/benet/be_main.c:1951 be_clear_vf_tvt() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/emulex/benet/be_main.c:2063 be_set_vf_tx_rate() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/emulex/benet/be_main.c:2091 be_set_vf_link_state() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:2609 ice_set_vf_port_vlan() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3050 ice_get_vf_cfg() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3103 ice_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3181 ice_set_vf_mac() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3237 ice_set_vf_trust() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3286 ice_set_vf_link_state() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:3919 i40e_validate_vf() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:3957 i40e_ndo_set_vf_mac() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4104 i40e_ndo_set_vf_port_vlan() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4263 i40e_ndo_set_vf_bw() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4309 i40e_ndo_get_vf_config() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4371 i40e_ndo_set_vf_link_state() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4441 i40e_ndo_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4441 i40e_ndo_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4504 i40e_ndo_set_vf_trust() warn: can 'vf_id' underflow 's32min-2147483646'

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'pm-5.4-final' of git://git./linux/kernel/git/rafael/linux-pm

Pull power management regression fix from Rafael Wysocki:
 "Fix problems with switching cpufreq drivers on some x86 systems with
  ACPI (and with changing the operation modes of the intel_pstate driver
  on those systems) introduced by recent changes related to the
  management of frequency limits in cpufreq"

* tag 'pm-5.4-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM: QoS: Invalidate frequency QoS requests after removal

Merge tag 'drm-fixes-2019-11-22' of git://anongit.freedesktop.org/drm/drm

Pull drm fixes from Dave Airlie:
 "Two sets of fixes in here, one for amdgpu, and one for i915.

  The amdgpu ones are pretty small, i915's CI system seems to have a few
  problems in the last week or so, there is one major regression fix for
  fb_mmap, but there are a bunch of other issues fixed in there as well,
  oops, screen flashes and rcu related.

  amdgpu:
   - Remove experimental flag for navi14
   - Fix confusing power message failures on older VI parts
   - Hang fix for gfxoff when using the read register interface
   - Two stability regression fixes for Raven

  i915:
   - Fix kernel oops on dumb_create ioctl on no crtc situation
   - Fix bad ugly colored flash on VLV/CHV related to gamma LUT update
   - Fix unity of the frequencies reported on PMU
   - Fix kernel oops on set_page_dirty using better locks around it
   - Protect the request pointer with RCU to prevent it being freed
     while we might need still
   - Make pool objects read-only
   - Restore physical addresses for fb_map to avoid corrupted page
     table"

* tag 'drm-fixes-2019-11-22' of git://anongit.freedesktop.org/drm/drm:
  drm/i915/fbdev: Restore physical addresses for fb_mmap()
  Revert "drm/amd/display: enable S/G for RAVEN chip"
  drm/amdgpu: disable gfxoff on original raven
  drm/amdgpu: disable gfxoff when using register read interface
  drm/amd/powerplay: correct fine grained dpm force level setting
  drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs
  drm/amdgpu: remove experimental flag for Navi14
  drm/i915: make pool objects read-only
  drm/i915: Protect request peeking with RCU
  drm/i915/userptr: Try to acquire the page lock around set_page_dirty()
  drm/i915/pmu: "Frequency" is reported as accumulated cycles
  drm/i915: Preload LUTs if the hw isn't currently using them
  drm/i915: Don't oops in dumb_create ioctl if we have no crtcs

mm/ksm.c: don't WARN if page is still mapped in remove_stable_node()

It's possible to hit the WARN_ON_ONCE(page_mapped(page)) in
remove_stable_node() when it races with __mmput() and squeezes in
between ksm_exit() and exit_mmap().

  WARNING: CPU: 0 PID: 3295 at mm/ksm.c:888 remove_stable_node+0x10c/0x150

  Call Trace:
   remove_all_stable_nodes+0x12b/0x330
   run_store+0x4ef/0x7b0
   kernfs_fop_write+0x200/0x420
   vfs_write+0x154/0x450
   ksys_write+0xf9/0x1d0
   do_syscall_64+0x99/0x510
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

Remove the warning as there is nothing scary going on.

Link: http://lkml.kernel.org/r/20191119131850.5675-1-aryabinin@virtuozzo.com
Fixes: cbf86cfe04a6 ("ksm: remove old stable nodes more thoroughly")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span()

Let's limit shrinking to !ZONE_DEVICE so we can fix the current code.
We should never try to touch the memmap of offline sections where we
could have uninitialized memmaps and could trigger BUGs when calling
page_to_nid() on poisoned pages.

There is no reliable way to distinguish an uninitialized memmap from an
initialized memmap that belongs to ZONE_DEVICE, as we don't have
anything like SECTION_IS_ONLINE we can use similar to
pfn_to_online_section() for !ZONE_DEVICE memory.

E.g., set_zone_contiguous() similarly relies on pfn_to_online_section()
and will therefore never set a ZONE_DEVICE zone consecutive.  Stopping
to shrink the ZONE_DEVICE therefore results in no observable changes,
besides /proc/zoneinfo indicating different boundaries - something we
can totally live with.

Before commit d0dc12e86b31 ("mm/memory_hotplug: optimize memory
hotplug"), the memmap was initialized with 0 and the node with the right
value.  So the zone might be wrong but not garbage.  After that commit,
both the zone and the node will be garbage when touching uninitialized
memmaps.

Toshiki reported a BUG (race between delayed initialization of
ZONE_DEVICE memmaps without holding the memory hotplug lock and
concurrent zone shrinking).

  https://lkml.org/lkml/2019/11/14/1040

"Iteration of create and destroy namespace causes the panic as below:

      kernel BUG at mm/page_alloc.c:535!
      CPU: 7 PID: 2766 Comm: ndctl Not tainted 5.4.0-rc4 #6
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
      RIP: 0010:set_pfnblock_flags_mask+0x95/0xf0
      Call Trace:
       memmap_init_zone_device+0x165/0x17c
       memremap_pages+0x4c1/0x540
       devm_memremap_pages+0x1d/0x60
       pmem_attach_disk+0x16b/0x600 [nd_pmem]
       nvdimm_bus_probe+0x69/0x1c0
       really_probe+0x1c2/0x3e0
       driver_probe_device+0xb4/0x100
       device_driver_attach+0x4f/0x60
       bind_store+0xc9/0x110
       kernfs_fop_write+0x116/0x190
       vfs_write+0xa5/0x1a0
       ksys_write+0x59/0xd0
       do_syscall_64+0x5b/0x180
       entry_SYSCALL_64_after_hwframe+0x44/0xa9

  While creating a namespace and initializing memmap, if you destroy the
  namespace and shrink the zone, it will initialize the memmap outside
  the zone and trigger VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page),
  pfn), page) in set_pfnblock_flags_mask()."

This BUG is also mitigated by this commit, where we for now stop to
shrink the ZONE_DEVICE zone until we can do it in a safe and clean way.

Link: http://lkml.kernel.org/r/20191006085646.5768-5-david@redhat.com
Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") [visible after d0dc12e86b319]
Signed-off-by: David Hildenbrand <david@redhat.com>
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Reported-by: Toshiki Fukasawa <t-fukasawa@vx.jp.nec.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Damian Tometzki <damian.tometzki@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Halil Pasic <pasic@linux.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jun Yao <yaojun8558363@gmail.com>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Pankaj Gupta <pagupta@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pavel Tatashin <pavel.tatashin@microsoft.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Qian Cai <cai@lca.pw>
Cc: Rich Felker <dalias@libc.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>
Cc: Will Deacon <will@kernel.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org> [4.13+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Revert "fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()"

This reverts commit 56e94ea132bb5c2c1d0b60a6aeb34dcb7d71a53d.

Commit 56e94ea132bb ("fs: ocfs2: fix possible null-pointer dereferences
in ocfs2_xa_prepare_entry()") introduces a regression that fail to
create directory with mount option user_xattr and acl.  Actually the
reported NULL pointer dereference case can be correctly handled by
loc->xl_ops->xlo_add_entry(), so revert it.

Link: http://lkml.kernel.org/r/1573624916-83825-1-git-send-email-joseph.qi@linux.alibaba.com
Fixes: 56e94ea132bb ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()")
Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Reported-by: Thomas Voegtle <tv@lio96.de>
Acked-by: Changwei Ge <gechangwei@live.cn>
Cc: Jia-Ju Bai <baijiaju1990@gmail.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Gang He <ghe@suse.com>
Cc: Jun Piao <piaojun@huawei.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

can: m_can_platform: remove unnecessary m_can_class_resume() call

The function m_can_runtime_resume() is getting recursively called from
m_can_class_resume(). This results in a lock up.

We need not call m_can_class_resume() during m_can_runtime_resume().

Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework")
Signed-off-by: Pankaj Sharma <pankj.sharma@samsung.com>
Signed-off-by: Sriram Dash <sriram.dash@samsung.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

can: m_can_platform: set net_device structure as driver data

The current code is failing during clock prepare enable because of not
getting proper clock from platform device.

[    0.852089] Call trace:
[    0.854516]  0xffff0000fa22a668
[    0.857638]  clk_prepare+0x20/0x34
[    0.861019]  m_can_runtime_resume+0x2c/0xe4
[    0.865180]  pm_generic_runtime_resume+0x28/0x38
[    0.869770]  __rpm_callback+0x16c/0x1bc
[    0.873583]  rpm_callback+0x24/0x78
[    0.877050]  rpm_resume+0x428/0x560
[    0.880517]  __pm_runtime_resume+0x7c/0xa8
[    0.884593]  m_can_clk_start.isra.9.part.10+0x1c/0xa8
[    0.889618]  m_can_class_register+0x138/0x370
[    0.893950]  m_can_plat_probe+0x120/0x170
[    0.897939]  platform_drv_probe+0x4c/0xa0
[    0.901924]  really_probe+0xd8/0x31c
[    0.905477]  driver_probe_device+0x58/0xe8
[    0.909551]  device_driver_attach+0x68/0x70
[    0.913711]  __driver_attach+0x9c/0xf8
[    0.917437]  bus_for_each_dev+0x50/0xa0
[    0.921251]  driver_attach+0x20/0x28
[    0.924804]  bus_add_driver+0x148/0x1fc
[    0.928617]  driver_register+0x6c/0x124
[    0.932431]  __platform_driver_register+0x48/0x50
[    0.937113]  m_can_plat_driver_init+0x18/0x20
[    0.941446]  do_one_initcall+0x4c/0x19c
[    0.945259]  kernel_init_freeable+0x1d0/0x280
[    0.949591]  kernel_init+0x10/0x100
[    0.953057]  ret_from_fork+0x10/0x18
[    0.956614] Code: 00000000 00000000 00000000 00000000 (fa22a668)
[    0.962681] ---[ end trace 881f71bd609de763 ]---
[    0.967301] Kernel panic - not syncing: Attempted to kill init!

A device driver for CAN controller hardware registers itself with the
Linux network layer as a network device. So, the driver data for m_can
should ideally be of type net_device.

Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework")
Signed-off-by: Pankaj Sharma <pankj.sharma@samsung.com>
Signed-off-by: Sriram Dash <sriram.dash@samsung.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Merge branch 'hv_netvsc-Fix-send-indirection-table-offset'

Haiyang Zhang says:

====================
hv_netvsc: Fix send indirection table offset

Fix send indirection table offset issues related to guest and
host bugs.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

hv_netvsc: Fix send_table offset in case of a host bug

If negotiated NVSP version <= NVSP_PROTOCOL_VERSION_6, the offset may
be wrong (too small) due to a host bug. This can cause missing the
end of the send indirection table, and add multiple zero entries from
leading zeros before the data region. This bug adds extra burden on
channel 0.

So fix the offset by computing it from the data structure sizes. This
will ensure netvsc driver runs normally on unfixed hosts, and future
fixed hosts.

Fixes: 5b54dac856cb ("hyperv: Add support for virtual Receive Side Scaling (vRSS)")
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

hv_netvsc: Fix offset usage in netvsc_send_table()

To reach the data region, the existing code adds offset in struct
nvsp_5_send_indirect_table on the beginning of this struct. But the
offset should be based on the beginning of its container,
struct nvsp_message. This bug causes the first table entry missing,
and adds an extra zero from the zero pad after the data region.
This can put extra burden on the channel 0.

So, correct the offset usage. Also add a boundary check to ensure
not reading beyond data region.

Fixes: 5b54dac856cb ("hyperv: Add support for virtual Receive Side Scaling (vRSS)")
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net-ipv6: IPV6_TRANSPARENT - check NET_RAW prior to NET_ADMIN

NET_RAW is less dangerous, so more likely to be available to a process,
so check it first to prevent some spurious logging.

This matches IP_TRANSPARENT which checks NET_RAW first.

Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'drm-intel-fixes-2019-11-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

- Fix kernel oops on dumb_create ioctl on no crtc situation
- Fix bad ugly colored flash on VLV/CHV related to gamma LUT update
- Fix unity of the frequencies reported on PMU
- Fix kernel oops on set_page_dirty using better locks around it
- Protect the request pointer with RCU to prevent it being freed while we might need still
- Make pool objects read-only
- Restore physical addresses for fb_map to avoid corrupted page table

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121165339.GA23920@intel.com

Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux

Pull arm64 fix from Will Deacon:
 "Ensure PAN is re-enabled following user fault in uaccess routines.

  After I thought we were done for 5.4, we had a report this week of a
  nasty issue that has been shown to leak data between different user
  address spaces thanks to corruption of entries in the TLB. In
  hindsight, we should have spotted this in review when the PAN code was
  merged back in v4.3, but hindsight is 20/20 and I'm trying not to beat
  myself up too much about it despite being fairly miserable.

  Anyway, the fix is "obvious" but the actual failure is more more
  subtle, and is described in the commit message. I've included a fairly
  mechanical follow-up patch here as well, which moves this checking out
  into the C wrappers which is what we do for {get,put}_user() already
  and allows us to remove these bloody assembly macros entirely. The
  patches have passed kernelci [1] [2] [3] and CKI [4] tests over night,
  as well as some targetted testing [5] for this particular issue.

  The first patch is tagged for stable and should be applied to 4.14,
  4.19 and 5.3. I have separate backports for 4.4 and 4.9, which I'll
  send out once this has landed in your tree (although the original
  patch applies cleanly, it won't build for those two trees).

  Thanks to Pavel Tatashin for reporting this and Mark Rutland for
  helping to diagnose the issue and review/test the solution"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: uaccess: Remove uaccess_*_not_uao asm macros
  arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess fault

sfc: Only cancel the PPS workqueue if it exists

The workqueue only exists for the primary PF. For other functions
we hit a WARN_ON in kernel/workqueue.c.

Fixes: 7c236c43b838 ("sfc: Add support for IEEE-1588 PTP")
Signed-off-by: Martin Habets <mhabets@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'for-linus-20191121' of git://git.kernel.dk/linux-block

Pull block fix from Jens Axboe:
 "Just a single fix for an issue in nbd introduced in this cycle"

* tag 'for-linus-20191121' of git://git.kernel.dk/linux-block:
  nbd:fix memory leak in nbd_get_socket()

Merge tag 'gpio-v5.4-5' of git://git./linux/kernel/git/linusw/linux-gpio

Pull GPIO fixes from Linus Walleij:
 "A last set of small fixes for GPIO, this cycle was quite busy.

   - Fix debounce delays on the MAX77620 GPIO expander

   - Use the correct unit for debounce times on the BD70528 GPIO expander

   - Get proper deps for parallel builds of the GPIO tools

   - Add a specific ACPI quirk for the Terra Pad 1061"

* tag 'gpio-v5.4-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist
  tools: gpio: Correctly add make dependencies for gpio_utils
  gpio: bd70528: Use correct unit for debounce times
  gpio: max77620: Fixup debounce delays

Merge tag 'for-linus-2019-11-21' of git://git./linux/kernel/git/brauner/linux

Pull pidfd fixlet from Christian Brauner:
 "This contains a simple fix for the pidfd poll method. In the original
  patchset pidfd_poll() was made to return an unsigned int. However, the
  poll method is defined to return a __poll_t. While the unsigned int is
  not a huge deal it's just nicer to return a __poll_t.

  I've decided to send it right before the 5.4 release mainly so that
  stable doesn't need to backport it to both 5.4 and 5.3"

* tag 'for-linus-2019-11-21' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
  fork: fix pidfd_poll()'s return type

nfc: port100: handle command failure cleanly

If starting the transfer of a command suceeds but the transfer for the reply
fails, it is not enough to initiate killing the transfer for the
command may still be running. You need to wait for the killing to finish
before you can reuse URB and buffer.

Reported-and-tested-by: syzbot+711468aa5c3a1eabf863@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

drm/i915/fbdev: Restore physical addresses for fb_mmap()

fbdev uses the physical address of our framebuffer for its fb_mmap()
routine. While we need to adapt this address for the new io BAR, we have
to fix v5.4 first! The simplest fix is to restore the smem back to v5.3
and we will then probably have to implement our fbops->fb_mmap() callback
to handle local memory.

Reported-by: Neil MacLeod <freedesktop@nmacleod.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256
Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Neil MacLeod <freedesktop@nmacleod.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113180633.3947-1-chris@chris-wilson.co.uk
(cherry picked from commit abc5520704ab438099fe352636b30b05c1253bea)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 9faf5fa4d3dad3b0c0fa6e67689c144981a11c27)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

net-sysfs: fix netdev_queue_add_kobject() breakage

kobject_put() should only be called in error path.

Fixes: b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jouni Hogander <jouni.hogander@unikie.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'drm-fixes-5.4-2019-11-20' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

drm-fixes-5.4-2019-11-20:

amdgpu:
- Remove experimental flag for navi14
- Fix confusing power message failures on older VI parts
- Hang fix for gfxoff when using the read register interface
- Two stability regression fixes for Raven

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120235130.23755-1-alexander.deucher@amd.com

Revert "drm/amd/display: enable S/G for RAVEN chip"

This reverts commit 1c4259159132ae4ceaf7c6db37a6cf76417f73d9.

S/G display is not stable with the IOMMU enabled on some
platforms.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/amdgpu: disable gfxoff on original raven

There are still combinations of sbios and firmware that
are not stable.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=204689
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/amdgpu: disable gfxoff when using register read interface

When gfxoff is enabled, accessing gfx registers via MMIO
can lead to a hang.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205497
Acked-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/amd/powerplay: correct fine grained dpm force level setting

For fine grained dpm, there is only two levels supported. However
to reflect correctly the current clock frequency, there is an
intermediate level faked. Thus on forcing level setting, we
need to treat level 2 correctly as level 1.

Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs

Otherwise, the error message prompted will confuse user.

Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/amdgpu: remove experimental flag for Navi14

5.4 and newer works fine with navi14.

Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Merge tag 'mlx5-fixes-2019-11-20' of git://git./linux/kernel/git/saeed/linux

Saeed Mahameed says:

====================
Mellanox, mlx5 fixes 2019-11-20

This series introduces some fixes to mlx5 driver.

Please pull and let me know if there is any problem.

For -stable v4.9:
 ('net/mlx5e: Fix set vf link state error flow')

For -stable v4.14
 ('net/mlxfw: Verify FSM error code translation doesn't exceed array size')

For -stable v4.19
 ('net/mlx5: Fix auto group size calculation')

For -stable v5.3
 ('net/mlx5e: Fix error flow cleanup in mlx5e_tc_tun_create_header_ipv4/6')
 ('net/mlx5e: Do not use non-EXT link modes in EXT mode')
 ('net/mlx5: Update the list of the PCI supported devices')
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

r8152: Re-order napi_disable in rtl8152_close

Both rtl_work_func_t() and rtl8152_close() call napi_disable().
Since the two calls aren't protected by a lock, if the close
function starts executing before the work function, we can get into a
situation where the napi_disable() function is called twice in
succession (first by rtl8152_close(), then by set_carrier()).

In such a situation, the second call would loop indefinitely, since
rtl8152_close() doesn't call napi_enable() to clear the NAPI_STATE_SCHED
bit.

The rtl8152_close() function in turn issues a
cancel_delayed_work_sync(), and so it would wait indefinitely for the
rtl_work_func_t() to complete. Since rtl8152_close() is called by a
process holding rtnl_lock() which is requested by other processes, this
eventually leads to a system deadlock and crash.

Re-order the napi_disable() call to occur after the work function
disabling and urb cancellation calls are issued.

Change-Id: I6ef0b703fc214998a037a68f722f784e1d07815e
Reported-by: http://crbug.com/1017928
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'qca_spi-fixes'

Stefan Wahren says:

====================
net: qca_spi: Fix receive and reset issues

This small patch series fixes two major issues in the SPI driver for the
QCA700x.

It has been tested on a Charge Control C 300 (NXP i.MX6ULL +
2x QCA7000).
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

net: qca_spi: Move reset_count to struct qcaspi

The reset counter is specific for every QCA700x chip. So move this
into the private driver struct. Otherwise we get unpredictable reset
behavior in setups with multiple QCA700x chips.

Fixes: 291ab06ecf67 (net: qualcomm: new Ethernet over SPI driver for QCA7000)
Signed-off-by: Stefan Wahren <stefan.wahren@in-tech.com>
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: qca_spi: fix receive buffer size check

When receiving many or larger packets, e.g. when doing a file download,
it was observed that the read buffer size register reports up to 4 bytes
more than the current define allows in the check.
If this is the case, then no data transfer is initiated to receive the
packets (and thus to empty the buffer) which results in a stall of the
interface.

These 4 bytes are a hardware generated frame length which is prepended
to the actual frame, thus we have to respect it during our check.

Fixes: 026b907d58c4 ("net: qca_spi: Add available buffer space verification")
Signed-off-by: Michael Heimpold <michael.heimpold@in-tech.com>
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'ibmvnic-regression'

Juliet Kim says:

====================
Support both XIVE and XICS modes in ibmvnic

This series aims to support both XICS and XIVE with avoiding
a regression in behavior when a system runs in XICS mode.

Patch 1 reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(“net/ibmvnic: Fix EOI when running in XIVE mode.”)

Patch 2 Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

net/ibmvnic: Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode

Reversion of commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(“net/ibmvnic: Fix EOI when running in XIVE mode.”) leaves us
calling H_EOI even in XIVE mode. That will fail with H_FUNCTION
because H_EOI is not supported in that mode. That failure is
harmless. Ignore it so we can use common code for both XICS and
XIVE.

Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Revert "net/ibmvnic: Fix EOI when running in XIVE mode"

This reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(“net/ibmvnic: Fix EOI when running in XIVE mode.”) since that
has the unintended effect of changing the interrupt priority
and emits warning when running in legacy XICS mode.

Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net/mlxfw: Verify FSM error code translation doesn't exceed array size

Array mlxfw_fsm_state_err_str contains value to string translation, when
values are provided by mlxfw_dev. If value is larger than
MLXFW_FSM_STATE_ERR_MAX, return "unknown error" as expected instead of
reading an address than exceed array size.

Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

net/mlx5: Update the list of the PCI supported devices

Add the upcoming ConnectX-6 LX device ID.

Fixes: 85327a9c4150 ("net/mlx5: Update the list of the PCI supported devices")
Signed-off-by: Shani Shapp <shanish@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

net/mlx5: Fix auto group size calculation

Once all the large flow groups (defined by the user when the flow table
is created - max_num_groups) were created, then all the following new
flow groups will have only one flow table entry, even though the flow table
has place to larger groups.
Fix the condition to prefer large flow group.

Fixes: f0d22d187473 ("net/mlx5_core: Introduce flow steering autogrouped flow table")
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>

net/mlx5e: Add missing capability bit check for IP-in-IP

Device that doesn't support IP-in-IP offloads has to filter csum and gso
offload support, otherwise kernel will conclude that device is capable of
offloading csum and gso for IP-in-IP tunnels and that might result in
IP-in-IP tunnel not functioning.

Fixes: 25948b87dda2 ("net/mlx5e: Support TSO and TX checksum offloads for IP-in-IP")
Signed-off-by: Marina Varshaver <marinav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>