<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/arm/kernel/process.c, branch v4.1.20</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Merge branches 'misc', 'vdso' and 'fixes' into for-next</title>
<updated>2015-04-14T21:28:25+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2015-04-14T21:28:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c848791f0336914a3081ea3fe029cf177d81de81'/>
<id>c848791f0336914a3081ea3fe029cf177d81de81</id>
<content type='text'>
Conflicts:
	arch/arm/mm/proc-macros.S
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	arch/arm/mm/proc-macros.S
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: move reboot code to arch/arm/kernel/reboot.c</title>
<updated>2015-04-02T08:50:45+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2015-04-01T16:02:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=045ab94e10ee17038066d71abc8fdce719ab56f9'/>
<id>045ab94e10ee17038066d71abc8fdce719ab56f9</id>
<content type='text'>
Move shutdown and reboot related code to a separate file, out of
process.c.  This helps to avoid polluting process.c with non-process
related code.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move shutdown and reboot related code to a separate file, out of
process.c.  This helps to avoid polluting process.c with non-process
related code.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: fix broken hibernation</title>
<updated>2015-04-02T08:50:10+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2015-04-01T15:20:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=767bf7e7a1e82a81c59778348d156993d0a6175d'/>
<id>767bf7e7a1e82a81c59778348d156993d0a6175d</id>
<content type='text'>
Normally, when a CPU wants to clear a cache line to zero in the external
L2 cache, it would generate bus cycles to write each word as it would do
with any other data access.

However, a Cortex A9 connected to a L2C-310 has a specific feature where
the CPU can detect this operation, and signal that it wants to zero an
entire cache line.  This feature, known as Full Line of Zeros (FLZ),
involves a non-standard AXI signalling mechanism which only the L2C-310
can properly interpret.

There are separate enable bits in both the L2C-310 and the Cortex A9 -
the L2C-310 needs to be enabled and have the FLZ enable bit set in the
auxiliary control register before the Cortex A9 has this feature
enabled.

Unfortunately, the suspend code was not respecting this - it's not
obvious from the code:

swsusp_arch_suspend()
 cpu_suspend() /* saves the Cortex A9 auxiliary control register */
  arch_save_image()
  soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
   cpu_resume() /* restores the Cortex A9 registers, inc auxcr */

At this point, we end up with the L2C disabled, but the Cortex A9 with
FLZ enabled - which means any memset() or zeroing of a full cache line
will fail to take effect.

A similar issue exists in the resume path, but it's slightly more
complex:

swsusp_arch_suspend()
 cpu_suspend() /* saves the Cortex A9 auxiliary control register */
  arch_save_image() /* image with A9 auxcr saved */
...
swsusp_arch_resume()
 call_with_stack()
  arch_restore_image() /* restores image with A9 auxcr saved above */
  soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
   cpu_resume() /* restores the Cortex A9 registers, inc auxcr */

Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled.

There's no need to turn off the L2C in either of these two paths; there
are benefits from not doing so - for example, the page copies will be
faster with the L2C enabled.

Hence, fix this by providing a variant of soft_restart() which can be
used without turning the L2 cache controller off, and use it in both
of these paths to keep the L2C enabled across the respective resume
transitions.

Fixes: 8ef418c7178f ("ARM: l2c: trial at enabling some Cortex-A9 optimisations")
Reported-by: Sean Cross &lt;xobs@kosagi.com&gt;
Tested-by: Sean Cross &lt;xobs@kosagi.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Normally, when a CPU wants to clear a cache line to zero in the external
L2 cache, it would generate bus cycles to write each word as it would do
with any other data access.

However, a Cortex A9 connected to a L2C-310 has a specific feature where
the CPU can detect this operation, and signal that it wants to zero an
entire cache line.  This feature, known as Full Line of Zeros (FLZ),
involves a non-standard AXI signalling mechanism which only the L2C-310
can properly interpret.

There are separate enable bits in both the L2C-310 and the Cortex A9 -
the L2C-310 needs to be enabled and have the FLZ enable bit set in the
auxiliary control register before the Cortex A9 has this feature
enabled.

Unfortunately, the suspend code was not respecting this - it's not
obvious from the code:

