<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/clocksource, branch v3.18.51</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.51</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.51'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2016-09-01T02:05:44Z</updated>
<entry>
<title>clocksource/drivers/sun4i: Clear interrupts after stopping timer in probe function</title>
<updated>2016-09-01T02:05:44Z</updated>
<author>
<name>Chen-Yu Tsai</name>
<email>wens@csie.org</email>
</author>
<published>2016-08-25T06:26:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c8ca488fa42069e07e2fce5789dcbddc4fb2f143'/>
<id>urn:sha1:c8ca488fa42069e07e2fce5789dcbddc4fb2f143</id>
<content type='text'>
[ Upstream commit b53e7d000d9e6e9fd2c6eb6b82d2783c67fd599e ]

The bootloader (U-boot) sometimes uses this timer for various delays.
It uses it as a ongoing counter, and does comparisons on the current
counter value. The timer counter is never stopped.

In some cases when the user interacts with the bootloader, or lets
it idle for some time before loading Linux, the timer may expire,
and an interrupt will be pending. This results in an unexpected
interrupt when the timer interrupt is enabled by the kernel, at
which point the event_handler isn't set yet. This results in a NULL
pointer dereference exception, panic, and no way to reboot.

Clear any pending interrupts after we stop the timer in the probe
function to avoid this.

Cc: stable@vger.kernel.org
Signed-off-by: Chen-Yu Tsai &lt;wens@csie.org&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Acked-by: Maxime Ripard &lt;maxime.ripard@free-electrons.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier</title>
<updated>2015-07-05T14:12:52Z</updated>
<author>
<name>Damian Eppel</name>
<email>d.eppel@samsung.com</email>
</author>
<published>2015-06-26T13:23:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9d7754d5411c49d47846010ee85269b322c8ca3f'/>
<id>urn:sha1:9d7754d5411c49d47846010ee85269b322c8ca3f</id>
<content type='text'>
[ Upstream commit 56a94f13919c0db5958611b388e1581b4852f3c9 ]

Whilst testing cpu hotplug events on kernel configured with
DEBUG_PREEMPT and DEBUG_ATOMIC_SLEEP we get following BUG message,
caused by calling request_irq() and free_irq() in the context of
hotplug notification (which is in this case atomic context).

