linux-toradex.git/arch/arm, branch v4.20-rc6

Merge branch 'spectre' of git://git.armlinux.org.uk/~rmk/linux-arm

2018-12-07T00:45:36+00:00

Pull ARM spectre fix from Russell King:
 "Exynos folk noticed that CPU hotplug wasn't working with their kernel
  configuration, and have tested this as fixing the problem"

* 'spectre' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: ensure that processor vtables is not lost after boot

Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm

2018-12-07T00:39:44+00:00

Pull ARM fixes from Russell King:
 "Some small fixes that have been accumulated:

   - Chris Cole noticed that in a SMP environment, the DMA cache
     coherence handling can produce undesirable results in a corner
     case

   - Propagate that fix for ARMv7M as well

   - Fix a false positive with source fortification

   - Fix an uninitialised return that Nathan Jones spotted"

* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 8816/1: dma-mapping: fix potential uninitialized return
  ARM: 8815/1: V7M: align v7m_dma_inv_range() with v7 counterpart
  ARM: 8814/1: mm: improve/fix ARM v7_dma_inv_range() unaligned address handling
  ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE

ARM: ensure that processor vtables is not lost after boot

2018-12-06T16:42:05+00:00

Marek Szyprowski reported problems with CPU hotplug in current kernels.
This was tracked down to the processor vtables being located in an
init section, and therefore discarded after kernel boot, despite being
required after boot to properly initialise the non-boot CPUs.

Arrange for these tables to end up in .rodata when required.

Reported-by: Marek Szyprowski 
Tested-by: Krzysztof Kozlowski 
Fixes: 383fb3ee8024 ("ARM: spectre-v2: per-CPU vtables to work around big.Little systems")
Signed-off-by: Russell King

ARM: 8816/1: dma-mapping: fix potential uninitialized return

2018-12-04T22:38:34+00:00

While trying to use the dma_mmap_*() interface, it was noticed that this
interface returns strange values when passed an incorrect length.

If neither of the if() statements fire then the return value is
uninitialized. In the worst case it returns 0 which means the caller
will think the function succeeded.

Fixes: 1655cf8829d8 ("ARM: dma-mapping: Remove traces of NOMMU code")
Signed-off-by: Nathan Jones 
Reviewed-by: Robin Murphy 
Acked-by: Vladimir Murzin 
Signed-off-by: Russell King

ARM: 8815/1: V7M: align v7m_dma_inv_range() with v7 counterpart

2018-12-04T22:38:33+00:00

Chris has discovered and reported that v7_dma_inv_range() may corrupt
memory if address range is not aligned to cache line size.

Since the whole cache-v7m.S was lifted form cache-v7.S the same
observation applies to v7m_dma_inv_range(). So the fix just mirrors
what has been done for v7 with a little specific of M-class.

Cc: Chris Cole 
Signed-off-by: Vladimir Murzin 
Signed-off-by: Russell King

ARM: 8814/1: mm: improve/fix ARM v7_dma_inv_range() unaligned address handling

2018-12-04T22:38:32+00:00

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: Chris Cole 
Signed-off-by: Russell King

Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

2018-12-02T20:19:44+00:00

Pull ARM SoC fixes from Olof Johansson:
 "Volume is a little higher than usual due to a set of gpio fixes for
  Davinci platforms that's been around a while, still seemed appropriate
  to not hold off until next merge window.

  Besides that it's the usual mix of minor fixes, mostly corrections of
  small stuff in device trees.

  Major stability-related one is the removal of a regulator from DT on
  Rock960, since DVFS caused undervoltage. I expect it'll be restored
  once they figure out the underlying issue"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (28 commits)
  MAINTAINERS: Remove unused Qualcomm SoC mailing list
  ARM: davinci: dm644x: set the GPIO base to 0
  ARM: davinci: da830: set the GPIO base to 0
  ARM: davinci: dm355: set the GPIO base to 0
  ARM: davinci: dm646x: set the GPIO base to 0
  ARM: davinci: dm365: set the GPIO base to 0
  ARM: davinci: da850: set the GPIO base to 0
  gpio: davinci: restore a way to manually specify the GPIO base
  ARM: davinci: dm644x: define gpio interrupts as separate resources
  ARM: davinci: dm355: define gpio interrupts as separate resources
  ARM: davinci: dm646x: define gpio interrupts as separate resources
  ARM: davinci: dm365: define gpio interrupts as separate resources
  ARM: davinci: da8xx: define gpio interrupts as separate resources
  ARM: dts: at91: sama5d2: use the divided clock for SMC
  ARM: dts: imx51-zii-rdu1: Remove EEPROM node
  ARM: dts: rockchip: Remove @0 from the veyron memory node
  arm64: dts: rockchip: Fix PCIe reset polarity for rk3399-puma-haikou.
  arm64: dts: qcom: msm8998: Reserve gpio ranges on MTP
  arm64: dts: sdm845-mtp: Reserve reserved gpios
  arm64: dts: ti: k3-am654: Fix wakeup_uart reg address
  ...

Merge tag 'imx-fixes-4.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes

2018-11-30T19:57:53+00:00

i.MX fixes for 4.20, round 2:
 - Reomve non-existing EEPROM device from imx51-zii-rdu1 board.
   It was added by mistake.

* tag 'imx-fixes-4.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  ARM: dts: imx51-zii-rdu1: Remove EEPROM node

Signed-off-by: Olof Johansson

Merge tag 'omap-for-v4.20/fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

2018-11-30T19:56:50+00:00

Few minor fixes for omaps for v4.20-rc cycle

This set of fixes contains minor regression fixes for LogicPD dts files
for MMC pinctrl and interrupts. There is also one section annotation fix
that shows up with Clang, and a fix for an unitialized field for omap1.

* tag 'omap-for-v4.20/fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP1: ams-delta: Fix possible use of uninitialized field
  ARM: dts: am3517-som: Fix WL127x Wifi interrupt
  ARM: dts: logicpd-somlv: Fix interrupt on mmc3_dat1
  ARM: dts: LogicPD Torpedo: Fix mmc3_dat1 interrupt
  ARM: dts: am3517: Fix pinmuxing for CD on MMC1
  ARM: OMAP2+: prm44xx: Fix section annotation on omap44xx_prm_enable_io_wakeup

Signed-off-by: Olof Johansson

Merge tag 'davinci-fixes-for-v4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into fixes

2018-11-30T19:54:31+00:00

DaVinci: fix GPIO breakage after v4.19

This set of changes is needed to fix the broken GPIO support
for DaVinci boards in legacy mode after certain changes made to the
GPIO driver in 4.19, namely: commits 587f7a694f01 ("gpio: davinci: Use
dev name for label and automatic base selection") and eb3744a2dd01
("gpio: davinci: Do not assume continuous IRQ numbering").

* tag 'davinci-fixes-for-v4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
  ARM: davinci: dm644x: set the GPIO base to 0
  ARM: davinci: da830: set the GPIO base to 0
  ARM: davinci: dm355: set the GPIO base to 0
  ARM: davinci: dm646x: set the GPIO base to 0
  ARM: davinci: dm365: set the GPIO base to 0
  ARM: davinci: da850: set the GPIO base to 0
  gpio: davinci: restore a way to manually specify the GPIO base
  ARM: davinci: dm644x: define gpio interrupts as separate resources
  ARM: davinci: dm355: define gpio interrupts as separate resources
  ARM: davinci: dm646x: define gpio interrupts as separate resources
  ARM: davinci: dm365: define gpio interrupts as separate resources
  ARM: davinci: da8xx: define gpio interrupts as separate resources

Signed-off-by: Olof Johansson