swsusp_arch_suspend()
 cpu_suspend() /* saves the Cortex A9 auxiliary control register */
  arch_save_image()
  soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
   cpu_resume() /* restores the Cortex A9 registers, inc auxcr */

At this point, we end up with the L2C disabled, but the Cortex A9 with
FLZ enabled - which means any memset() or zeroing of a full cache line
will fail to take effect.

A similar issue exists in the resume path, but it's slightly more
complex:

swsusp_arch_suspend()
 cpu_suspend() /* saves the Cortex A9 auxiliary control register */
  arch_save_image() /* image with A9 auxcr saved */
...
swsusp_arch_resume()
 call_with_stack()
  arch_restore_image() /* restores image with A9 auxcr saved above */
  soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
   cpu_resume() /* restores the Cortex A9 registers, inc auxcr */

Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled.

There's no need to turn off the L2C in either of these two paths; there
are benefits from not doing so - for example, the page copies will be
faster with the L2C enabled.

Hence, fix this by providing a variant of soft_restart() which can be
used without turning the L2 cache controller off, and use it in both
of these paths to keep the L2C enabled across the respective resume
transitions.

Fixes: 8ef418c7178f ("ARM: l2c: trial at enabling some Cortex-A9 optimisations")
Reported-by: Sean Cross &lt;xobs@kosagi.com&gt;
Tested-by: Sean Cross &lt;xobs@kosagi.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8331/1: VDSO initialization, mapping, and synchronization</title>
<updated>2015-03-27T22:20:45+00:00</updated>
<author>
<name>Nathan Lynch</name>
<email>nathan_lynch@mentor.com</email>
</author>
<published>2015-03-25T18:15:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ecf99a439105ebd0a507af1a9cd901a2e166bf9a'/>
<id>ecf99a439105ebd0a507af1a9cd901a2e166bf9a</id>
<content type='text'>
Initialize the VDSO page list at boot, install the VDSO mapping at
exec time, and update the data page during timer ticks.  This code is
not built if CONFIG_VDSO is not enabled.

Account for the VDSO length when randomizing the offset from the
stack.  The [vdso] and [vvar] pages are placed immediately following
the sigpage with separate _install_special_mapping calls.

We want to "penalize" systems lacking the arch timer as little
as possible.  Previous versions of this code installed the VDSO
unconditionally and unmodified, making it a measurably slower way for
glibc to invoke the real syscalls on such systems.  E.g. calling
gettimeofday via glibc goes from ~560ns to ~630ns on i.MX6Q.

If we can indicate to glibc that the time-related APIs in the VDSO are
not accelerated, glibc can continue to invoke the syscalls directly
instead of dispatching through the VDSO only to fall back to the slow
path.

Thus, if the architected timer is unusable for whatever reason, patch
the VDSO at boot time so that symbol lookups for gettimeofday and
clock_gettime return NULL.  (This is similar to what powerpc does and
borrows code from there.)  This allows glibc to perform the syscall
directly instead of passing control to the VDSO, which minimizes the
penalty.  In my measurements the time taken for a gettimeofday call
via glibc goes from ~560ns to ~580ns (again on i.MX6Q), and this is
solely due to adding a test and branch to glibc's gettimeofday syscall
wrapper.

An alternative to patching the VDSO at boot would be to not install
the VDSO at all when the arch timer isn't usable.  Another alternative
is to include a separate "dummy" vdso.so without gettimeofday and
clock_gettime, which would be selected at boot time.  Either of these
would get cumbersome if the VDSO were to gain support for an API such
as getcpu which is unrelated to arch timer support.

Signed-off-by: Nathan Lynch &lt;nathan_lynch@mentor.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Initialize the VDSO page list at boot, install the VDSO mapping at
exec time, and update the data page during timer ticks.  This code is
not built if CONFIG_VDSO is not enabled.

Account for the VDSO length when randomizing the offset from the
stack.  The [vdso] and [vvar] pages are placed immediately following
the sigpage with separate _install_special_mapping calls.

