ARM: OMAP2+: extend pruss pdata-quirks to AM437x SoCs

The omap_device API is needed to perform the reset management for
any IP instances with PRCM RSTCTRL registers (hard reset lines).
This API is limited to the mach-omap2 layer, and cannot be exposed
to drivers layer directly.

AM437x requires the same functional reset management with PRUSS
as on AM33xx, so extend the AM33xx pruss pdata quirks to AM437x
as well. AM33xx relied on pdata quirks and platform data ops for
the PRUSS IP, to plumb the required omap_device API with the PRUSS
SoC bus driver ops to achieve the required reset functionality.
This was implemented in this fashion as there is no separate reset
driver at the moment.

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

ARM: dts: AM4372: Add PRUSS MDIO controller node

The PRU-ICSS1 instance on AM437x SoCs has a MDIO sub-module that
can be used to control external PHYs associated with the Industrial
Ethernet peripherals within the PRUSS. The MDIO module used within
this PRU-ICSS is an instance of the MDIO Controller used in TI
Davinci SoCs. The same bus frequency of 1 MHz is chosen as the
regular MDIO node. Note that there is no MDIO node added to the
smaller PRU-ICSS0 instance as the MDIO pins are not pinned out.

The node is added to the common am4372 dtsi file and is disabled.
This needs to be enabled in the respective board files using the
relevant AM437x SoCs supporting PRUSS and where the ethernet is
pinned out and connected properly.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: fix reg address, add commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: AM4372: Add the PRU-ICSS0 DT node

The AM437x SoC has a second smaller PRU-ICSS subsystem (PRUSS0)
in addition to the primary PRUSS1 instance. The PRUSS0 has less
DRAM per PRU, and no Shared DRAM among other minor differences.
The IEP and MII_RT modules even though present within the IP are
are not pinned out.

This PRUSS0 instance has a weird SoC integration. It shares the
same L3 OCP interconnect interface with PRUSS1, and also shares
its reset line and clocks. Any external accesses from PRUSS0
requires the PRUSS1's PRUSS_SYSCFG register to be programmed
properly. That said, it is its own IP instance (a cut-down version),
and so it has been added as an independent node (sibling node to
PRUSS1 node) and a child node of the PRUSS SoC bus node. This
allows the PRUSS0 instance to be enabled/disabled independently
of the PRUSS1 instance.

The nodes are added in disabled state as not every SoC in the
AM437x family has the PRU-ICSSs (AM4372 SoC lacks the support).
They need to be enabled in the respective board dts file based
on the SoC being used.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
     PRU-ICSS0 PRU0 Core: am437x-pru0_0-fw
     PRU-ICSS0 PRU1 Core: am437x-pru0_1-fw

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

ARM: dts: AM4372: Add the PRU-ICSS1 DT node

Add the DT node for the PRU-ICSS1 instance on the AM437x family
of SoCs. Each PRU-ICSS instance is represented by the pruss-soc-bus
node and a child PRUSS subsystem node. The PRU-ICSS instances are
not supported on AM4372 SoC though in the AM437x family, so the
nodes are added in disabled state in the common am4372 dtsi file.
They should be enabled in only those derivative board files that
use a SoC containing PRU-ICSS.

The PRU-ICSS1 on AM437x is very similar to the PRUSS in AM33xx,
except for variations in the RAM sizes, bus addresses and the
number of interrupts coming into the MPU INTC (host interrupt
7 is routed to the other PRUSS instead of MPU).

The PRUSS subsystem node contains the entire address space and
the various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS 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 nodes define the addresses for the Instruction RAM, the Debug
and Control sub-modules for that PRU core. The firmware for each
PRU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
     PRU-ICSS1 PRU0 Core: am437x-pru1_0-fw
     PRU-ICSS1 PRU1 Core: am437x-pru1_1-fw

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

ARM: dts: am335x-icev2: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
on the AM335x ICEv2 board, so enable both these PRU-ICSS nodes. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: dts: am335x-evmsk: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
on the AM335x SK EVM board, so enable both these PRU-ICSS nodes. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: dts: am335x-evm: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
on the AM335x EVM, so enable both these PRU-ICSS nodes. The PRU
nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: dts: am335x-bone-common: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. Enable both these
PRU-ICSS nodes on all the AM335x beaglebone boards as they mostly
use a AM3358 or a AM3359 SoC which do contain the PRU-ICSS IP.
The PRU nodes are already enabled in the base dts file, and so
become effective automatically with the enabling of these PRU-ICSS
nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x

The omap_device API is needed to perform the reset management for
any IP instances with PRCM RSTCTRL registers (hard reset lines).
This API is limited to the mach-omap2 layer, and cannot be exposed
to drivers layer directly. So use platform data ops and pdata quirks
for the PRUSS IP in AM335x SoCs to plumb the required omap_device
API. The PRUSS SoC bus driver can then use these pdata ops to
achieve the required reset functionality.

This is being implemented this way as there is no separate reset
driver at the moment.

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

ARM: dts: AM33xx: Add PRUSS MDIO controller node

The PRUSS on AM335x SoCs has a MDIO sub-module that can be used
to control external PHYs associated with the Industrial Ethernet
peripherals within the PRUSS. The MDIO module used within the
PRU-ICSS is an instance of the MDIO Controller used in TI Davinci
SoCs. The same bus frequency of 1 MHz is chosen as the regular
MDIO node.

The node is added to the common am33xx dts file and is disabled.
This needs to be enabled in the respective board files using the
relevant AM335x SoCs supporting PRUSS and where the ethernet is
pinned out and connected properly.

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

ARM: dts: AM33xx: Add the PRU-ICSS DT nodes

Add the DT nodes for the PRU-ICSS on AM33xx family of SoCs. The
AM33xx SoCs contain a single PRU-ICSS instance and is represented
by the pruss-soc-bus node and a child PRUSS node. PRU-ICSS is not
supported on AM3352 SoC though in the AM33xx family, so the nodes
are added in disabled state to the common am33xx dtsi file. They
should be enabled in only those derivative board files that use
a SoC containing PRU-ICSS.

The PRUSS subsystem node contains the entire address space and
the various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS 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 nodes define the addresses for the Instruction RAM, the
Debug and Control sub-modules for that PRU core. The firmware for
each PRU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
     PRU-ICSS PRU0 Core: am335x-pru1_0-fw
     PRU-ICSS PRU1 Core: am335x-pru1_1-fw

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

soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC

The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1,
each of which has two PRU processor cores. The two PRU-ICSS instances
are identical to each other with few minor SoC integration differences,
and are very similar to the PRU-ICSS1 of AM57xx/AM43xx. The Shared Data
RAM size is larger and the number of interrupts coming into MPU INTC
is like the instances on AM437x. There are also few other differences
attributing to integration in Keystone architecture (like no SYSCFG
register or PRCM handshake protocols). Other IP level differences
include different constant table, 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 platform drivers have been enhanced to support
these 66AK2G PRU-ICSS instances through new 66AK2G specific compatibles
for properly probing and booting all the different PRU cores in each
PRU-ICSS processor subsystem. The SoC-level integration differences
are dealt with using match data within the PRUSS INTC and PRUSS SoC
bus drivers. A build dependency with ARCH_KEYSTONE is added to enable
the driver to be built in K2G-only configuration. The initial names
for the firmware images for each PRU core are retrieved from DT nodes,
and can be adjusted through sysfs if required.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: Configure SYSCFG properly during probe/remove