[   40.785859] CPU1: Software reset
[   40.786660] BUG: sleeping function called from invalid context at mm/slub.c:1241
[   40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[   40.786678] Preemption disabled at:[&lt;  (null)&gt;]   (null)
[   40.786681]
[   40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc4-00024-g7dca860 #36
[   40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   40.786728] [&lt;c0014a00&gt;] (unwind_backtrace) from [&lt;c0011980&gt;] (show_stack+0x10/0x14)
[   40.786747] [&lt;c0011980&gt;] (show_stack) from [&lt;c0449ba0&gt;] (dump_stack+0x70/0xbc)
[   40.786767] [&lt;c0449ba0&gt;] (dump_stack) from [&lt;c00c6124&gt;] (kmem_cache_alloc+0xd8/0x170)
[   40.786785] [&lt;c00c6124&gt;] (kmem_cache_alloc) from [&lt;c005d6f8&gt;] (request_threaded_irq+0x64/0x128)
[   40.786804] [&lt;c005d6f8&gt;] (request_threaded_irq) from [&lt;c0350b8c&gt;] (exynos4_local_timer_setup+0xc0/0x13c)
[   40.786820] [&lt;c0350b8c&gt;] (exynos4_local_timer_setup) from [&lt;c0350ca8&gt;] (exynos4_mct_cpu_notify+0x30/0xa8)
[   40.786838] [&lt;c0350ca8&gt;] (exynos4_mct_cpu_notify) from [&lt;c003b330&gt;] (notifier_call_chain+0x44/0x84)
[   40.786857] [&lt;c003b330&gt;] (notifier_call_chain) from [&lt;c0022fd4&gt;] (__cpu_notify+0x28/0x44)
[   40.786873] [&lt;c0022fd4&gt;] (__cpu_notify) from [&lt;c0013714&gt;] (secondary_start_kernel+0xec/0x150)
[   40.786886] [&lt;c0013714&gt;] (secondary_start_kernel) from [&lt;40008764&gt;] (0x40008764)

Interrupts cannot be requested/freed in the CPU_STARTING/CPU_DYING
notifications which run on the hotplugged cpu with interrupts and
preemption disabled.

To avoid the issue, request the interrupts for all possible cpus in
the boot code. The interrupts are marked NO_AUTOENABLE to avoid a racy
request_irq/disable_irq() sequence. The flag prevents the
request_irq() code from enabling the interrupt immediately.

The interrupt is then enabled in the CPU_STARTING notifier of the
hotplugged cpu and again disabled with disable_irq_nosync() in the
CPU_DYING notifier.

[ tglx: Massaged changelog to match the patch ]

Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for local timer registration")
Reported-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Tested-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Tested-by: Marcin Jabrzyk &lt;m.jabrzyk@samsung.com&gt;
Signed-off-by: Damian Eppel &lt;d.eppel@samsung.com&gt;
Cc: m.szyprowski@samsung.com
Cc: kyungmin.park@samsung.com
Cc: daniel.lezcano@linaro.org
Cc: kgene@kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1435324984-7328-1-git-send-email-d.eppel@samsung.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>clocksource: efm32: Fix a NULL pointer dereference</title>
<updated>2015-04-17T00:11:29Z</updated>
<author>
<name>Yongbae Park</name>
<email>yongbae2@gmail.com</email>
</author>
<published>2015-03-03T10:46:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3c6527a54302f6ad724c8657a03dc4cdf64abe6c'/>
<id>urn:sha1:3c6527a54302f6ad724c8657a03dc4cdf64abe6c</id>
<content type='text'>
[ Upstream commit 7b8f10da3bf1056546133c9f54f49ce389fd95ab ]

The initialisation of the efm32 clocksource first sets up the irq and only
after that initialises the data needed for irq handling. In case this
initialisation is delayed the irq handler would dereference a NULL pointer.

I'm not aware of anything that could delay the process in such a way, but it's
better to be safe than sorry, so setup the irq only when the clock event device
is ready.

Cc: stable@vger.kernel.org
Acked-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Yongbae Park &lt;yongbae2@gmail.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>clockevents: sun5i: Fix setup_irq init sequence</title>
<updated>2015-04-17T00:11:27Z</updated>
<author>
<name>Yongbae Park</name>
<email>yongbae2@gmail.com</email>
</author>
<published>2015-03-03T04:05:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5820c59b7d2b67f3ffadfb88d85dd2ce81b1241f'/>
<id>urn:sha1:5820c59b7d2b67f3ffadfb88d85dd2ce81b1241f</id>
<content type='text'>
[ Upstream commit 1096be084ac59927158ce80ff1d31c33eed0e565 ]

The interrupt is enabled before the handler is set. Even this bug
did not appear, it is potentially dangerous as it can lead to a
NULL pointer dereference.

Fix the error by enabling the interrupt after
clockevents_config_and_register() is called.

Cc: stable@vger.kernel.org
Signed-off-by: Yongbae Park &lt;yongbae2@gmail.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>clocksource: mtk: Fix race conditions in probe code</title>
<updated>2015-03-06T22:53:04Z</updated>
<author>
<name>Matthias Brugger</name>
<email>matthias.bgg@gmail.com</email>
</author>
<published>2015-02-19T10:41:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=df1d6514e97391aa4e2459f6cf04d7f3be9b0faf'/>
<id>urn:sha1:df1d6514e97391aa4e2459f6cf04d7f3be9b0faf</id>
<content type='text'>
commit d4a19eb3b15a4ba98f627182f48d5bc0cffae670 upstream.

We have two race conditions in the probe code which could lead to a null
pointer dereference in the interrupt handler.

The interrupt handler accesses the clockevent device, which may not yet be
registered.

First race condition happens when the interrupt handler gets registered before
the interrupts get disabled. The second race condition happens when the
interrupts get enabled, but the clockevent device is not yet registered.

Fix that by disabling the interrupts before we register the interrupt and enable
the interrupts after the clockevent device got registered.

Reported-by: Gongbae Park &lt;yongbae2@gmail.com&gt;
Signed-off-by: Matthias Brugger &lt;matthias.bgg@gmail.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>clocksource: arch_timer: Only use the virtual counter (CNTVCT) on arm64</title>
<updated>2015-02-06T06:36:09Z</updated>
<author>
<name>Catalin Marinas</name>
<email>catalin.marinas@arm.com</email>
</author>
<published>2014-12-10T11:02:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b2f21d1b7bc80150f2b7d1fecae5f64c9ead26fa'/>
<id>urn:sha1:b2f21d1b7bc80150f2b7d1fecae5f64c9ead26fa</id>
<content type='text'>
commit d6ad36913083d683aad4e02e53580c995f1a6ede upstream.

Commit 0b46b8a718c6 (clocksource: arch_timer: Fix code to use physical
timers when requested) introduces the use of physical counters in the
ARM architected timer driver. However, he arm64 kernel uses CNTVCT in
VDSO. When booting in EL2, the kernel switches to the physical timers to
make things easier for KVM but it continues to use the virtual counter
both in user and kernel. While in such scenario CNTVCT == CNTPCT (since
CNTVOFF is initialised by the kernel to 0), we want to spot firmware
bugs corrupting CNTVOFF early (which would affect CNTVCT).

Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Tested-by: Yingjoe Chen &lt;yingjoe.chen@mediatek.com&gt;
Cc: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Fixes: 0b46b8a718c6 ("clocksource: arch_timer: Fix code to use physical
timers when requested")
Cc: Ian Campbell &lt;ijc@hellion.org.uk&gt;
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>clocksource: exynos_mct: Fix bitmask regression for exynos4_mct_write</title>
<updated>2015-01-30T01:40:45Z</updated>
<author>
<name>Tobias Jakobi</name>
<email>tjakobi@math.uni-bielefeld.de</email>
</author>
<published>2014-10-22T01:37:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ec987a13d5ec90d690a52304224d731881544f86'/>
<id>urn:sha1:ec987a13d5ec90d690a52304224d731881544f86</id>
<content type='text'>
commit 8c38d28ba8da98f7102c31d35359b4dbe9d1f329 upstream.

EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask
produces a number outside the range 0x00 to 0xff, which always results
in execution of the default switch statement.

Obviously this is wrong and git history shows that the bitmask inversion
was incorrectly set during a refactoring of the MCT code.

Fix this by putting the inversion at the correct position again.

Acked-by: Kukjin Kim &lt;kgene.kim@samsung.com&gt;
Reported-by: GP Orcullo &lt;kinsamanka@gmail.com&gt;
Reviewed-by: Doug Anderson &lt;dianders@chromium.org&gt;
Signed-off-by: Tobias Jakobi &lt;tjakobi@math.uni-bielefeld.de&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>clocksource: arch_timer: Fix code to use physical timers when requested</title>
<updated>2015-01-08T18:30:15Z</updated>
<author>
<name>Sonny Rao</name>
<email>sonnyrao@chromium.org</email>
</author>
<published>2014-11-24T07:02:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=82c236bcbe0c3898025588b1725d0fa6c3d55b20'/>
<id>urn:sha1:82c236bcbe0c3898025588b1725d0fa6c3d55b20</id>
<content type='text'>
commit 0b46b8a718c6e90910a1b1b0fe797be3c167e186 upstream.

This is a bug fix for using physical arch timers when
the arch_timer_use_virtual boolean is false.  It restores the
arch_counter_get_cntpct() function after removal in

0d651e4e "clocksource: arch_timer: use virtual counters"

We need this on certain ARMv7 systems which are architected like this:

* The firmware doesn't know and doesn't care about hypervisor mode and
  we don't want to add the complexity of hypervisor there.

* The firmware isn't involved in SMP bringup or resume.

* The ARCH timer come up with an uninitialized offset between the
  virtual and physical counters.  Each core gets a different random
  offset.

* The device boots in "Secure SVC" mode.

* Nothing has touched the reset value of CNTHCTL.PL1PCEN or
  CNTHCTL.PL1PCTEN (both default to 1 at reset)

One example of such as system is RK3288 where it is much simpler to
use the physical counter since there's nobody managing the offset and
each time a core goes down and comes back up it will get reinitialized
to some other random value.

Fixes: 0d651e4e65e9 ("clocksource: arch_timer: use virtual counters")
Signed-off-by: Sonny Rao &lt;sonnyrao@chromium.org&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Acked-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>clockevent: sun4i: Fix race condition in the probe code</title>
<updated>2014-11-19T09:43:51Z</updated>
<author>
<name>Maxime Ripard</name>
<email>maxime.ripard@free-electrons.com</email>
</author>
<published>2014-11-18T22:59:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6bab4a8a1888729f17f4923cc5867e4674f66333'/>
<id>urn:sha1:6bab4a8a1888729f17f4923cc5867e4674f66333</id>
<content type='text'>
The interrupts were activated and the handler registered before the clockevent
was registered in the probe function.

The interrupt handler, however, was making the assumption that the clockevent
device was registered.

That could cause a null pointer dereference if the timer interrupt was firing
during this narrow window.

Fix that by moving the clockevent registration before the interrupt is enabled.

Reported-by: Roman Byshko &lt;rbyshko@gmail.com&gt;
Signed-off-by: Maxime Ripard &lt;maxime.ripard@free-electrons.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
</content>
</entry>
<entry>
<title>ARM/ARM64: arch-timer: fix arch_timer_probed logic</title>
<updated>2014-10-26T19:50:00Z</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2014-10-15T15:06:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=59aa896db80479dec29f471a7ca2b9eeeeb7d38e'/>
<id>urn:sha1:59aa896db80479dec29f471a7ca2b9eeeeb7d38e</id>
<content type='text'>
Commit c387f07e6205 (clocksource: arm_arch_timer: Discard unavailable
timers correctly) changed the way the driver makes sure both the memory
and system-register timers have been probed before finalizing the probing.

There is a interesting flaw in this logic that leads to this final step
never to be executed. Things seems to work pretty well until something
actually needs the data that is produced during this final stage.

For example, KVM explodes on the first run of a guest when executed on
a platform that has both memory and sysreg nodes (Juno, for example).

Just fix the damned logic, and enjoy booting VMs again.

Tested on a Juno system.

Cc: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Cc: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Cc: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Reported-by: Riku Voipio &lt;riku.voipio@linaro.org&gt;
Acked-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Acked-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Tested-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
</content>
</entry>
</feed>
