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

TI-Feature: vignesh_next
TI-Tree: git://git.ti.com/~vigneshr/ti-linux-kernel/vigneshr-ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y-for-next

* 'ti-linux-4.14.y-for-next' of git://git.ti.com/~vigneshr/ti-linux-kernel/vigneshr-ti-linux-kernel:
  mtd: spi-nor: cadence-quadspi: Fix dma coherent mask definition
  net: ethernet: ti: am65-cpsw-nuss: fix tx checksum offload
  TMP
  SPI WIP

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

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

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

* 'rpmsg-ti-linux-4.14.y-next' of git://git.ti.com/rpmsg/rpmsg:
  remoteproc/pruss: update pruss_get() to retrieve a PRUSS id
  remoteproc/pruss: store the pruss instance id
  remoteproc: expose rproc_set_firmware() to remoteproc clients

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

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

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

* 'platform-ti-linux-4.14.y-next' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  Revert "dt-bindings: irqchip: Introduce TI SCI irqchip bindings"
  Revert "irqchip: tisci: Add the TI SCI irqchip driver"
  ti_config_fragments: v8_baseport: Enable TI_SCI_INTA/R_IRQCHIP
  dmaengine: ti: k3-udma: Adapt glue layer to new tisci_irq API
  dmaengine: ti: k3-udma: Change to the new tisci_irq API
  arm64: dts: ti: Add Interrupt controller nodes
  irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver
  irqchip: ti-sci-intr: Add support for Interrupt Router driver
  firmware: ti_sci: Add helpers to mange resources
  firmware: ti_sci: Update IRQ management ops
  firmware: ti_sci: Add support for RM core ops
  Revert "ti_config_fragments: v8_baseport: Enable TI_SCI_IRQCHIP"
  arm64: dts: k3-am6: Exclude sysfw reserved rings in main NAVSS ringacc
  dmaengine: ti: k3-udma: Exclude sysfw used channels and flow

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

Revert "dt-bindings: irqchip: Introduce TI SCI irqchip bindings"

This reverts commit 64b4f8c711b62679428fe3c35e7ae0b69a51ba82.

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

Revert "irqchip: tisci: Add the TI SCI irqchip driver"

This reverts commit 71664a5c4ce4ef564c261122f20be53ac7433d49.

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

ti_config_fragments: v8_baseport: Enable TI_SCI_INTA/R_IRQCHIP

Enable Interrupt Router and Interrupt Aggregator drivers.

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

dmaengine: ti: k3-udma: Adapt glue layer to new tisci_irq API

Adapt the new tisci irq changes to k3-udma glue layer.

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

dmaengine: ti: k3-udma: Change to the new tisci_irq API

Adapt the new tisci irq changes to k3-udma.

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

arm64: dts: ti: Add Interrupt controller nodes

Add Interrupt Router and aggregator nodes and drop ti-sci-irqchip node.

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

irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver

Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
which is an interrupt controller that does the following:
- Converts events to interrupts that can be understood by
  an interrupt router.
- Allows for multiplexing of events to interrupts.
- Allows for grouping of multiple events to a single interrupt.

Configuration of the interrupt aggregator registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.

Add support for Interrupt Aggregator driver over TISCI protocol.

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

irqchip: ti-sci-intr: Add support for Interrupt Router driver

Texas Instruments' K3 generation SoCs has an IP Interrupt Router
that does allows for multiplexing of input interrupts to host
interrupt controller. Interrupt Router inputs are either from a
peripheral or from an Interrupt Aggregator which is another
interrupt controller.

Configuration of the interrupt router registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.

Add support for Interrupt Router driver over TISCI protocol.

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

firmware: ti_sci: Add helpers to mange resources

Each resource with in the device can be uniquely identified
by a type and subtype. Since this is generic across the device,
resource allocation also can be made generic instead of
each client driver handling the resource. So add helper
apis to manage the resource.

devm_ti_sci_get_of_resource() expects resource from dt
in form of tuples <type, subtype>.

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

firmware: ti_sci: Update IRQ management ops

Starting from v2018.07 SYSFW, resource allocation to each device is
done statically at boot time by board resource assignment message.
Given that clients has to manage the allocation of these resources
with in the device, the RM apis that configures the resources gets
changed to take resource to configure as input.
In corporate these changes to IRQ management APIs.

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

firmware: ti_sci: Add support for RM core ops

TISCI provides support for getting the resources(IRQ, RING etc..)
assigned to a specific device. These resources can be handled by
the client and in turn sends TISCI cmd to configure the resources.

It is very important that client should keep track on usage of these
resources.

Add support for TISCI commands to get resource ranges.

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

Revert "ti_config_fragments: v8_baseport: Enable TI_SCI_IRQCHIP"

This reverts commit c84b0a42d0c596b6509c84e1a44e2ea3eb11b6a4.

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

arm64: dts: k3-am6: Exclude sysfw reserved rings in main NAVSS ringacc

General purpose ring 302 and 303 is reserved for sysfw use. Exclude them
from the GP ring range.

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

dmaengine: ti: k3-udma: Exclude sysfw used channels and flow

tchan0, rchan0 and rflow0 is reserved to be used only by sysfw. Make sure
that the driver will not allow these resources to be taken.

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

mtd: spi-nor: cadence-quadspi: Fix dma coherent mask definition

Kbuild test bot reports:
All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:11:0,
                    from include/linux/clk.h:16,
                    from drivers/mtd/spi-nor/cadence-quadspi.c:18:
   include/linux/bitops.h:7:24: warning: left shift count >= width of type [-Wshift-count-overflow]
    #define BIT(nr)   (1UL << (nr))

>> drivers/mtd/spi-nor/cadence-quadspi.c:1480:23: note: in expansion of macro 'BIT'
     .dma_coherent_mask = BIT(48),
                          ^~~
Fix this by using BIT_ULL() which is guaranteed to be 64-bit long even
on a 32-bit system.

Fixes: 680c9a3fd327 ("mtd: spi-nor: cadence-quadspi: Set coherent dma mask as required")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>

net: ethernet: ti: am65-cpsw-nuss: fix tx checksum offload

Reset CPPI5 PS data word 2 which controls TX checksum offload, because it
might contain garbage or values from previous packets and, as result, it
can cause invalid checksum calculation for packets for whihc HW TX checksum
offload should not be done.

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

TMP

Signed-off-by: Vignesh R <vigneshr@ti.com>

SPI WIP

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

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

* 'platform-ti-linux-4.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  dmaengine: ti: k3-udma: glue: Plug rflow leaks

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

remoteproc/pruss: update pruss_get() to retrieve a PRUSS id

Update the pruss_get() function to take in an additional integer
pointer argument in which the PRUSS instance id is filled in and
provided back to the callers. This allows the drivers to add some
instance-specific logic/customization in their code, as the PRUSS
handle is not useful to build this logic.