The PRUSS CFG module's SYSCFG register is used for managing the
PRCM clock management settings at the PRU-ICSS subsystem level.

Add two helper functions pruss_{enable/disable}_module() that
programs this SYSCFG register during probe and remove. The
register is currently programmed for the default Smart-Idle
and Smart-Standby always during probe. The MStandby is enabled
during remove to undo the settings in probe to properly configure
the SYSCFG in the case that a firmware has disabled MStandby.
This is needed on SoCs like AM57xx that do not have a reset line
and so cannot reset the register properly.

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

soc: ti: pruss: Fix system suspend/MStandby config issues

The PRU-ICSS subsystem has a separate PRUSS_CFG module that contains
various configuration registers. This includes a control bit STANDBY_INIT
in PRUSS_CFG register to initiate a Standby sequence (when set) and
trigger a MStandby request to the SoC's PRCM module. This same bit is
also used to enable the OCP master ports (when cleared). The system
suspend/resume functionality on AM33xx/AM437x/AM57xx SoCs requires
all initiators to assert their MStandby signal properly inorder to
successfully enter suspend, and resume on a wakeup event.

Certain firmwares can enable the OCP master ports through the
STANDBY_INIT programming on the firmware side in order to access
peripherals or memories external to the PRUSS. This causes a hang
in the resume sequence on AM33xx/AM437x boards and requires a
board reset to come out of the hang.

This patch adds the preliminary System PM callbacks in the PRUSS SoC
bus driver, and fixes this system resume hang by setting the STANDBY_INIT
in the PM system suspend callback and resetting it back in the PM system
resume callback, if so configured. The clearing of the STANDBY_INIT
during resume requires an acknowledgment from PRCM and is done through
the monitoring of the PRUSS_SYSCFG.SUB_MWAIT bit.

NOTE:
1. This patch only adds the PM callbacks with code to fix the System
   Suspend/Resume hang issue on AM33xx/AM437x SoCs, but does not
   implement the full context save and restore required for the PRUSS
   drivers to work across system suspend/resume when the power domain
   is switched off (L4PER domain is switched OFF on AM335x/AM437x
   during system suspend/resume, so PRUSS modules do lose context).
2. The PRUSS driver functionality on AM57xx SoCs is not affected that
   much because the PER power domain to which the PRUSS IPs belong is
   not switched OFF during suspend/resume.

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

soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs

The AM57xx family of SoCs supports two PRU-ICSS instances, each of
which has two PRU processor cores. The two PRU-ICSS instances are
identical to each other, and are very similar to the PRU-ICSS1 of
AM33xx/AM43xx except for a few minor differences like the RAM sizes
and the number of interrupts coming into the MPU INTC. They do
not have a programmable module reset line unlike those present on
AM33xx/AM43xx SoCs. The modules are reset just like any other IP
with the SoC's global cold/warm resets. Each PRU-ICSS's INTC is also
preceded by a Crossbar that enables multiple external events to be
routed to a specific number of input interrupt events. Any interrupt
event directed towards PRUSS needs this crossbar to be setup properly
on the firmware side.

The existing PRUSS platform drivers have been enhanced to support
these AM57xx PRU-ICSS instances through new AM57xx specific
compatibles for properly probing and booting all the different PRU
cores in each PRU-ICSS processor subsystem. The SoC-level integration
differences are dealt with using match data within the PRUSS SoC bus
driver. A build dependency with SOC_DRA7XX is also added to enable
the driver to be built in AM57xx-only configuration (there is no
separate Kconfig option for AM57xx vs DRA7xx). The initial names
for the firmware images for each PRU core are retrieved from DT
nodes, and can be adjusted through sysfs if required.

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

soc: ti: pruss: Add support for PRU-ICSS0 on AM437x SoCs

The AM437x SoCs have a second smaller PRU-ICSS subsystem (PRUSS0)
in addition to the primary PRUSS1 instance. The PRUSS0 is another
instantiation of the IP, but is not identical to PRUSS1. It is
essentially a cut-down version of the IP, with less DRAM per PRU,
no Shared DRAM etc. It also does not have direct access to L3 bus
regions, there is a single interface to L3 for both PRUSS0 and
PRUSS1, and it would have to go through the PRUSS1's interface.
The PRUSS_SYSCFG register is reserved on PRUSS0, so any external
access requires the programming the corresponding PRUSS_SYSCFG
register in PRUSS1. It does have its own dedicated I/O lines
though. Note that this instance does not support any PRU Ethernet
related usecases.

The PRUSS remoteproc drivers have been enhanced to support this
smaller PRUSS0 instance using instance-specific data. The adaptation
uses a newly introduced pruss_match_private_data structure and the
pruss_get_private_data() function to retrieve a PRUSS instance
specific data using a device-name based lookup logic. The reset
and the L3 external access are managed by the common PRUSS SoC bus
driver so that PRUSS1 and PRUSS0 can be independently supported.
The initial names for the firmware images for each PRU core are
retrieved from DT nodes, and can be adjusted through sysfs if
required.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: Add support for PRU-ICSS1 on AM437x SoCs

Enhance all the PRUSS platform drivers to support the PRU-ICSS1
sub-system on the AM437x family of SoCs. AM437x has two PRU-ICSS
instances, and support has been added only for the PRU-ICSS1 at
the moment. PRU-ICSS1 on AM437x is very similar to the PRU-ICSS
on AM33xx except for few minor differences - increased Instruction
RAM, increased Shared Data RAM2, and 1 less interrupt (PRUSS host
interrupt 7 which is redirected to the other PRUSS) towards the
MPU INTC.

The adaptation uses newly introduced compatibles in each driver
and relying on match data within the PRUSS INTC and PRUSS SoC bus
drivers to account for the SoC-level integration differences. The
initial names for the firmware images for each PRU core are
retrieved from DT nodes, and can be adjusted through sysfs if
required.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>

remoteproc/pru: Add pru-specific debugfs support

The remoteproc core creates certain standard debugfs entries,
that does not give a whole lot of useful information for the
PRUs. The PRU remoteproc driver is enhanced to add additional
debugfs entries for PRU. These will be auto-cleaned up when
the parent rproc debug directory is removed.

The enhanced debugfs support adds two new entries: 'regs' and
'single_step'. The 'regs' dumps out the useful CTRL sub-module
registers as well as each of the 32 GPREGs and CT_REGs registers.
The GPREGs and CT_REGs though are printed only when the PRU is
halted and accessible as per the IP design.

The 'single_step' utilizes the single-step execution of the PRU
cores. Writing a non-zero value performs a single step, and a
zero value restores the PRU to execute in the same mode as the
mode before the first single step. (note: if the PRU is halted
because of a halt instruction, then no change occurs).

Logic for setting the PC and jumping over a halt instruction shall
be added in the future.

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

remoteproc/pru: Add a PRU remoteproc driver

The Programmable Real-Time Unit Subsystem (PRUSS) consists of
dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs)
for program execution. This patch adds a remoteproc platform
driver for managing the individual PRU RISC cores life cycle.

The PRU remoteproc driver uses the standard remoteproc core ELF
loader. However, the PRUs do not have a unified address space,
(has an Instruction RAM and a primary Data RAM at both 0x0) and
leverage an added .da_to_va ops to use the standard ELF loader.
This remoteproc driver does not have support for error recovery
and system suspend/resume features. Different compatibles are
used to allow providing scalability for instance-specific device
data if needed. The driver uses a default firmware-name retrieved
from device-tree, and the firmwares are expected to be present
in the standard Linux firmware search paths. They can also be
adjusted by userspace if required through the sysfs interface
provided by the remoteproc core.

