Skip to content
  1. Dec 12, 2015
  3. Dec 11, 2015
    • Catalin Marinas's avatar
      arm64: Improve error reporting on set_pte_at() checks · 82d34008
      Catalin Marinas authored 
      

Currently the BUG_ON() checks do not give enough information about the
PTEs being set. This patch changes BUG_ON to WARN_ONCE and dumps the
values of the old and new PTEs. In addition, the checks are only made if
the new PTE entry is valid.

Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
Reported-by: default avatarMing Lei <tom.leiming@gmail.com>
Cc: Will Deacon <will.deacon@arm.com>
      82d34008
    • Stefan Agner's avatar
      ARM: dts: vf610: use reset values for L2 cache latencies · 9c171905
      Stefan Agner authored 
      Linux on Vybrid used several different L2 latencies so far, none
of them seem to be the right ones. According to the application note
AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
on CPU clock and is inside the L2 cache controller, whereas the data
portion is stored in the external SRAM running on platform clock.
Hence it is likely that the correct value requires a higher data
latency then tag latency.

These are the values which have been used so far:
- The mainline values:
  arm,data-latency = <1 1 1>;
  arm,tag-latency = <2 2 2>;
  Those values have lead to problems on higher clocks. They look
  like a poor translation from the reset values (missing +1 offset
  and a mix up between tag/latency values).
- The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
  arm,data-latency = <4 2 3>
  arm,tag-latency = <4 2 3>
  The cache initialization function along with the value matches the
  i.MX6 code from the same kernel, so it seems that those values have
  just been copied.
- The Colibri values:
  arm,data-latency = <2 1 2>;
  arm,tag-latency = <3 2 3>;
  Those were a mix between the values of the Linux 3.0 based BSP and
  the mainline values above.
- The SoC Reset values (converted to DT notation):
  arm,data-latency = <3 3 3>;
  arm,tag-latency = <2 2 2>;

So far there is no official statement on what the correct values are.
See also the related Freescale community thread:
https://community.freescale.com/message/579785#579785



For now, the reset values seem to be the best bet. Remove all other
"bogus" values and use the reset value on vf610.dtsi level.

Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      9c171905
  5. Dec 10, 2015
  7. Dec 09, 2015
    • Andrew Donnellan's avatar
      Revert "powerpc/eeh: Don't unfreeze PHB PE after reset" · dc9c41bd
      Andrew Donnellan authored 
      

This reverts commit 527d10ef.

The reverted commit breaks cxlflash devices following an EEH reset (and
possibly other cxl devices, however this has not been tested).

The reverted commit changed the behaviour of eeh_reset_device() so that PHB
PEs are not unfrozen following the completion of the reset. This should not
be problematic, as no device resources should have been associated with the
PHB PE.

However, when attempting to load the cxlflash driver after a reset, the
driver attempts to read Vital Product Data through a call to
pci_read_vpd() (which is called on the physical cxl device, not on the
virtual AFU device). pci_read_vpd() in turn attempts to read from the cxl
device's config space. This fails, as the PE it's trying to read from is
still frozen. In turn, the driver gets an -ENODEV and fails to initialise.

It appears this issue only affects some parts of the VPD area, as "lspci
-vvv", which only reads a subset of the VPD bytes, is not broken by the
original patch.

At this stage, we don't fully understand why we're trying to read a frozen
PE, and we don't know how this affects other cxl devices. It is possible
that there is an underlying bug in the cxl driver or the powerpc CAPI
support code, or alternatively a bug in the PCI resource allocation/mapping
code that is incorrectly mapping resources to PE#0.

As such, this fix is incomplete, however it is necessary to prevent a
serious regression in CAPI support.

In the meantime, revert the commit, especially as it was intended to be a
non-functional change.

Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: Ian Munsie <imunsie@au1.ibm.com>
Cc: Daniel Axtens <dja@axtens.net>
Signed-off-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      dc9c41bd
    • Paul Gortmaker's avatar
      powerpc/sbc8641: drop bogus PHY IRQ entries from DTS file · 5b01310c
      Paul Gortmaker authored 
      

