1. 07 Oct, 2019 1 commit
    • Will Deacon's avatar
      ARM: 8898/1: mm: Don't treat faults reported from cache maintenance as writes · 6a684e00
      Will Deacon authored
      [ Upstream commit 83402036
      
       ]
      
      Translation faults arising from cache maintenance instructions are
      rather unhelpfully reported with an FSR value where the WnR field is set
      to 1, indicating that the faulting access was a write. Since cache
      maintenance instructions on 32-bit ARM do not require any particular
      permissions, this can cause our private 'cacheflush' system call to fail
      spuriously if a translation fault is generated due to page aging when
      targetting a read-only VMA.
      
      In this situation, we will return -EFAULT to userspace, although this is
      unfortunately suppressed by the popular '__builtin___clear_cache()'
      intrinsic provided by GCC, which returns void.
      
      Although it's tempting to write this off as a userspace issue, we can
      actually do a little bit better on CPUs that support LPAE, even if the
      short-descriptor format is in use. On these CPUs, cache maintenance
      faults additionally set the CM field in the FSR, which we can use to
      suppress the write permission checks in the page fault handler and
      succeed in performing cache maintenance to read-only areas even in the
      presence of a translation fault.
      Reported-by: default avatarOrion Hodson <oth@google.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6a684e00
  2. 05 Oct, 2019 5 commits
    • Luis Araneda's avatar
      ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up · 881edc16
      Luis Araneda authored
      commit b7005d4e upstream.
      
      This fixes a kernel panic on memcpy when
      FORTIFY_SOURCE is enabled.
      
      The initial smp implementation on commit aa7eb2bb
      ("arm: zynq: Add smp support")
      used memcpy, which worked fine until commit ee333554
      ("ARM: 8749/1: Kconfig: Add ARCH_HAS_FORTIFY_SOURCE")
      enabled overflow checks at runtime, producing a read
      overflow panic.
      
      The computed size of memcpy args are:
      - p_size (dst): 4294967295 = (size_t) -1
      - q_size (src): 1
      - size (len): 8
      
      Additionally, the memory is marked as __iomem, so one of
      the memcpy_* functions should be used for read/write.
      
      Fixes: aa7eb2bb
      
       ("arm: zynq: Add smp support")
      Signed-off-by: default avatarLuis Araneda <luaraneda@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichal Simek <michal.simek@xilinx.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      881edc16
    • Lihua Yao's avatar
      ARM: samsung: Fix system restart on S3C6410 · 22092794
      Lihua Yao authored
      commit 16986074 upstream.
      
      S3C6410 system restart is triggered by watchdog reset.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 9f55342c
      
       ("ARM: dts: s3c64xx: Fix infinite interrupt in soft mode")
      Signed-off-by: default avatarLihua Yao <ylhuajnu@outlook.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22092794
    • Marek Szyprowski's avatar
      ARM: dts: exynos: Mark LDO10 as always-on on Peach Pit/Pi Chromebooks · 6fceb241
      Marek Szyprowski authored
      [ Upstream commit 5b0eeeaa ]
      
      Commit aff138bf ("ARM: dts: exynos: Add TMU nodes regulator supply
      for Peach boards") assigned LDO10 to Exynos Thermal Measurement Unit,
      but it turned out that it supplies also some other critical parts and
      board freezes/crashes when it is turned off.
      
      The mentioned commit made Exynos TMU a consumer of that regulator and in
      typical case Exynos TMU driver keeps it enabled from early boot. However
      there are such configurations (example is multi_v7_defconfig), in which
      some of the regulators are compiled as modules and are not available
      from early boot. In such case it may happen that LDO10 is turned off by
      regulator core, because it has no consumers yet (in this case consumer
      drivers cannot get it, because the supply regulators for it are not yet
      available). This in turn causes the board to crash. This patch restores
      'always-on' property for the LDO10 regulator.
      
      Fixes: aff138bf
      
       ("ARM: dts: exynos: Add TMU nodes regulator supply for Peach boards")
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6fceb241
    • Stefan Agner's avatar
      ARM: dts: imx7-colibri: disable HS400 · dfaf6058
      Stefan Agner authored
      [ Upstream commit a95fbda0
      
       ]
      
      Force HS200 by masking bit 63 of the SDHCI capability register.
      The i.MX ESDHC driver uses SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400. With
      that the stack checks bit 63 to descide whether HS400 is available.
      Using sdhci-caps-mask allows to mask bit 63. The stack then selects
      HS200 as operating mode.
      
      This prevents rare communication errors with minimal effect on
      performance:
      	sdhci-esdhc-imx 30b60000.usdhc: warning! HS400 strobe DLL
      		status REF not lock!
      Signed-off-by: default avatarStefan Agner <stefan.agner@toradex.com>
      Signed-off-by: default avatarPhilippe Schenker <philippe.schenker@toradex.com>
      Reviewed-by: default avatarOleksandr Suvorov <oleksandr.suvorov@toradex.com>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dfaf6058
    • André Draszik's avatar
      ARM: dts: imx7d: cl-som-imx7: make ethernet work again · c20ee5d9
      André Draszik authored
      [ Upstream commit 9846a452 ]
      
      Recent changes to the atheros at803x driver caused
      ethernet to stop working on this board.
      In particular commit 6d4cd041
      ("net: phy: at803x: disable delay only for RGMII mode")
      and commit cd28d1d6
      
      
      ("net: phy: at803x: Disable phy delay for RGMII mode")
      fix the AR8031 driver to configure the phy's (RX/TX)
      delays as per the 'phy-mode' in the device tree.
      
      This now prevents ethernet from working on this board.
      
      It used to work before those commits, because the
      AR8031 comes out of reset with RX delay enabled, and
      the at803x driver didn't touch the delay configuration
      at all when "rgmii" mode was selected, and because
      arch/arm/mach-imx/mach-imx7d.c:ar8031_phy_fixup()
      unconditionally enables TX delay.
      
      Since above commits ar8031_phy_fixup() also has no
      effect anymore, and the end-result is that all delays
      are disabled in the phy, no ethernet.
      
      Update the device tree to restore functionality.
      Signed-off-by: default avatarAndré Draszik <git@andred.net>
      CC: Ilya Ledvich <ilya@compulab.co.il>
      CC: Igor Grinberg <grinberg@compulab.co.il>
      CC: Rob Herring <robh+dt@kernel.org>
      CC: Mark Rutland <mark.rutland@arm.com>
      CC: Shawn Guo <shawnguo@kernel.org>
      CC: Sascha Hauer <s.hauer@pengutronix.de>
      CC: Pengutronix Kernel Team <kernel@pengutronix.de>
      CC: Fabio Estevam <festevam@gmail.com>
      CC: NXP Linux Team <linux-imx@nxp.com>
      CC: devicetree@vger.kernel.org
      CC: linux-arm-kernel@lists.infradead.org
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c20ee5d9
  3. 21 Sep, 2019 7 commits
  4. 16 Sep, 2019 9 commits
  5. 29 Aug, 2019 1 commit
    • Marc Zyngier's avatar
      KVM: arm: Don't write junk to CP15 registers on reset · ef61b790
      Marc Zyngier authored
      [ Upstream commit c69509c7
      
       ]
      
      At the moment, the way we reset CP15 registers is mildly insane:
      We write junk to them, call the reset functions, and then check that
      we have something else in them.
      
      The "fun" thing is that this can happen while the guest is running
      (PSCI, for example). If anything in KVM has to evaluate the state
      of a CP15 register while junk is in there, bad thing may happen.
      
      Let's stop doing that. Instead, we track that we have called a
      reset function for that register, and assume that the reset
      function has done something.
      
      In the end, the very need of this reset check is pretty dubious,
      as it doesn't check everything (a lot of the CP15 reg leave outside
      of the cp15_regs[] array). It may well be axed in the near future.
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ef61b790
  6. 16 Aug, 2019 2 commits
  7. 06 Aug, 2019 4 commits
    • Douglas Anderson's avatar
      ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend · ea26b427
      Douglas Anderson authored
      [ Upstream commit 8ef1ba39 ]
      
      This is similar to commit e6186820
      
       ("arm64: dts: rockchip: Arch
      counter doesn't tick in system suspend").  Specifically on the rk3288
      it can be seen that the timer stops ticking in suspend if we end up
      running through the "osc_disable" path in rk3288_slp_mode_set().  In
      that path the 24 MHz clock will turn off and the timer stops.
      
      To test this, I ran this on a Chrome OS filesystem:
        before=$(date); \
        suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \
        echo ${before}; date
      
      ...and I found that unless I plug in a device that requests USB wakeup
      to be active that the two calls to "date" would show that fewer than
      30 seconds passed.
      
      NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't
      supported yet on upstream Linux so this was tested on a downstream
      kernel.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ea26b427
    • Douglas Anderson's avatar
      ARM: dts: rockchip: Make rk3288-veyron-mickey's emmc work again · 22befe67
      Douglas Anderson authored
      [ Upstream commit 99fa0667
      
       ]
      
      When I try to boot rk3288-veyron-mickey I totally fail to make the
      eMMC work.  Specifically my logs (on Chrome OS 4.19):
      
        mmc_host mmc1: card is non-removable.
        mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
        mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
        mmc1: switch to bus width 8 failed
        mmc1: switch to bus width 4 failed
        mmc1: new high speed MMC card at address 0001
        mmcblk1: mmc1:0001 HAG2e 14.7 GiB
        mmcblk1boot0: mmc1:0001 HAG2e partition 1 4.00 MiB
        mmcblk1boot1: mmc1:0001 HAG2e partition 2 4.00 MiB
        mmcblk1rpmb: mmc1:0001 HAG2e partition 3 4.00 MiB, chardev (243:0)
        mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
        mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
        mmc1: switch to bus width 8 failed
        mmc1: switch to bus width 4 failed
        mmc1: tried to HW reset card, got error -110
        mmcblk1: error -110 requesting status
        mmcblk1: recovery failed!
        print_req_error: I/O error, dev mmcblk1, sector 0
        ...
      
      When I remove the '/delete-property/mmc-hs200-1_8v' then everything is
      hunky dory.
      
      That line comes from the original submission of the mickey dts
      upstream, so presumably at the time the HS200 was failing and just
      enumerating things as a high speed device was fine.  ...or maybe it's
      just that some mickey devices work when enumerating at "high speed",
      just not mine?
      
      In any case, hs200 seems good now.  Let's turn it on.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      22befe67
    • Douglas Anderson's avatar
      ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200 · 8c5a33d3
      Douglas Anderson authored
      [ Upstream commit 1c047902 ]
      
      As some point hs200 was failing on rk3288-veyron-minnie.  See commit
      98492678 ("ARM: dts: rockchip: temporarily remove emmc hs200 speed
      from rk3288 minnie").  Although I didn't track down exactly when it
      started working, it seems to work OK now, so let's turn it back on.
      
      To test this, I booted from SD card and then used this script to
      stress the enumeration process after fixing a memory leak [1]:
        cd /sys/bus/platform/drivers/dwmmc_rockchip
        for i in $(seq 1 3000); do
          echo "========================" $i
          echo ff0f0000.dwmmc > unbind
          sleep .5
          echo ff0f0000.dwmmc > bind
          while true; do
            if [ -e /dev/mmcblk2 ]; then
              break;
            fi
            sleep .1
          done
        done
      
      It worked fine.
      
      [1] https://lkml.kernel.org/r/20190503233526.226272-1-dianders@chromium.org
      
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8c5a33d3
    • Russell King's avatar
      ARM: riscpc: fix DMA · 3c1d1bad
      Russell King authored
      [ Upstream commit ffd9a1ba ]
      
      DMA got broken a while back in two different ways:
      1) a change in the behaviour of disable_irq() to wait for the interrupt
         to finish executing causes us to deadlock at the end of DMA.
      2) a change to avoid modifying the scatterlist left the first transfer
         uninitialised.
      
      DMA is only used with expansion cards, so has gone unnoticed.
      
      Fixes: fa4e9989
      
       ("[ARM] dma: RiscPC: don't modify DMA SG entries")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3c1d1bad
  8. 21 Jul, 2019 3 commits
  9. 14 Jul, 2019 3 commits
    • Bartosz Golaszewski's avatar
      ARM: davinci: da8xx: specify dma_coherent_mask for lcdc · 9c2dd6d4
      Bartosz Golaszewski authored
      [ Upstream commit 68f2515b ]
      
      The lcdc device is missing the dma_coherent_mask definition causing the
      following warning on da850-evm:
      
      da8xx_lcdc da8xx_lcdc.0: found Sharp_LK043T1DG01 panel
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1 at kernel/dma/mapping.c:247 dma_alloc_attrs+0xc8/0x110
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper Not tainted 5.2.0-rc3-00077-g16d72dd4
      
       #18
      Hardware name: DaVinci DA850/OMAP-L138/AM18x EVM
      [<c000fce8>] (unwind_backtrace) from [<c000d900>] (show_stack+0x10/0x14)
      [<c000d900>] (show_stack) from [<c001a4f8>] (__warn+0xec/0x114)
      [<c001a4f8>] (__warn) from [<c001a634>] (warn_slowpath_null+0x3c/0x48)
      [<c001a634>] (warn_slowpath_null) from [<c0065860>] (dma_alloc_attrs+0xc8/0x110)
      [<c0065860>] (dma_alloc_attrs) from [<c02820f8>] (fb_probe+0x228/0x5a8)
      [<c02820f8>] (fb_probe) from [<c02d3e9c>] (platform_drv_probe+0x48/0x9c)
      [<c02d3e9c>] (platform_drv_probe) from [<c02d221c>] (really_probe+0x1d8/0x2d4)
      [<c02d221c>] (really_probe) from [<c02d2474>] (driver_probe_device+0x5c/0x168)
      [<c02d2474>] (driver_probe_device) from [<c02d2728>] (device_driver_attach+0x58/0x60)
      [<c02d2728>] (device_driver_attach) from [<c02d27b0>] (__driver_attach+0x80/0xbc)
      [<c02d27b0>] (__driver_attach) from [<c02d047c>] (bus_for_each_dev+0x64/0xb4)
      [<c02d047c>] (bus_for_each_dev) from [<c02d1590>] (bus_add_driver+0xe4/0x1d8)
      [<c02d1590>] (bus_add_driver) from [<c02d301c>] (driver_register+0x78/0x10c)
      [<c02d301c>] (driver_register) from [<c000a5c0>] (do_one_initcall+0x48/0x1bc)
      [<c000a5c0>] (do_one_initcall) from [<c05cae6c>] (kernel_init_freeable+0x10c/0x1d8)
      [<c05cae6c>] (kernel_init_freeable) from [<c048a000>] (kernel_init+0x8/0xf4)
      [<c048a000>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34)
      Exception stack(0xc6837fb0 to 0xc6837ff8)
      7fa0:                                     00000000 00000000 00000000 00000000
      7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      7fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      ---[ end trace 8a8073511be81dd2 ]---
      
      Add a 32-bit mask to the platform device's definition.
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9c2dd6d4
    • Bartosz Golaszewski's avatar
      ARM: davinci: da850-evm: call regulator_has_full_constraints() · 3bbcc8b9
      Bartosz Golaszewski authored
      [ Upstream commit 0c0c9b57
      
       ]
      
      The BB expander at 0x21 i2c bus 1 fails to probe on da850-evm because
      the board doesn't set has_full_constraints to true in the regulator
      API.
      
      Call regulator_has_full_constraints() at the end of board registration
      just like we do in da850-lcdk and da830-evm.
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3bbcc8b9
    • Teresa Remmet's avatar
      ARM: dts: am335x phytec boards: Fix cd-gpios active level · e71daed5
      Teresa Remmet authored
      [ Upstream commit 8a0098c0
      
       ]
      
      Active level of the mmc1 cd gpio needs to be low instead of high.
      Fix PCM-953 and phyBOARD-WEGA.
      Signed-off-by: default avatarTeresa Remmet <t.remmet@phytec.de>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e71daed5
  10. 10 Jul, 2019 1 commit
  11. 25 Jun, 2019 3 commits
  12. 19 Jun, 2019 1 commit