The PRU remoteproc driver uses a client-driven boot methodology
- it does _not_ support auto-boot so that the PRU load and boot
is dictated by the corresponding client drivers for achieving
various usecases. This allows flexibility for the client drivers
or applications to set a firmware name (if needed) based on their
desired functionality and boot the PRU. The sysfs bind and unbind
attributes have also been suppressed so that the PRU devices cannot
be unbound and thereby shutdown a PRU from underneath a PRU client
driver.

The PRU interrupt configuration is handled within the PRUSS INTC
platform driver, and leverages the system events to interrupt
channels and host interrupts mapping configuration through a
PRU firmware resource table for now. This will be revisited and
enhanced in the future for a better interface. The mappings
are currently programmed during the booting/shutdown of the PRU.

The driver currently supports the AM335x SoC, and support for other
TI SoCs will be added in subsequent patches.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>

dt-bindings: remoteproc: Add binding doc for PRU Cores in the PRU-ICSS

The Programmable Real-Time Unit Subsystem (PRUSS) consists of dual
32-bit RISC cores (Programmable Real-Time Units, or PRUs) for program
execution. This patch adds the bindings for these PRU cores.

The binding currently covers the OMAP architecture SoCs - AM33xx,
AM437x and AM57xx; and a Keystone 2 architecture based 66AK2G SoC.
The Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs
will be covered in a subsequent patch.

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

remoteproc: Extend rproc_da_to_va() API with a flags parameter

The rproc_da_to_va() API is currently used to perform any device
to kernel address translations to meet the different needs of the
remoteproc core/platform drivers (eg: loading). The function also
invokes the da_to_va ops, if present, to allow the remoteproc
platform drivers to provide address translation. However, not all
platform implementations have linear address spaces, and may need
an additional parameter to be able to perform proper translations.

The rproc_da_to_va() API and the rproc .da_to_va ops have therefore
been expanded to take in an additional flags field enabling some
remoteproc implementations (like the TI PRUSS remoteproc driver)
to use these flags. Also, define some semantics for this flags
argument as this can vary from one implementation to another. A
new flags type is encoded into the upper 16 bits along side the
actual value in the lower 16-bits for the flags argument, to
allow different individual implementations to have better
flexibility in interpreting the flags as per their needs.

Also, update the various remoteproc implementations that use the
.da_to_va() ops for the new signature.

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

remoteproc: move rproc_da_to_va declaration to remoteproc.h

The rproc_da_to_va() API is an exported function, so move its
declaration from the remoteproc local remoteproc_internal.h
to the public remoteproc.h file.

This will allow drivers outside of the remoteproc folder to be
able to use this API.

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

remoteproc: Add support to handle device specific resource types

The remoteproc framework handles a fixed set of resource table entries
today. To make it scalable across multiple platforms, it makes sense
for the framework to provide a way for the device specific implementation
to define and handle vendor specific resource types. These resource types
would be very specific to an implementation instance that it does not
make sense for the framework to handle it. There can be two types of
such resources depending on whether they need to be handled prior to
the loading of the firmware segments or after. A post-loading resource
type is typically needed because it references a loaded segment pointer
for conveying the resource information.

For instance, a remoteproc implementation might want timers information
embedded in the resource table so that the driver could parse the binary
and enable accordingly. Another example would be hwspinlocks that it
is using, to properly share system wide resources. A PRU post-loading
vendor resource handler for interrupts requires the PRU event - interrupt
channel information to be loaded into device memory.

This patch adds a function pointer to the list of rproc_ops for the
driver implementation to handle such custom vendor resources, and
reuses the same handler between pre-loading and post-loading resource
types, with the sub-types in the implementation handling the processing
of those resource types.

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

remoteproc: Fix unbalanced boot with sysfs for no auto-boot rprocs

The remoteproc core performs automatic boot and shutdown of a remote
processor during rproc_add() and rproc_del() for remote processors
supporting 'auto-boot'. The remoteproc devices not using 'auto-boot'
require either a remoteproc client driver or a userspace client to
use the sysfs 'state' variable to perform the boot and shutdown. The
in-kernel client drivers hold the corresponding remoteproc driver
module's reference count when they acquire a rproc handle through
the rproc_get_by_phandle() API, but there is no such support for
userspace applications performing the boot through sysfs interface.

The shutdown of a remoteproc upon removing a remoteproc platform
driver is automatic only with 'auto-boot' and this can cause a
remoteproc with no auto-boot to stay powered on and never freed
up if booted using the sysfs interface without a matching stop,
and when the remoteproc driver module is removed or unbound from
the device. This will result in a memory leak as well as the
corresponding remoteproc ida being never deallocated. Fix this
by holding a module reference count for the remoteproc's driver
during a sysfs 'start' and releasing it during the sysfs 'stop'
operation.

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

remoteproc: Add a rproc_set_firmware() API

A new API, rproc_set_firmware() is added to allow the remoteproc platform
drivers and remoteproc client drivers to be able to configure a custom
firmware name that is different from the default name used during
remoteproc registration. This function is being introduced to provide
a kernel-level equivalent of the current sysfs interface to remoteproc
client drivers, and can only change firmwares when the remoteproc is
offline. This allows some remoteproc drivers to choose different firmwares
at runtime based on the functionality the remote processor is providing.
The TI PRU Ethernet driver will be an example of such usage as it
requires to use different firmwares for different supported protocols.

Also, update the firmware_store() function used by the sysfs interface
to reuse this function to avoid code duplication.

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

remoteproc: Add missing kernel-doc comment for auto-boot

The commit ddf711872c9d ("remoteproc: Introduce auto-boot flag")
introduced the auto-boot flag but missed adding the corresponding
kernel-doc comment. Add the same.

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

clk: ti: am43xx: drop idlest polling from pruss clkctrl clock

The PRUSS modules on AM43xx SoCs have a hardreset line and are controlled
by a PRCM reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the PRUSS clocks. These details should be handled
by the driver integration code itself.

Add the CLKF_NO_IDLEST flag to the PRUSS clkctrl clock so that these
module status checks are skipped.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: revise patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

clk: ti: am33xx: drop idlest polling from pruss clkctrl clock

The PRUSS module on AM33xx SoCs has a hardreset line and is controlled
by a PRCM reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the PRUSS clocks. These details should be handled
by the driver integration code itself.

Add the CLKF_NO_IDLEST flag to the PRUSS clkctrl clock so that these
module status checks are skipped.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: revise patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

irqchip/irq-pruss-intc: Add API to trigger a PRU sysevent

The PRUSS INTC can generate an interrupt to various processor
subsystems on the SoC through a set of 64 possible PRU system
events. These system events can be used by PRU client drivers
or applications for event notifications/signalling between PRUs
and MPU or other processors. A new API, pruss_intc_trigger() is
provided to MPU-side PRU client drivers/applications to be able
to trigger an event/interrupt using IRQ numbers provided by the
PRUSS-INTC irqdomain chip.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts

The Programmable Real-Time Unit Subsystem (PRUSS) contains an
interrupt controller (INTC) that can handle various system input
events and post interrupts back to the device-level initiators.
The INTC can support upto 64 input events with individual control
configuration and hardware prioritization. These events are mapped
onto 10 interrupt signals through two levels of many-to-one mapping
support. Different interrupt signals are routed to the individual
PRU cores or to the host CPU.

