Skip to content

L
linux
Switch branch/tag
  1. 10 Nov, 2016 27 commits
  3. 31 Oct, 2016 13 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.8.6 · 5d506f21
      Greg Kroah-Hartman authored
      5d506f21
    • Vishal Verma's avatar
      libnvdimm: clear the internal poison_list when clearing badblocks · 13c06fcc
      Vishal Verma authored 
      commit e046114a upstream.

nvdimm_clear_poison cleared the user-visible badblocks, and sent
commands to the NVDIMM to clear the areas marked as 'poison', but it
neglected to clear the same areas from the internal poison_list which is
used to marshal ARS results before sorting them by namespace. As a
result, once on-demand ARS functionality was added:

37b137ff nfit, libnvdimm: allow an ARS scrub to be triggered on demand

A scrub triggered from either sysfs or an MCE was found to be adding
stale entries that had been cleared from gendisk->badblocks, but were
still present in nvdimm_bus->poison_list. Additionally, the stale entries
could be triggered into producing stale disk->badblocks by simply disabling
and re-enabling the namespace or region.

This adds the missing step of clearing poison_list entries when clearing
poison, so that it is always in sync with badblocks.

Fixes: 37b137ff ("nfit, libnvdimm: allow an ARS scrub to be triggered on demand")
Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13c06fcc
    • Lorenzo Pieralisi's avatar
      PCI: tegra: Fix pci_remap_iospace() failure path · 10a12e89
      Lorenzo Pieralisi authored 
      commit 13f392eb upstream.

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI tegra host bridge driver adds the PCI IO resource retrieved from
firmware to the host bridge resource windows even if the
pci_remap_iospace() call fails; this is an actual bug in that the PCI host
bridge would consider the PCI IO resource valid (and possibly assign it to
downstream devices) even if the kernel was not able to map the PCI host
bridge memory address driving IO cycle to the CPU virtual address space (ie
pci_remap_iospace() failures).

Add the PCI host bridge driver pci_remap_iospace() failure path and do not
add the corresponding PCI host bridge PCI IO resources retrieved through
firmware when the pci_remap_iospace() function call fails, fixing the
issue.

Fixes: e6e9f471 ("PCI: tegra: Use generic pci_remap_iospace() rather than ARM32-specific one")
Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
CC: Thierry Reding <treding@nvidia.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10a12e89
    • Lorenzo Pieralisi's avatar
      PCI: designware: Fix pci_remap_iospace() failure path · 12d904f4
      Lorenzo Pieralisi authored 
      commit bcd7b718 upstream.

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI designware host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).

Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.

Fixes: cbce7900 ("PCI: designware: Make driver arch-agnostic")
Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
CC: Jingoo Han <jingoohan1@gmail.com>
CC: Pratyush Anand <pratyush.anand@gmail.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12d904f4
    • Lorenzo Pieralisi's avatar
      PCI: versatile: Fix pci_remap_iospace() failure path · 9a7f38f1
      Lorenzo Pieralisi authored 
      commit 53f4f7ee upstream.

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI versatile host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).

Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.

Fixes: b7e78170 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host driver")
Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
CC: Rob Herring <robh@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9a7f38f1
    • Lorenzo Pieralisi's avatar
      PCI: generic: Fix pci_remap_iospace() failure path · 57ac6016
      Lorenzo Pieralisi authored 
      commit 43281ede upstream.

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI common host bridge driver does not remove the PCI IO resource from
the host bridge resource windows if the pci_remap_iospace() call fails;
this is an actual bug in that the PCI host bridge would consider the PCI IO
resource valid (and possibly assign it to downstream devices) even if the
kernel was not able to map the PCI host bridge memory address driving IO
cycle to the CPU virtual address space (ie pci_remap_iospace() failures).

Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.

Fixes: 4e64dbe2 ("PCI: generic: Expose pci_host_common_probe() for use by other drivers")
Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
Acked-by: default avatarWill Deacon <will.deacon@arm.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      57ac6016
    • Lorenzo Pieralisi's avatar
      PCI: aardvark: Fix pci_remap_iospace() failure path · fb98cd86
      Lorenzo Pieralisi authored 
      commit db047f8a upstream.

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridge's memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI aardvark host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).

Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.

Fixes: 8c39d710 ("PCI: aardvark: Add Aardvark PCI host controller driver")
Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb98cd86
    • Lorenzo Pieralisi's avatar
      PCI: rcar: Fix pci_remap_iospace() failure path · c76bf06c
      Lorenzo Pieralisi authored 
      commit 5e8c8732 upstream.

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI rcar host bridge driver does not remove the PCI IO resource from
the host bridge resource windows if the pci_remap_iospace() call fails;
this is an actual bug in that the PCI host bridge would consider the PCI IO
resource valid (and possibly assign it to downstream devices) even if the
kernel was not able to map the PCI host bridge memory address driving IO
cycle to the CPU virtual address space (ie pci_remap_iospace() failures).

Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.

Fixes: 5d2917d4 ("PCI: rcar: Convert to DT resource parsing API")
Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
CC: Phil Edworthy <phil.edworthy@renesas.com>
CC: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c76bf06c
    • Javier Martinez Canillas's avatar
      ARM: dts: omap3: overo: add missing unit name for lcd35 display · 847fd175
      Javier Martinez Canillas authored 
      commit 0b965a13 upstream.

