<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/arm/mm, branch linux-3.17.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.17.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.17.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2014-12-06T23:57:29Z</updated>
<entry>
<title>ARM: 8222/1: mvebu: enable strex backoff delay</title>
<updated>2014-12-06T23:57:29Z</updated>
<author>
<name>Thomas Petazzoni</name>
</author>
<published>2014-11-25T17:43:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=856b4c2a8dd01ed8bc9386555d5c14ab50983e14'/>
<id>urn:sha1:856b4c2a8dd01ed8bc9386555d5c14ab50983e14</id>
<content type='text'>
commit 995ab5189d1d7264e79e665dfa032a19b3ac646e upstream.

Under extremely rare conditions, in an MPCore node consisting of at
least 3 CPUs, two CPUs trying to perform a STREX to data on the same
shared cache line can enter a livelock situation.

This patch enables the HW mechanism that overcomes the bug. This fixes
the incorrect setup of the STREX backoff delay bit due to a wrong
description in the specification.

Note that enabling the STREX backoff delay mechanism is done by
leaving the bit *cleared*, while the bit was currently being set by
the proc-v7.S code.

[Thomas: adapt to latest mainline, slightly reword the commit log, add
stable markers.]

Fixes: de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines")

Signed-off-by: Nadav Haklai &lt;nadavh@marvell.com&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Acked-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: 8216/1: xscale: correct auxiliary register in suspend/resume</title>
<updated>2014-12-06T23:57:29Z</updated>
<author>
<name>Dmitry Eremin-Solenikov</name>
</author>
<published>2014-11-21T14:29:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3f5a994f524d36475501ed3f78b101983a4779e9'/>
<id>urn:sha1:3f5a994f524d36475501ed3f78b101983a4779e9</id>
<content type='text'>
commit ef59a20ba375aeb97b3150a118318884743452a8 upstream.

According to the manuals I have, XScale auxiliary register should be
reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init
correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and
cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to
also use c1, c0, 1.

The issue was primarily noticed thanks to qemu reporing "unsupported
instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255
XScale Core manuals and in PXA270 and PXA320 Developers Guides.

Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board.

Tested-by: Robert Jarzmik &lt;robert.jarzmik@free.fr&gt;
Signed-off-by: Dmitry Eremin-Solenikov &lt;dbaryshkov@gmail.com&gt;
Acked-by: Robert Jarzmik &lt;robert.jarzmik@free.fr&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: 8198/1: make kuser helpers depend on MMU</title>
<updated>2014-11-21T17:23:11Z</updated>
<author>
<name>Nathan Lynch</name>
</author>
<published>2014-11-10T22:46:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=49b6d80d46d366346c86e00745aaf79ec3685f28'/>
<id>urn:sha1:49b6d80d46d366346c86e00745aaf79ec3685f28</id>
<content type='text'>
commit 08b964ff3c51b10aaf2e6ba639f40054c09f0f7a upstream.

The kuser helpers page is not set up on non-MMU systems, so it does
not make sense to allow CONFIG_KUSER_HELPERS to be enabled when
CONFIG_MMU=n.  Allowing it to be set on !MMU results in an oops in
set_tls (used in execve and the arm_syscall trap handler):

Unhandled exception: IPSR = 00000005 LR = fffffff1
CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc1-00041-ga30465a #216
task: 8b838000 ti: 8b82a000 task.ti: 8b82a000
PC is at flush_thread+0x32/0x40
LR is at flush_thread+0x21/0x40
pc : [&lt;8f00157a&gt;]    lr : [&lt;8f001569&gt;]    psr: 4100000b
sp : 8b82be20  ip : 00000000  fp : 8b83c000
r10: 00000001  r9 : 88018c84  r8 : 8bb85000
r7 : 8b838000  r6 : 00000000  r5 : 8bb77400  r4 : 8b82a000
r3 : ffff0ff0  r2 : 8b82a000  r1 : 00000000  r0 : 88020354
xPSR: 4100000b
CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc1-00041-ga30465a #216
[&lt;8f002bc1&gt;] (unwind_backtrace) from [&lt;8f002033&gt;] (show_stack+0xb/0xc)
[&lt;8f002033&gt;] (show_stack) from [&lt;8f00265b&gt;] (__invalid_entry+0x4b/0x4c)

As best I can tell this issue existed for the set_tls ARM syscall
before commit fbfb872f5f41 "ARM: 8148/1: flush TLS and thumbee
register state during exec" consolidated the TLS manipulation code
into the set_tls helper function, but now that we're using it to flush
register state during execve, !MMU users encounter the oops at the
first exec.

Prevent CONFIG_MMU=n configurations from enabling
CONFIG_KUSER_HELPERS.

