rpmsg/rpmsg.git
15 months agosoc: ti: pruss: update pruss_get() to retrieve a PRUSS id rpmsg-ti-linux-4.19.y-next
Suman Anna [Mon, 17 Jun 2019 21:15:41 +0000 (16:15 -0500)]
soc: ti: 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. The invocation
within the PRU Soft UART driver and PRU PWM drivers have also been
updated, with these drivers not needing the PRUSS instance id at present.

Signed-off-by: Suman Anna <s-anna@ti.com>
15 months agosoc: ti: pruss: store the pruss instance id
Suman Anna [Thu, 2 May 2019 22:18:05 +0000 (17:18 -0500)]
soc: ti: 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>
15 months agoMerged TI feature connectivity into ti-linux-4.19.y
LCPD Auto Merger [Sat, 18 Jan 2020 17:28:12 +0000 (11:28 -0600)]
Merged TI feature connectivity into ti-linux-4.19.y

TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-4.19.y

* 'connectivity-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
  net: ethernet: ti: icssg-prueth: Add multicast filter support
  mtd: spi-nor: cadence-quadspi: Fix issue with merge conflict resolution
  net: phy: dp83867: add w/a for packet errors seen with short cables

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
15 months agonet: ethernet: ti: icssg-prueth: Add multicast filter support
Roger Quadros [Thu, 16 Jan 2020 19:10:26 +0000 (19:10 +0000)]
net: ethernet: ti: icssg-prueth: Add multicast filter support

Each ICSSG port supports 8 MAC filters (FT1) that can be used
to implement multicast filtering. However, since 8 filters are not
sufficient for a real world case, we optimize it a bit by reserving
first 2 filters for usually required multicast addresses.

  1) 01-80-C2-00-00-XX Known Service Ethernet Multicast addresses
  2) 01-00-5e-00-00-XX Local Network Control Block
                       (224.0.0.0 - 224.0.0.255  (224.0.0/24))

Then we use the remaining 6 FT1 filters as a pool for an other
multicast addresses.

At any instant if we run out of the filters then we just turn on all
multicast packets.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
15 months agomtd: spi-nor: cadence-quadspi: Fix issue with merge conflict resolution
Vignesh Raghavendra [Fri, 17 Jan 2020 17:06:27 +0000 (17:06 +0000)]
mtd: spi-nor: cadence-quadspi: Fix issue with merge conflict resolution

Recent merge conflict resolution mistakenly used QSPI dev pointer for
dma_map_single() instead of DMA device's dev pointer. Fix this.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
15 months agonet: phy: dp83867: add w/a for packet errors seen with short cables
Grygorii Strashko [Fri, 10 Jan 2020 15:00:04 +0000 (17:00 +0200)]
net: phy: dp83867: add w/a for packet errors seen with short cables

Introduce the W/A for packet errors seen with short cables (<1m) between
two DP83867 PHYs.

The W/A recommended by DM requires FFE Equalizer Configuration tuning by
writing value 0x0E81 to DSP_FFE_CFG register (0x012C), surrounded by hard
and soft resets as following:

write_reg(0x001F, 0x8000); //hard reset
write_reg(DSP_FFE_CFG, 0x0E81);
write_reg(0x001F, 0x4000); //soft reset

Hence DP83867 PHY DM says "Changing this register to 0x0E81, will not
effect Long Cable performance." the W/A enabled by default.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoMerged TI feature connectivity into ti-linux-4.19.y
LCPD Auto Merger [Wed, 15 Jan 2020 12:35:44 +0000 (06:35 -0600)]
Merged TI feature connectivity into ti-linux-4.19.y

TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-4.19.y

* 'connectivity-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
  net: ethernet: ti: am65-cpsw-nuss: fix vlan packets drop with size >1518
  net: ethernet: ti: ale: fix seeing unreg mcast packets with promisc and allmulti disabled
  serial: 8250: 8250_omap: Don't queue new DMA request for RX timeout
  ntb: ntb_hw_epf: Do not set dma_mask for NTB device (struct ntb_dev)
  usb: dwc3: gadget: Fix request complete check

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
16 months agonet: ethernet: ti: am65-cpsw-nuss: fix vlan packets drop with size >1518
Grygorii Strashko [Sat, 11 Jan 2020 18:53:46 +0000 (18:53 +0000)]
net: ethernet: ti: am65-cpsw-nuss: fix vlan packets drop with size >1518

After the CPSW2G network device goes through down/up it will stop receiving
VLAN tagged packets of max allowed size >1518 bytes.

The issue happens because MAC SL reset (which is done on ifup) will reset
not only Port's MAC SL registers, but also CPSW_PN_RX_MAXLEN_REG (ofs:
0x00022024).

Value set: 0x5f2
Reset value: 0x5ee

Steps to reproduce:
  boot
  ifconfig eth0 down up
  vconfig add eth0 100
  ifconfig eth0.100 <eth0.100.ip>
  from PC/other DUT run iperf to <eth0.100.ip>, udp, -l1472

Fix it by always restoring CPSW_PN_RX_MAXLEN_REG value after MAC SL reset.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agonet: ethernet: ti: ale: fix seeing unreg mcast packets with promisc and allmulti...
Grygorii Strashko [Sat, 11 Jan 2020 18:54:00 +0000 (18:54 +0000)]
net: ethernet: ti: ale: fix seeing unreg mcast packets with promisc and allmulti disabled

On AM65xx MCU CPSW2G NUSS and 66AK2E/L NUSS the unregistered multicast
packets are still can be received with promisc and allmulti disabled.

This happens, because ALE VLAN entries on these SoCs do not contain port
masks for reg/unreg mcast packets, but instead store indexes of
ALE_VLAN_MASK_MUXx_REG registers which intended for store port masks for
reg/unreg mcast packets.

ALE VLAN entry:UNREG_MCAST_FLOOD_INDEX -> ALE_VLAN_MASK_MUXx
ALE VLAN entry:REG_MCAST_FLOOD_INDEX -> ALE_VLAN_MASK_MUXy