Commit b8d368ca ("ARM: dts: omap3: overo: remove unneded unit names
in display nodes") removed the unit names for all Overo display nodes
that didn't have a reg property.

But the display in arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi does
have a reg property so the correct fix was to make the unit name match
the value of the reg property, instead of removing it.

This patch fixes the following DTC warning for boards using this dtsi:

"ocp/spi@48098000/display has a reg or ranges property, but no unit name"

Fixes: b8d368ca ("ARM: dts: omap3: overo: remove unneded unit names in display nodes")
Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      847fd175
    • Linus Walleij's avatar
      ARM: dts: fix RealView EB SMSC ethernet version · 45de0cf9
      Linus Walleij authored 
      commit c4ad7256 upstream.

The ethernet version in the earlier RealView EB variants is
LAN91C111 and not LAN9118 according to ARM DUI 0303E
"RealView Emulation Baseboard User Guide" page 3-57.

Make sure that this is used for the base variant of the board.

As the DT bindings for LAN91C111 does not specify any power
supplies, these need to be deleted from the DTS file.

Fixes: 2440d29d ("ARM: dts: realview: support all the RealView EB board variants")
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      45de0cf9
    • Jon Mason's avatar
      ARM: dts: NSP: Correct RAM amount for BCM958625HR board · e566ea9a
      Jon Mason authored 
      commit c53beb47 upstream.

The BCM958625HR board has 2GB of RAM available.  Increase the amount
from 512MB to 2GB and add the device type to the memory entry.

Fixes: 9a4865d4 ("ARM: dts: NSP: Specify RAM amount for BCM958625HR board")
Signed-off-by: default avatarJon Mason <jon.mason@broadcom.com>
Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e566ea9a
    • Robert Jarzmik's avatar
      ARM: pxa: fix GPIO double shifts · 96e4f098
      Robert Jarzmik authored 
      commit ca26475b upstream.

The commit 9bf448c6 ("ARM: pxa: use generic gpio operation instead of
gpio register") from Oct 17, 2011, leads to the following static checker
warning:
  arch/arm/mach-pxa/spitz_pm.c:172 spitz_charger_wakeup()
  warn: double left shift '!gpio_get_value(SPITZ_GPIO_KEY_INT)
        << (1 << ((SPITZ_GPIO_KEY_INT) & 31))'

As Dan reported, the value is shifted three times :
 - once by gpio_get_value(), which returns either 0 or BIT(gpio)
 - once by the shift operation '<<'
 - a last time by GPIO_bit(gpio) which is BIT(gpio)

Therefore the calculation lead to a chained or operator of :
 - (1 << gpio) << (1 << gpio) = (2^gpio)^gpio = 2 ^ (gpio * gpio)

It is be sheer luck the former statement works, only because each gpio
used is strictly smaller than 6, and therefore 2^(gpio^2) never
overflows a 32 bits value, and because it is used as a boolean value to
check a gpio activation.

As the xxx_charger_wakeup() functions are used as a true/false detection
mechanism, take that opportunity to change their prototypes from integer
return value to boolean one.

Fixes: 9bf448c6 ("ARM: pxa: use generic gpio operation instead of
gpio register")
Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96e4f098
    • Robert Jarzmik's avatar
      ARM: pxa: pxa_cplds: fix interrupt handling · d685eefb
      Robert Jarzmik authored 
      commit 9ba63e3c upstream.

Since its initial commit, the driver is buggy for multiple interrupts
handling. The translation from the former lubbock.c file was not
complete, and might stall all interrupt handling when multiple
interrupts occur.

This is especially true when inside the interrupt handler and if a new
interrupt comes and is not handled, leaving the output line still held,
and not creating a transition as the GPIO block behind would expect to
trigger another cplds_irq_handler() call.

For the record, the hardware is working as follows.

The interrupt mechanism relies on :
 - one status register
 - one mask register

Let's suppose the input irq lines are called :
 - i_sa1111
 - i_lan91x
 - i_mmc_cd
Let's suppose the status register for each irq line is called :
 - status_sa1111
 - status_lan91x
 - status_mmc_cd
Let's suppose the interrupt mask for each irq line is called :
 - irqen_sa1111
 - irqen_lan91x
 - irqen_mmc_cd
Let's suppose the output irq line, connected to GPIO0 is called :
 - o_gpio0

The behavior is as follows :
 - o_gpio0 = not((status_sa1111 & irqen_sa1111) |
		 (status_lan91x & irqen_lan91x) |
		 (status_mmc_cd & irqen_mmc_cd))
   => this is a N-to-1 NOR gate and multiple AND gates
 - irqen_* is exactly as programmed by a write to the FPGA
 - status_* behavior is governed by a bi-stable D flip-flop
   => on next FPGA clock :
     - if i_xxx is high, status_xxx becomes 1
     - if i_xxx is low, status_xxx remains as it is
     - if software sets status_xxx to 0, the D flip-flop is reset
       => status_xxx becomes 0
       => on next FPGA clock cycle, if i_xxx is high, status_xxx becomes
	  1 again

Fixes: fc9e38c0 ("ARM: pxa: lubbock: use new pxa_cplds driver")
Reported-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d685eefb
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7