Fixes: fbfb872f5f41 (ARM: 8148/1: flush TLS and thumbee register state during exec)

Signed-off-by: Nathan Lynch &lt;nathan_lynch@mentor.com&gt;
Reported-by: Stefan Agner &lt;stefan@agner.ch&gt;
Acked-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: 8165/1: alignment: don't break misaligned NEON load/store</title>
<updated>2014-09-25T14:32:57Z</updated>
<author>
<name>Robin Murphy</name>
</author>
<published>2014-09-25T10:56:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5ca918e5e3f9df4634077c06585c42bc6a8d699a'/>
<id>urn:sha1:5ca918e5e3f9df4634077c06585c42bc6a8d699a</id>
<content type='text'>
The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn
instructions (where the optional alignment hint is given but incorrect)
as LDR/STR, leading to register corruption. Detect these and correctly
treat them as unhandled, so that userspace gets the fault it expects.

Reported-by: Simon Hosie &lt;simon.hosie@arm.com&gt;
Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 8164/1: mm: clear SCTLR.HA instead of setting it for LPAE</title>
<updated>2014-09-25T14:32:57Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2014-09-25T10:39:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2c553ac19e73235b61b67fdc5c14be9913a2758d'/>
<id>urn:sha1:2c553ac19e73235b61b67fdc5c14be9913a2758d</id>
<content type='text'>
SCTLR.HA (hardware access flag) is deprecated and not actually
implemented by any CPUs. Furthermore, it can confuse cr_alignment checks
where the whole value of SCTLR is compared against the value sitting in
the hardware, since the bit is actually RAZ/WI and will not match the
saved cr_alignment value.

Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 8132/1: LPAE: drop wrong carry flag correction after adding TTBR1_OFFSET</title>
<updated>2014-09-02T19:55:23Z</updated>
<author>
<name>Konstantin Khlebnikov</name>
</author>
<published>2014-08-28T11:49:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7e66cbc93f876e24c2f8434cf011b94be242005e'/>
<id>urn:sha1:7e66cbc93f876e24c2f8434cf011b94be242005e</id>
<content type='text'>
ARM: LPAE: drop wrong carry flag correction after adding TTBR1_OFFSET