The commit b361da837392 ("net: netcp: ale: add proper ale entry mask bits
for netcp switch ALE") update ALE code to support such ALE entries, it
always used ALE_VLAN_MASK_MUX0_REG index in ALE VLAN entry for unreg mcast
packets mask configuration, which is read-only, at least for AM65xx MCU
CPSW2G NUSS and 66AK2E/L NUSS. As a result unreg mcast packets are allowed
always.

Hence, update ALE code to use ALE_VLAN_MASK_MUX1_REG index for ALE VLAN
entries to configure unreg mcast port mask.

Fixes: b361da837392 ("net: netcp: ale: add proper ale entry mask bits for netcp switch ALE")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoserial: 8250: 8250_omap: Don't queue new DMA request for RX timeout
Vignesh Raghavendra [Tue, 14 Jan 2020 14:53:03 +0000 (14:53 +0000)]
serial: 8250: 8250_omap: Don't queue new DMA request for RX timeout

When RX Timeout interrupt is raised without any data in RX FIFO (i.e
when UART_LSR_DR bit is not set) don't queue a new RX DMA request as
request will be immediately subjected to teardown as part of RX timeout
handling. This removes dependency on DMA driver to call completion
callback for descriptor terminated before completion.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agontb: ntb_hw_epf: Do not set dma_mask for NTB device (struct ntb_dev)
Kishon Vijay Abraham I [Mon, 13 Jan 2020 14:49:21 +0000 (14:49 +0000)]
ntb: ntb_hw_epf: Do not set dma_mask for NTB device (struct ntb_dev)

NTB device is not a real device and the piece of hardware actually
doing the DMA is the PCI device itself. As a result the DMA
capability of the NTB device is not configured (DMA ops of NTB device
is not populated) and dma_coerce_mask_and_coherent() on NTB device
fails.

Remove configuring dma_mask with dma_coerce_mask_and_coherent() on
NTB device and fix ntb_perf.c and ntb_tool.c to use PCI device for
dma_alloc_coherent(). ntb_transport.c already used PCI device for
dma_alloc_coherent().

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agousb: dwc3: gadget: Fix request complete check
Thinh Nguyen [Tue, 14 Jan 2020 15:20:36 +0000 (15:20 +0000)]
usb: dwc3: gadget: Fix request complete check

commit ea0d762775e20aaff7909a3f0866ff1688b1c618 upstream.

We can only check for IN direction if the request had completed. For OUT
direction, it's perfectly fine that the host can send less than the
setup length. Let's return true fall all cases of OUT direction.

Fixes: e0c42ce590fe ("usb: dwc3: gadget: simplify IOC handling")
Cc: stable@vger.kernel.org
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Link: https://lore.kernel.org/r/ac5a3593a94fdaa3d92e6352356b5f7a01ccdc7c.1576291140.git.thinhn@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoMerged TI feature connectivity into ti-linux-4.19.y
LCPD Auto Merger [Fri, 10 Jan 2020 10:17:17 +0000 (04:17 -0600)]
Merged TI feature connectivity into ti-linux-4.19.y

TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-4.19.y

* 'connectivity-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
  PCI: dwc: Use private data pointer of "struct irq_domain" to get pcie_port
  usb: gadget: legacy: set max_speed to super-speed
  arm64: dts: ti: k3-j721e: Fix "cdns,no-bar-match-nbits" dt property
  arm64: dts: ti: k3-j721e: Add "max-virtual-functions" dt property to pcie-ep
  PCI: cadence: Avoid using phys_to_virt() for reading MSI-X table
  dt-bindings: PCI: cadence: Add dt binding to specify maximum virtual function
  PCI: keystone: Allow AM654 PCIe Endpoint to raise MSI-X interrupt
  PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table address
  PCI: endpoint: Fix ->set_msix() to take BIR and offset as arguments
  PCI: endpoint: Clear BAR before freeing its space
  PCI: endpoint: Skip odd BAR when skipping 64bit BAR
  PCI: endpoint: Allocate enough space for fixed size BAR
  PCI: endpoint: Set endpoint controller pointer to NULL
  net: phy: dp83867: w/a for fld detect threshold bootstrapping issue
  net: phy: dp83867: fix hfs boot in rgmii mode
  net: phy: dp83867: move dt parsing to probe
  net: phy: dp83867: do not call config_init twice
  net: phy: dp83867: add soft reset delay
  net: phy: dp83867: Allocate state struct in probe
  drivers: depend on HAS_IOMEM for devm_platform_ioremap_resource()

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
16 months agoPCI: dwc: Use private data pointer of "struct irq_domain" to get pcie_port
Kishon Vijay Abraham I [Fri, 20 Dec 2019 10:10:26 +0000 (15:40 +0530)]
PCI: dwc: Use private data pointer of "struct irq_domain" to get pcie_port

No functional change. Get "struct pcie_port *" from private data
pointer of "struct irq_domain" in dw_pcie_irq_domain_free() to make
it look similar to how "struct pcie_port *" is obtained in
dw_pcie_irq_domain_alloc()

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agousb: gadget: legacy: set max_speed to super-speed
Roger Quadros [Mon, 23 Dec 2019 06:47:35 +0000 (08:47 +0200)]
usb: gadget: legacy: set max_speed to super-speed

commit  upstream.

These interfaces do support super-speed so let's not
limit maximum speed to high-speed.

Cc: <stable@vger.kernel.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoarm64: dts: ti: k3-j721e: Fix "cdns,no-bar-match-nbits" dt property
Kishon Vijay Abraham I [Thu, 19 Dec 2019 10:23:53 +0000 (15:53 +0530)]
arm64: dts: ti: k3-j721e: Fix "cdns,no-bar-match-nbits" dt property

"cdns,no-bar-match-nbits" was set to "32" which would limit the
PCIe controller to access only 32-bit address space. Change it to
"64" to indicate the PCIe controller can access the entire 64-bit
address space.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoarm64: dts: ti: k3-j721e: Add "max-virtual-functions" dt property to pcie-ep
Kishon Vijay Abraham I [Thu, 19 Dec 2019 10:18:44 +0000 (15:48 +0530)]
arm64: dts: ti: k3-j721e: Add "max-virtual-functions" dt property to pcie-ep

Add "max-virtual-functions" dt property to pcie-ep to specify the
maximum number of virtual function supported by each physical function.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoPCI: cadence: Avoid using phys_to_virt() for reading MSI-X table
Kishon Vijay Abraham I [Thu, 19 Dec 2019 10:18:43 +0000 (15:48 +0530)]
PCI: cadence: Avoid using phys_to_virt() for reading MSI-X table

Memory allocated for mapping Base Address Register (including MSI-X
table) is done using dma_alloc_coherent(). cdns_pcie_ep_send_msix_irq()
uses phys_to_virt() to get the virtual address for reading the MSI-X
table. However phys_to_virt() does not handle bus mappings for DMA
transfers.

Avoid using phys_to_virt() to get virtual address for reading MSI-X
table and use the virtual address stored in pci_epf_bar.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agodt-bindings: PCI: cadence: Add dt binding to specify maximum virtual function
Kishon Vijay Abraham I [Thu, 19 Dec 2019 10:18:42 +0000 (15:48 +0530)]
dt-bindings: PCI: cadence: Add dt binding to specify maximum virtual function

Add dt binding to specify maximum virtual function for each of the
supported physical function.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoPCI: keystone: Allow AM654 PCIe Endpoint to raise MSI-X interrupt
Kishon Vijay Abraham I [Thu, 19 Dec 2019 10:18:41 +0000 (15:48 +0530)]
PCI: keystone: Allow AM654 PCIe Endpoint to raise MSI-X interrupt

AM654 PCIe EP controller has MSI-X capability register and has the
ability to raise MSI-X interrupt. Add support in pci-keystone.c
for PCIe endpoint controller in AM654 to raise MSI-X interrupts.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoPCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table address
Kishon Vijay Abraham I [Thu, 19 Dec 2019 10:18:40 +0000 (15:48 +0530)]
PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table address

commit beb4641a787df79a14 ("PCI: dwc: Add MSI-X callbacks handler"),
in order to raise MSI-X interrupt, obtained MSIX table address from
Base Address Register (BAR). However BAR only holds PCI address
programmed by the host whereas the MSI-X table should be in the local
memory.

Store the MSI-X table address (virtual address) as part of ->set_bar()
callback and use that to get the message address and message data
here.

Fixes: commit beb4641a787df79a14 ("PCI: dwc: Add MSI-X callbacks
handler")

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoPCI: endpoint: Fix ->set_msix() to take BIR and offset as arguments
Kishon Vijay Abraham I [Thu, 19 Dec 2019 10:18:39 +0000 (15:48 +0530)]
PCI: endpoint: Fix ->set_msix() to take BIR and offset as arguments

commit 8963106eabdc5691 ("PCI: endpoint: Add MSI-X interfaces") while
adding support to raise MSI-X interrupts from endpoint didn't include
BAR Indicator register (BIR) configuration and MSI-X table offset as
arguments in pci_epc_set_msix(). This would result in endpoint
controller register using random BAR indicator register, the memory
for which might not be allocated by the endpoint function driver.
Add BAR indicator register and MSI-X table offset as arguments in
pci_epc_set_msix() and allocate space for MSI-X table and pending
bit array (PBA) in pci-epf-test endpoint function driver.

Fixes: commit 8963106eabdc5691 ("PCI: endpoint: Add MSI-X interfaces")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoPCI: endpoint: Clear BAR before freeing its space
Alan Mikhak [Thu, 19 Dec 2019 10:18:38 +0000 (15:48 +0530)]
PCI: endpoint: Clear BAR before freeing its space

commit 2d6d5c2de32054881477d82c56e3556df2d599ae upstream.

Associated pci_epf_bar structure is needed in pci_epc_clear_bar() to
clear a BAR correctly but it is reset in pci_epf_free_space() (that
is called first) which results in pci_epc_clear_bar() failure.

Reorder the pci_epc_clear_bar()/pci_epf_free_space() calls execution
to fix the issue.

Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com>
[lorenzo.pieralisi@arm.com: reworded the commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoPCI: endpoint: Skip odd BAR when skipping 64bit BAR
Alan Mikhak [Thu, 19 Dec 2019 10:18:37 +0000 (15:48 +0530)]
PCI: endpoint: Skip odd BAR when skipping 64bit BAR

commit 815dacdc4339e586d2ba3ff49aaa5c42214349ea upstream.

Always skip odd BAR when skipping 64bit BARs in pci_epf_test_set_bar()
and pci_epf_test_alloc_space() otherwise pci_epf_test_set_bar() will
call pci_epc_set_bar() on an odd loop index when skipping reserved 64bit
BAR.

Moreover, pci_epf_test_alloc_space() will call pci_epf_alloc_space() on
bind for an odd loop index when BAR is 64bit but leaks on subsequent
unbind by not calling pci_epf_free_space().

Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Paul Walmsley <paul.walmsley@sifive.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoPCI: endpoint: Allocate enough space for fixed size BAR
Alan Mikhak [Thu, 19 Dec 2019 10:18:36 +0000 (15:48 +0530)]
PCI: endpoint: Allocate enough space for fixed size BAR

commit fb092190dbb4bc33f60c23031f54a0232319f6ca upstream.

PCI endpoint test function code should honor the .bar_fixed_size parameter
from underlying endpoint controller drivers or results may be unexpected.

In pci_epf_test_alloc_space(), check if BAR being used for test
register space is a fixed size BAR. If so, allocate the required fixed
size.

Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoPCI: endpoint: Set endpoint controller pointer to NULL
Alan Mikhak [Thu, 19 Dec 2019 10:18:35 +0000 (15:48 +0530)]
PCI: endpoint: Set endpoint controller pointer to NULL

commit a578bf299e5cc9cb40bd0a9cc62cbbd4dcaec087 upstream.

Set endpoint controller pointer to NULL in pci_epc_remove_epf()
to avoid -EBUSY on subsequent call to pci_epc_add_epf().

Add a check for NULL endpoint function pointer.

Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agonet: phy: dp83867: w/a for fld detect threshold bootstrapping issue
Grygorii Strashko [Thu, 19 Dec 2019 11:55:42 +0000 (13:55 +0200)]
net: phy: dp83867: w/a for fld detect threshold bootstrapping issue

When the Phy is strapped to enable Fast Link Drop (FLD) feature
STRAP_STS2.STRAP_ FLD (reg 0x006F bit 10), the Energy Lost Thershold for
FLD Energy Lost Mode FLD_THR_CFG.ENERGY_LOST_FLD_THR (reg 0x002e bits 2:0)
will be defaulted to 0x2. This may cause the phy link to be unstable.
DM recommends to always restore ENERGY_LOST_FLD_THR to 0x1.

Hence, restore default value of FLD_THR_CFG.ENERGY_LOST_FLD_THR to 0x1 when
FLD is enabled by bootstrapping as recommended by DM.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agonet: phy: dp83867: fix hfs boot in rgmii mode
Grygorii Strashko [Thu, 19 Dec 2019 11:55:41 +0000 (13:55 +0200)]
net: phy: dp83867: fix hfs boot in rgmii mode

commit fafc5db28a2ff39092bafe8ac9b8b19c4904f633 upstream.

The commit ef87f7da6b28 ("net: phy: dp83867: move dt parsing to probe")
causes regression on TI dra71x-evm and dra72x-evm, where DP83867 PHY is
used in "rgmii-id" mode - the networking stops working.
Unfortunately, it's not enough to just move DT parsing code to .probe() as
it depends on phydev->interface value, which is set to correct value abter
the .probe() is completed and before calling .config_init(). So, RGMII
configuration can't be loaded from DT.

To fix and issue
- move RGMII validation code to .config_init()
- parse RGMII parameters in dp83867_of_init(), but consider them as
optional.

Fixes: ef87f7da6b28 ("net: phy: dp83867: move dt parsing to probe")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agonet: phy: dp83867: move dt parsing to probe
Grygorii Strashko [Thu, 19 Dec 2019 11:55:40 +0000 (13:55 +0200)]
net: phy: dp83867: move dt parsing to probe

commit ef87f7da6b28dfaf7aac435350fe287cc667124a upstream.

Move DT parsing code to probe dp83867_probe() as it's one time operation.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agonet: phy: dp83867: do not call config_init twice
Max Uvarov [Thu, 19 Dec 2019 11:55:39 +0000 (13:55 +0200)]
net: phy: dp83867: do not call config_init twice

commit c8081fc397fa04675e410900693a57085ef4b760 upstream.

Phy state machine calls _config_init just after
reset.

Signed-off-by: Max Uvarov <muvarov@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agonet: phy: dp83867: add soft reset delay
Max Uvarov [Thu, 19 Dec 2019 11:55:38 +0000 (13:55 +0200)]
net: phy: dp83867: add soft reset delay

commit 72a7d452b0f09dcd5d3e18cff1e3839f8b1acc1f upstream.

Similar to dp83640 delay after soft reset
is needed to set up registers correctly.

Signed-off-by: Max Uvarov <muvarov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agonet: phy: dp83867: Allocate state struct in probe
Trent Piepho [Thu, 19 Dec 2019 11:55:37 +0000 (13:55 +0200)]
net: phy: dp83867: Allocate state struct in probe

commit 565d9d221bcb4cae926585681089b3ba4ef9be8e upstream.

This was being done in config the first time the phy was configured.
Should be in the probe method.

Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agodrivers: depend on HAS_IOMEM for devm_platform_ioremap_resource()
Bartosz Golaszewski [Tue, 7 Jan 2020 01:34:11 +0000 (19:34 -0600)]
drivers: depend on HAS_IOMEM for devm_platform_ioremap_resource()

commit 837ccda3480d2861c09aabc5fa014be18df9dd3c upstream.

We only build devm_ioremap_resource() if HAS_IOMEM is selected, so this
dependency must cascade down to devm_platform_ioremap_resource().

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoMerge tag 'v4.19.90' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
Dan Murphy [Wed, 8 Jan 2020 18:09:00 +0000 (12:09 -0600)]
Merge tag 'v4.19.90' of git./linux/kernel/git/stable/linux-stable into ti-linux-4.19.y

This is the 4.19.90 stable release

* tag 'v4.19.90' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (1925 commits)
  Linux 4.19.90
  of: unittest: fix memory leak in attach_node_and_children
  scsi: zorro_esp: Limit DMA transfers to 65536 bytes (except on Fastlane)
  idr: Fix idr_get_next_ul race with idr_remove
  iio: imu: mpu6050: add missing available scan masks
  scsi: qla2xxx: Change discovery state before PLOGI
  raid5: need to set STRIPE_HANDLE for batch head
  gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist
  cifs: Fix potential softlockups while refreshing DFS cache
  kernel/module.c: wakeup processes in module_wq on module unload
  of: overlay: add_changeset_property() memory leak
  gfs2: fix glock reference problem in gfs2_trans_remove_revoke
  PCI: rcar: Fix missing MACCTLR register setting in initialization sequence
  leds: trigger: netdev: fix handling on interface rename
  net/mlx5e: Fix SFF 8472 eeprom length
  sunrpc: fix crash when cache_head become valid before update
  firmware: arm_scmi: Avoid double free in error flow
  gre: refetch erspan header from skb->data after pskb_may_pull()
  perf callchain: Fix segfault in thread__resolve_callchain_sample()
  workqueue: Fix missing kfree(rescuer) in destroy_workqueue()
  ...

Signed-off-by: Dan Murphy <dmurphy@ti.com>
# Conflicts:
# arch/arm64/boot/dts/ti/k3-am65-main.dtsi
# arch/arm64/boot/dts/ti/k3-am65.dtsi
# drivers/ata/ahci_platform.c
# drivers/mtd/spi-nor/cadence-quadspi.c
# drivers/net/phy/dp83867.c
# drivers/pci/controller/dwc/pci-keystone.c
# drivers/remoteproc/da8xx_remoteproc.c
# drivers/remoteproc/remoteproc_sysfs.c

16 months agoMerged TI feature connectivity into ti-linux-4.19.y
LCPD Auto Merger [Wed, 1 Jan 2020 17:36:33 +0000 (11:36 -0600)]
Merged TI feature connectivity into ti-linux-4.19.y

TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-4.19.y

* 'connectivity-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
  net: ethernet: ti: prueth: request_irq after rproc_boot
  HACK: mmc: sdhci_am654: Disable command queuing for AM65x
  spi: spi-ti-qspi: Fix a bug when accessing non default CS

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
16 months agonet: ethernet: ti: prueth: request_irq after rproc_boot
Roger Quadros [Tue, 24 Dec 2019 13:47:30 +0000 (13:47 +0000)]
net: ethernet: ti: prueth: request_irq after rproc_boot

As INTC is not configured till rproc_boot, if we request_irq
from INTC before rproc_boot, the below warnings are seen.

[  134.607712] pruss_intc_irq_set_affinity: event 20 not configured: ch = -1, host = -1
[  134.615535] pruss_intc_irq_set_affinity: event 22 not configured: ch = -1, host = -1

So let's request_irq after rproc_boot.

NOTE: this issue was introduced only after
commit 26e32f353dbb ("TEMP: irqchip/irq-pruss-intc: Allow setting irq affinity for PRU events")

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoHACK: mmc: sdhci_am654: Disable command queuing for AM65x
Faiz Abbas [Sun, 22 Dec 2019 02:38:25 +0000 (02:38 +0000)]
HACK: mmc: sdhci_am654: Disable command queuing for AM65x

Disable command queuing for devices compatible with am654x.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
16 months agoMerged TI feature rpmsg into ti-linux-4.19.y
LCPD Auto Merger [Tue, 24 Dec 2019 20:36:14 +0000 (14:36 -0600)]
Merged TI feature rpmsg into ti-linux-4.19.y

TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg

* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  remoteproc/k3-r5: fix probe failure on Split-mode _only_ devices
  rpmsg: rpc: fix static checker errors

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
16 months agoMerge branch 'rpmsg-ti-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti... rpmsg-ti-linux-4.19.y-intg
Suman Anna [Tue, 24 Dec 2019 19:34:56 +0000 (13:34 -0600)]
Merge branch 'rpmsg-ti-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y-intg

Signed-off-by: Suman Anna <s-anna@ti.com>
16 months agoMerge branch 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux... rpmsg-ti-linux-4.19.y
Suman Anna [Tue, 24 Dec 2019 19:21:59 +0000 (13:21 -0600)]
Merge branch 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y

Pull in the updated rpmsg base feature branch that includes a minor fix
in the rpmsg-rpc driver for issues reported by the static code checker
tool Klocwork.

* 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: rpc: fix static checker errors

Signed-off-by: Suman Anna <s-anna@ti.com>
16 months agoMerge branch 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti...
Suman Anna [Tue, 24 Dec 2019 19:18:52 +0000 (13:18 -0600)]
Merge branch 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y

Pull in the dedicated AM65x remoteproc topic branch that includes a fix
for probe failures in remoteproc mode on devices where the R5FSS is
only capable of Split-mode.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/k3-r5: fix probe failure on Split-mode _only_ devices

Signed-off-by: Suman Anna <s-anna@ti.com>
16 months agoremoteproc/k3-r5: fix probe failure on Split-mode _only_ devices
Suman Anna [Fri, 20 Dec 2019 21:48:58 +0000 (15:48 -0600)]
remoteproc/k3-r5: fix probe failure on Split-mode _only_ devices

The R5F subsystem/cluster on K3 SoCs can support both LockStep and
Split-modes (superset) or just Split-mode depending on an eFUSE
capability register. The k3_r5_rproc_configure() function is used to
configure the R5F remote processors in remoteproc mode, and performs
this by requesting the System Firmware as per the requested DT properties.
This function initializes identical settings for both cores in LockStep
mode by first programming it for Split-mode and then reverting back
to LockStep mode after the settings initialization. The Split-mode
setting is done on Core0 always irrespective of the mode.

The LockStep configuration bit is Read-only though on Split-mode _only_
devices and as such the System Firmware does not allow the LockStep
mode bit to be configured on such devices. The current logic in
k3_r5_rproc_configure() fails on Split-mode devices because of this
unconditional programming of the LockStep mode bit.

Fix this by limiting the LockStep mode bit clear configuration only on
devices supporting both LockStep/Split-modes.

Reported-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
16 months agoMerged TI feature audio-display into ti-linux-4.19.y
LCPD Auto Merger [Fri, 20 Dec 2019 14:36:43 +0000 (08:36 -0600)]
Merged TI feature audio-display into ti-linux-4.19.y

TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y

* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
  drm/tidss: remove underflow handling
  drm/tidss: increase preload to avoid underflows
  arm64: dts: ti: k3-am65-main: fix DSS irq trigger type

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
16 months agoMerge branch 'ti/4.19-pull' of https://bitbucket.itg.ti.com/scm/~a0400822/linux into...
Jyri Sarha [Fri, 20 Dec 2019 13:48:06 +0000 (15:48 +0200)]
Merge branch 'ti/4.19-pull' of https://bitbucket.itg.ti.com/scm/~a0400822/linux into audio_display-ti-linux-4.19.y

[GIT PULL] underflow fixes for .06

* 'ti/4.19-pull' of https://bitbucket.itg.ti.com/scm/~a0400822/linux:
  drm/tidss: remove underflow handling
  drm/tidss: increase preload to avoid underflows
  arm64: dts: ti: k3-am65-main: fix DSS irq trigger type

16 months agodrm/tidss: remove underflow handling
Tomi Valkeinen [Fri, 20 Dec 2019 09:24:47 +0000 (11:24 +0200)]
drm/tidss: remove underflow handling

It was found out that we may have lots of underflows even in a normal,
working, setup.

This may happen during the DSS preload period, where DSS fills all its
fifos and buffers at maximum speed. Underflow indicates that the DMA
cannot keep up with the DSS's internal pixel processing, but as the
pixels are not consumed yet by anything, there's no harm in these
underflows. It effectively just indicates that DSS's internal processing
is being limited by the DMA.

If an underflow happens during the active period of the display, it
causes a sync-lost interrupt as the videoport cannot get the pixels it
needs. This sync-lost is often caused by an underflow, though.

So, underflow alone is not an indication of a problem, but sync lost
always is.

This patch removes underflow handling from the driver to get rid of the
underflow error print floods. In the future we may want to improve this
so that via a debug option some kind of underflow statistics could be
collected.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Jyri Sarha <jsarha@ti.com>
16 months agodrm/tidss: increase preload to avoid underflows
Tomi Valkeinen [Thu, 19 Dec 2019 07:57:17 +0000 (09:57 +0200)]
drm/tidss: increase preload to avoid underflows

AM6 EVM shows underflows with some downscaling use cases. One way to
decrease the possibility of underflows is to adjust the preload value.
The driver currently sets it to a rather low value.

This patch makes the HW use the fifo high-threshold value as the preload
value, which should minimize the possibility of underflows from preload
perspective.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
16 months agorpmsg: rpc: fix static checker errors rpmsg-linux-4.19.y
Suman Anna [Wed, 18 Dec 2019 22:30:15 +0000 (16:30 -0600)]
rpmsg: rpc: fix static checker errors

Fix couple of minor issues reported by the Klocwork static checker
analysis tool:
 - Perform a sanity check on the function index against the available
   number of functions supported by the rppc device to avoid out-of-bound
   array access in rppc_write().
 - Remove a stale local variable redefinition to avoid returning an
   uninitialized return value in certain paths in rppc_probe().

Fixes: 1b5a3b2ef344 ("rpmsg: rpc: introduce a new rpmsg_rpc driver")
Signed-off-by: Suman Anna <s-anna@ti.com>
16 months agoLinux 4.19.90
Greg Kroah-Hartman [Tue, 17 Dec 2019 19:36:04 +0000 (20:36 +0100)]
Linux 4.19.90

16 months agoof: unittest: fix memory leak in attach_node_and_children
Erhard Furtner [Tue, 26 Nov 2019 01:48:04 +0000 (02:48 +0100)]
of: unittest: fix memory leak in attach_node_and_children

[ Upstream commit 2aacace6dbbb6b6ce4e177e6c7ea901f389c0472 ]

In attach_node_and_children memory is allocated for full_name via
kasprintf. If the condition of the 1st if is not met the function
returns early without freeing the memory. Add a kfree() to fix that.

This has been detected with kmemleak:
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205327
It looks like the leak was introduced by this commit:
Fixes: 5babefb7f7ab ("of: unittest: allow base devicetree to have symbol metadata")

Signed-off-by: Erhard Furtner <erhard_f@mailbox.org>
Reviewed-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoscsi: zorro_esp: Limit DMA transfers to 65536 bytes (except on Fastlane)
Kars de Jong [Tue, 12 Nov 2019 17:55:23 +0000 (18:55 +0100)]
scsi: zorro_esp: Limit DMA transfers to 65536 bytes (except on Fastlane)

[ Upstream commit 02f7e9f351a9de95577eafdc3bd413ed1c3b589f ]

When using this driver on a Blizzard 1260, there were failures whenever DMA
transfers from the SCSI bus to memory of 65535 bytes were followed by a DMA
transfer of 1 byte. This caused the byte at offset 65535 to be overwritten
with 0xff. The Blizzard hardware can't handle single byte DMA transfers.

Besides this issue, limiting the DMA length to something that is not a
multiple of the page size is very inefficient on most file systems.

It seems this limit was chosen because the DMA transfer counter of the ESP
by default is 16 bits wide, thus limiting the length to 65535 bytes.
However, the value 0 means 65536 bytes, which is handled by the ESP and the
Blizzard just fine. It is also the default maximum used by esp_scsi when
drivers don't provide their own dma_length_limit() function.

The limit of 65536 bytes can be used by all boards except the Fastlane. The
old driver used a limit of 65532 bytes (0xfffc), which is reintroduced in
this patch.

Fixes: b7ded0e8b0d1 ("scsi: zorro_esp: Limit DMA transfers to 65535 bytes")
Link: https://lore.kernel.org/r/20191112175523.23145-1-jongk@linux-m68k.org
Signed-off-by: Kars de Jong <jongk@linux-m68k.org>
Reviewed-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoidr: Fix idr_get_next_ul race with idr_remove
Matthew Wilcox (Oracle) [Sat, 2 Nov 2019 01:36:39 +0000 (21:36 -0400)]
idr: Fix idr_get_next_ul race with idr_remove

[ Upstream commit 5a74ac4c4a97bd8b7dba054304d598e2a882fea6 ]

Commit 5c089fd0c734 ("idr: Fix idr_get_next race with idr_remove")
neglected to fix idr_get_next_ul().  As far as I can tell, nobody's
actually using this interface under the RCU read lock, but fix it now
before anybody decides to use it.

Fixes: 5c089fd0c734 ("idr: Fix idr_get_next race with idr_remove")
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoiio: imu: mpu6050: add missing available scan masks
Jean-Baptiste Maneyrol [Thu, 27 Jun 2019 13:19:53 +0000 (13:19 +0000)]
iio: imu: mpu6050: add missing available scan masks

[ Upstream commit 1244a720572fd1680ac8d6b8a4235f2e8557b810 ]

Driver only supports 3-axis gyro and/or 3-axis accel.
For icm20602, temp data is mandatory for all configurations.

Fix all single and double axis configurations (almost never used) and more
importantly fix 3-axis gyro and 6-axis accel+gyro buffer on icm20602 when
temp data is not enabled.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Fixes: 1615fe41a195 ("iio: imu: mpu6050: Fix FIFO layout for ICM20602")
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoscsi: qla2xxx: Change discovery state before PLOGI
Roman Bolshakov [Mon, 25 Nov 2019 16:56:54 +0000 (19:56 +0300)]
scsi: qla2xxx: Change discovery state before PLOGI

[ Upstream commit 58e39a2ce4be08162c0368030cdc405f7fd849aa ]

When a port sends PLOGI, discovery state should be changed to login
pending, otherwise RELOGIN_NEEDED bit is set in
qla24xx_handle_plogi_done_event(). RELOGIN_NEEDED triggers another PLOGI,
and it never goes out of the loop until login timer expires.

Fixes: 8777e4314d397 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine")
Fixes: 8b5292bcfcacf ("scsi: qla2xxx: Fix Relogin to prevent modifying scan_state flag")
Cc: Quinn Tran <qutran@marvell.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191125165702.1013-6-r.bolshakov@yadro.com
Acked-by: Himanshu Madhani <hmadhani@marvell.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Tested-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoraid5: need to set STRIPE_HANDLE for batch head
Guoqing Jiang [Wed, 27 Nov 2019 16:57:50 +0000 (17:57 +0100)]
raid5: need to set STRIPE_HANDLE for batch head

[ Upstream commit a7ede3d16808b8f3915c8572d783530a82b2f027 ]

With commit 6ce220dd2f8ea71d6afc29b9a7524c12e39f374a ("raid5: don't set
STRIPE_HANDLE to stripe which is in batch list"), we don't want to set
STRIPE_HANDLE flag for sh which is already in batch list.

However, the stripe which is the head of batch list should set this flag,
otherwise panic could happen inside init_stripe at BUG_ON(sh->batch_head),
it is reproducible with raid5 on top of nvdimm devices per Xiao oberserved.

Thanks for Xiao's effort to verify the change.

Fixes: 6ce220dd2f8ea ("raid5: don't set STRIPE_HANDLE to stripe which is in batch list")
Reported-by: Xiao Ni <xni@redhat.com>
Tested-by: Xiao Ni <xni@redhat.com>
Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agogpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist
Hans de Goede [Wed, 6 Nov 2019 11:51:09 +0000 (12:51 +0100)]
gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist

[ Upstream commit 2727315df3f5ffbebcb174eed3153944a858b66f ]

The Terra Pad 1061 has the usual micro-USB-B id-pin handler, but instead
of controlling the actual micro-USB-B it turns the 5V boost for the
tablet's USB-A connector and its keyboard-cover connector off.

The actual micro-USB-B connector on the tablet is wired for charging only,
and its id pin is *not* connected to the GPIO which is used for the
(broken) id-pin event handler in the DSDT.

While at it not only add a comment why the Terra Pad 1061 is on the
blacklist, but also fix the missing comment for the Minix Neo Z83-4 entry.

Fixes: 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agocifs: Fix potential softlockups while refreshing DFS cache
Paulo Alcantara (SUSE) [Fri, 22 Nov 2019 15:30:53 +0000 (12:30 -0300)]
cifs: Fix potential softlockups while refreshing DFS cache

[ Upstream commit 84a1f5b1cc6fd7f6cd99fc5630c36f631b19fa60 ]

We used to skip reconnects on all SMB2_IOCTL commands due to SMB3+
FSCTL_VALIDATE_NEGOTIATE_INFO - which made sense since we're still
establishing a SMB session.

However, when refresh_cache_worker() calls smb2_get_dfs_refer() and
we're under reconnect, SMB2_ioctl() will not be able to get a proper
status error (e.g. -EHOSTDOWN in case we failed to reconnect) but an
-EAGAIN from cifs_send_recv() thus looping forever in
refresh_cache_worker().

Fixes: e99c63e4d86d ("SMB3: Fix deadlock in validate negotiate hits reconnect")
Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Suggested-by: Aurelien Aptel <aaptel@suse.com>
Reviewed-by: Aurelien Aptel <aaptel@suse.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agokernel/module.c: wakeup processes in module_wq on module unload
Konstantin Khorenko [Wed, 13 Nov 2019 09:29:50 +0000 (12:29 +0300)]
kernel/module.c: wakeup processes in module_wq on module unload

[ Upstream commit 5d603311615f612320bb77bd2a82553ef1ced5b7 ]

Fix the race between load and unload a kernel module.

sys_delete_module()
 try_stop_module()
  mod->state = _GOING
add_unformed_module()
 old = find_module_all()
 (old->state == _GOING =>
  wait_event_interruptible())

 During pre-condition
 finished_loading() rets 0
 schedule()
 (never gets waken up later)
 free_module()
  mod->state = _UNFORMED
   list_del_rcu(&mod->list)
   (dels mod from "modules" list)

return

The race above leads to modprobe hanging forever on loading
a module.

Error paths on loading module call wake_up_all(&module_wq) after
freeing module, so let's do the same on straight module unload.

Fixes: 6e6de3dee51a ("kernel/module.c: Only return -EEXIST for modules that have finished loading")
Reviewed-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
Signed-off-by: Jessica Yu <jeyu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoof: overlay: add_changeset_property() memory leak
Frank Rowand [Thu, 21 Nov 2019 19:16:56 +0000 (13:16 -0600)]
of: overlay: add_changeset_property() memory leak

[ Upstream commit 637392a8506a3a7dd24ab9094a14f7522adb73b4 ]

No changeset entries are created for #address-cells and #size-cells
properties, but the duplicated properties are never freed.  This
results in a memory leak which is detected by kmemleak:

 unreferenced object 0x85887180 (size 64):
   backtrace:
     kmem_cache_alloc_trace+0x1fb/0x1fc
     __of_prop_dup+0x25/0x7c
     add_changeset_property+0x17f/0x370
     build_changeset_next_level+0x29/0x20c
     of_overlay_fdt_apply+0x32b/0x6b4
     ...

Fixes: 6f75118800ac ("of: overlay: validate overlay properties #address-cells and #size-cells")
Reported-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Tested-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agogfs2: fix glock reference problem in gfs2_trans_remove_revoke
Bob Peterson [Thu, 14 Nov 2019 14:49:11 +0000 (09:49 -0500)]
gfs2: fix glock reference problem in gfs2_trans_remove_revoke

[ Upstream commit fe5e7ba11fcf1d75af8173836309e8562aefedef ]

Commit 9287c6452d2b fixed a situation in which gfs2 could use a glock
after it had been freed. To do that, it temporarily added a new glock
reference by calling gfs2_glock_hold in function gfs2_add_revoke.
However, if the bd element was removed by gfs2_trans_remove_revoke, it
failed to drop the additional reference.

This patch adds logic to gfs2_trans_remove_revoke to properly drop the
additional glock reference.

Fixes: 9287c6452d2b ("gfs2: Fix occasional glock use-after-free")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoPCI: rcar: Fix missing MACCTLR register setting in initialization sequence
Yoshihiro Shimoda [Tue, 5 Nov 2019 10:51:29 +0000 (19:51 +0900)]
PCI: rcar: Fix missing MACCTLR register setting in initialization sequence

[ Upstream commit 7c7e53e1c93df14690bd12c1f84730fef927a6f1 ]

The R-Car Gen2/3 manual - available at:

https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz/rzg/rzg1m.html#documents

"RZ/G Series User's Manual: Hardware" section

strictly enforces the MACCTLR inizialization value - 39.3.1 - "Initial
Setting of PCI Express":

"Be sure to write the initial value (= H'80FF 0000) to MACCTLR before
enabling PCIETCTLR.CFINIT".

To avoid unexpected behavior and to match the SW initialization sequence
guidelines, this patch programs the MACCTLR with the correct value.

Note that the MACCTLR.SPCHG bit in the MACCTLR register description
reports that "Only writing 1 is valid and writing 0 is invalid" but this
"invalid" has to be interpreted as a write-ignore aka "ignored", not
"prohibited".

Reported-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Fixes: c25da4778803 ("PCI: rcar: Add Renesas R-Car PCIe driver")
Fixes: be20bbcb0a8c ("PCI: rcar: Add the initialization of PCIe link in resume_noirq()")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: <stable@vger.kernel.org> # v5.2+
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoleds: trigger: netdev: fix handling on interface rename
Martin Schiller [Fri, 25 Oct 2019 07:01:42 +0000 (09:01 +0200)]
leds: trigger: netdev: fix handling on interface rename

[ Upstream commit 5f820ed52371b4f5d8c43c93f03408d0dbc01e5b ]

The NETDEV_CHANGENAME code is not "unneeded" like it is stated in commit
4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface
rename").

The event was accidentally misinterpreted equivalent to
NETDEV_UNREGISTER, but should be equivalent to NETDEV_REGISTER.

This was the case in the original code from the openwrt project.

Otherwise, you are unable to set netdev led triggers for (non-existent)
netdevices, which has to be renamed. This is the case, for example, for
ppp interfaces in openwrt.

Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger")
Fixes: 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename")
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agonet/mlx5e: Fix SFF 8472 eeprom length
Eran Ben Elisha [Thu, 5 Dec 2019 08:30:22 +0000 (10:30 +0200)]
net/mlx5e: Fix SFF 8472 eeprom length

[ Upstream commit c431f8597863a91eea6024926e0c1b179cfa4852 ]

SFF 8472 eeprom length is 512 bytes. Fix module info return value to
support 512 bytes read.

Fixes: ace329f4ab3b ("net/mlx5e: ethtool, Remove unsupported SFP EEPROM high pages query")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Aya Levin <ayal@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agosunrpc: fix crash when cache_head become valid before update
Pavel Tikhomirov [Tue, 1 Oct 2019 08:03:59 +0000 (11:03 +0300)]
sunrpc: fix crash when cache_head become valid before update

[ Upstream commit 5fcaf6982d1167f1cd9b264704f6d1ef4c505d54 ]

I was investigating a crash in our Virtuozzo7 kernel which happened in
in svcauth_unix_set_client. I found out that we access m_client field
in ip_map structure, which was received from sunrpc_cache_lookup (we
have a bit older kernel, now the code is in sunrpc_cache_add_entry), and
these field looks uninitialized (m_client == 0x74 don't look like a
pointer) but in the cache_head in flags we see 0x1 which is CACHE_VALID.

It looks like the problem appeared from our previous fix to sunrpc (1):
commit 4ecd55ea0742 ("sunrpc: fix cache_head leak due to queued
request")

And we've also found a patch already fixing our patch (2):
commit d58431eacb22 ("sunrpc: don't mark uninitialised items as VALID.")

Though the crash is eliminated, I think the core of the problem is not
completely fixed:

Neil in the patch (2) makes cache_head CACHE_NEGATIVE, before
cache_fresh_locked which was added in (1) to fix crash. These way
cache_is_valid won't say the cache is valid anymore and in
svcauth_unix_set_client the function cache_check will return error
instead of 0, and we don't count entry as initialized.

But it looks like we need to remove cache_fresh_locked completely in
sunrpc_cache_lookup:

In (1) we've only wanted to make cache_fresh_unlocked->cache_dequeue so
that cache_requests with no readers also release corresponding
cache_head, to fix their leak.  We with Vasily were not sure if
cache_fresh_locked and cache_fresh_unlocked should be used in pair or
not, so we've guessed to use them in pair.

Now we see that we don't want the CACHE_VALID bit set here by
cache_fresh_locked, as "valid" means "initialized" and there is no
initialization in sunrpc_cache_add_entry. Both expiry_time and
last_refresh are not used in cache_fresh_unlocked code-path and also not
required for the initial fix.

So to conclude cache_fresh_locked was called by mistake, and we can just
safely remove it instead of crutching it with CACHE_NEGATIVE. It looks
ideologically better for me. Hope I don't miss something here.

Here is our crash backtrace:
[13108726.326291] BUG: unable to handle kernel NULL pointer dereference at 0000000000000074
[13108726.326365] IP: [<ffffffffc01f79eb>] svcauth_unix_set_client+0x2ab/0x520 [sunrpc]
[13108726.326448] PGD 0
[13108726.326468] Oops: 0002 [#1] SMP
[13108726.326497] Modules linked in: nbd isofs xfs loop kpatch_cumulative_81_0_r1(O) xt_physdev nfnetlink_queue bluetooth rfkill ip6table_nat nf_nat_ipv6 ip_vs_wrr ip_vs_wlc ip_vs_sh nf_conntrack_netlink ip_vs_sed ip_vs_pe_sip nf_conntrack_sip ip_vs_nq ip_vs_lc ip_vs_lblcr ip_vs_lblc ip_vs_ftp ip_vs_dh nf_nat_ftp nf_conntrack_ftp iptable_raw xt_recent nf_log_ipv6 xt_hl ip6t_rt nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_TCPMSS xt_tcpmss vxlan ip6_udp_tunnel udp_tunnel xt_statistic xt_NFLOG nfnetlink_log dummy xt_mark xt_REDIRECT nf_nat_redirect raw_diag udp_diag tcp_diag inet_diag netlink_diag af_packet_diag unix_diag rpcsec_gss_krb5 xt_addrtype ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 ebtable_nat ebtable_broute nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_mangle ip6table_raw nfsv4
[13108726.327173]  dns_resolver cls_u32 binfmt_misc arptable_filter arp_tables ip6table_filter ip6_tables devlink fuse_kio_pcs ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat iptable_nat nf_nat_ipv4 xt_comment nf_conntrack_ipv4 nf_defrag_ipv4 xt_wdog_tmo xt_multiport bonding xt_set xt_conntrack iptable_filter iptable_mangle kpatch(O) ebtable_filter ebt_among ebtables ip_set_hash_ip ip_set nfnetlink vfat fat skx_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass fuse pcspkr ses enclosure joydev sg mei_me hpwdt hpilo lpc_ich mei ipmi_si shpchp ipmi_devintf ipmi_msghandler xt_ipvs acpi_power_meter ip_vs_rr nfsv3 nfsd auth_rpcgss nfs_acl nfs lockd grace fscache nf_nat cls_fw sch_htb sch_cbq sch_sfq ip_vs em_u32 nf_conntrack tun br_netfilter veth overlay ip6_vzprivnet ip6_vznetstat ip_vznetstat
[13108726.327817]  ip_vzprivnet vziolimit vzevent vzlist vzstat vznetstat vznetdev vzmon vzdev bridge pio_kaio pio_nfs pio_direct pfmt_raw pfmt_ploop1 ploop ip_tables ext4 mbcache jbd2 sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper scsi_transport_iscsi 8021q syscopyarea sysfillrect garp sysimgblt fb_sys_fops mrp stp ttm llc bnx2x crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel drm dm_multipath ghash_clmulni_intel uas aesni_intel lrw gf128mul glue_helper ablk_helper cryptd tg3 smartpqi scsi_transport_sas mdio libcrc32c i2c_core usb_storage ptp pps_core wmi sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: kpatch_cumulative_82_0_r1]
[13108726.328403] CPU: 35 PID: 63742 Comm: nfsd ve: 51332 Kdump: loaded Tainted: G        W  O   ------------   3.10.0-862.20.2.vz7.73.29 #1 73.29
[13108726.328491] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 10/02/2018
[13108726.328554] task: ffffa0a6a41b1160 ti: ffffa0c2a74bc000 task.ti: ffffa0c2a74bc000
[13108726.328610] RIP: 0010:[<ffffffffc01f79eb>]  [<ffffffffc01f79eb>] svcauth_unix_set_client+0x2ab/0x520 [sunrpc]
[13108726.328706] RSP: 0018:ffffa0c2a74bfd80  EFLAGS: 00010246
[13108726.328750] RAX: 0000000000000001 RBX: ffffa0a6183ae000 RCX: 0000000000000000
[13108726.328811] RDX: 0000000000000074 RSI: 0000000000000286 RDI: ffffa0c2a74bfcf0
[13108726.328864] RBP: ffffa0c2a74bfe00 R08: ffffa0bab8c22960 R09: 0000000000000001
[13108726.328916] R10: 0000000000000001 R11: 0000000000000001 R12: ffffa0a32aa7f000
[13108726.328969] R13: ffffa0a6183afac0 R14: ffffa0c233d88d00 R15: ffffa0c2a74bfdb4
[13108726.329022] FS:  0000000000000000(0000) GS:ffffa0e17f9c0000(0000) knlGS:0000000000000000
[13108726.329081] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[13108726.332311] CR2: 0000000000000074 CR3: 00000026a1b28000 CR4: 00000000007607e0
[13108726.334606] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[13108726.336754] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[13108726.338908] PKRU: 00000000
[13108726.341047] Call Trace:
[13108726.343074]  [<ffffffff8a2c78b4>] ? groups_alloc+0x34/0x110
[13108726.344837]  [<ffffffffc01f5eb4>] svc_set_client+0x24/0x30 [sunrpc]
[13108726.346631]  [<ffffffffc01f2ac1>] svc_process_common+0x241/0x710 [sunrpc]
[13108726.348332]  [<ffffffffc01f3093>] svc_process+0x103/0x190 [sunrpc]
[13108726.350016]  [<ffffffffc07d605f>] nfsd+0xdf/0x150 [nfsd]
[13108726.351735]  [<ffffffffc07d5f80>] ? nfsd_destroy+0x80/0x80 [nfsd]
[13108726.353459]  [<ffffffff8a2bf741>] kthread+0xd1/0xe0
[13108726.355195]  [<ffffffff8a2bf670>] ? create_kthread+0x60/0x60
[13108726.356896]  [<ffffffff8a9556dd>] ret_from_fork_nospec_begin+0x7/0x21
[13108726.358577]  [<ffffffff8a2bf670>] ? create_kthread+0x60/0x60
[13108726.360240] Code: 4c 8b 45 98 0f 8e 2e 01 00 00 83 f8 fe 0f 84 76 fe ff ff 85 c0 0f 85 2b 01 00 00 49 8b 50 40 b8 01 00 00 00 48 89 93 d0 1a 00 00 <f0> 0f c1 02 83 c0 01 83 f8 01 0f 8e 53 02 00 00 49 8b 44 24 38
[13108726.363769] RIP  [<ffffffffc01f79eb>] svcauth_unix_set_client+0x2ab/0x520 [sunrpc]
[13108726.365530]  RSP <ffffa0c2a74bfd80>
[13108726.367179] CR2: 0000000000000074

Fixes: d58431eacb22 ("sunrpc: don't mark uninitialised items as VALID.")
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Acked-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agofirmware: arm_scmi: Avoid double free in error flow
Wen Yang [Mon, 25 Nov 2019 15:54:09 +0000 (23:54 +0800)]
firmware: arm_scmi: Avoid double free in error flow

[ Upstream commit 8305e90a894f82c278c17e51a28459deee78b263 ]

If device_register() fails, both put_device() and kfree() are called,
ending with a double free of the scmi_dev.

Calling kfree() is needed only when a failure happens between the
allocation of the scmi_dev and its registration, so move it to there
and remove it from the error flow.

Fixes: 46edb8d1322c ("firmware: arm_scmi: provide the mandatory device release callback")
Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agogre: refetch erspan header from skb->data after pskb_may_pull()
Cong Wang [Fri, 6 Dec 2019 03:39:02 +0000 (19:39 -0800)]
gre: refetch erspan header from skb->data after pskb_may_pull()

[ Upstream commit 0e4940928c26527ce8f97237fef4c8a91cd34207 ]

After pskb_may_pull() we should always refetch the header
pointers from the skb->data in case it got reallocated.

In gre_parse_header(), the erspan header is still fetched
from the 'options' pointer which is fetched before
pskb_may_pull().

Found this during code review of a KMSAN bug report.

Fixes: cb73ee40b1b3 ("net: ip_gre: use erspan key field for tunnel lookup")
Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Acked-by: William Tu <u9012063@gmail.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoperf callchain: Fix segfault in thread__resolve_callchain_sample()
Adrian Hunter [Thu, 14 Nov 2019 14:25:38 +0000 (16:25 +0200)]
perf callchain: Fix segfault in thread__resolve_callchain_sample()

[ Upstream commit aceb98261ea7d9fe38f9c140c5531f0b13623832 ]

Do not dereference 'chain' when it is NULL.

  $ perf record -e intel_pt//u -e branch-misses:u uname
  $ perf report --itrace=l --branch-history
  perf: Segmentation fault

Fixes: e9024d519d89 ("perf callchain: Honour the ordering of PERF_CONTEXT_{USER,KERNEL,etc}")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lore.kernel.org/lkml/20191114142538.4097-1-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoworkqueue: Fix missing kfree(rescuer) in destroy_workqueue()
Tejun Heo [Fri, 20 Sep 2019 20:39:57 +0000 (13:39 -0700)]
workqueue: Fix missing kfree(rescuer) in destroy_workqueue()

commit 8efe1223d73c218ce7e8b2e0e9aadb974b582d7f upstream.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Qian Cai <cai@lca.pw>
Fixes: def98c84b6cd ("workqueue: Fix spurious sanity check failures in destroy_workqueue()")
Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
16 months agoblk-mq: make sure that line break can be printed
Ming Lei [Mon, 4 Nov 2019 08:26:53 +0000 (16:26 +0800)]
blk-mq: make sure that line break can be printed

commit d2c9be89f8ebe7ebcc97676ac40f8dec1cf9b43a upstream.

8962842ca5ab ("blk-mq: avoid sysfs buffer overflow with too many CPU cores")
avoids sysfs buffer overflow, and reserves one character for line break.
However, the last snprintf() doesn't get correct 'size' parameter passed
in, so fixed it.

Fixes: 8962842ca5ab ("blk-mq: avoid sysfs buffer overflow with too many CPU cores")
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
16 months agos390/smp,vdso: fix ASCE handling
Heiko Carstens [Mon, 18 Nov 2019 12:09:52 +0000 (13:09 +0100)]
s390/smp,vdso: fix ASCE handling

[ Upstream commit a2308c11ecbc3471ebb7435ee8075815b1502ef0 ]

When a secondary CPU is brought up it must initialize its control
registers. CPU A which triggers that a secondary CPU B is brought up
stores its control register contents into the lowcore of new CPU B,
which then loads these values on startup.

This is problematic in various ways: the control register which
contains the home space ASCE will correctly contain the kernel ASCE;
however control registers for primary and secondary ASCEs are
initialized with whatever values were present in CPU A.

Typically:
- the primary ASCE will contain the user process ASCE of the process
  that triggered onlining of CPU B.
- the secondary ASCE will contain the percpu VDSO ASCE of CPU A.

Due to lazy ASCE handling we may also end up with other combinations.

When then CPU B switches to a different process (!= idle) it will
fixup the primary ASCE. However the problem is that the (wrong) ASCE
from CPU A was loaded into control register 1: as soon as an ASCE is
attached (aka loaded) a CPU is free to generate TLB entries using that
address space.
Even though it is very unlikey that CPU B will actually generate such
entries, this could result in TLB entries of the address space of the
process that ran on CPU A. These entries shouldn't exist at all and
could cause problems later on.

Furthermore the secondary ASCE of CPU B will not be updated correctly.
This means that processes may see wrong results or even crash if they
access VDSO data on CPU B. The correct VDSO ASCE will eventually be
loaded on return to user space as soon as the kernel executed a call
to strnlen_user or an atomic futex operation on CPU B.

Fix both issues by intializing the to be loaded control register
contents with the correct ASCEs and also enforce (re-)loading of the
ASCEs upon first context switch and return to user space.

Fixes: 0aaba41b58bc ("s390: remove all code using the access register mode")
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agomm, thp, proc: report THP eligibility for each vma
Michal Hocko [Fri, 28 Dec 2018 08:38:21 +0000 (00:38 -0800)]
mm, thp, proc: report THP eligibility for each vma

[ Upstream commit 7635d9cbe8327e131a1d3d8517dc186c2796ce2e ]

Userspace falls short when trying to find out whether a specific memory
range is eligible for THP.  There are usecases that would like to know
that
http://lkml.kernel.org/r/alpine.DEB.2.21.1809251248450.50347@chino.kir.corp.google.com
: This is used to identify heap mappings that should be able to fault thp
: but do not, and they normally point to a low-on-memory or fragmentation
: issue.

The only way to deduce this now is to query for hg resp.  nh flags and
confronting the state with the global setting.  Except that there is also
PR_SET_THP_DISABLE that might change the picture.  So the final logic is
not trivial.  Moreover the eligibility of the vma depends on the type of
VMA as well.  In the past we have supported only anononymous memory VMAs
but things have changed and shmem based vmas are supported as well these
days and the query logic gets even more complicated because the
eligibility depends on the mount option and another global configuration
knob.

Simplify the current state and report the THP eligibility in
/proc/<pid>/smaps for each existing vma.  Reuse
transparent_hugepage_enabled for this purpose.  The original
implementation of this function assumes that the caller knows that the vma
itself is supported for THP so make the core checks into
__transparent_hugepage_enabled and use it for existing callers.
__show_smap just use the new transparent_hugepage_enabled which also
checks the vma support status (please note that this one has to be out of
line due to include dependency issues).

[mhocko@kernel.org: fix oops with NULL ->f_mapping]
Link: http://lkml.kernel.org/r/20181224185106.GC16738@dhcp22.suse.cz
Link: http://lkml.kernel.org/r/20181211143641.3503-3-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Paul Oppenheimer <bepvte@gmail.com>
Cc: William Kucharski <william.kucharski@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agomfd: rk808: Fix RK818 ID template
Daniel Schultz [Tue, 17 Sep 2019 08:12:53 +0000 (10:12 +0200)]
mfd: rk808: Fix RK818 ID template

[ Upstream commit 37ef8c2c15bdc1322b160e38986c187de2b877b2 ]

The Rockchip PMIC driver can automatically detect connected component
versions by reading the ID_MSB and ID_LSB registers. The probe function
will always fail with RK818 PMICs because the ID_MSK is 0xFFF0 and the
RK818 template ID is 0x8181.

This patch changes this value to 0x8180.

Fixes: 9d6105e19f61 ("mfd: rk808: Fix up the chip id get failed")
Cc: stable@vger.kernel.org
Cc: Elaine Zhang <zhangqing@rock-chips.com>
Cc: Joseph Chen <chenjh@rock-chips.com>
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoext4: fix a bug in ext4_wait_for_tail_page_commit
yangerkun [Thu, 19 Sep 2019 06:35:08 +0000 (14:35 +0800)]
ext4: fix a bug in ext4_wait_for_tail_page_commit

commit 565333a1554d704789e74205989305c811fd9c7a upstream.

No need to wait for any commit once the page is fully truncated.
Besides, it may confuse e.g. concurrent ext4_writepage() with the page
still be dirty (will be cleared by truncate_pagecache() in
ext4_setattr()) but buffers has been freed; and then trigger a bug
show as below:

[   26.057508] ------------[ cut here ]------------
[   26.058531] kernel BUG at fs/ext4/inode.c:2134!
...
[   26.088130] Call trace:
[   26.088695]  ext4_writepage+0x914/0xb28
[   26.089541]  writeout.isra.4+0x1b4/0x2b8
[   26.090409]  move_to_new_page+0x3b0/0x568
[   26.091338]  __unmap_and_move+0x648/0x988
[   26.092241]  unmap_and_move+0x48c/0xbb8
[   26.093096]  migrate_pages+0x220/0xb28
[   26.093945]  kernel_mbind+0x828/0xa18
[   26.094791]  __arm64_sys_mbind+0xc8/0x138
[   26.095716]  el0_svc_common+0x190/0x490
[   26.096571]  el0_svc_handler+0x60/0xd0
[   26.097423]  el0_svc+0x8/0xc

Run the procedure (generate by syzkaller) parallel with ext3.

void main()
{
int fd, fd1, ret;
void *addr;
size_t length = 4096;
int flags;
off_t offset = 0;
char *str = "12345";

fd = open("a", O_RDWR | O_CREAT);
assert(fd >= 0);

/* Truncate to 4k */
ret = ftruncate(fd, length);
assert(ret == 0);

/* Journal data mode */
flags = 0xc00f;
ret = ioctl(fd, _IOW('f', 2, long), &flags);
assert(ret == 0);

/* Truncate to 0 */
fd1 = open("a", O_TRUNC | O_NOATIME);
assert(fd1 >= 0);

addr = mmap(NULL, length, PROT_WRITE | PROT_READ,
MAP_SHARED, fd, offset);
assert(addr != (void *)-1);

memcpy(addr, str, 5);
mbind(addr, length, 0, 0, 0, MPOL_MF_MOVE);
}

And the bug will be triggered once we seen the below order.

reproduce1                         reproduce2

...                            |   ...
truncate to 4k                 |
change to journal data mode    |
                               |   memcpy(set page dirty)
truncate to 0:                 |
ext4_setattr:                  |
...                            |
ext4_wait_for_tail_page_commit |
                               |   mbind(trigger bug)
truncate_pagecache(clean dirty)|   ...
...                            |

mbind will call ext4_writepage() since the page still be dirty, and then
report the bug since the buffers has been free. Fix it by return
directly once offset equals to 0 which means the page has been fully
truncated.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: yangerkun <yangerkun@huawei.com>
Link: https://lore.kernel.org/r/20190919063508.1045-1-yangerkun@huawei.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
16 months agosplice: only read in as much information as there is pipe buffer space
Darrick J. Wong [Tue, 15 Oct 2019 15:44:32 +0000 (08:44 -0700)]
splice: only read in as much information as there is pipe buffer space

commit 3253d9d093376d62b4a56e609f15d2ec5085ac73 upstream.

Andreas Grünbacher reports that on the two filesystems that support
iomap directio, it's possible for splice() to return -EAGAIN (instead of
a short splice) if the pipe being written to has less space available in
its pipe buffers than the length supplied by the calling process.

Months ago we fixed splice_direct_to_actor to clamp the length of the
read request to the size of the splice pipe.  Do the same to do_splice.

Fixes: 17614445576b6 ("splice: don't read more than available pipe space")
Reported-by: syzbot+3c01db6025f26530cf8d@syzkaller.appspotmail.com
Reported-by: Andreas Grünbacher <andreas.gruenbacher@gmail.com>
Reviewed-by: Andreas Grünbacher <andreas.gruenbacher@gmail.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
16 months agortc: disable uie before setting time and enable after
Alexandre Belloni [Sun, 20 Oct 2019 23:13:20 +0000 (01:13 +0200)]
rtc: disable uie before setting time and enable after

commit 7e7c005b4b1f1f169bcc4b2c3a40085ecc663df2 upstream.

When setting the time in the future with the uie timer enabled,
rtc_timer_do_work will loop for a while because the expiration of the uie
timer was way before the current RTC time and a new timer will be enqueued
until the current rtc time is reached.

If the uie timer is enabled, disable it before setting the time and enable
it after expiring current timers (which may actually be an alarm).

This is the safest thing to do to ensure the uie timer is still
synchronized with the RTC, especially in the UIE emulation case.

Reported-by: syzbot+08116743f8ad6f9a6de7@syzkaller.appspotmail.com
Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events")
Link: https://lore.kernel.org/r/20191020231320.8191-1-alexandre.belloni@bootlin.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
16 months agomm/shmem.c: cast the type of unmap_start to u64
Chen Jun [Sun, 1 Dec 2019 01:58:11 +0000 (17:58 -0800)]
mm/shmem.c: cast the type of unmap_start to u64

commit aa71ecd8d86500da6081a72da6b0b524007e0627 upstream.

In 64bit system. sb->s_maxbytes of shmem filesystem is MAX_LFS_FILESIZE,
which equal LLONG_MAX.

If offset > LLONG_MAX - PAGE_SIZE, offset + len < LLONG_MAX in
shmem_fallocate, which will pass the checking in vfs_fallocate.

/* Check for wrap through zero too */
if (((offset + len) > inode->i_sb->s_maxbytes) || ((offset + len) < 0))
return -EFBIG;

loff_t unmap_start = round_up(offset, PAGE_SIZE) in shmem_fallocate
causes a overflow.

Syzkaller reports a overflow problem in mm/shmem:

  UBSAN: Undefined behaviour in mm/shmem.c:2014:10
  signed integer overflow: '9223372036854775807 + 1' cannot be represented in type 'long long int'
  CPU: 0 PID:17076 Comm: syz-executor0 Not tainted 4.1.46+ #1
  Hardware name: linux, dummy-virt (DT)
  Call trace:
     dump_backtrace+0x0/0x2c8 arch/arm64/kernel/traps.c:100
     show_stack+0x20/0x30 arch/arm64/kernel/traps.c:238
     __dump_stack lib/dump_stack.c:15 [inline]
     ubsan_epilogue+0x18/0x70 lib/ubsan.c:164
     handle_overflow+0x158/0x1b0 lib/ubsan.c:195
     shmem_fallocate+0x6d0/0x820 mm/shmem.c:2104
     vfs_fallocate+0x238/0x428 fs/open.c:312
     SYSC_fallocate fs/open.c:335 [inline]
     SyS_fallocate+0x54/0xc8 fs/open.c:239

The highest bit of unmap_start will be appended with sign bit 1
(overflow) when calculate shmem_falloc.start:

    shmem_falloc.start = unmap_start >> PAGE_SHIFT.

Fix it by casting the type of unmap_start to u64, when right shifted.

This bug is found in LTS Linux 4.1.  It also seems to exist in mainline.

Link: http://lkml.kernel.org/r/1573867464-5107-1-git-send-email-chenjun102@huawei.com
Signed-off-by: Chen Jun <chenjun102@huawei.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
16 months agofirmware: qcom: scm: Ensure 'a0' status code is treated as signed
Will Deacon [Mon, 4 Nov 2019 15:58:15 +0000 (15:58 +0000)]
firmware: qcom: scm: Ensure 'a0' status code is treated as signed

commit ff34f3cce278a0982a7b66b1afaed6295141b1fc upstream.

The 'a0' member of 'struct arm_smccc_res' is declared as 'unsigned long',
however the Qualcomm SCM firmware interface driver expects to receive
negative error codes via this field, so ensure that it's cast to 'long'
before comparing to see if it is less than 0.

Cc: <stable@vger.kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
16 months agoext4: work around deleting a file with i_nlink == 0 safely
Theodore Ts'o [Tue, 12 Nov 2019 03:18:13 +0000 (22:18 -0500)]
ext4: work around deleting a file with i_nlink == 0 safely

commit c7df4a1ecb8579838ec8c56b2bb6a6716e974f37 upstream.

If the file system is corrupted such that a file's i_links_count is
too small, then it's possible that when unlinking that file, i_nlink
will already be zero.  Previously we were working around this kind of
corruption by forcing i_nlink to one; but we were doing this before
trying to delete the directory entry --- and if the file system is
corrupted enough that ext4_delete_entry() fails, then we exit with
i_nlink elevated, and this causes the orphan inode list handling to be
FUBAR'ed, such that when we unmount the file system, the orphan inode
list can get corrupted.

A better way to fix this is to simply skip trying to call drop_nlink()
if i_nlink is already zero, thus moving the check to the place where
it makes the most sense.

https://bugzilla.kernel.org/show_bug.cgi?id=205433

Link: https://lore.kernel.org/r/20191112032903.8828-1-tytso@mit.edu
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
16 months agopowerpc: Fix vDSO clock_getres()
Vincenzo Frascino [Mon, 2 Dec 2019 07:57:29 +0000 (07:57 +0000)]
powerpc: Fix vDSO clock_getres()

[ Upstream commit 552263456215ada7ee8700ce022d12b0cffe4802 ]

clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().

In particular, posix_get_hrtimer_res() does:
    sec = 0;
    ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or at run time.

Fix the powerpc vdso implementation of clock_getres keeping a copy of
hrtimer_resolution in vdso data and using that directly.

Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel")
Cc: stable@vger.kernel.org
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
[chleroy: changed CLOCK_REALTIME_RES to CLOCK_HRTIMER_RES]
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/a55eca3a5e85233838c2349783bcb5164dae1d09.1575273217.git.christophe.leroy@c-s.fr
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agopowerpc: Avoid clang warnings around setjmp and longjmp
Nathan Chancellor [Tue, 19 Nov 2019 04:57:11 +0000 (21:57 -0700)]
powerpc: Avoid clang warnings around setjmp and longjmp

[ Upstream commit c9029ef9c95765e7b63c4d9aa780674447db1ec0 ]

Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when
setjmp is used") disabled -Wbuiltin-requires-header because of a
warning about the setjmp and longjmp declarations.

r367387 in clang added another diagnostic around this, complaining
that there is no jmp_buf declaration.

  In file included from ../arch/powerpc/xmon/xmon.c:47:
  ../arch/powerpc/include/asm/setjmp.h:10:13: error: declaration of
  built-in function 'setjmp' requires the declaration of the 'jmp_buf'
  type, commonly provided in the header <setjmp.h>.
  [-Werror,-Wincomplete-setjmp-declaration]
  extern long setjmp(long *);
              ^
  ../arch/powerpc/include/asm/setjmp.h:11:13: error: declaration of
  built-in function 'longjmp' requires the declaration of the 'jmp_buf'
  type, commonly provided in the header <setjmp.h>.
  [-Werror,-Wincomplete-setjmp-declaration]
  extern void longjmp(long *, long);
              ^
  2 errors generated.

We are not using the standard library's longjmp/setjmp implementations
for obvious reasons; make this clear to clang by using -ffreestanding
on these files.

Cc: stable@vger.kernel.org # 4.14+
Suggested-by: Segher Boessenkool <segher@kernel.crashing.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20191119045712.39633-3-natechancellor@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoregulator: 88pm800: fix warning same module names
Anders Roxell [Wed, 12 Jun 2019 08:11:58 +0000 (10:11 +0200)]
regulator: 88pm800: fix warning same module names

[ Upstream commit 6f10419187d0d5fe395e2a2f2a64370961bf02a3 ]

When building with CONFIG_MFD_88PM800 and CONFIG_REGULATOR_88PM800
enabled as loadable modules, we see the following warning:

warning: same module names found:
  drivers/regulator/88pm800.ko
  drivers/mfd/88pm800.ko

Rework so that the file is named 88pm800-regulator.

Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoath10k: fix fw crash by moving chip reset after napi disabled
Miaoqing Pan [Fri, 24 May 2019 03:16:22 +0000 (11:16 +0800)]
ath10k: fix fw crash by moving chip reset after napi disabled

[ Upstream commit 08d80e4cd27ba19f9bee9e5f788f9a9fc440a22f ]

On SMP platform, when continuously running wifi up/down, the napi
poll can be scheduled during chip reset, which will call
ath10k_pci_has_fw_crashed() to check the fw status. But in the reset
period, the value from FW_INDICATOR_ADDRESS register will return
0xdeadbeef, which also be treated as fw crash. Fix the issue by
moving chip reset after napi disabled.

ath10k_pci 0000:01:00.0: firmware crashed! (guid 73b30611-5b1e-4bdd-90b4-64c81eb947b6)
ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
ath10k_pci 0000:01:00.0: failed to get memcpy hi address for firmware address 4: -16
ath10k_pci 0000:01:00.0: failed to read firmware dump area: -16
ath10k_pci 0000:01:00.0: Copy Engine register dump:
ath10k_pci 0000:01:00.0: [00]: 0x0004a000   0   0   0   0
ath10k_pci 0000:01:00.0: [01]: 0x0004a400   0   0   0   0
ath10k_pci 0000:01:00.0: [02]: 0x0004a800   0   0   0   0
ath10k_pci 0000:01:00.0: [03]: 0x0004ac00   0   0   0   0
ath10k_pci 0000:01:00.0: [04]: 0x0004b000   0   0   0   0
ath10k_pci 0000:01:00.0: [05]: 0x0004b400   0   0   0   0
ath10k_pci 0000:01:00.0: [06]: 0x0004b800   0   0   0   0
ath10k_pci 0000:01:00.0: [07]: 0x0004bc00   1   0   1   0
ath10k_pci 0000:01:00.0: [08]: 0x0004c000   0   0   0   0
ath10k_pci 0000:01:00.0: [09]: 0x0004c400   0   0   0   0
ath10k_pci 0000:01:00.0: [10]: 0x0004c800   0   0   0   0
ath10k_pci 0000:01:00.0: [11]: 0x0004cc00   0   0   0   0

Tested HW: QCA9984,QCA9887,WCN3990

Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agomedia: vimc: fix component match compare
Helen Koike [Fri, 17 May 2019 17:20:11 +0000 (13:20 -0400)]
media: vimc: fix component match compare

[ Upstream commit ee1c71a8e1456ab53fe667281d855849edf26a4d ]

If the system has other devices being registered in the component
framework, the compare function will be called with a device that
doesn't belong to vimc.
This device is not necessarily a platform_device, nor have a
platform_data (which causes a NULL pointer dereference error) and if it
does have a pdata, it is not necessarily type of struct vimc_platform_data.
So casting to any of these types is wrong.

Instead of expecting a given pdev with a given pdata, just expect for
the device it self. vimc-core is the one who creates them, we know in
advance exactly which object to expect in the match.

Fixes: 4a29b7090749 ("[media] vimc: Subdevices as modules")

Signed-off-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agomlxsw: spectrum_router: Refresh nexthop neighbour when it becomes dead
Ido Schimmel [Tue, 11 Jun 2019 07:19:41 +0000 (10:19 +0300)]
mlxsw: spectrum_router: Refresh nexthop neighbour when it becomes dead

[ Upstream commit 83d5782681cc12b3d485a83cb34c46b2445f510c ]

The driver tries to periodically refresh neighbours that are used to
reach nexthops. This is done by periodically calling neigh_event_send().

However, if the neighbour becomes dead, there is nothing we can do to
return it to a connected state and the above function call is basically
a NOP.

This results in the nexthop never being written to the device's
adjacency table and therefore never used to forward packets.

Fix this by dropping our reference from the dead neighbour and
associating the nexthop with a new neigbhour which we will try to
refresh.

Fixes: a7ff87acd995 ("mlxsw: spectrum_router: Implement next-hop routing")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reported-by: Alex Veber <alexve@mellanox.com>
Tested-by: Alex Veber <alexve@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agopower: supply: cpcap-battery: Fix signed counter sample register
Tony Lindgren [Sun, 7 Apr 2019 18:12:50 +0000 (11:12 -0700)]
power: supply: cpcap-battery: Fix signed counter sample register

[ Upstream commit c68b901ac4fa969db8917b6a9f9b40524a690d20 ]

The accumulator sample register is signed 32-bits wide register on
droid 4. And only the earlier version of cpcap has a signed 24-bits
wide register. We're currently passing it around as unsigned, so
let's fix that and use sign_extend32() for the earlier revision.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agox86/MCE/AMD: Carve out the MC4_MISC thresholding quirk
Shirish S [Wed, 16 Jan 2019 15:10:40 +0000 (15:10 +0000)]
x86/MCE/AMD: Carve out the MC4_MISC thresholding quirk

[ Upstream commit 30aa3d26edb0f3d7992757287eec0ca588a5c259 ]

The MC4_MISC thresholding quirk needs to be applied during S5 -> S0 and
S3 -> S0 state transitions, which follow different code paths. Carve it
out into a separate function and call it mce_amd_feature_init() where
the two code paths of the state transitions converge.

 [ bp: massage commit message and the carved out function. ]

Signed-off-by: Shirish S <shirish.s@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Yazen Ghannam <yazen.ghannam@amd.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/1547651417-23583-3-git-send-email-shirish.s@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agox86/MCE/AMD: Turn off MC4_MISC thresholding on all family 0x15 models
Shirish S [Thu, 10 Jan 2019 07:54:40 +0000 (07:54 +0000)]
x86/MCE/AMD: Turn off MC4_MISC thresholding on all family 0x15 models

[ Upstream commit c95b323dcd3598dd7ef5005d6723c1ba3b801093 ]

MC4_MISC thresholding is not supported on all family 0x15 processors,
hence skip the x86_model check when applying the quirk.

 [ bp: massage commit message. ]

Signed-off-by: Shirish S <shirish.s@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/1547106849-3476-2-git-send-email-shirish.s@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoscsi: hisi_sas: Reject setting programmed minimum linkrate > 1.5G
Luo Jiaxing [Fri, 25 Jan 2019 14:22:34 +0000 (22:22 +0800)]
scsi: hisi_sas: Reject setting programmed minimum linkrate > 1.5G

[ Upstream commit eb44e4d7b5a3090f0114927f42ae575c29664a09 ]

The SAS controller cannot support a programmed minimum linkrate of > 1.5G
(it will always negotiate to 1.5G at least), so just reject it.

This solves a strange situation where the PHY negotiated linkrate may be
less than the programmed minimum linkrate.

Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoscsi: hisi_sas: send primitive NOTIFY to SSP situation only
Xiang Chen [Fri, 25 Jan 2019 14:22:30 +0000 (22:22 +0800)]
scsi: hisi_sas: send primitive NOTIFY to SSP situation only

[ Upstream commit 569eddcf3a0f4efff4ef96a7012010e0f7daa8b4 ]

Send primitive NOTIFY to SSP situation only, or it causes underflow issue
when sending IO. Also rename hisi_sas_hw.sl_notify() to hisi_sas_hw.
sl_notify_ssp().

Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agonet: hns3: Check variable is valid before assigning it to another
Yonglong Liu [Wed, 20 Feb 2019 02:32:41 +0000 (10:32 +0800)]
net: hns3: Check variable is valid before assigning it to another

[ Upstream commit 676131f7c53ecdd79e29fc8cfcdefe6f9f2485e8 ]

In hnae3_register_ae_dev(), ae_algo->ops is assigned to ae_dev->ops
before check that ae_algo->ops is valid.

And in hnae3_register_ae_algo(), missing check for ae_algo->ops.

This patch fixes them.

Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agonet: hns3: change hnae3_register_ae_dev() to int
Huazhong Tan [Wed, 30 Jan 2019 20:55:44 +0000 (04:55 +0800)]
net: hns3: change hnae3_register_ae_dev() to int

[ Upstream commit 74354140a579008fd164241e3697d9c37e5b8989 ]

hnae3_register_ae_dev() may fail, and it should return a error code
to its caller, so change hnae3_register_ae_dev() return type to int.

Also, when hnae3_register_ae_dev() return error, hns3_probe() should
do some error handling and return the error code.

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agonet: hns3: clear pci private data when unload hns3 driver
Jian Shen [Sat, 26 Jan 2019 16:49:11 +0000 (00:49 +0800)]
net: hns3: clear pci private data when unload hns3 driver

[ Upstream commit ac864c2346d087dd3739435af1b8d36be5f60c75 ]

When unload hns3 driver, we should clear the pci private data.

Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agonet/smc: do not wait under send_lock
Karsten Graul [Wed, 30 Jan 2019 17:51:05 +0000 (18:51 +0100)]
net/smc: do not wait under send_lock

[ Upstream commit 33f3fcc290671590821ff3c0c9396db1ec9b7d4c ]

smc_cdc_get_free_slot() might wait for free transfer buffers when using
SMC-R. This wait should not be done under the send_lock, which is a
spin_lock. This fixes a cpu loop in parallel threads waiting for the
send_lock.

Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agosch_cake: Correctly update parent qlen when splitting GSO packets
Toke Høiland-Jørgensen [Wed, 9 Jan 2019 16:09:44 +0000 (17:09 +0100)]
sch_cake: Correctly update parent qlen when splitting GSO packets

[ Upstream commit 8c6c37fdc20ec9ffaa342f827a8e20afe736fb0c ]

To ensure parent qdiscs have the same notion of the number of enqueued
packets even after splitting a GSO packet, update the qdisc tree with the
number of packets that was added due to the split.

Reported-by: Pete Heist <pete@heistp.net>
Tested-by: Pete Heist <pete@heistp.net>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agopvcalls-front: don't return error when the ring is full
Stefano Stabellini [Fri, 21 Dec 2018 23:06:32 +0000 (15:06 -0800)]
pvcalls-front: don't return error when the ring is full

[ Upstream commit d90a1ca60a1eccb4383fe203c76223ab4c0799ed ]

When the ring is full, size == array_size. It is not an error condition,
so simply return 0 instead of an error.

Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoe100: Fix passing zero to 'PTR_ERR' warning in e100_load_ucode_wait
YueHaibing [Mon, 19 Nov 2018 12:48:19 +0000 (20:48 +0800)]
e100: Fix passing zero to 'PTR_ERR' warning in e100_load_ucode_wait

[ Upstream commit cd0d465bb697a9c7bf66a9fe940f7981232f1676 ]

Fix a static code checker warning:
drivers/net/ethernet/intel/e100.c:1349
 e100_load_ucode_wait() warn: passing zero to 'PTR_ERR'

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agodrbd: Change drbd_request_detach_interruptible's return type to int
Nathan Chancellor [Thu, 20 Dec 2018 16:23:44 +0000 (17:23 +0100)]
drbd: Change drbd_request_detach_interruptible's return type to int

[ Upstream commit 5816a0932b4fd74257b8cc5785bc8067186a8723 ]

Clang warns when an implicit conversion is done between enumerated
types:

drivers/block/drbd/drbd_state.c:708:8: warning: implicit conversion from
enumeration type 'enum drbd_ret_code' to different enumeration type
'enum drbd_state_rv' [-Wenum-conversion]
                rv = ERR_INTR;
                   ~ ^~~~~~~~

drbd_request_detach_interruptible's only call site is in the return
statement of adm_detach, which returns an int. Change the return type of
drbd_request_detach_interruptible to match, silencing Clang's warning.

Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoscsi: lpfc: Correct topology type reporting on G7 adapters
James Smart [Fri, 30 Nov 2018 00:09:38 +0000 (16:09 -0800)]
scsi: lpfc: Correct topology type reporting on G7 adapters

[ Upstream commit 76558b25733140a0c6bd53ea8af04b2811c92ec3 ]

Driver missed classifying the chip type for G7 when reporting supported
topologies. This resulted in loop being shown as supported on FC links that
are not supported per the standard.

Add the chip classifications to the topology checks in the driver.

Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoscsi: lpfc: Correct code setting non existent bits in sli4 ABORT WQE
James Smart [Fri, 30 Nov 2018 00:09:37 +0000 (16:09 -0800)]
scsi: lpfc: Correct code setting non existent bits in sli4 ABORT WQE

[ Upstream commit 1c36833d82ff24d0d54215fd956e7cc30fffce54 ]

Driver is setting bits in word 10 of the SLI4 ABORT WQE (the wqid).  The
field was a carry over from a prior SLI revision. The field does not exist
in SLI4, and the action may result in an overlap with future definition of
the WQE.

Remove the setting of WQID in the ABORT WQE.

Also cleaned up WQE field settings - initialize to zero, don't bother to
set fields to zero.

Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoscsi: lpfc: Cap NPIV vports to 256
James Smart [Fri, 30 Nov 2018 00:09:33 +0000 (16:09 -0800)]
scsi: lpfc: Cap NPIV vports to 256

[ Upstream commit 8b47ae69e049ae0b3373859d901f0334322f9fe9 ]

Depending on the chipset, the number of NPIV vports may vary and be in
excess of what most switches support (256). To avoid confusion with the
users, limit the reported NPIV vports to 256.

Additionally correct the 16G adapter which is reporting a bogus NPIV vport
number if the link is down.

Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
16 months agoomap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251
H. Nikolaus Schaller [Thu, 7 Nov 2019 10:30:39 +0000 (11:30 +0100)]
omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251

[ Upstream commit 2398c41d64321e62af54424fd399964f3d48cdc2 ]

With a wl1251 child node of mmc3 in the device tree decoded
in omap_hsmmc.c to handle special wl1251 initialization, we do
no longer need to instantiate the mmc3 through pdata quirks.

We also can remove the wlan regulator and reset/interrupt definitions
and do them through device tree.

Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel")
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Cc: <stable@vger.kernel.org> # v4.7+
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>