The PRUSS INTC platform driver manages this PRUSS interrupt
controller and implements an irqchip driver to provide a Linux
standard way for the PRU client users to enable/disable/ack/
re-trigger a PRUSS system event. The system events to interrupt
channels and host interrupts relies on the mapping configuration
provided through a firmware resource table for now. This will be
revisited and enhanced in the future for a better interface. The
mappings will currently be programmed during the boot/shutdown
of the PRU.

The PRUSS INTC module is reference counted during the interrupt
setup phase through the irqchip's irq_request_resources() and
irq_release_resources() ops. This restricts the module from being
removed as long as there are active interrupt users.

The driver currently supports the AM335x SoC, and support for other
TI SoCs will be added in subsequent patches.

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

dt-bindings: irqchip: Add PRUSS interrupt controller bindings

The Programmable Real-Time Unit Subsystem (PRUSS) contains an
interrupt controller (INTC) that can handle various system input
events and post interrupts back to the device-level initiators.
The INTC can support upto 64 input events with individual control
configuration and hardware prioritization. These events are mapped
onto 10 interrupt signals through two levels of many-to-one mapping
support. Different interrupt signals are routed to the individual
PRU cores or to the host CPU.

Add the bindings document for this interrupt controller. The binding
currently covers the OMAP architecture SoCs - AM33xx, AM437x and AM57xx;
and a Keystone 2 architecture based 66AK2G SoC. The Davinci based
OMAPL138 SoCs and K3 architecture based AM65x SoCs will be covered
in a subsequent patch.

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

soc: ti: pruss: Parse various syscon nodes and store their regmaps

The PRUSS device node currently uses three different syscon nodes for
CFG, IEP and MII_RT sub-modules. Parse these syscon nodes and store
their regmap handles to allow adding functions to program any register
within these sub-modules.

The MFD_SYSCON Kconfig option is also 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.

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

soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs

The PRUSS platform driver deals with the overall PRUSS and is
used for managing the subsystem level resources like various
memories. It is responsible for the creation and deletion of
the platform devices for the child PRU devices and other child
devices (Interrupt Controller or MDIO node or some syscon nodes)
so that they can be managed by specific platform drivers.

This design provides flexibility in representing the different
modules of PRUSS accordingly, and at the same time allowing the
PRUSS driver to add some instance specific configuration within
an SoC.

The driver currently supports the AM335x SoC, and support for
other TI SoCs will be added in subsequent patches.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>

soc: ti: pruss: Add pruss_soc_bus platform driver

The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present of various TI SoCs such as
AM335x or AM437x or the Keystone 66AK2G. Each SoC can have
one or more PRUSS instances that may or may not be identical.
For example, AM335x SoCs have a single PRUSS, while AM437x has
two PRUSS instances PRUSS1 and PRUSS0, with the PRUSS0 being
a cut-down version of the PRUSS1.

The PRUSS consists of dual 32-bit RISC cores called the
Programmable Real-Time Units (PRUs), some shared, data and
instruction memories, some internal peripheral modules, and
an interrupt controller. The programmable nature of the PRUs
provide flexibility to implement custom peripheral interfaces,
fast real-time responses, or specialized data handling.

The PRU-ICSS functionality is achieved through four different
modules, each implementing a platform driver addressing a
specific portion of the PRUSS. Some sub-modules of the PRU-ICSS
IP reuse some of the existing drivers (like davinci mdio driver
or the generic syscon driver). The pruss_soc_bus driver deals
with the SoC integration aspects of the PRUSS IP(s) and manages
the common clock, reset and interconnect configuration and
creates the child PRUSS devices. The second pruss driver is
responsible for the creation and deletion of various platform
devices for the child PRU device and other child devices. A third
driver manages the PRUSS interrupt controller and implements an
irqchip driver to provide a Linux standard way of interrupt
management to PRU clients. The fourth platform driver is a
remoteproc driver and performs the individual PRU RISC cores
management. This design provides flexibility in representing
the different modules of PRUSS accordingly.

The driver currently supports the AM335x SoC, and support for
other TI SoCs will be added in subsequent patches.

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

soc: ti: pruss: Define platform data for PRUSS bus driver

The PRUSS can have a PRCM reset line associated with the IP on
some OMAP architecture based SoCs. The reset needs to be programmed
properly before accessing any of the internal registers in the PRUSS.
This functionality is achieved through the omap_device layer, which
is not exposed outside of mach-omap2 layer. Define a platform data
structure for PRUSS so that this API can be invoked through platform
data ops from the driver.

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

dt-bindings: soc: ti: Add TI PRUSS bindings

This patch adds the bindings for the Programmable Real-Time Unit
and Industrial Communication Subsystem (PRU-ICSS) present on various
TI SoCs. The IP is present on multiple TI SoC architecture families
including the OMAP architecture SoCs such as AM33xx, AM437x and
AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is
also present on the Davinci based OMAPL138 SoCs and K3 architecture
based AM65x SoCs as well (not covered for now).

The IP has a number of sub-modules some of which have their own
devices. This binding covers only the top-level sub-system devices,
and some sub-modules like MDIO, MII_RT and IEP. The remaining
sub-modules bindings shall be defined in the respective driver
subsystem bindings folders. Couple of full examples have also
been added demonstrating the devices on AM335x and the unique
configuration on AM437x SoCs.

The binding status is also marked as unstable as the binding does
not cover all the sub-modules that are present within the PRU-ICSS.

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

remoteproc/keystone: add support for MPM userspace loader

The Keystone remoteproc driver performs the device management of
different DSP processor subsystems present on various Keystone 2
family of SoCs. The driver currently supports loading/booting using
the remoteproc core's 'auto-boot' feature and supports advanced
features like error recovery.

This patch enhances the Keystone remoteproc driver to add support
for a TI specific userspace based loading/booting mechanism called
the Multi Proc Manager (MPM) by exposing a character device interface
to userspace per device. A new module parameter 'use_rproc_core_loader'
is introduced to configure the driver for in-kernel auto-boot mode
or the MPM non auto-boot mode, with the default configured for MPM.
The standard platform driver's bind and unbind sysfs attributes are
suppressed for MPM-based stack so that the regular sysfs approach of
booting and shutting down a Keystone DSP remote processor does not
mess up the MPM-based state-machine by unbinding the device from the
driver even when it has open usage reference counts. The standard
remoteproc sysfs interfaces for changing 'state' and 'firmware'
conflict with the MPM state-machine and are denied using the
remoteproc generic 'deny_sysfs_ops' flag.  An exception notification
is also provided through an UIO device exposed by the keystone
remoteproc driver for now.

The MPM loading/booting mechanism uses the file operations exported
by the character device. The mmap interface is used for mapping device
memory into userspace for loading and the ioctl interfaces are used
for reset and remoteproc resource table configuration and triggering
the boot and shutdown of the DSPs.

The address and size of the various DSP internal RAM memories to
be used with the mmap interface are provided through two sysfs
files 'addr' and 'size' for each region, and are created under the
respective dspX misc device for each DSP remoteproc processor. These
files are created in their own directory for each region accessible
under the /sys/class/misc/dspX/ path, where X is the DSP number
(indexed from 0). The MPM also relies on another memory mapping
character device (/dev/dspmem) to support loading images into
external DDR memory and the Multicore Shared Memory (MSM). This
sysfs logic allows the userspace-based Multi Proc Manager (MPM)
stack to not rely on procfs-based DT parsing for looking up the
memories.