In commit 7fb00c2fca4b6c58be521eb3676cf4b4ba8dde3b ("ARM: 8114/1: LPAE:
load upper bits of early TTBR0/TTBR1") part which fixes carrying in adding
TTBR1_OFFSET to TTRR1 was wrong:

        addls   ttbr1, ttbr1, #TTBR1_OFFSET
        adcls   tmp, tmp, #0

addls doesn't update flags, adcls adds carry from cmp above:

        cmp     ttbr1, tmp                    @ PHYS_OFFSET &gt; PAGE_OFFSET?

Condition 'ls' means carry flag is clear or zero flag is set, thus only one
case is affected: when PHYS_OFFSET == PAGE_OFFSET.

It seems safer to remove this fixup. Bug is here for ages and nobody
complained. Let's fix it separately.

Reported-and-Tested-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;

Signed-off-by: Konstantin Khlebnikov &lt;k.khlebnikov@samsung.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 8128/1: abort: don't clear the exclusive monitors</title>
<updated>2014-08-27T14:40:12Z</updated>
<author>
<name>Mark Rutland</name>
</author>
<published>2014-08-15T11:11:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=85868313177700d20644263a782351262d2aff84'/>
<id>urn:sha1:85868313177700d20644263a782351262d2aff84</id>
<content type='text'>
The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors
upon entry to the kernel, but this is redundant:

  - We clear the monitors on every exception return since commit
    200b812d0084 ("Clear the exclusive monitor when returning from an
    exception"), so this is not necessary to ensure the monitors are
    cleared before returning from a fault handler.

  - Any dummy STREX will target a temporary scratch area in memory, and
    may succeed or fail without corrupting useful data. Its status value
    will not be used.

  - Any other STREX in the kernel must be preceded by an LDREX, which
    will initialise the monitors consistently and will not depend on the
    earlier state of the monitors.

Therefore we have no reason to care about the initial state of the
exclusive monitors when a data abort is taken, and clearing the monitors
prior to exception return (as we already do) is sufficient.

This patch removes the redundant clearing of the exclusive monitors from
the early abort handlers.

Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 8114/1: LPAE: load upper bits of early TTBR0/TTBR1</title>
<updated>2014-08-09T07:42:12Z</updated>
<author>
<name>Konstantin Khlebnikov</name>
</author>
<published>2014-07-25T08:16:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7fb00c2fca4b6c58be521eb3676cf4b4ba8dde3b'/>
<id>urn:sha1:7fb00c2fca4b6c58be521eb3676cf4b4ba8dde3b</id>
<content type='text'>
This patch fixes booting when idmap pgd lays above 4gb. Commit
4756dcbfd37 mostly had fixed this, but it'd failed to load upper bits.

Also this fixes adding TTBR1_OFFSET to TTRR1: if lower part overflows
carry flag must be added to the upper part.

Signed-off-by: Konstantin Khlebnikov &lt;k.khlebnikov@samsung.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>Merge tag 'soc-for-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc</title>
<updated>2014-08-08T18:14:29Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2014-08-08T18:14:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b3345d7c57d70e6cb6749af25cdbe80515582e99'/>
<id>urn:sha1:b3345d7c57d70e6cb6749af25cdbe80515582e99</id>
<content type='text'>
Pull ARM SoC platform changes from Olof Johansson:
 "This is the bulk of new SoC enablement and other platform changes for
  3.17:

   - Samsung S5PV210 has been converted to DT and multiplatform
   - Clock drivers and bindings for some of the lower-end i.MX 1/2
     platforms
   - Kirkwood, one of the popular Marvell platforms, is folded into the
     mvebu platform code, removing mach-kirkwood
   - Hwmod data for TI AM43xx and DRA7 platforms
   - More additions of Renesas shmobile platform support
   - Removal of plat-samsung contents that can be removed with S5PV210
     being multiplatform/DT-enabled and the other two old platforms
     being removed

  New platforms (most with only basic support right now):

   - Hisilicon X5HD2 settop box chipset is introduced
   - Mediatek MT6589 (mobile chipset) is introduced
   - Broadcom BCM7xxx settop box chipset is introduced

  + as usual a lot other pieces all over the platform code"

* tag 'soc-for-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (240 commits)
  ARM: hisi: remove smp from machine descriptor
  power: reset: move hisilicon reboot code
  ARM: dts: Add hix5hd2-dkb dts file.
  ARM: debug: Rename Hi3716 to HIX5HD2
  ARM: hisi: enable hix5hd2 SoC
  ARM: hisi: add ARCH_HISI
  MAINTAINERS: add entry for Broadcom ARM STB architecture
  ARM: brcmstb: select GISB arbiter and interrupt drivers
  ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
  ARM: configs: enable SMP in bcm_defconfig
  ARM: add SMP support for Broadcom mobile SoCs
  Documentation: arm: misc updates to Marvell EBU SoC status
  Documentation: arm: add URLs to public datasheets for the Marvell Armada XP SoC
  ARM: mvebu: fix build without platforms selected
  ARM: mvebu: add cpuidle support for Armada 38x
  ARM: mvebu: add cpuidle support for Armada 370
  cpuidle: mvebu: add Armada 38x support
  cpuidle: mvebu: add Armada 370 support
  cpuidle: mvebu: rename the driver from armada-370-xp to mvebu-v7
  ARM: mvebu: export the SCU address
  ...
</content>
</entry>
<entry>
<title>CMA: generalize CMA reserved area management functionality</title>
<updated>2014-08-07T01:01:16Z</updated>
<author>
<name>Joonsoo Kim</name>
</author>
<published>2014-08-06T23:05:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a254129e8686bff7a340b58f35241b04927e81c0'/>
<id>urn:sha1:a254129e8686bff7a340b58f35241b04927e81c0</id>
<content type='text'>
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the KVM on powerpc.  They have their own code
to manage CMA reserved area even if they looks really similar.  From my
guess, it is caused by some needs on bitmap management.  KVM side wants
to maintain bitmap not for 1 page, but for more size.  Eventually it use
bitmap where one bit represents 64 pages.

When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me.  I want to change
this situation and reduce future code management overhead through this
patch.

This change could also help developer who want to use CMA in their new
feature development, since they can use CMA easily without copying &amp;
pasting this reserved area management code.

In previous patches, we have prepared some features to generalize CMA
reserved area management and now it's time to do it.  This patch moves
core functions to mm/cma.c and change DMA APIs to use these functions.

There is no functional change in DMA APIs.

Signed-off-by: Joonsoo Kim &lt;iamjoonsoo.kim@lge.com&gt;
Acked-by: Michal Nazarewicz &lt;mina86@mina86.com&gt;
Acked-by: Zhang Yanfei &lt;zhangyanfei@cn.fujitsu.com&gt;
Acked-by: Minchan Kim &lt;minchan@kernel.org&gt;
Reviewed-by: Aneesh Kumar K.V &lt;aneesh.kumar@linux.vnet.ibm.com&gt;
Cc: Alexander Graf &lt;agraf@suse.de&gt;
Cc: Aneesh Kumar K.V &lt;aneesh.kumar@linux.vnet.ibm.com&gt;
Cc: Gleb Natapov &lt;gleb@kernel.org&gt;
Acked-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Tested-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
