<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/powerpc/kernel/time.c, branch linux-4.19.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.19.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.19.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-04-29T14:31:14Z</updated>
<entry>
<title>Revert "powerpc/64: irq_work avoid interrupt when called with hardware irqs enabled"</title>
<updated>2020-04-29T14:31:14Z</updated>
<author>
<name>Nicholas Piggin</name>
</author>
<published>2020-04-02T12:04:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d59e5b00d5771d65ff084668535de0f23924fdab'/>
<id>urn:sha1:d59e5b00d5771d65ff084668535de0f23924fdab</id>
<content type='text'>
[ Upstream commit abc3fce76adbdfa8f87272c784b388cd20b46049 ]

This reverts commit ebb37cf3ffd39fdb6ec5b07111f8bb2f11d92c5f.

That commit does not play well with soft-masked irq state
manipulations in idle, interrupt replay, and possibly others due to
tracing code sometimes using irq_work_queue (e.g., in
trace_hardirqs_on()). That can cause PACA_IRQ_DEC to become set when
it is not expected, and be ignored or cleared or cause warnings.

The net result seems to be missing an irq_work until the next timer
interrupt in the worst case which is usually not going to be noticed,
however it could be a long time if the tick is disabled, which is
against the spirit of irq_work and might cause real problems.

The idea is still solid, but it would need more work. It's not really
clear if it would be worth added complexity, so revert this for
now (not a straight revert, but replace with a comment explaining why
we might see interrupts happening, and gives git blame something to
find).

Fixes: ebb37cf3ffd3 ("powerpc/64: irq_work avoid interrupt when called with hardware irqs enabled")
Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20200402120401.1115883-1-npiggin@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc/pseries: Mark accumulate_stolen_time() as notrace</title>
<updated>2020-01-04T18:12:41Z</updated>
<author>
<name>Michael Ellerman</name>
</author>
<published>2019-10-13T10:23:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=178f6bdf75f9cde5f8e73cda0489caf8b6f455f9'/>
<id>urn:sha1:178f6bdf75f9cde5f8e73cda0489caf8b6f455f9</id>
<content type='text'>
[ Upstream commit eb8e20f89093b64f48975c74ccb114e6775cee22 ]

accumulate_stolen_time() is called prior to interrupt state being
reconciled, which can trip the warning in arch_local_irq_restore():

  WARNING: CPU: 5 PID: 1017 at arch/powerpc/kernel/irq.c:258 .arch_local_irq_restore+0x9c/0x130
  ...
  NIP .arch_local_irq_restore+0x9c/0x130
  LR  .rb_start_commit+0x38/0x80
  Call Trace:
    .ring_buffer_lock_reserve+0xe4/0x620
    .trace_function+0x44/0x210
    .function_trace_call+0x148/0x170
    .ftrace_ops_no_ops+0x180/0x1d0
    ftrace_call+0x4/0x8
    .accumulate_stolen_time+0x1c/0xb0
    decrementer_common+0x124/0x160

For now just mark it as notrace. We may change the ordering to call it
after interrupt state has been reconciled, but that is a larger
change.

Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20191024055932.27940-1-mpe@ellerman.id.au
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc: Fix vDSO clock_getres()</title>
<updated>2019-12-17T19:35:40Z</updated>
<author>
<name>Vincenzo Frascino</name>
</author>
<published>2019-12-02T07:57:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=79bee5a380342b48d0ce177cb2fb75ef6eeeb1a2'/>
<id>urn:sha1:79bee5a380342b48d0ce177cb2fb75ef6eeeb1a2</id>
<content type='text'>
[ Upstream commit 552263456215ada7ee8700ce022d12b0cffe4802 ]

clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().

In particular, posix_get_hrtimer_res() does:
    sec = 0;
    ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or at run time.

Fix the powerpc vdso implementation of clock_getres keeping a copy of
hrtimer_resolution in vdso data and using that directly.

Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel")
Cc: stable@vger.kernel.org
Signed-off-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Reviewed-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Acked-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
[chleroy: changed CLOCK_REALTIME_RES to CLOCK_HRTIMER_RES]
Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/a55eca3a5e85233838c2349783bcb5164dae1d09.1575273217.git.christophe.leroy@c-s.fr
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc/time: Fix clockevent_decrementer initalisation for PR KVM</title>
<updated>2019-11-24T07:21:08Z</updated>
<author>
<name>Michael Ellerman</name>
</author>
<published>2018-10-17T12:39:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e2a37708cfca2e9815fc9a2456263b4fbbcfc367'/>
<id>urn:sha1:e2a37708cfca2e9815fc9a2456263b4fbbcfc367</id>
<content type='text'>
[ Upstream commit b4d16ab58c41ff0125822464bdff074cebd0fe47 ]