The MPM supports various kinds of firmware images - images with and
without resource tables, images that have a resource table but with
or without the virtio device resource entries. The loadable regions
include images just using internal DSP memories, or images using
portions of the MSM RAM and/or external DDR. The load/boot of images
with and without resource tables are supported using separate ioctl
operations. The KEYSTONE_RPROC_IOC_SET_STATE ioctl is used to boot
and shutdown remote processors for images with resource tables, and
the KEYSTONE_RPROC_IOC_DSP_RESET/BOOT ioctls for images without a
resource table. The boot address/entry point is published during the
corresponding ioctls that trigger a boot, and is stored in a local
variable in driver instance and later picked up by remoteproc core
driver through fw_ops.

This logic is created anew using an older code from Cyril Chemparathy
as a baseline.

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

remoteproc/keystone: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the keystone
remoteproc driver source file and drop the previous boilerplate
license text.

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

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: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2G ICE board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 40 MB is currently reserved at address
0x81d000000 (aliased at 0x9d000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

This address and size are aligned with the values used on the
K2G EVM board so that same firmwares can be run on both the K2G
boards. Note that these values are different from those used on
the other K2HK/K2L/K2E EVM boards.

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

TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2G EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 40 MB is currently reserved at address
0x81d000000 (aliased at 0x9d000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

Note that this carveout is smaller and at a different address in
comparision to those used on K2HK/K2L/K2E EVMs. This is done to
align with the usage on K2G ICE board which has a smaller DDR memory
footprint, and thereby allow same firmwares to be run on both the
K2G boards.

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

TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2E EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

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

TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2L EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

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

TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2HK EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

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

ARM: dts: keystone-k2g: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2G
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

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

ARM: dts: keystone-k2e: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2E
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

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

ARM: dts: keystone-k2l: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2L
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

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

ARM: dts: keystone-k2hk: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2H
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

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

TEMP: soc: ti: add the keystone_dsp_mem driver

A very simple keystone_dsp_mem driver has been added for TI's Keystone 2
family of SoCs. This driver provides a user-space mapping interface for
some On-chip Multicore Shared Memory (MSM) SRAM Memory regions and/or
some portions of the platform board's DDR memory. This is done to enable
the Multi Proc Manager (MPM) based loader for loading different firmware
images into both DDR and On-chip SRAM in userspace for the various C66
DSP co-processors on the SoC.

The different MSM RAM regions to be exposed to userspace through this
driver need to be defined as 'reserved' child nodes under the parent
MSM RAM mmio-sram node with a specific compatible "ti,keystone-dsp-msm-ram"
property. Each of the DDR regions to be exposed should also be defined
using reserved-memory child nodes with the "no-map" property set and
using a specific compatible "ti,keystone-dsp-mpm-pool" property. Multiple
discrete regions of either SRAM and/or DDR can be exposed to userspace
by defining similar DTS nodes.

The keystone-dsp-mem driver provides sysfs entries to allow userspace
to read the address and size of supported DDR and Multicore Shared Memory
(MSM) RAM memories that are exposed to userspace. This sysfs logic provides
an agnostic way of presenting the supported memories irrespective of how
the driver acquires the memories. The 32-bit DDR alias addresses are used
while presenting the DDR regions through sysfs as per current MPM usage.
Each supported memory region is represented by its own directory, and are
created under the dspmem misc device. The directories can be accessed
under the /sys/class/misc/dspmem/ path.

The mapping interfaces are provided through a miscdevice and exposed
using the character device /dev/dspmem (matching the usage within MPM).
The mmap logic itself is based on a mechanism used within the UIO
framework.

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

TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding

Add the device tree binding document for the userspace memory mapping
driver on TI Keystone SoCs. This driver is used to expose either some
portions of the DDR and/or some portions of the On-chip RAM controlled
by the Multicore Shared Memory Controller (MSMC) to userspace for the
Multi Proc Manager (MPM) stack.

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/davinci: Use %zx for formating size_t

da8xx_rproc_mem size is of type size_t, so use %zx to format the debug
print of it to avoid a compile warning.

Acked-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '1e28dbbeced6' from v4.20]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/wkup_m3: set deny_sysfs_ops flag

The Wakeup M3 remote processor is controlled by the wkup_m3_ipc
client driver, so set the newly introduced 'deny_sysfs_ops' flag
to not allow any overriding of the remoteproc firmware or state
from userspace.

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

remoteproc: introduce deny_sysfs_ops flag

The remoteproc framework provides sysfs interfaces for changing
the firmware name and for starting/stopping a remote processor
through the sysfs files 'state' and 'firmware'. These interfaces
are currently allowed irrespective of how the remoteprocs were
booted (like remoteproc self auto-boot, remoteproc client-driven
boot etc). These interfaces can adversely affect a remoteproc
and its clients especially when a remoteproc is being controlled
by a remoteproc client driver(s). Also, not all remoteproc
drivers may want to support the sysfs interfaces by default.

Add support to deny the sysfs state/firmware change by introducing
a state flag 'deny_sysfs_ops' that the individual remoteproc drivers
can set based on their usage needs. The default behavior is to
allow the sysfs operations as before.

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

rpmsg: add a description field

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

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

Based on an initial patch from Ohad Ben-Cohen.

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

samples/rpmsg: Introduce a module parameter for message count

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

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

remoteproc: add an api to do pa to da conversion

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

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

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

remoteproc: add api for retrieving a rproc unique id

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

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

remoteproc: add name in rproc_mem_entry struct

[ Upstream commit 3265230c5b05fe919291d09e266a8aedc85ebad0 ]

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

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

remoteproc: Check for NULL firmwares in sysfs interface

[ Upstream commit faeadbb64094757150a8c2a3175ca418dbdd472c ]

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

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

rpmsg: char: Migrate to iter versions of read and write

[ Upstream commit ccf45b18ce89f598c69a0c945ced1635013fc0b1 ]

In order to be able to use the aio interface for writing to a rpmsg_char
the write_iter function must be implemented, so migrate to iter version
for read and write functions.

Regular read and write uses the iter methods if present and is as such
unaffected.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'ccf45b18ce89' from v4.20]
Signed-off-by: Suman Anna <s-anna@ti.com>

Linux 4.19

MAINTAINERS: Add an entry for the code of conduct

As I introduced these files, I'm willing to be the maintainer of them as
well.

Acked-by: Chris Mason <clm@fb.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct: Change the contact email address

The contact point for the kernel's Code of Conduct should now be the
Code of Conduct Committee, not the full TAB.  Change the email address
in the file to properly reflect this.

Acked-by: Chris Mason <clm@fb.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct Interpretation: Put in the proper URL for the committee

There was a blank <URL> reference for how to find the Code of Conduct
Committee.  Fix that up by pointing it to the correct kernel.org website
page location.

Acked-by: Chris Mason <clm@fb.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct: Provide links between the two documents

Create a link between the Code of Conduct and the Code of Conduct
Interpretation so that people can see that they are related.

Acked-by: Chris Mason <clm@fb.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct Interpretation: Properly reference the TAB correctly

We use the term "TAB" before defining it later in the document.  Fix
that up by defining it at the first location.

Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Chris Mason <clm@fb.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted

The Contributor Covenant Code of Conduct is a general document meant to
provide a set of rules for almost any open source community.  Every
open-source community is unique and the Linux kernel is no exception.
Because of this, this document describes how we in the Linux kernel
community will interpret it.  We also do not expect this interpretation
to be static over time, and will adjust it as needed.

This document was created with the input and feedback of the TAB as well
as many current kernel maintainers.

Co-Developed-by: Thomas Gleixner <tglx@linutronix.de>
Co-Developed-by: Olof Johansson <olof@lixom.net>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Acked-by: Borislav Petkov <bp@kernel.org>
Acked-by: Chris Mason <clm@fb.com>
Acked-by: Christian Lütke-Stetzkamp <christian@lkamp.de>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: David Sterba <kdave@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.de>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Hans de Goede <j.w.r.degoede@gmail.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Jaegeuk Kim <jaegeuk@kernel.org>
Acked-by: James Smart <james.smart@broadcom.com>
Acked-by: James Smart <jsmart2021@gmail.com>
Acked-by: Jan Kara <jack@ucw.cz>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Acked-by: Jiri Kosina <jikos@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: Joerg Roedel <joro@8bytes.org>
Acked-by: Johan Hovold <johan@kernel.org>
Acked-by: Johannes Thumshirn <jth@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Lina Iyer <ilina@codeaurora.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Matias Bjørling <mb@lightnvm.io>
Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Mimi Zohar <zohar@linux.ibm.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Mishi Choudhary <mishi@linux.com>
Acked-by: Nikolay Borisov <n.borisov.lkml@gmail.com>
Acked-by: Oded Gabbay <oded.gabbay@gmail.com>
Acked-by: Palmer Dabbelt <palmer@dabbelt.com>
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Rik van Riel <riel@surriel.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Sean Paul <sean@poorly.run>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Shuah Khan <shuah@kernel.org>
Acked-by: Simon Horman <horms@verge.net.au>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Takashi Iwai <tiwai@kernel.org>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of conduct: Fix wording around maintainers enforcing the code of conduct

As it was originally worded, this paragraph requires maintainers to
enforce the code of conduct, or face potential repercussions.  It sends
the wrong message, when really we just want maintainers to be part of
the solution and not violate the code of conduct themselves.

Removing it doesn't limit our ability to enforce the code of conduct,
and we can still encourage maintainers to help maintain high standards
for the level of discourse in their subsystem.

Signed-off-by: Chris Mason <clm@fb.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Acked-by: Borislav Petkov <bp@kernel.org>
Acked-by: Christian Lütke-Stetzkamp <christian@lkamp.de>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: David Sterba <kdave@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.de>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Florian Westphal <fw@strlen.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Hans de Goede <j.w.r.degoede@gmail.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Jaegeuk Kim <jaegeuk@kernel.org>
Acked-by: James Smart <james.smart@broadcom.com>
Acked-by: James Smart <jsmart2021@gmail.com>
Acked-by: Jan Kara <jack@ucw.cz>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Acked-by: Jiri Kosina <jikos@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: Joerg Roedel <joro@8bytes.org>
Acked-by: Johan Hovold <johan@kernel.org>
Acked-by: Johannes Thumshirn <jth@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Lina Iyer <ilina@codeaurora.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Matias Bjørling <mb@lightnvm.io>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Mimi Zohar <zohar@linux.ibm.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Nikolay Borisov <n.borisov.lkml@gmail.com>
Acked-by: Oded Gabbay <oded.gabbay@gmail.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Palmer Dabbelt <palmer@dabbelt.com>
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Rik van Riel <riel@surriel.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Shuah Khan <shuah@kernel.org>
Acked-by: Simon Horman <horms@verge.net.au>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Takashi Iwai <tiwai@kernel.org>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tim Bird <tim.bird@sony.com>
Acked-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

Wolfram writes:
  "i2c for 4.19

   Another driver bugfix and MAINTAINERS addition from I2C."

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: rcar: cleanup DMA for all kinds of failure
  MAINTAINERS: Add entry for Broadcom STB I2C controller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

David writes:
  "Networking:

   A few straggler bug fixes:

   1) Fix indexing of multi-pass dumps of ipv6 addresses, from David
      Ahern.

   2) Revert RCU locking change for bonding netpoll, causes worse
      problems than it solves.

   3) pskb_trim_rcsum_slow() doesn't handle odd trim offsets, resulting
      in erroneous bad hw checksum triggers with CHECKSUM_COMPLETE
      devices.  From Dimitris Michailidis.

   4) a revert to some neighbour code changes that adjust notifications
      in a way that confuses some apps."

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  Revert "neighbour: force neigh_invalidate when NUD_FAILED update is from admin"
  net/ipv6: Fix index counter for unicast addresses in in6_dump_addrs
  net: fix pskb_trim_rcsum_slow() with odd trim offset
  Revert "bond: take rcu lock in netpoll_send_skb_on_dev"

Revert "neighbour: force neigh_invalidate when NUD_FAILED update is from admin"

This reverts commit 8e326289e3069dfc9fa9c209924668dd031ab8ef.

This patch results in unnecessary netlink notification when one
tries to delete a neigh entry already in NUD_FAILED state. Found
this with a buggy app that tries to delete a NUD_FAILED entry
repeatedly. While the notification issue can be fixed with more
checks, adding more complexity here seems unnecessary. Also,
recent tests with other changes in the neighbour code have
shown that the INCOMPLETE and PROBE checks are good enough for
the original issue.

Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net/ipv6: Fix index counter for unicast addresses in in6_dump_addrs

The loop wants to skip previously dumped addresses, so loops until
current index >= saved index. If the message fills it wants to save
the index for the next address to dump - ie., the one that did not
fit in the current message.

Currently, it is incrementing the index counter before comparing to the
saved index, and then the saved index is off by 1 - it assumes the
current address is going to fit in the message.

Change the index handling to increment only after a succesful dump.

Fixes: 502a2ffd7376a ("ipv6: convert idev_list to list macros")
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

i2c: rcar: cleanup DMA for all kinds of failure

DMA needs to be cleaned up not only on timeout, but on all errors where
it has been setup before.

Fixes: 73e8b0528346 ("i2c: rcar: add DMA support")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

MAINTAINERS: Add entry for Broadcom STB I2C controller

Add an entry for the Broadcom STB I2C controller in the MAINTAINERS file.

Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
[wsa: fixed sorting and a whitespace error]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Ingo writes:
  "x86 fixes:

   It's 4 misc fixes, 3 build warning fixes and 3 comment fixes.

   In hindsight I'd have left out the 3 comment fixes to make the pull
   request look less scary at such a late point in the cycle. :-/"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels
  x86/fpu: Fix i486 + no387 boot crash by only saving FPU registers on context switch if there is an FPU
  x86/fpu: Remove second definition of fpu in __fpu__restore_sig()
  x86/entry/64: Further improve paranoid_entry comments
  x86/entry/32: Clear the CS high bits
  x86/boot: Add -Wno-pointer-sign to KBUILD_CFLAGS
  x86/time: Correct the attribute on jiffies' definition
  x86/entry: Add some paranoid entry/exit CR3 handling comments
  x86/percpu: Fix this_cpu_read()
  x86/tsc: Force inlining of cyc2ns bits

Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Ingo writes:
  "scheduler fixes:

   Two fixes: a CFS-throttling bug fix, and an interactivity fix."

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/fair: Fix the min_vruntime update logic in dequeue_entity()
  sched/fair: Fix throttle_list starvation with low CFS quota

Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Ingo writes:
  "perf fixes:

   Misc perf tooling fixes."

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf tools: Stop fallbacking to kallsyms for vdso symbols lookup
  perf tools: Pass build flags to traceevent build
  perf report: Don't crash on invalid inline debug information
  perf cpu_map: Align cpu map synthesized events properly.
  perf tools: Fix tracing_path_mount proper path
  perf tools: Fix use of alternatives to find JDIR
  perf evsel: Store ids for events with their own cpus perf_event__synthesize_event_update_cpus
  perf vendor events intel: Fix wrong filter_band* values for uncore events
  Revert "perf tools: Fix PMU term format max value calculation"
  tools headers uapi: Sync kvm.h copy
  tools arch uapi: Sync the x86 kvm.h copy