This file was originally cloned off of the MPC8641D-HPCN reference
platform, which actually had a PHY IRQ line connected. However this
board does not. The bogus entry was largely inert and went undetected
until commit 321beec5 ("net: phy: Use
interrupts when available in NOLINK state") was added to the tree.

With the above commit, the board fails to NFS boot since it sits waiting
for a PHY IRQ event that of course never arrives. Removing the bogus
entries from the DTS file fixes the issue.

Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      5b01310c
  9. Dec 08, 2015
    • Geyslan G. Bem's avatar
      um: fix returns without va_end · 887a9853
      Geyslan G. Bem authored 
      

When using va_list ensure that va_start will be followed by va_end.

Signed-off-by: default avatarGeyslan G. Bem <geyslan@gmail.com>
Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      887a9853
    • Richard Weinberger's avatar
      um: Fix fpstate handling · 8090bfd2
      Richard Weinberger authored 
      

The x86 FPU cleanup changed fpstate to a plain integer.
UML on x86 has to deal with that too.

Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      8090bfd2
    • Lorenzo Colitti's avatar
      arch: um: fix error when linking vmlinux. · fb1770aa
      Lorenzo Colitti authored 
      

On gcc Ubuntu 4.8.4-2ubuntu1~14.04, linking vmlinux fails with:

arch/um/os-Linux/built-in.o: In function `os_timer_create':
/android/kernel/android/arch/um/os-Linux/time.c:51: undefined reference to `timer_create'
arch/um/os-Linux/built-in.o: In function `os_timer_set_interval':
/android/kernel/android/arch/um/os-Linux/time.c:84: undefined reference to `timer_settime'
arch/um/os-Linux/built-in.o: In function `os_timer_remain':
/android/kernel/android/arch/um/os-Linux/time.c:109: undefined reference to `timer_gettime'
arch/um/os-Linux/built-in.o: In function `os_timer_one_shot':
/android/kernel/android/arch/um/os-Linux/time.c:132: undefined reference to `timer_settime'
arch/um/os-Linux/built-in.o: In function `os_timer_disable':
/android/kernel/android/arch/um/os-Linux/time.c:145: undefined reference to `timer_settime'

This is because -lrt appears in the generated link commandline
after arch/um/os-Linux/built-in.o. Fix this by removing -lrt from
arch/um/Makefile and adding it to the UM-specific section of
scripts/link-vmlinux.sh.

Signed-off-by: default avatarLorenzo Colitti <lorenzo@google.com>
Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      fb1770aa
    • Richard Weinberger's avatar
      um: Fix get_signal() usage · db2f24dc
      Richard Weinberger authored 
      

If get_signal() returns us a signal to post
we must not call it again, otherwise the already
posted signal will be overridden.
Before commit a610d6e6 this was the case as we stopped
the while after a successful handle_signal().

Cc: <stable@vger.kernel.org> # 3.10-
Fixes: a610d6e6 ("pull clearing RESTORE_SIGMASK into block_sigmask()")
Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      db2f24dc
    • Alistair Popple's avatar
      powerpc/opal-irqchip: Fix double endian conversion · 25642e14
      Alistair Popple authored 
      

The OPAL event calls return a mask of events that are active in big
endian format. This is checked when unmasking the events in the
irqchip by comparison with a cached value. The cached value was stored
in big endian format but should've been converted to CPU endian
first.

This bug leads to OPAL event delivery being delayed or dropped on some
systems. Symptoms may include a non-functional console.

The bug is fixed by calling opal_handle_events(...) instead of
duplicating code in opal_event_unmask(...).

Fixes: 9f0fd049 ("powerpc/powernv: Add a virtual irqchip for opal events")
Cc: stable@vger.kernel.org # v4.2+
Reported-by: default avatarDouglas L Lehr <dllehr@us.ibm.com>
Signed-off-by: default avatarAlistair Popple <alistair@popple.id.au>
Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      25642e14
  11. Dec 07, 2015
  13. Dec 06, 2015
  15. Dec 05, 2015
  17. Dec 04, 2015
  19. Dec 03, 2015
  21. Dec 02, 2015
    • Stefan Agner's avatar
      ARM: dts: vf610: fix clock definition for SAI2 · 531ee1f4
      Stefan Agner authored 
      

So far, only the bus clock has been assigned, but in reality the
SAI IP has for clock inputs. The driver has been updated to
make use of the additional clock inputs by c3ecef21 ("ASoC:
fsl_sai: add sai master mode support"). Due to a bug in the
clock tree, the audio clock has been enabled none the less by
the specified bus clock (see "ARM: imx: clk-vf610: fix SAI
clock tree"), which made master mode even without the proper
clock assigned working.

This patch completes the clock definition for SAI2. On Vybrid,
only two MCLK out of the four options are available (the first
being the bus clock itself). See chapter 8.10.1.2.3 of the
Vybrid Reference manual ("SAI transmitter and receiver options
for MCLK selection"). Note: The audio clocks are only required
in master mode.

Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      531ee1f4
    • Liu Jiang's avatar
      x86/PCI/ACPI: Fix regression caused by commit 4d6b4e69 · 727ae8be
      Liu Jiang authored 
      

Commit 4d6b4e69 ("x86/PCI/ACPI: Use common interface to support
PCI host bridge") converted x86 to use the common interface
acpi_pci_root_create, but the conversion missed on code piece in
arch/x86/pci/bus_numa.c, which causes regression on some legacy
AMD platforms as reported by Arthur Marsh <arthur.marsh@internode.on.net>.
The root causes is that acpi_pci_root_create() fails to insert
host bridge resources into iomem_resource/ioport_resource because
x86_pci_root_bus_resources() has already inserted those resources.
So change x86_pci_root_bus_resources() to not insert resources into
iomem_resource/ioport_resource.

Fixes: 4d6b4e69 ("x86/PCI/ACPI: Use common interface to support PCI host bridge")
Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
Reported-and-tested-by: default avatarArthur Marsh <arthur.marsh@internode.on.net>
Reported-and-tested-by: default avatarKrzysztof Kolasa <kkolasa@winsoft.pl>
Reported-and-tested-by: default avatarKeith Busch <keith.busch@intel.com>
Reported-and-tested-by: default avatarHans de Bruin <jmdebruin@xmsnet.nl>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      727ae8be
  23. Dec 01, 2015
    • Arnd Bergmann's avatar
      ARM: ixp4xx: fix read{b,w,l} return types · d66e5139
      Arnd Bergmann authored 
      

On ixp4xx, the readl() function returns an 'unsigned long' output
when indirect I/O is used. This is unlike any other platform, and
it causes lots of harmless compiler warnings, such as:

drivers/ata/libahci.c: In function 'ahci_show_host_version':
drivers/ata/libahci.c:254:22: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
drivers/block/mtip32xx/mtip32xx.c: In function 'mtip_hw_read_registers':
drivers/block/mtip32xx/mtip32xx.c:2602:31: warning: format '%X' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
drivers/block/cciss.c: In function 'print_cfg_table':
drivers/block/cciss.c:3845:25: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]

This changes all six of the ixp4xx specific I/O read functions
to return the same types that we have in the normal asm/io.h,
to avoid the warnings.

Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Acked-by: default avatarKrzysztof Halasa <khalasa@piap.pl>
      d66e5139
  25. Nov 30, 2015