The already existing usage within both the regular PRU Ethernet
and the ICSSG PRU Ethernet drivers have also been updated accordingly,
and this will cater to its need for supporting switching between
different Ethernet protocols dynamically per instance.

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

remoteproc/pruss: store the pruss instance id

Add logic to the PRUSS platform driver to store the instance id
of a PRUSS instance. This is being added to enable support for
the PRU Ethernet driver to be able to switch between different
Ethernet protocols dynamically per instance.

The values for instance ids are not always zero-indexed on all
SoCs, they were chosen to match the numbering used in the TRMs.
The instance ids are computed assigned using the PRUSS memory
region base address lookup table. The base address matching
logic is not robust for long-term for newer SoCs, but is okay
for currently supported SoCs as all the addresses are unique.
This is done this way to retain the current usage of minimal
static data and to avoid having to introduce the instance
specific static data just for the instance id data.

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

remoteproc: expose rproc_set_firmware() to remoteproc clients

The rproc_set_firmware() API added in commit ("remoteproc: add a
rproc_set_firmware() API") allows the remoteproc platform drivers
to be able to configure a custom firmware name overriding the default
firmware name used during the remoteproc registration time. This
function was limited to only the remoteproc platform drivers. Expose
this function to drivers outside of the remoteproc folder as well
so that remoteproc client drivers can also use it to customize the
firmware name. The TI PRU Ethernet driver will be an example of
such usage as it requires to use different firmwares for different
supported protocols.

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

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

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

* 'rpmsg-ti-linux-4.14.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  remoteproc/pru: allow fw intc resource fallback for PRUs with no DT irqs
  remoteproc/pru: fix ti,pru-interrupt-map range checks for K3 SoCs
  remoteproc/pruss_intc: fix interrupt configuration for SYSEVENT > 31

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

remoteproc/pru: allow fw intc resource fallback for PRUs with no DT irqs

The commit 2c562b01f8d2 ("remoteproc/pru: add support for parsing pru
interrupt mapping from DT") provided an alternate way of configuring the
PRU INTC through a DT property 'ti,pru-interrupt-map' in the client's DT
node. This is a single property used for all the PRU cores referenced by
a client node, and supercedes any firmware provided intc configuration
structure. The current logic handled this as an all or nothing DT-based
irq mapping configuration for all referenced PRU cores. Any PRU cores that
do not have any irqs listed in the 'ti,pru-interrupt-map' are treated as
PRU cores requiring no interrupts at all.

Enhance this logic to allow any referenced PRU cores with zero entries in
the 'ti,pru-interrupt-map' property to fallback to process the interrupts
through the firmware intc vendor resource type. This provides the maximum
flexibility for PRU client drivers/applications.

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

remoteproc/pru: fix ti,pru-interrupt-map range checks for K3 SoCs

The ICSSG instances on AM65x SoCs have more System Events, Interrupt
Channels and Host Interrupts compared to the previous generation PRUSS
instances on other SoCs. The logic in pru_rproc_get() function to parse
and program the interrupts from DT is still checking against the values
relevant to previous generation PRUSS instances and therefore would
result in invalid failures when any of the new events are used on AM65x
platforms.

Fix this logic properly for K3 SoCs. The logic was simply designed around
storing a flag that is set only on K3 SoCs, and can be reworked to use
match data to scale beyond current SoCs if needed.

Fixes: 529c7767b4f3 ("remoteproc/pru: add support for various PRU cores on K3 AM6x SoCs")
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pruss_intc: fix interrupt configuration for SYSEVENT > 31

The PRU interrupt configuration logic relied on a sysevt_mask local
variable for enabling/disabling a specific System Event in the
appropriate PRU_INTC_ESR/PRU_INTC_ECR register. The commit 3c0029274705
("remoteproc/pruss_intc: add support for ICSSG INTC on K3 AM6x SoCs")
has modified the local state variable sysevt_mask from a u64 to an u32
array to scale for the increased number of events, and uses the bit
position in the corresponding u32 array element to mark a specific event.
This conversion missed performing a modulo operation on the event number
while storing the event bit, thereby rendering all System Events > 31
to be unmarked in the sysevt_mask array and not enabling/disabling any
of these System Events.

This bug resulted in the PRU Ethernet functionality being broken on
AM335x ICE and AM437x IDK boards. The functionality on K2G ICE and
AM57xx IDK boards was not broken (weird!!) even though the events were
not configured. Fix this logic to properly enable/disable all possible
System Events.

Fixes: 3c0029274705 ("remoteproc/pruss_intc: add support for ICSSG INTC on K3 AM6x SoCs")
Reported-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

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

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

* 'connectivity-ti-linux-4.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  arm64: dts: k3-am6: Add dma-coherent property to OSPI nodes
  mtd: spi-nor: cadence-quadspi: Set coherent dma mask as required
  mtd: spi-nor: cadence-quadspi: Convert driver data to struct

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

dmaengine: ti: k3-udma: glue: Plug rflow leaks

We need to free the rflow ranges at k3_nav_udmax_release_rx_chn()
else we leak the rflow range.

Fixes: 429c39089a1b ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine users")
Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

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

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

* 'connectivity-ti-linux-4.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  arm64: dts: ti: Describe the SERDES clock inputs, outputs and mux in dt
  phy: ti: phy-ti-am654: Add support to select PLL mux and left/right output mux
  dt-bindings: phy: ti: Add specification for the clocks

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

arm64: dts: k3-am6: Add dma-coherent property to OSPI nodes

Add dma-coherent property to OSPI nodes as, data movement between OSPI
and memory via UDMA is IO coherent wrt A53 accesses on AM654 SoC.

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

mtd: spi-nor: cadence-quadspi: Set coherent dma mask as required

On AM654 SoC, which is IO coherent wrt memory access via DMA, driver
needs to set coherent dma mask appropriately. Otherwise, streaming DMA
mapping APIs seem to be using swiotlb/bounce buffer and running out of
memory like:
[   62.087773] cadence-qspi 47040000.ospi: swiotlb buffer is full (sz: 52428800 bytes)
[   62.095553] cadence-qspi 47040000.ospi: DMA: Out of SW-IOMMU space for 52428800 bytes
[   62.103461] Kernel panic - not syncing: DMA: Random memory could be DMA written

Therefore provide a way to pass coherent dma mask via driver data. And
set it accordingly during driver probe. Also, set appropriate mask for
AM654 SoC.

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

mtd: spi-nor: cadence-quadspi: Convert driver data to struct

Convert driver data to struct to enable passing of additional
platform specific information in the following patches.

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

arm64: dts: ti: Describe the SERDES clock inputs, outputs and mux in dt

Keep the default configuration (k3-am6.dtsi) such that PLL mux of
SERDES0 uses the the left input connected to SoC clock and PLL mux
of SERDES1 uses the right input connected to SoC clock.

In the DT overlay file for 2lane PCIe SERDES personality card,
change the configuration such that the PLL mux of SERDES1 uses the
right output of SERDES0 and the right output of SERDES0 is connected
to the left input of SERDES0.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

phy: ti: phy-ti-am654: Add support to select PLL mux and left/right output mux

SERDES in am654x has three input clocks (left input, externel reference
clock and right input) and two output clocks (left output and right
output) in addition to a PLL mux clock which the SERDES uses for Clock
Multiplier Unit (CMU refclock).

The PLL mux clock can select from one of the three input clocks.
The right output can select between left input and external reference
clock while the left output can select between the right input and
external reference clock.

Add support to select PLL mux and left/right output mux as specified in
device tree.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

dt-bindings: phy: ti: Add specification for the clocks

AM654x has two SERDES instances. Each instance has three input clocks
(left input, externel reference clock and right input) and two output
clocks (left output and right output) in addition to a PLL mux clock
which the SERDES uses for Clock Multiplier Unit (CMU refclock).
The PLL mux clock can select from one of the three input clocks.
The right output can select between left input and external reference
clock while the left output can select between the right input and
external reference clock.

The left and right input reference clock of SERDES0 and SERDES1
respectively are connected to the SoC clock. In the case of two lane
SERDES personality card, the left input of SERDES1 is connected to
the right output of SERDES0 in a chained fashion.

See section "Reference Clock Distribution" of AM65x Sitara Processors
TRM (SPRUID7 – April 2018) for more details.

Add dt-binding documentation in order to represent all these different
configurations in device tree.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

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

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

* 'connectivity-ti-linux-4.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  arm64: dts: k3-am6: Add DMA entries for UART nodes
  serial: 8250_omap: Add DMA support for UARTs on AM654 SoC
  serial: 8250_omap: Get FIFO/DMA triggers from driver data
  serial: 8250_omap; Support EFR2 register
  serial: 8250_omap: Extend driver data to pass DMA configuration
  serial: 8250_omap: Introduce new callback to handle RX DMA
  serial: 8250_omap: Terminate DMA before pushing data on RX timeout
  serial: 8250_omap: account for DMA cached data
  serial: 8250_omap: Work around errata spurious IRQs with DMA
  arm64: dts: k3-am654-idk: add aliases for PRUSS eth

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

arm64: dts: k3-am6: Add DMA entries for UART nodes

Add DMA entries for MCU UART0, MAIN UART0,1,2. While at that fix up
main_pdma1 psil configs to be in packet mode for UART as UART is
supposed to operate in packet mode.

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

serial: 8250_omap: Add DMA support for UARTs on AM654 SoC

Unlike, older OMAP SoCs, AM654 SoC has configurable RX timeout behavior
(controlled via EFR2) and better DMA integration. This allows to
transfer a large amount of data per DMA transfer compared to older SoCs.
Add support for the same.

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

serial: 8250_omap: Get FIFO/DMA triggers from driver data

If driver data provides DMA information, then use that data to configure
DMA burst size and FIFO trigger values. This is required to support
longer DMA transfers and optimal DMA burst sizes for different SoCs.

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

serial: 8250_omap; Support EFR2 register

AM654 SoC has a newer version of 8250 OMAP UART IP that as Enhanced
Feature Register 2 (EFR2). This register provides a way to configure UART
RX timeout to fire when there is no activity on RX line, irrespective
whether are not there is data in RX FIFO. Using this feature its
possible to queue RX DMA for length > RX FIFO size and still reliably
detect timeout condition.

Add a quirk in the driver to make use of this feature.

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

serial: 8250_omap: Extend driver data to pass DMA configuration

Although same 8250_omap is reused across different SoC, their
integration wrt DMA varies greatly across SoCs. Therefore, provide DMA
configuration and ops via driver data for maximum reuse of code.

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

serial: 8250_omap: Introduce new callback to handle RX DMA

Introduce new callback to handle different RX related interrupts when
DMA is enabled. This is required in order to add DMA support for UART on
AM654 SoC in later patches.

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

serial: 8250_omap: Terminate DMA before pushing data on RX timeout

Terminate and flush DMA internal buffers, before pushing RX data to
higher layer. Otherwise, this will lead to data corruption, as driver
would end up pushing stale buffer data to higher layer while actual data
is still stuck inside DMA hardware and has yet not arrived at the
memory.
While at that, replace deprecated dmaengine_terminate_all() with
dmaengine_terminate_async().

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

serial: 8250_omap: account for DMA cached data

Take into account data stuck in DMA internal buffers pushing data to
higher layer. dma_tx_state has "cached" member that provides this
information.

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

serial: 8250_omap: Work around errata spurious IRQs with DMA

As per Advisory 27 of AM437x Silicon errata document, Spurious UART
interrupts may occur when enabling DMA mode (FCR.DMA_MODE). The
Interrupt Controller flags that a UART interrupt has occurred; however,
the associated IT_PENDING bit remains set to 1, indicating that no
interrupt is pending. Acknowledge the spurious interrupts for every
occurrence as workaround.

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

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

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

* 'connectivity-ti-linux-4.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  arm64: dts: ti: k3-am654-base-board: Enable UHS modes in sdhci1
  mmc: sdhci-of-arasan: Don't register rockchip specific callback for am65x
  ti_config_fragments/connectivity.cfg: Enable TSCADC
  arm64: dts: k3-am654-base-board: Enable ADCs
  arm64: dts: k3-am6: Add ADC DT nodes
  iio: adc: ti_am335x_adc: Use ADC dev pointer while allocating DMA buffer
  mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
  dt-bindings: ti-tsc-adc: Document compatible properties for tscadc IP
  phy: phy-am654-mmc: Reset all accessed registers to default values on power_off

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

arm64: dts: k3-am654-idk: add aliases for PRUSS eth

In order to allow the bootloader to fill in the MAC addresses for
PRUSS-based Ethernet it requires aliases to be established in the
form of ethernetX. Hence, go ahead and add those aliases for the
four additional interfaces introduced by the AM654 IDK daughtercard
to allow for this mechanism to work.

Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

arm64: dts: ti: k3-am654-base-board: Enable UHS modes in sdhci1

Remove the sdhci-caps-mask for sdhci1 to enable UHS modes (uptil
SDR104 mode) for the SD card.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

mmc: sdhci-of-arasan: Don't register rockchip specific callback for am65x

The start_signal_voltage_switch() callback is a rockchip specific
quirk. Don't register it for am65x.

This enables am65x to use the sdhci start_signal_voltage_switch and
hence enable UHS modes for the SD card.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

ti_config_fragments/connectivity.cfg: Enable TSCADC

Enable MFD TSCADC driver as a module to use ADC on AM654 SoC.

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

arm64: dts: k3-am654-base-board: Enable ADCs

Two ADC interfaces on AM654 SoC are bought out on header/test points.
Enable ADC interface in DT to be able to use them.

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

arm64: dts: k3-am6: Add ADC DT nodes

AM654 SoC has two ADCs. Each ADC has two DMA RX channels (one per FIFO)
which are connected to MCU PDMA0. Add DT entries for the same.

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

iio: adc: ti_am335x_adc: Use ADC dev pointer while allocating DMA buffer

We should use device pointer of ADC device and not that of DMA device
when allocated coherent buffer for DMA in ADC driver. Fix this by using
ADC device pointer when allocating/freeing buffers for DMA.

Fixes: f438b9da75eb ("drivers: iio: ti_am335x_adc: add dma support")
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

mfd: ti_am335x_tscadc: Provide unique name for child mfd cells

Provide unique names for child mfd cells, this is required in order to
support registering of multiple instances of same ti_am335x_tscadc IP.

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

dt-bindings: ti-tsc-adc: Document compatible properties for tscadc IP

Add binding for compatible property for tscadc and its child nodes.

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

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

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

* 'platform-ti-linux-4.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  dmaengine: ti: k3-udma: Fix channel teardown handling
  dmaengine: ti: k3-udma: Rename udma_stop_hard to udma_reset_chan
  dmaengine: ti: k3-udma: Use teardown for memcpy channels when stopping
  dmaengine: ti: k3-udma: Use different counters for packets and TRs
  dmaengine: ti: k3-udma: Do pause/resume on the remote (peer) side only
  soc: ti: k3: add COMPILE_TEST to kbuild for DMA modules

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

phy: phy-am654-mmc: Reset all accessed registers to default values on power_off

The bootloader may leave the phy in an unknown state before booting
kernel. Therefore, make sure that all registers bits are reset to
their default values on init and during power_off.

Also remove an extra blank line.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

dmaengine: ti: k3-udma: Fix channel teardown handling

In terminate_all we set the given channel to start a teardown. New
transfers can not be started before the teardown is completed and we must
not reset the RT_CTL registers before the teardown is completed.

To ensure that we obey this rule:
Wait for a completion in udma_synchronize() before resetting the RT_CTL
registers.

In issue_pending() mkae sure that we are not pushing new descriptor to the
ring while the channel is in teardown (we initiated the teardown and the
channel is still enabled).

When we receive the teardown complete message make sure that we pick up
the next pending (if any) descriptor.

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

dmaengine: ti: k3-udma: Rename udma_stop_hard to udma_reset_chan

The udma_stop_hard() is used to reset the RT_CTL registers to clear any
non autoclearing bits, like TDOWN or FLUSH.

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

dmaengine: ti: k3-udma: Use teardown for memcpy channels when stopping

The teardown is the proper way to stop a channel, even in case when it has
no ongoing transfers, which is typical for the memcpy use cases.

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

dmaengine: ti: k3-udma: Use different counters for packets and TRs

Audio is using cyclic TR mode and we used the sg_idx to track which TR just
given the interrupt (period irq). But the same sg_idx is used by the packet
tracking logic as well.

When the cyclic TR is stopped we might (or might not) get back the TR
descriptor from UDMA and if the sg_idx was not 0, we might be accessing to
invalid memory causing crash.

Use different counters for packets (within a transfer - in reality we only
have 1 packet for any given transfer type) and for the TR tracking.

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

dmaengine: ti: k3-udma: Do pause/resume on the remote (peer) side only

Pause the remote side only to stop it from pulling data from the peripheral
when after the pause is called.

PDMA for example is still going to serve DMA requests up until it's FIFO
have space for new data if it is not paused.

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

soc: ti: k3: add COMPILE_TEST to kbuild for DMA modules

If this is not in place, building allmodconfig generates following warnings:

warning: (TI_K3_NAVSS_UDMA) selects TI_K3_NAVSS_RINGACC which has unmet direct dependencies (SOC_TI && ARCH_K3)
warning: (TI_K3_NAVSS_UDMA) selects TI_K3_NAVSS_PSILCFG which has unmet direct dependencies (SOC_TI && ARCH_K3 && TI_SCI_PROTOCOL)
warning: (TI_K3_NAVSS_UDMA) selects TI_K3_NAVSS_RINGACC which has unmet direct dependencies (SOC_TI && ARCH_K3)
warning: (TI_K3_NAVSS_UDMA) selects TI_K3_NAVSS_PSILCFG which has unmet direct dependencies (SOC_TI && ARCH_K3 && TI_SCI_PROTOCOL)

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

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

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

* 'connectivity-ti-linux-4.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  net: ethernet: ti: am65-cpsw-nuss: fix modular build
  net: ethernet: ti: am65-cpsw-nuss: fix ndev features declaration
  net: ethernet: ti: am65-cpsw-nuss: add tx checksum offload support
  net: ethernet: ti: am65-cpsw-nuss: add rx checksum offload support

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

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

This is the 4.14.59 stable release

* tag 'v4.14.59' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (49 commits)
  Linux 4.14.59
  turn off -Wattribute-alias
  can: m_can.c: fix setup of CCCR register: clear CCCR NISO bit before checking can.ctrlmode
  can: peak_canfd: fix firmware < v3.3.0: limit allocation to 32-bit DMA addr only
  can: xilinx_can: fix RX overflow interrupt not being enabled
  can: xilinx_can: fix incorrect clear of non-processed interrupts
  can: xilinx_can: keep only 1-2 frames in TX FIFO to fix TX accounting
  can: xilinx_can: fix device dropping off bus on RX overrun
  can: xilinx_can: fix recovery from error states not being propagated
  can: xilinx_can: fix power management handling
  can: xilinx_can: fix RX loop if RXNEMP is asserted without RXOK
  driver core: Partially revert "driver core: correct device's shutdown order"
  usb: gadget: f_fs: Only return delayed status when len is 0
  usb: dwc2: Fix DMA alignment to start at allocated boundary
  usb: core: handle hub C_PORT_OVER_CURRENT condition
  usb: cdc_acm: Add quirk for Castles VEGA3000
  staging: speakup: fix wraparound in uaccess length check
  tcp: add tcp_ooo_try_coalesce() helper
  tcp: call tcp_drop() from tcp_data_queue_ofo()
  tcp: detect malicious patterns in tcp_collapse_ofo_queue()
  ...

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

Linux 4.14.59

turn off -Wattribute-alias

Starting with gcc-8.1, we get a warning about all system call definitions,
which use an alias between functions with incompatible prototypes, e.g.:

In file included from ../mm/process_vm_access.c:19:
../include/linux/syscalls.h:211:18: warning: 'sys_process_vm_readv' alias between functions of incompatible types 'long int(pid_t,  const struct iovec *, long unsigned int,  const struct iovec *, long unsigned int,  long unsigned int)' {aka 'long int(int,  const struct iovec *, long unsigned int,  const struct iovec *, long unsigned int,  long unsigned int)'} and 'long int(long int,  long int,  long int,  long int,  long int,  long int)' [-Wattribute-alias]
  asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
                  ^~~
../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
  __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
  ^~~~~~~~~~~~~~~~~
../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
 #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
                                    ^~~~~~~~~~~~~~~
../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
 SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,
 ^~~~~~~~~~~~~~~
../include/linux/syscalls.h:215:18: note: aliased declaration here
  asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
                  ^~~
../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
  __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
  ^~~~~~~~~~~~~~~~~
../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
 #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
                                    ^~~~~~~~~~~~~~~
../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
 SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,

This is really noisy and does not indicate a real problem. In the latest
mainline kernel, this was addressed by commit bee20031772a ("disable
-Wattribute-alias warning for SYSCALL_DEFINEx()"), which seems too invasive
to backport.

This takes a much simpler approach and just disables the warning across the
kernel.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: m_can.c: fix setup of CCCR register: clear CCCR NISO bit before checking can.ctrlmode

commit 393753b217f05474e714aea36c37501546ed1202 upstream.

Inside m_can_chip_config(), when setting up the new value of the CCCR,
the CCCR_NISO bit is not cleared like the others, CCCR_TEST, CCCR_MON,
CCCR_BRSE and CCCR_FDOE, before checking the can.ctrlmode bits for
CAN_CTRLMODE_FD_NON_ISO.

This way once the controller was configured for CAN_CTRLMODE_FD_NON_ISO,
this mode could never be cleared again.

This fix is only relevant for controllers with version 3.1.x or 3.2.x.
Older versions do not support NISO.

Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: peak_canfd: fix firmware < v3.3.0: limit allocation to 32-bit DMA addr only

commit 5d4c94ed9f564224d7b37dbee13f7c5d4a8a01ac upstream.

The DMA logic in firmwares < v3.3.0 embedded in the PCAN-PCIe FD cards
family is not capable of handling a mix of 32-bit and 64-bit logical
addresses. If the board is equipped with 2 or 4 CAN ports, then such a
situation might lead to a PCIe Bus Error "Malformed TLP" packet
as well as "irq xx: nobody cared" issue.

This patch adds a workaround that requests only 32-bit DMA addresses
when these might be allocated outside of the 4 GB area.

This issue has been fixed in firmware v3.3.0 and next.

Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: xilinx_can: fix RX overflow interrupt not being enabled

commit 83997997252f5d3fc7f04abc24a89600c2b504ab upstream.

RX overflow interrupt (RXOFLW) is disabled even though xcan_interrupt()
processes it. This means that an RX overflow interrupt will only be
processed when another interrupt gets asserted (e.g. for RX/TX).

Fix that by enabling the RXOFLW interrupt.

Fixes: b1201e44f50b ("can: xilinx CAN controller support")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: xilinx_can: fix incorrect clear of non-processed interrupts

commit 2f4f0f338cf453bfcdbcf089e177c16f35f023c8 upstream.

xcan_interrupt() clears ERROR|RXOFLV|BSOFF|ARBLST interrupts if any of
them is asserted. This does not take into account that some of them
could have been asserted between interrupt status read and interrupt
clear, therefore clearing them without handling them.

Fix the code to only clear those interrupts that it knows are asserted
and therefore going to be processed in xcan_err_interrupt().

Fixes: b1201e44f50b ("can: xilinx CAN controller support")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: xilinx_can: keep only 1-2 frames in TX FIFO to fix TX accounting

commit 620050d9c2be15c47017ba95efe59e0832e99a56 upstream.

The xilinx_can driver assumes that the TXOK interrupt only clears after
it has been acknowledged as many times as there have been successfully
sent frames.

However, the documentation does not mention such behavior, instead
saying just that the interrupt is cleared when the clear bit is set.

Similarly, testing seems to also suggest that it is immediately cleared
regardless of the amount of frames having been sent. Performing some
heavy TX load and then going back to idle has the tx_head drifting
further away from tx_tail over time, steadily reducing the amount of
frames the driver keeps in the TX FIFO (but not to zero, as the TXOK
interrupt always frees up space for 1 frame from the driver's
perspective, so frames continue to be sent) and delaying the local echo
frames.

The TX FIFO tracking is also otherwise buggy as it does not account for
TX FIFO being cleared after software resets, causing
  BUG!, TX FIFO full when queue awake!
messages to be output.

There does not seem to be any way to accurately track the state of the
TX FIFO for local echo support while using the full TX FIFO.

The Zynq version of the HW (but not the soft-AXI version) has watermark
programming support and with it an additional TX-FIFO-empty interrupt
bit.

Modify the driver to only put 1 frame into TX FIFO at a time on soft-AXI
and 2 frames at a time on Zynq. On Zynq the TXFEMP interrupt bit is used
to detect whether 1 or 2 frames have been sent at interrupt processing
time.

Tested with the integrated CAN on Zynq-7000 SoC. The 1-frame-FIFO mode
was also tested.

An alternative way to solve this would be to drop local echo support but
keep using the full TX FIFO.

v2: Add FIFO space check before TX queue wake with locking to
synchronize with queue stop. This avoids waking the queue when xmit()
had just filled it.

v3: Keep local echo support and reduce the amount of frames in FIFO
instead as suggested by Marc Kleine-Budde.

Fixes: b1201e44f50b ("can: xilinx CAN controller support")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: xilinx_can: fix device dropping off bus on RX overrun

commit 2574fe54515ed3487405de329e4e9f13d7098c10 upstream.

The xilinx_can driver performs a software reset when an RX overrun is
detected. This causes the device to enter Configuration mode where no
messages are received or transmitted.

The documentation does not mention any need to perform a reset on an RX
overrun, and testing by inducing an RX overflow also indicated that the
device continues to work just fine without a reset.

Remove the software reset.

Tested with the integrated CAN on Zynq-7000 SoC.

Fixes: b1201e44f50b ("can: xilinx CAN controller support")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: xilinx_can: fix recovery from error states not being propagated

commit 877e0b75947e2c7acf5624331bb17ceb093c98ae upstream.

The xilinx_can driver contains no mechanism for propagating recovery
from CAN_STATE_ERROR_WARNING and CAN_STATE_ERROR_PASSIVE.

Add such a mechanism by factoring the handling of
XCAN_STATE_ERROR_PASSIVE and XCAN_STATE_ERROR_WARNING out of
xcan_err_interrupt and checking for recovery after RX and TX if the
interface is in one of those states.

Tested with the integrated CAN on Zynq-7000 SoC.

Fixes: b1201e44f50b ("can: xilinx CAN controller support")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: xilinx_can: fix power management handling

commit 8ebd83bdb027f29870d96649dba18b91581ea829 upstream.

There are several issues with the suspend/resume handling code of the
driver:

- The device is attached and detached in the runtime_suspend() and
  runtime_resume() callbacks if the interface is running. However,
  during xcan_chip_start() the interface is considered running,
  causing the resume handler to incorrectly call netif_start_queue()
  at the beginning of xcan_chip_start(), and on xcan_chip_start() error
  return the suspend handler detaches the device leaving the user
  unable to bring-up the device anymore.

- The device is not brought properly up on system resume. A reset is
  done and the code tries to determine the bus state after that.
  However, after reset the device is always in Configuration mode
  (down), so the state checking code does not make sense and
  communication will also not work.

- The suspend callback tries to set the device to sleep mode (low-power
  mode which monitors the bus and brings the device back to normal mode
  on activity), but then immediately disables the clocks (possibly
  before the device reaches the sleep mode), which does not make sense
  to me. If a clean shutdown is wanted before disabling clocks, we can
  just bring it down completely instead of only sleep mode.

Reorganize the PM code so that only the clock logic remains in the
runtime PM callbacks and the system PM callbacks contain the device
bring-up/down logic. This makes calling the runtime PM callbacks during
e.g. xcan_chip_start() safe.

The system PM callbacks now simply call common code to start/stop the
HW if the interface was running, replacing the broken code from before.

xcan_chip_stop() is updated to use the common reset code so that it will
wait for the reset to complete. Reset also disables all interrupts so do
not do that separately.

Also, the device_may_wakeup() checks are removed as the driver does not
have wakeup support.

Tested on Zynq-7000 integrated CAN.

Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: xilinx_can: fix RX loop if RXNEMP is asserted without RXOK

commit 32852c561bffd613d4ed7ec464b1e03e1b7b6c5c upstream.

If the device gets into a state where RXNEMP (RX FIFO not empty)
interrupt is asserted without RXOK (new frame received successfully)
interrupt being asserted, xcan_rx_poll() will continue to try to clear
RXNEMP without actually reading frames from RX FIFO. If the RX FIFO is
not empty, the interrupt will not be cleared and napi_schedule() will
just be called again.

This situation can occur when:

(a) xcan_rx() returns without reading RX FIFO due to an error condition.
The code tries to clear both RXOK and RXNEMP but RXNEMP will not clear
due to a frame still being in the FIFO. The frame will never be read
from the FIFO as RXOK is no longer set.

(b) A frame is received between xcan_rx_poll() reading interrupt status
and clearing RXOK. RXOK will be cleared, but RXNEMP will again remain
set as the new message is still in the FIFO.

I'm able to trigger case (b) by flooding the bus with frames under load.

There does not seem to be any benefit in using both RXNEMP and RXOK in
the way the driver does, and the polling example in the reference manual
(UG585 v1.10 18.3.7 Read Messages from RxFIFO) also says that either
RXOK or RXNEMP can be used for detecting incoming messages.

Fix the issue and simplify the RX processing by only using RXNEMP
without RXOK.

Tested with the integrated CAN on Zynq-7000 SoC.

Fixes: b1201e44f50b ("can: xilinx CAN controller support")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

driver core: Partially revert "driver core: correct device's shutdown order"

commit 722e5f2b1eec7de61117b7c0a7914761e3da2eda upstream.

Commit 52cdbdd49853 (driver core: correct device's shutdown order)
introduced a regression by breaking device shutdown on some systems.

Namely, the devices_kset_move_last() call in really_probe() added by
that commit is a mistake as it may cause parents to follow children
in the devices_kset list which then causes shutdown to fail.  For
example, if a device has children before really_probe() is called
for it (which is not uncommon), that call will cause it to be
reordered after the children in the devices_kset list and the
ordering of that list will not reflect the correct device shutdown
order any more.

Also it causes the devices_kset list to be constantly reordered
until all drivers have been probed which is totally pointless
overhead in the majority of cases and it only covered an issue
with system shutdown, while system-wide suspend/resume potentially
had the same issue on the affected platforms (which was not covered).

Moreover, the shutdown issue originally addressed by the change in
really_probe() made by commit 52cdbdd49853 is not present in 4.18-rc
any more, since dra7 started to use the sdhci-omap driver which
doesn't disable any regulators during shutdown, so the really_probe()
part of commit 52cdbdd49853 can be safely reverted.  [The original
issue was related to the omap_hsmmc driver used by dra7 previously.]

For the above reasons, revert the really_probe() modifications made
by commit 52cdbdd49853.

The other code changes made by commit 52cdbdd49853 are useful and
they need not be reverted.

Fixes: 52cdbdd49853 (driver core: correct device's shutdown order)
Link: https://lore.kernel.org/lkml/CAFgQCTt7VfqM=UyCnvNFxrSw8Z6cUtAi3HUwR4_xPAc03SgHjQ@mail.gmail.com/
Reported-by: Pingfan Liu <kernelfans@gmail.com>
Tested-by: Pingfan Liu <kernelfans@gmail.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: f_fs: Only return delayed status when len is 0

commit 4d644abf25698362bd33d17c9ddc8f7122c30f17 upstream.

Commit 1b9ba000 ("Allow function drivers to pause control
transfers") states that USB_GADGET_DELAYED_STATUS is only
supported if data phase is 0 bytes.

It seems that when the length is not 0 bytes, there is no
need to explicitly delay the data stage since the transfer
is not completed until the user responds. However, when the
length is 0, there is no data stage and the transfer is
finished once setup() returns, hence there is a need to
explicitly delay completion.

This manifests as the following bugs:

Prior to 946ef68ad4e4 ('Let setup() return
USB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs
would require user to queue a 0 byte request in order to
clear setup state. However, that 0 byte request was actually
not needed and would hang and cause errors in other setup
requests.

After the above commit, 0 byte setups work since the gadget
now accepts empty queues to ep0 to clear the delay, but all
other setups hang.

Fixes: 946ef68ad4e4 ("Let setup() return USB_GADGET_DELAYED_STATUS")
Signed-off-by: Jerry Zhang <zhangjerry@google.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc2: Fix DMA alignment to start at allocated boundary

commit 56406e017a883b54b339207b230f85599f4d70ae upstream.

The commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more
supported way") introduced a common way to align DMA allocations.
The code in the commit aligns the struct dma_aligned_buffer but the
actual DMA address pointed by data[0] gets aligned to an offset from
the allocated boundary by the kmalloc_ptr and the old_xfer_buffer
pointers.

This is against the recommendation in Documentation/DMA-API.txt which
states:

  Therefore, it is recommended that driver writers who don't take
  special care to determine the cache line size at run time only map
  virtual regions that begin and end on page boundaries (which are
  guaranteed also to be cache line boundaries).

The effect of this is that architectures with non-coherent DMA caches
may run into memory corruption or kernel crashes with Unhandled
kernel unaligned accesses exceptions.

Fix the alignment by positioning the DMA area in front of the allocation
and use memory at the end of the area for storing the orginal
transfer_buffer pointer. This may have the added benefit of increased
performance as the DMA area is now fully aligned on all architectures.

Tested with Lantiq xRX200 (MIPS) and RPi Model B Rev 2 (ARM).

Fixes: 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more supported way")
Cc: <stable@vger.kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Antti Seppälä <a.seppala@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: handle hub C_PORT_OVER_CURRENT condition

commit 249a32b7eeb3edb6897dd38f89651a62163ac4ed upstream.

Based on USB2.0 Spec Section 11.12.5,

  "If a hub has per-port power switching and per-port current limiting,
  an over-current on one port may still cause the power on another port
  to fall below specific minimums. In this case, the affected port is
  placed in the Power-Off state and C_PORT_OVER_CURRENT is set for the
  port, but PORT_OVER_CURRENT is not set."

so let's check C_PORT_OVER_CURRENT too for over current condition.

Fixes: 08d1dec6f405 ("usb:hub set hub->change_bits when over-current happens")
Cc: <stable@vger.kernel.org>
Tested-by: Alessandro Antenucci <antenucci@korg.it>
Signed-off-by: Bin Liu <b-liu@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: cdc_acm: Add quirk for Castles VEGA3000

commit 1445cbe476fc3dd09c0b380b206526a49403c071 upstream.

The device (a POS terminal) implements CDC ACM, but has not union
descriptor.

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: speakup: fix wraparound in uaccess length check

commit b96fba8d5855c3617adbfb43ca4723a808cac954 upstream.

If softsynthx_read() is called with `count < 3`, `count - 3` wraps, causing
the loop to copy as much data as available to the provided buffer. If
softsynthx_read() is invoked through sys_splice(), this causes an
unbounded kernel write; but even when userspace just reads from it
normally, a small size could cause userspace crashes.

Fixes: 425e586cf95b ("speakup: add unicode variant of /dev/softsynth")
Cc: stable@vger.kernel.org
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: add tcp_ooo_try_coalesce() helper

[ Upstream commit 58152ecbbcc6a0ce7fddd5bf5f6ee535834ece0c ]

In case skb in out_or_order_queue is the result of
multiple skbs coalescing, we would like to get a proper gso_segs
counter tracking, so that future tcp_drop() can report an accurate
number.

I chose to not implement this tracking for skbs in receive queue,
since they are not dropped, unless socket is disconnected.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: call tcp_drop() from tcp_data_queue_ofo()

[ Upstream commit 8541b21e781a22dce52a74fef0b9bed00404a1cd ]

In order to be able to give better diagnostics and detect
malicious traffic, we need to have better sk->sk_drops tracking.

Fixes: 9f5afeae5152 ("tcp: use an RB tree for ooo receive queue")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: detect malicious patterns in tcp_collapse_ofo_queue()

[ Upstream commit 3d4bf93ac12003f9b8e1e2de37fe27983deebdcf ]

In case an attacker feeds tiny packets completely out of order,
tcp_collapse_ofo_queue() might scan the whole rb-tree, performing
expensive copies, but not changing socket memory usage at all.

1) Do not attempt to collapse tiny skbs.
2) Add logic to exit early when too many tiny skbs are detected.

We prefer not doing aggressive collapsing (which copies packets)
for pathological flows, and revert to tcp_prune_ofo_queue() which
will be less expensive.

In the future, we might add the possibility of terminating flows
that are proven to be malicious.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: avoid collapses in tcp_prune_queue() if possible

[ Upstream commit f4a3313d8e2ca9fd8d8f45e40a2903ba782607e7 ]

Right after a TCP flow is created, receiving tiny out of order
packets allways hit the condition :

if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
tcp_clamp_window(sk);

tcp_clamp_window() increases sk_rcvbuf to match sk_rmem_alloc
(guarded by tcp_rmem[2])

Calling tcp_collapse_ofo_queue() in this case is not useful,
and offers a O(N^2) surface attack to malicious peers.

Better not attempt anything before full queue capacity is reached,
forcing attacker to spend lots of resource and allow us to more
easily detect the abuse.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: free batches of packets in tcp_prune_ofo_queue()

[ Upstream commit 72cd43ba64fc172a443410ce01645895850844c8 ]

Juha-Matti Tilli reported that malicious peers could inject tiny
packets in out_of_order_queue, forcing very expensive calls
to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for
every incoming packet. out_of_order_queue rb-tree can contain
thousands of nodes, iterating over all of them is not nice.

Before linux-4.9, we would have pruned all packets in ofo_queue
in one go, every XXXX packets. XXXX depends on sk_rcvbuf and skbs
truesize, but is about 7000 packets with tcp_rmem[2] default of 6 MB.

Since we plan to increase tcp_rmem[2] in the future to cope with
modern BDP, can not revert to the old behavior, without great pain.

Strategy taken in this patch is to purge ~12.5 % of the queue capacity.

Fixes: 36a6503fedda ("tcp: refine tcp_prune_ofo_queue() to not drop all packets")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Juha-Matti Tilli <juha-matti.tilli@iki.fi>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: do not delay ACK in DCTCP upon CE status change

[ Upstream commit a0496ef2c23b3b180902dd185d0d63ccbc624cf8 ]

Per DCTCP RFC8257 (Section 3.2) the ACK reflecting the CE status change
has to be sent immediately so the sender can respond quickly:

""" When receiving packets, the CE codepoint MUST be processed as follows:

   1.  If the CE codepoint is set and DCTCP.CE is false, set DCTCP.CE to
       true and send an immediate ACK.

   2.  If the CE codepoint is not set and DCTCP.CE is true, set DCTCP.CE
       to false and send an immediate ACK.
"""

Previously DCTCP implementation may continue to delay the ACK. This
patch fixes that to implement the RFC by forcing an immediate ACK.

Tested with this packetdrill script provided by Larry Brakmo

0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 setsockopt(3, SOL_TCP, TCP_CONGESTION, "dctcp", 5) = 0
0.000 bind(3, ..., ...) = 0
0.000 listen(3, 1) = 0

0.100 < [ect0] SEW 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
0.100 > SE. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
0.110 < [ect0] . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4
   +0 setsockopt(4, SOL_SOCKET, SO_DEBUG, [1], 4) = 0

0.200 < [ect0] . 1:1001(1000) ack 1 win 257
0.200 > [ect01] . 1:1(0) ack 1001

0.200 write(4, ..., 1) = 1
0.200 > [ect01] P. 1:2(1) ack 1001

0.200 < [ect0] . 1001:2001(1000) ack 2 win 257
+0.005 < [ce] . 2001:3001(1000) ack 2 win 257

+0.000 > [ect01] . 2:2(0) ack 2001
// Previously the ACK below would be delayed by 40ms
+0.000 > [ect01] E. 2:2(0) ack 3001

+0.500 < F. 9501:9501(0) ack 4 win 257

Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: do not cancel delay-AcK on DCTCP special ACK

[ Upstream commit 27cde44a259c380a3c09066fc4b42de7dde9b1ad ]

Currently when a DCTCP receiver delays an ACK and receive a
data packet with a different CE mark from the previous one's, it
sends two immediate ACKs acking previous and latest sequences
respectly (for ECN accounting).

Previously sending the first ACK may mark off the delayed ACK timer
(tcp_event_ack_sent). This may subsequently prevent sending the
second ACK to acknowledge the latest sequence (tcp_ack_snd_check).
The culprit is that tcp_send_ack() assumes it always acknowleges
the latest sequence, which is not true for the first special ACK.

The fix is to not make the assumption in tcp_send_ack and check the
actual ack sequence before cancelling the delayed ACK. Further it's
safer to pass the ack sequence number as a local variable into
tcp_send_ack routine, instead of intercepting tp->rcv_nxt to avoid
future bugs like this.

Reported-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: helpers to send special DCTCP ack

[ Upstream commit 2987babb6982306509380fc11b450227a844493b ]

Refactor and create helpers to send the special ACK in DCTCP.

Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: fix dctcp delayed ACK schedule

[ Upstream commit b0c05d0e99d98d7f0cd41efc1eeec94efdc3325d ]

Previously, when a data segment was sent an ACK was piggybacked
on the data segment without generating a CA_EVENT_NON_DELAYED_ACK
event to notify congestion control modules. So the DCTCP
ca->delayed_ack_reserved flag could incorrectly stay set when
in fact there were no delayed ACKs being reserved. This could result
in sending a special ECN notification ACK that carries an older
ACK sequence, when in fact there was no need for such an ACK.
DCTCP keeps track of the delayed ACK status with its own separate
state ca->delayed_ack_reserved. Previously it may accidentally cancel
the delayed ACK without updating this field upon sending a special
ACK that carries a older ACK sequence. This inconsistency would
lead to DCTCP receiver never acknowledging the latest data until the
sender times out and retry in some cases.

Packetdrill script (provided by Larry Brakmo)

0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 setsockopt(3, SOL_TCP, TCP_CONGESTION, "dctcp", 5) = 0
0.000 bind(3, ..., ...) = 0
0.000 listen(3, 1) = 0

0.100 < [ect0] SEW 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
0.100 > SE. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
0.110 < [ect0] . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4

0.200 < [ect0] . 1:1001(1000) ack 1 win 257
0.200 > [ect01] . 1:1(0) ack 1001

0.200 write(4, ..., 1) = 1
0.200 > [ect01] P. 1:2(1) ack 1001

0.200 < [ect0] . 1001:2001(1000) ack 2 win 257
0.200 write(4, ..., 1) = 1
0.200 > [ect01] P. 2:3(1) ack 2001

0.200 < [ect0] . 2001:3001(1000) ack 3 win 257
0.200 < [ect0] . 3001:4001(1000) ack 3 win 257
0.200 > [ect01] . 3:3(0) ack 4001

0.210 < [ce] P. 4001:4501(500) ack 3 win 257

+0.001 read(4, ..., 4500) = 4500
+0 write(4, ..., 1) = 1
+0 > [ect01] PE. 3:4(1) ack 4501

+0.010 < [ect0] W. 4501:5501(1000) ack 4 win 257
// Previously the ACK sequence below would be 4501, causing a long RTO
+0.040~+0.045 > [ect01] . 4:4(0) ack 5501   // delayed ack

+0.311 < [ect0] . 5501:6501(1000) ack 4 win 257  // More data
+0 > [ect01] . 4:4(0) ack 6501     // now acks everything

+0.500 < F. 9501:9501(0) ack 4 win 257

Reported-by: Larry Brakmo <brakmo@fb.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Lawrence Brakmo <brakmo@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vxlan: fix default fdb entry netlink notify ordering during netdev create

[ Upstream commit e99465b952861533d9ba748fdbecc96d9a36da3e ]

Problem:
In vxlan_newlink, a default fdb entry is added before register_netdev.
The default fdb creation function also notifies user-space of the
fdb entry on the vxlan device which user-space does not know about yet.
(RTM_NEWNEIGH goes before RTM_NEWLINK for the same ifindex).

This patch fixes the user-space netlink notification ordering issue
with the following changes:
- decouple fdb notify from fdb create.
- Move fdb notify after register_netdev.
- Call rtnl_configure_link in vxlan newlink handler to notify
userspace about the newlink before fdb notify and
hence avoiding the user-space race.

Fixes: afbd8bae9c79 ("vxlan: add implicit fdb entry for default destination")
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vxlan: make netlink notify in vxlan_fdb_destroy optional

[ Upstream commit f6e053858671bb156b6e44ad66418acc8c7f4e77 ]

Add a new option do_notify to vxlan_fdb_destroy to make
sending netlink notify optional. Used by a later patch.

Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vxlan: add new fdb alloc and create helpers

[ Upstream commit 7431016b107c95cb5b2014aa1901fcb115f746bc ]

- Add new vxlan_fdb_alloc helper
- rename existing vxlan_fdb_create into vxlan_fdb_update:
        because it really creates or updates an existing
        fdb entry
- move new fdb creation into a separate vxlan_fdb_create

Main motivation for this change is to introduce the ability
to decouple vxlan fdb creation and notify, used in a later patch.

Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rtnetlink: add rtnl_link_state check in rtnl_configure_link

[ Upstream commit 5025f7f7d506fba9b39e7fe8ca10f6f34cb9bc2d ]

rtnl_configure_link sets dev->rtnl_link_state to
RTNL_LINK_INITIALIZED and unconditionally calls
__dev_notify_flags to notify user-space of dev flags.

current call sequence for rtnl_configure_link
rtnetlink_newlink
    rtnl_link_ops->newlink
    rtnl_configure_link (unconditionally notifies userspace of
                         default and new dev flags)

If a newlink handler wants to call rtnl_configure_link
early, we will end up with duplicate notifications to
user-space.

This patch fixes rtnl_configure_link to check rtnl_link_state
and call __dev_notify_flags with gchanges = 0 if already
RTNL_LINK_INITIALIZED.

Later in the series, this patch will help the following sequence
where a driver implementing newlink can call rtnl_configure_link
to initialize the link early.

makes the following call sequence work:
rtnetlink_newlink
    rtnl_link_ops->newlink (vxlan) -> rtnl_configure_link (initializes
                                                link and notifies
                                                user-space of default
                                                dev flags)
    rtnl_configure_link (updates dev flags if requested by user ifm
                         and notifies user-space of new dev flags)

Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sock: fix sg page frag coalescing in sk_alloc_sg

[ Upstream commit 144fe2bfd236dc814eae587aea7e2af03dbdd755 ]

Current sg coalescing logic in sk_alloc_sg() (latter is used by tls and
sockmap) is not quite correct in that we do fetch the previous sg entry,
however the subsequent check whether the refilled page frag from the
socket is still the same as from the last entry with prior offset and
length matching the start of the current buffer is comparing always the
first sg list entry instead of the prior one.

Fixes: 3c4d7559159b ("tls: kernel TLS support")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Dave Watson <davejwatson@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: phy: consider PHY_IGNORE_INTERRUPT in phy_start_aneg_priv

[ Upstream commit 215d08a85b9acf5e1fe9dbf50f1774cde333efef ]

The situation described in the comment can occur also with
PHY_IGNORE_INTERRUPT, therefore change the condition to include it.

Fixes: f555f34fdc58 ("net: phy: fix auto-negotiation stall due to unavailable interrupt")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>