We want to "penalize" systems lacking the arch timer as little
as possible.  Previous versions of this code installed the VDSO
unconditionally and unmodified, making it a measurably slower way for
glibc to invoke the real syscalls on such systems.  E.g. calling
gettimeofday via glibc goes from ~560ns to ~630ns on i.MX6Q.

If we can indicate to glibc that the time-related APIs in the VDSO are
not accelerated, glibc can continue to invoke the syscalls directly
instead of dispatching through the VDSO only to fall back to the slow
path.

Thus, if the architected timer is unusable for whatever reason, patch
the VDSO at boot time so that symbol lookups for gettimeofday and
clock_gettime return NULL.  (This is similar to what powerpc does and
borrows code from there.)  This allows glibc to perform the syscall
directly instead of passing control to the VDSO, which minimizes the
penalty.  In my measurements the time taken for a gettimeofday call
via glibc goes from ~560ns to ~580ns (again on i.MX6Q), and this is
solely due to adding a test and branch to glibc's gettimeofday syscall
wrapper.

An alternative to patching the VDSO at boot would be to not install
the VDSO at all when the arch timer isn't usable.  Another alternative
is to include a separate "dummy" vdso.so without gettimeofday and
clock_gettime, which would be selected at boot time.  Either of these
would get cumbersome if the VDSO were to gain support for an API such
as getcpu which is unrelated to arch timer support.

Signed-off-by: Nathan Lynch &lt;nathan_lynch@mentor.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8241/1: Update processor_modes for hyp and monitor mode</title>
<updated>2014-12-03T16:00:07+00:00</updated>
<author>
<name>Stephen Boyd</name>
<email>sboyd@codeaurora.org</email>
</author>
<published>2014-12-01T18:45:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f3a04202c519a1b496a63d83fc92067fe695f69a'/>
<id>f3a04202c519a1b496a63d83fc92067fe695f69a</id>
<content type='text'>
If the kernel is running in hypervisor mode or monitor mode we'll
print UK6_32 or UK10_32 if we call into __show_regs(). Let's
update these strings to indicate the new modes that didn't exist
when this code was written.

Signed-off-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the kernel is running in hypervisor mode or monitor mode we'll
print UK6_32 or UK10_32 if we call into __show_regs(). Let's
update these strings to indicate the new modes that didn't exist
when this code was written.

Signed-off-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'restart-handler-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging</title>
<updated>2014-10-10T20:38:02+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-10-10T20:38:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=93834c6419bccf102a17971c6b114826597a61c5'/>
<id>93834c6419bccf102a17971c6b114826597a61c5</id>
<content type='text'>
Pull restart handler infrastructure from Guenter Roeck:
 "This series was supposed to be pulled through various trees using it,
  and I did not plan to send a separate pull request.  As it turns out,
  the pinctrl tree did not merge with it, is now upstream, and uses it,
  meaning there are now build failures.

  Please pull this series directly to fix those build failures"

* tag 'restart-handler-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  arm/arm64: unexport restart handlers
  watchdog: sunxi: register restart handler with kernel restart handler
  watchdog: alim7101: register restart handler with kernel restart handler
  watchdog: moxart: register restart handler with kernel restart handler
  arm: support restart through restart handler call chain
  arm64: support restart through restart handler call chain
  power/restart: call machine_restart instead of arm_pm_restart
  kernel: add support for kernel restart handler call chain
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull restart handler infrastructure from Guenter Roeck:
 "This series was supposed to be pulled through various trees using it,
  and I did not plan to send a separate pull request.  As it turns out,
  the pinctrl tree did not merge with it, is now upstream, and uses it,
  meaning there are now build failures.

  Please pull this series directly to fix those build failures"