net: fix pskb_trim_rcsum_slow() with odd trim offset

We've been getting checksum errors involving small UDP packets, usually
59B packets with 1 extra non-zero padding byte. netdev_rx_csum_fault()
has been complaining that HW is providing bad checksums. Turns out the
problem is in pskb_trim_rcsum_slow(), introduced in commit 88078d98d1bb
("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends").

The source of the problem is that when the bytes we are trimming start
at an odd address, as in the case of the 1 padding byte above,
skb_checksum() returns a byte-swapped value. We cannot just combine this
with skb->csum using csum_sub(). We need to use csum_block_sub() here
that takes into account the parity of the start address and handles the
swapping.

Matches existing code in __skb_postpull_rcsum() and esp_remove_trailer().

Fixes: 88078d98d1bb ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends")
Signed-off-by: Dimitris Michailidis <dmichail@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'drm-fixes-2018-10-20-1' of git://anongit.freedesktop.org/drm/drm

Dave writes:
  "drm fixes for 4.19 final (part 2)

   Looked like two stragglers snuck in, one very urgent the pageflipping
   was missing a reference that could result in a GPF on non-i915
   drivers, the other is an overflow in the sun4i dotclock calcs
   resulting in a mode not getting set."

* tag 'drm-fixes-2018-10-20-1' of git://anongit.freedesktop.org/drm/drm:
  drm/sun4i: Fix an ulong overflow in the dotclock driver
  drm: Get ref on CRTC commit object when waiting for flip_done

Merge tag 'trace-v4.19-rc8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Steven writes:
  "tracing: A few small fixes to synthetic events

   Masami found some issues with the creation of synthetic events.  The
   first two patches fix handling of unsigned type, and handling of a
   space before an ending semi-colon.

   The third patch adds a selftest to test the processing of synthetic
   events."

* tag 'trace-v4.19-rc8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  selftests: ftrace: Add synthetic event syntax testcase
  tracing: Fix synthetic event to allow semicolon at end
  tracing: Fix synthetic event to accept unsigned modifier

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

Dmitry writes:
  "Input updates for 4.19-rc8

   Just an addition to elan touchpad driver ACPI table."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15IGM

Merge tag 'drm-misc-fixes-2018-10-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Second pull request for v4.19:
- Fix ulong overflow in sun4i
- Fix a serious GPF in waiting for flip_done from commit_tail().

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/97d1ed42-1d99-fcc5-291e-cd1dc29a4252@linux.intel.com

selftests: ftrace: Add synthetic event syntax testcase

Add a testcase to check the syntax and field types for
synthetic_events interface.

Link: http://lkml.kernel.org/r/153986838264.18251.16627517536956299922.stgit@devbox
Acked-by: Shuah Khan <shuah@kernel.org>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

tracing: Fix synthetic event to allow semicolon at end

Fix synthetic event to allow independent semicolon at end.

The synthetic_events interface accepts a semicolon after the
last word if there is no space.

 # echo "myevent u64 var;" >> synthetic_events

But if there is a space, it returns an error.

 # echo "myevent u64 var ;" > synthetic_events
 sh: write error: Invalid argument

This behavior is difficult for users to understand. Let's
allow the last independent semicolon too.

Link: http://lkml.kernel.org/r/153986835420.18251.2191216690677025744.stgit@devbox
Cc: Shuah Khan <shuah@kernel.org>
Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
Cc: stable@vger.kernel.org
Fixes: commit 4b147936fa50 ("tracing: Add support for 'synthetic' events")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

tracing: Fix synthetic event to accept unsigned modifier

Fix synthetic event to accept unsigned modifier for its field type
correctly.

Currently, synthetic_events interface returns error for "unsigned"
modifiers as below;

 # echo "myevent unsigned long var" >> synthetic_events
 sh: write error: Invalid argument

This is because argv_split() breaks "unsigned long" into "unsigned"
and "long", but parse_synth_field() doesn't expected it.

With this fix, synthetic_events can handle the "unsigned long"
correctly like as below;

 # echo "myevent unsigned long var" >> synthetic_events
 # cat synthetic_events
 myevent unsigned long var

Link: http://lkml.kernel.org/r/153986832571.18251.8448135724590496531.stgit@devbox
Cc: Shuah Khan <shuah@kernel.org>
Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
Cc: stable@vger.kernel.org
Fixes: commit 4b147936fa50 ("tracing: Add support for 'synthetic' events")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

Revert "bond: take rcu lock in netpoll_send_skb_on_dev"

This reverts commit 6fe9487892b32cb1c8b8b0d552ed7222a527fe30.

It is causing more serious regressions than the RCU warning
it is fixing.

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

Merge tag 'usb-4.19-final' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

I wrote:
  "USB fixes for 4.19-final

   Here are a small number of last-minute USB driver fixes

   Included here are:
     - spectre fix for usb storage gadgets
     - xhci fixes
     - cdc-acm fixes
     - usbip fixes for reported problems

   All of these have been in linux-next with no reported issues."

* tag 'usb-4.19-final' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  usb: gadget: storage: Fix Spectre v1 vulnerability
  USB: fix the usbfs flag sanitization for control transfers
  usb: xhci: pci: Enable Intel USB role mux on Apollo Lake platforms
  usb: roles: intel_xhci: Fix Unbalanced pm_runtime_enable
  cdc-acm: correct counting of UART states in serial state notification
  cdc-acm: do not reset notification buffer index upon urb unlinking
  cdc-acm: fix race between reset and control messaging
  usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control()
  selftests: usbip: add wait after attach and before checking port status

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

Jens writes:
  "Block fixes for 4.19-final

   Two small fixes that should go into this release."

* tag 'for-linus-20181019' of git://git.kernel.dk/linux-block:
  block: don't deal with discard limit in blkdev_issue_discard()
  nvme: remove ns sibling before clearing path

drm/sun4i: Fix an ulong overflow in the dotclock driver

The calculated ideal rate can easily overflow an unsigned long, thus
making the best div selection buggy as soon as no ideal match is found
before the overflow occurs.

Fixes: 4731a72df273 ("drm/sun4i: request exact rates to our parents")
Cc: <stable@vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018100250.12565-1-boris.brezillon@bootlin.com

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