In the recent commit 8b78fdb045de ("powerpc/time: Use
clockevents_register_device(), fixing an issue with large
decrementer") we changed the way we initialise the decrementer
clockevent(s).

We no longer initialise the mult &amp; shift values of
decrementer_clockevent itself.

This has the effect of breaking PR KVM, because it uses those values
in kvmppc_emulate_dec(). The symptom is guest kernels spin forever
mid-way through boot.

For now fix it by assigning back to decrementer_clockevent the mult
and shift values.

Fixes: 8b78fdb045de ("powerpc/time: Use clockevents_register_device(), fixing an issue with large decrementer")
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc/time: Use clockevents_register_device(), fixing an issue with large decrementer</title>
<updated>2019-11-24T07:20:09Z</updated>
<author>
<name>Anton Blanchard</name>
</author>
<published>2018-10-01T23:01:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9e4649e443e24fecfc5521f6452a0a4184488d30'/>
<id>urn:sha1:9e4649e443e24fecfc5521f6452a0a4184488d30</id>
<content type='text'>
[ Upstream commit 8b78fdb045de60a4eb35460092bbd3cffa925353 ]

We currently cap the decrementer clockevent at 4 seconds, even on systems
with large decrementer support. Fix this by converting the code to use
clockevents_register_device() which calculates the upper bound based on
the max_delta passed in.

Signed-off-by: Anton Blanchard &lt;anton@ozlabs.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc/time: inline arch_vtime_task_switch()</title>
<updated>2018-06-03T14:39:20Z</updated>
<author>
<name>Christophe Leroy</name>
</author>
<published>2018-05-29T16:19:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=60f1d2893ee6de65cdea609c84950b133e76a769'/>
<id>urn:sha1:60f1d2893ee6de65cdea609c84950b133e76a769</id>
<content type='text'>
arch_vtime_task_switch() is a small function which is called
only from vtime_common_task_switch(), so it is worth inlining

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc: remove unused to_tm() helper</title>
<updated>2018-06-03T10:43:34Z</updated>
<author>
<name>Arnd Bergmann</name>
</author>
<published>2018-04-23T08:36:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=34efabe418953002d1c8e0ab28634929a9ddf433'/>
<id>urn:sha1:34efabe418953002d1c8e0ab28634929a9ddf433</id>
<content type='text'>
to_tm() is now completely unused, the only reference being in the
_dump_time() helper that is also unused. This removes both, leaving
the rest of the powerpc RTC code y2038 safe to as far as the hardware
supports.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc: use time64_t in update_persistent_clock</title>
<updated>2018-06-03T10:43:34Z</updated>
<author>
<name>Arnd Bergmann</name>
</author>
<published>2018-04-23T08:36:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5235afa89a246c9d5ab35996bc38681c474c3ed7'/>
<id>urn:sha1:5235afa89a246c9d5ab35996bc38681c474c3ed7</id>
<content type='text'>
update_persistent_clock() is deprecated because it suffers from overflow
in 2038 on 32-bit architectures. This changes powerpc to use the
update_persistent_clock64() replacement, and to pass down 64-bit
timestamps consistently.

This is now simpler, as we no longer have to worry about the offset
numbers in tm_year and tm_mon that are different between the Linux
conventions and RTAS.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc: use time64_t in read_persistent_clock</title>
<updated>2018-06-03T10:43:33Z</updated>
<author>
<name>Arnd Bergmann</name>
</author>
<published>2018-04-23T08:36:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5bfd643583b2e2a203163fd6b617cd9027054200'/>
<id>urn:sha1:5bfd643583b2e2a203163fd6b617cd9027054200</id>
<content type='text'>
Looking through the remaining users of the deprecated mktime()
function, I found the powerpc rtc handlers, which use it in
place of rtc_tm_to_time64().

To clean this up, I'm changing over the read_persistent_clock()
function to the read_persistent_clock64() variant, and change
all the platform specific handlers along with it.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/time: account broadcast timer event interrupts separately</title>
<updated>2018-06-03T10:40:29Z</updated>
<author>
<name>Nicholas Piggin</name>
</author>
<published>2018-05-04T17:19:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e360cd37f0e9bac7b5f623132549e2d4b6417399'/>
<id>urn:sha1:e360cd37f0e9bac7b5f623132549e2d4b6417399</id>
<content type='text'>
These are not local timer interrupts but IPIs. It's good to be able
to see how timer offloading is behaving, so split these out into
their own category.

Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
</feed>