* tag 'restart-handler-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  arm/arm64: unexport restart handlers
  watchdog: sunxi: register restart handler with kernel restart handler
  watchdog: alim7101: register restart handler with kernel restart handler
  watchdog: moxart: register restart handler with kernel restart handler
  arm: support restart through restart handler call chain
  arm64: support restart through restart handler call chain
  power/restart: call machine_restart instead of arm_pm_restart
  kernel: add support for kernel restart handler call chain
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branches 'fiq' (early part), 'fixes', 'l2c' (early part) and 'misc' into for-next</title>
<updated>2014-10-02T20:47:02+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2014-10-02T20:47:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d5d16892243e7755da706d03b34da85ea6a74117'/>
<id>d5d16892243e7755da706d03b34da85ea6a74117</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8155/1: place sigpage at a random offset above stack</title>
<updated>2014-09-26T13:40:01+00:00</updated>
<author>
<name>Nathan Lynch</name>
<email>nathan_lynch@mentor.com</email>
</author>
<published>2014-09-22T21:12:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=389522b0c0530658eb9f9a53410ec2494616d785'/>
<id>389522b0c0530658eb9f9a53410ec2494616d785</id>
<content type='text'>
The sigpage is currently placed alongside shared libraries etc in the
address space.  Similar to what x86_64 does for its VDSO, place the
sigpage at a randomized offset above the stack so that learning the
base address of the sigpage doesn't help expose where shared libraries
are loaded in the address space (and vice versa).

Signed-off-by: Nathan Lynch &lt;nathan_lynch@mentor.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The sigpage is currently placed alongside shared libraries etc in the
address space.  Similar to what x86_64 does for its VDSO, place the
sigpage at a randomized offset above the stack so that learning the
base address of the sigpage doesn't help expose where shared libraries
are loaded in the address space (and vice versa).

Signed-off-by: Nathan Lynch &lt;nathan_lynch@mentor.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8154/1: use _install_special_mapping for sigpage</title>
<updated>2014-09-26T13:39:59+00:00</updated>
<author>
<name>Nathan Lynch</name>
<email>nathan_lynch@mentor.com</email>
</author>
<published>2014-09-22T21:08:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=02e0409a65560da66a747d2ac6023715b04659ea'/>
<id>02e0409a65560da66a747d2ac6023715b04659ea</id>
<content type='text'>
_install_special_mapping allows the VMA to be identifed in
/proc/pid/maps without the use of arch_vma_name, providing a
slight net reduction in object size:

  text    data     bss     dec     hex filename
  2996      96     144    3236     ca4 arch/arm/kernel/process.o (before)
  2956     104     144    3204     c84 arch/arm/kernel/process.o (after)

Signed-off-by: Nathan Lynch &lt;nathan_lynch@mentor.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
_install_special_mapping allows the VMA to be identifed in
/proc/pid/maps without the use of arch_vma_name, providing a
slight net reduction in object size:

  text    data     bss     dec     hex filename
  2996      96     144    3236     ca4 arch/arm/kernel/process.o (before)
  2956     104     144    3204     c84 arch/arm/kernel/process.o (after)

Signed-off-by: Nathan Lynch &lt;nathan_lynch@mentor.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm/arm64: unexport restart handlers</title>
<updated>2014-09-26T07:00:48+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2014-09-26T00:03:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6cd6d94d96d9b1cd8a62da91aac44cf56e301e75'/>
<id>6cd6d94d96d9b1cd8a62da91aac44cf56e301e75</id>
<content type='text'>
Implementing a restart handler in a module don't make sense as there would
be no guarantee that the module is loaded when a restart is needed.
Unexport arm_pm_restart to ensure that no one gets the idea to do it
anyway.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Acked-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
Cc: Dmitry Eremin-Solenikov &lt;dbaryshkov@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Jonas Jensen &lt;jonas.jensen@gmail.com&gt;
Cc: Maxime Ripard &lt;maxime.ripard@free-electrons.com&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Tomasz Figa &lt;t.figa@samsung.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Wim Van Sebroeck &lt;wim@iguana.be&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Implementing a restart handler in a module don't make sense as there would
be no guarantee that the module is loaded when a restart is needed.
Unexport arm_pm_restart to ensure that no one gets the idea to do it
anyway.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Acked-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
Cc: Dmitry Eremin-Solenikov &lt;dbaryshkov@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Jonas Jensen &lt;jonas.jensen@gmail.com&gt;
Cc: Maxime Ripard &lt;maxime.ripard@free-electrons.com&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Tomasz Figa &lt;t.figa@samsung.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Wim Van Sebroeck &lt;wim@iguana.be&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
