1. 20 Feb, 2019 10 commits
    • Nicholas Mc Guire's avatar
      gpio: pl061: handle failed allocations · 83476701
      Nicholas Mc Guire authored
      [ Upstream commit df209c43a0e8258e096fb722dfbdae4f0dd13fde ]
      
      devm_kzalloc(), devm_kstrdup() and devm_kasprintf() all can
      fail internal allocation and return NULL. Using any of the assigned
      objects without checking is not safe. As this is early in the boot
      phase and these allocations really should not fail, any failure here
      is probably an indication of a more serious issue so it makes little
      sense to try and rollback the previous allocated resources or try to
      continue;  but rather the probe function is simply exited with -ENOMEM.
      Signed-off-by: default avatarNicholas Mc Guire <hofrat@osadl.org>
      Fixes: 684284b6 ("ARM: integrator: add MMCI device to IM-PD1")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      83476701
    • Linus Walleij's avatar
      ARM: dts: kirkwood: Fix polarity of GPIO fan lines · 32f04710
      Linus Walleij authored
      [ Upstream commit b5f034845e70916fd33e172fad5ad530a29c10ab ]
      
      These two lines are active high, not active low. The bug was
      found when we changed the kernel to respect the polarity defined
      in the device tree.
      
      Fixes: 1b90e06b ("ARM: kirkwood: Use devicetree to define DNS-32[05] fan")
      Cc: Jamie Lentin <jm@lentin.co.uk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@bootlin.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Julien D'Ascenzio <jdascenzio@posteo.net>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Tested-by: default avatarJamie Lentin <jm@lentin.co.uk>
      Reported-by: default avatarJulien D'Ascenzio <jdascenzio@posteo.net>
      Tested-by: default avatarJulien D'Ascenzio <jdascenzio@posteo.net>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      32f04710
    • Peter Ujfalusi's avatar
      ARM: dts: da850-evm: Correct the sound card name · 20ad5046
      Peter Ujfalusi authored
      [ Upstream commit 7fca69d4e43fa1ae9cb4f652772c132dc5a659c6 ]
      
      To avoid  the following error:
      asoc-simple-card sound: ASoC: Failed to create card debugfs directory
      
      Which is because the card name contains '/' character, which can not be
      used in file or directory names.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      20ad5046
    • Russell King's avatar
      ARM: iop32x/n2100: fix PCI IRQ mapping · fd9d0553
      Russell King authored
      commit db4090920ba2d61a5827a23e441447926a02ffee upstream.
      
      Booting 4.20 on a TheCUS N2100 results in a kernel oops while probing
      PCI, due to n2100_pci_map_irq() having been discarded during boot.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Cc: stable@vger.kernel.org # 2.6.18+
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd9d0553
    • Mark Rutland's avatar
      arm64: KVM: Skip MMIO insn after emulation · fac39ee2
      Mark Rutland authored
      [ Upstream commit 0d640732dbebed0f10f18526de21652931f0b2f2 ]
      
      When we emulate an MMIO instruction, we advance the CPU state within
      decode_hsr(), before emulating the instruction effects.
      
      Having this logic in decode_hsr() is opaque, and advancing the state
      before emulation is problematic. It gets in the way of applying
      consistent single-step logic, and it prevents us from being able to fail
      an MMIO instruction with a synchronous exception.
      
      Clean this up by only advancing the CPU state *after* the effects of the
      instruction are emulated.
      
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fac39ee2
    • Arnd Bergmann's avatar
      ARM: pxa: avoid section mismatch warning · b9037406
      Arnd Bergmann authored
      [ Upstream commit 88af3209aa0881aa5ffd99664b6080a4be5f24e5 ]
      
      WARNING: vmlinux.o(.text+0x19f90): Section mismatch in reference from the function littleton_init_lcd() to the function .init.text:pxa_set_fb_info()
      The function littleton_init_lcd() references
      the function __init pxa_set_fb_info().
      This is often because littleton_init_lcd lacks a __init
      annotation or the annotation of pxa_set_fb_info is wrong.
      
      WARNING: vmlinux.o(.text+0xf824): Section mismatch in reference from the function zeus_register_ohci() to the function .init.text:pxa_set_ohci_info()
      The function zeus_register_ohci() references
      the function __init pxa_set_ohci_info().
      This is often because zeus_register_ohci lacks a __init
      annotation or the annotation of pxa_set_ohci_info is wrong.
      
      WARNING: vmlinux.o(.text+0xf95c): Section mismatch in reference from the function cm_x300_init_u2d() to the function .init.text:pxa3xx_set_u2d_info()
      The function cm_x300_init_u2d() references
      the function __init pxa3xx_set_u2d_info().
      This is often because cm_x300_init_u2d lacks a __init
      annotation or the annotation of pxa3xx_set_u2d_info is wrong.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b9037406
    • Russell King - ARM Linux's avatar
      ARM: dts: Fix OMAP4430 SDP Ethernet startup · 54b53c59
      Russell King - ARM Linux authored
      [ Upstream commit 84fb6c7feb1494ebb7d1ec8b95cfb7ada0264465 ]
      
      It was noticed that unbinding and rebinding the KSZ8851 ethernet
      resulted in the driver reporting "failed to read device ID" at probe.
      Probing the reset line with a 'scope while repeatedly attempting to
      bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
      constantly held at zero, meaning the device is held in reset, and
      does not respond on the SPI bus.
      
      Experimentation with the startup delay on the regulator set to 50ms
      shows that the reset is positively released after 20ms.
      
      Schematics for this board are not available, and the traces are buried
      in the inner layers of the board which makes tracing where the RSTN pin
      extremely difficult.  We can only guess that the RSTN pin is wired to a
      reset generator chip driven off the ethernet supply, which fits the
      observed behaviour.
      
      Include this delay in the regulator startup delay - effectively
      treating the reset as a "supply stable" indicator.
      
      This can not be modelled as a delay in the KSZ8851 driver since the
      reset generation is board specific - if the RSTN pin had been wired to
      a GPIO, reset could be released earlier via the already provided support
      in the KSZ8851 driver.
      
      This also got confirmed by Peter Ujfalusi <peter.ujfalusi@ti.com> based
      on Blaze schematics that should be very close to SDP4430:
      
      TPS22902YFPR is used as the regulator switch (gpio48 controlled):
      Convert arm boot_lock to raw The VOUT is routed to TPS3808G01DBV.
      (SCH Note: Threshold set at 90%. Vsense: 0.405V).
      
      According to the TPS3808 data sheet the RESET delay time when Ct is
      open (this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      [tony@atomide.com: updated with notes from schematics from Peter]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      54b53c59
    • Lubomir Rintel's avatar
      ARM: dts: mmp2: fix TWSI2 · 75086100
      Lubomir Rintel authored
      [ Upstream commit 1147e05ac9fc2ef86a3691e7ca5c2db7602d81dd ]
      
      Marvell keeps their MMP2 datasheet secret, but there are good clues
      that TWSI2 is not on 0xd4025000 on that platform, not does it use
      IRQ 58. In fact, the IRQ 58 on MMP2 seems to be a signal processor:
      
         arch/arm/mach-mmp/irqs.h:#define IRQ_MMP2_MSP  58
      
      I'm taking a somewhat educated guess that is probably a copy & paste
      error from PXA168 or PXA910 and that the real controller in fact hides
      at address 0xd4031000 and uses an interrupt line multiplexed via IRQ 17.
      
      I'm also copying some properties from TWSI1 that were missing or
      incorrect.
      
      Tested on a OLPC XO 1.75 machine, where the RTC is on TWSI2.
      Signed-off-by: default avatarLubomir Rintel <lkundrak@v3.sk>
      Tested-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      75086100
    • Nathan Chancellor's avatar
      ARM: OMAP2+: hwmod: Fix some section annotations · c34330e1
      Nathan Chancellor authored
      [ Upstream commit c10b26abeb53cabc1e6271a167d3f3d396ce0218 ]
      
      When building the kernel with Clang, the following section mismatch
      warnings appears:
      
      WARNING: vmlinux.o(.text+0x2d398): Section mismatch in reference from
      the function _setup() to the function .init.text:_setup_iclk_autoidle()
      The function _setup() references
      the function __init _setup_iclk_autoidle().
      This is often because _setup lacks a __init
      annotation or the annotation of _setup_iclk_autoidle is wrong.
      
      WARNING: vmlinux.o(.text+0x2d3a0): Section mismatch in reference from
      the function _setup() to the function .init.text:_setup_reset()
      The function _setup() references
      the function __init _setup_reset().
      This is often because _setup lacks a __init
      annotation or the annotation of _setup_reset is wrong.
      
      WARNING: vmlinux.o(.text+0x2d408): Section mismatch in reference from
      the function _setup() to the function .init.text:_setup_postsetup()
      The function _setup() references
      the function __init _setup_postsetup().
      This is often because _setup lacks a __init
      annotation or the annotation of _setup_postsetup is wrong.
      
      _setup is used in omap_hwmod_allocate_module, which isn't marked __init
      and looks like it shouldn't be, meaning to fix these warnings, those
      functions must be moved out of the init section, which this patch does.
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c34330e1
    • Yufen Wang's avatar
      ARM: 8808/1: kexec:offline panic_smp_self_stop CPU · aeef84f3
      Yufen Wang authored
      [ Upstream commit 82c08c3e7f171aa7f579b231d0abbc1d62e91974 ]
      
      In case panic() and panic() called at the same time on different CPUS.
      For example:
      CPU 0:
        panic()
           __crash_kexec
             machine_crash_shutdown
               crash_smp_send_stop
             machine_kexec
               BUG_ON(num_online_cpus() > 1);
      
      CPU 1:
        panic()
          local_irq_disable
          panic_smp_self_stop
      
      If CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop(), kdump
      fails. CPU1 can't receive the ipi irq, CPU1 will be always online.
      To fix this problem, this patch split out the panic_smp_self_stop()
      and add set_cpu_online(smp_processor_id(), false).
      Signed-off-by: default avatarYufen Wang <wangyufen@huawei.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      aeef84f3
  2. 06 Feb, 2019 1 commit
    • Koen Vandeputte's avatar
      ARM: cns3xxx: Fix writing to wrong PCI config registers after alignment · 1472585f
      Koen Vandeputte authored
      commit 65dbb423cf28232fed1732b779249d6164c5999b upstream.
      
      Originally, cns3xxx used its own functions for mapping, reading and
      writing config registers.
      
      Commit 802b7c06 ("ARM: cns3xxx: Convert PCI to use generic config
      accessors") removed the internal PCI config write function in favor of
      the generic one:
      
        cns3xxx_pci_write_config() --> pci_generic_config_write()
      
      cns3xxx_pci_write_config() expected aligned addresses, being produced by
      cns3xxx_pci_map_bus() while the generic one pci_generic_config_write()
      actually expects the real address as both the function and hardware are
      capable of byte-aligned writes.
      
      This currently leads to pci_generic_config_write() writing to the wrong
      registers.
      
      For instance, upon ath9k module loading:
      
      - driver ath9k gets loaded
      - The driver wants to write value 0xA8 to register PCI_LATENCY_TIMER,
        located at 0x0D
      - cns3xxx_pci_map_bus() aligns the address to 0x0C
      - pci_generic_config_write() effectively writes 0xA8 into register 0x0C
        (CACHE_LINE_SIZE)
      
      Fix the bug by removing the alignment in the cns3xxx mapping function.
      
      Fixes: 802b7c06 ("ARM: cns3xxx: Convert PCI to use generic config accessors")
      Signed-off-by: default avatarKoen Vandeputte <koen.vandeputte@ncentric.com>
      [lorenzo.pieralisi@arm.com: updated commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarKrzysztof Halasa <khalasa@piap.pl>
      Acked-by: default avatarTim Harvey <tharvey@gateworks.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      CC: stable@vger.kernel.org	# v4.0+
      CC: Bjorn Helgaas <bhelgaas@google.com>
      CC: Olof Johansson <olof@lixom.net>
      CC: Robin Leblon <robin.leblon@ncentric.com>
      CC: Rob Herring <robh@kernel.org>
      CC: Russell King <linux@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1472585f
  3. 13 Jan, 2019 1 commit
  4. 21 Dec, 2018 1 commit
    • Chris Cole's avatar
      ARM: 8814/1: mm: improve/fix ARM v7_dma_inv_range() unaligned address handling · fa5d9b58
      Chris Cole authored
      [ Upstream commit a1208f6a822ac29933e772ef1f637c5d67838da9 ]
      
      This patch addresses possible memory corruption when
      v7_dma_inv_range(start_address, end_address) address parameters are not
      aligned to whole cache lines. This function issues "invalidate" cache
      management operations to all cache lines from start_address (inclusive)
      to end_address (exclusive). When start_address and/or end_address are
      not aligned, the start and/or end cache lines are first issued "clean &
      invalidate" operation. The assumption is this is done to ensure that any
      dirty data addresses outside the address range (but part of the first or
      last cache lines) are cleaned/flushed so that data is not lost, which
      could happen if just an invalidate is issued.
      
      The problem is that these first/last partial cache lines are issued
      "clean & invalidate" and then "invalidate". This second "invalidate" is
      not required and worse can cause "lost" writes to addresses outside the
      address range but part of the cache line. If another component writes to
      its part of the cache line between the "clean & invalidate" and
      "invalidate" operations, the write can get lost. This fix is to remove
      the extra "invalidate" operation when unaligned addressed are used.
      
      A kernel module is available that has a stress test to reproduce the
      issue and a unit test of the updated v7_dma_inv_range(). It can be
      downloaded from
      http://ftp.sageembedded.com/outgoing/linux/cache-test-20181107.tgz.
      
      v7_dma_inv_range() is call by dmac_[un]map_area(addr, len, direction)
      when the direction is DMA_FROM_DEVICE. One can (I believe) successfully
      argue that DMA from a device to main memory should use buffers aligned
      to cache line size, because the "clean & invalidate" might overwrite
      data that the device just wrote using DMA. But if a driver does use
      unaligned buffers, at least this fix will prevent memory corruption
      outside the buffer.
      Signed-off-by: default avatarChris Cole <chris@sageembedded.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fa5d9b58
  5. 17 Dec, 2018 2 commits
  6. 27 Nov, 2018 1 commit
  7. 10 Nov, 2018 3 commits
  8. 20 Oct, 2018 1 commit
  9. 10 Oct, 2018 2 commits
  10. 26 Sep, 2018 4 commits
  11. 15 Sep, 2018 2 commits
  12. 09 Sep, 2018 1 commit
    • Jon Hunter's avatar
      ARM: tegra: Fix Tegra30 Cardhu PCA954x reset · 2f04971a
      Jon Hunter authored
      commit 6e1811900b6fe6f2b4665dba6bd6ed32c6b98575 upstream.
      
      On all versions of Tegra30 Cardhu, the reset signal to the NXP PCA9546
      I2C mux is connected to the Tegra GPIO BB0. Currently, this pin on the
      Tegra is not configured as a GPIO but as a special-function IO (SFIO)
      that is multiplexing the pin to an I2S controller. On exiting system
      suspend, I2C commands sent to the PCA9546 are failing because there is
      no ACK. Although it is not possible to see exactly what is happening
      to the reset during suspend, by ensuring it is configured as a GPIO
      and driven high, to de-assert the reset, the failures are no longer
      seen.
      
      Please note that this GPIO is also used to drive the reset signal
      going to the camera connector on the board. However, given that there
      is no camera support currently for Cardhu, this should not have any
      impact.
      
      Fixes: 40431d16 ("ARM: tegra: enable PCA9546 on Cardhu")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f04971a
  13. 05 Sep, 2018 2 commits
  14. 24 Aug, 2018 8 commits
  15. 15 Aug, 2018 1 commit