David writes:
  "Networking

   1) Fix gro_cells leak in xfrm layer, from Li RongQing.

   2) BPF selftests change RLIMIT_MEMLOCK blindly, don't do that.  From
      Eric Dumazet.

   3) AF_XDP calls synchronize_net() under RCU lock, fix from Björn
      Töpel.

   4) Out of bounds packet access in _decode_session6(), from Alexei
      Starovoitov.

   5) Several ethtool bugs, where we copy a struct into the kernel twice
      and our validations of the values in the first copy can be
      invalidated by the second copy due to asynchronous updates to the
      memory by the user.  From Wenwen Wang.

   6) Missing netlink attribute validation in cls_api, from Davide
      Caratti.

   7) LLC SAP sockets neet to be SOCK_RCU FREE, from Cong Wang.

   8) rxrpc operates on wrong kvec, from Yue Haibing.

   9) A regression was introduced by the disassosciation of route
      neighbour references in rt6_probe(), causing probe for
      neighbourless routes to not be properly rate limited.  Fix from
      Sabrina Dubroca.

   10) Unsafe RCU locking in tipc, from Tung Nguyen.

   11) Use after free in inet6_mc_check(), from Eric Dumazet.

   12) PMTU from icmp packets should update the SCTP transport pathmtu,
       from Xin Long.

   13) Missing peer put on error in rxrpc, from David Howells.

   14) Fix pedit in nfp driver, from Pieter Jansen van Vuuren.

   15) Fix overflowing shift statement in qla3xxx driver, from Nathan
       Chancellor.

   16) Fix Spectre v1 in ptp code, from Gustavo A. R. Silva.

   17) udp6_unicast_rcv_skb() interprets udpv6_queue_rcv_skb() return
       value in an inverted manner, fix from Paolo Abeni.

   18) Fix missed unresolved entries in ipmr dumps, from Nikolay
       Aleksandrov.

   19) Fix NAPI handling under high load, we can completely miss events
       when NAPI has to loop more than one time in a cycle.  From Heiner
       Kallweit."

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (49 commits)
  ip6_tunnel: Fix encapsulation layout
  tipc: fix info leak from kernel tipc_event
  net: socket: fix a missing-check bug
  net: sched: Fix for duplicate class dump
  r8169: fix NAPI handling under high load
  net: ipmr: fix unresolved entry dumps
  net: mscc: ocelot: Fix comment in ocelot_vlant_wait_for_completion()
  sctp: fix the data size calculation in sctp_data_size
  virtio_net: avoid using netif_tx_disable() for serializing tx routine
  udp6: fix encap return code for resubmitting
  mlxsw: core: Fix use-after-free when flashing firmware during init
  sctp: not free the new asoc when sctp_wait_for_connect returns err
  sctp: fix race on sctp_id2asoc
  r8169: re-enable MSI-X on RTL8168g
  net: bpfilter: use get_pid_task instead of pid_task
  ptp: fix Spectre v1 vulnerability
  net: qla3xxx: Remove overflowing shift statement
  geneve, vxlan: Don't set exceptions if skb->len < mtu
  geneve, vxlan: Don't check skb_dst() twice
  sctp: get pr_assoc and pr_stream all status with SCTP_PR_SCTP_ALL instead
  ...

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc

David writes:
  "Sparc fixes:

   The main bit here is fixing how fallback system calls are handled in
   the sparc vDSO.

   Unfortunately, I fat fingered the commit and some perf debugging
   hacks slipped into the vDSO fix, which I revert in the very next
   commit."

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  sparc: Revert unintended perf changes.
  sparc: vDSO: Silence an uninitialized variable warning
  sparc: Fix syscall fallback bugs in VDSO.

Merge tag 'drm-fixes-2018-10-19' of git://anongit.freedesktop.org/drm/drm

Dave writes:
  "drm fixes for 4.19 final

   Just a last set of misc core fixes for final.

   4 fixes, one use after free, one fb integration fix, one EDID fix,
   and one laptop panel quirk,"

* tag 'drm-fixes-2018-10-19' of git://anongit.freedesktop.org/drm/drm:
  drm/edid: VSDB yCBCr420 Deep Color mode bit definitions
  drm: fix use of freed memory in drm_mode_setcrtc
  drm: fb-helper: Reject all pixel format changing requests
  drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl

Merge tag 'for-gkh' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma

Doug writes:
  "Really final for-rc pull request for 4.19

   Ok, so last week I thought we had sent our final pull request for
   4.19.  Well, wouldn't ya know someone went and found a couple Spectre
   v1 fixes were needed :-/.  So, a couple *very* small specter patches
   for this (hopefully) final -rc week."

* tag 'for-gkh' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
  RDMA/ucma: Fix Spectre v1 vulnerability
  IB/ucm: Fix Spectre v1 vulnerability

x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels

We already build the swiotlb code for 32-bit kernels with PAE support,
but the code to actually use swiotlb has only been enabled for 64-bit
kernels for an unknown reason.

Before Linux v4.18 we paper over this fact because the networking code,
the SCSI layer and some random block drivers implemented their own
bounce buffering scheme.

[ mingo: Changelog fixes. ]

Fixes: 21e07dba9fb1 ("scsi: reduce use of block bounce buffers")
Fixes: ab74cfebafa3 ("net: remove the PCI_DMA_BUS_IS_PHYS check in illegal_highdma")
Reported-by: Matthew Whitehead <tedheadster@gmail.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Matthew Whitehead <tedheadster@gmail.com>
Cc: konrad.wilk@oracle.com
Cc: iommu@lists.linux-foundation.org
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181014075208.2715-1-hch@lst.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge tag 'drm-misc-fixes-2018-10-18' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

drm-misc-fixes for v4.19:
- Fix use of freed memory in drm_mode_setcrtc.
- Reject pixel format changing requests in fb helper.
- Add 6 bpc quirk for HP Pavilion 15-n233sl
- Fix VSDB yCBCr420 Deep Color mode bit definitions

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/647fe5d0-4ec5-57cc-9f23-a4836b29e278@linux.intel.com

ip6_tunnel: Fix encapsulation layout

Commit 058214a4d1df ("ip6_tun: Add infrastructure for doing
encapsulation") added the ip6_tnl_encap() call in ip6_tnl_xmit(), before
the call to ipv6_push_frag_opts() to append the IPv6 Tunnel Encapsulation
Limit option (option 4, RFC 2473, par. 5.1) to the outer IPv6 header.

As long as the option didn't actually end up in generated packets, this
wasn't an issue. Then commit 89a23c8b528b ("ip6_tunnel: Fix missing tunnel
encapsulation limit option") fixed sending of this option, and the
resulting layout, e.g. for FoU, is:

.-------------------.------------.----------.-------------------.----- - -
| Outer IPv6 Header | UDP header | Option 4 | Inner IPv6 Header | Payload
'-------------------'------------'----------'-------------------'----- - -

Needless to say, FoU and GUE (at least) won't work over IPv6. The option
is appended by default, and I couldn't find a way to disable it with the
current iproute2.

Turn this into a more reasonable:

.-------------------.----------.------------.-------------------.----- - -
| Outer IPv6 Header | Option 4 | UDP header | Inner IPv6 Header | Payload
'-------------------'----------'------------'-------------------'----- - -

With this, and with 84dad55951b0 ("udp6: fix encap return code for
resubmitting"), FoU and GUE work again over IPv6.

Fixes: 058214a4d1df ("ip6_tun: Add infrastructure for doing encapsulation")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tipc: fix info leak from kernel tipc_event

We initialize a struct tipc_event allocated on the kernel stack to
zero to avert info leak to user space.

Reported-by: syzbot+057458894bc8cada4dee@syzkaller.appspotmail.com
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>