<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch/powerpc/include/asm/paca.h, branch linux-7.0.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.0.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.0.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-02-21T04:15:40+00:00</updated>
<entry>
<title>powerpc: Remove duplicate/unnecessary ifdefs</title>
<updated>2024-02-21T04:15:40+00:00</updated>
<author>
<name>Shrikanth Hegde</name>
<email>sshegde@linux.ibm.com</email>
</author>
<published>2024-02-16T05:30:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8c328de8fd5046eb3ec5a7ff7b682a8175e986c3'/>
<id>urn:sha1:8c328de8fd5046eb3ec5a7ff7b682a8175e986c3</id>
<content type='text'>
When an ifdef is used in the below manner, second one could be considered
as duplicate.

  ifdef DEFINE_A
  ...code block...
  ifdef DEFINE_A       &lt;-- This is a duplicate.
  ...code block...
  endif
  else
  ifndef DEFINE_A     &lt;-- This is also duplicate.
  ...code block...
  endif
  endif

More details about the script and methods used to find these code
patterns are in cover letter of [1].

Few places in arch/powerpc where this pattern was seen:

  paca.h:
  Hunk1: Code is under check of CONFIG_PPC64 from line 13, hence the
  second CONFIG_PPC64 at line 166 is a duplicate.
  Hunk2: CONFIG_PPC_BOOK3S_64 was defined back to back. Merged the two
  ifdefs.

  asm-offsets.c:
  Code is under check of CONFIG_PPC64 from line 176 hence second
  CONFIG_PPC64 at line 249 is a duplicate.

  powermac/feature.c:
  #ifndef CONFIG_PPC64 is used at line 2066. And then in #else again
  #ifdef CONFIG_PPC64 is used. Which is a duplicate since in #else means
  CONFIG_PPC64 is defined.

  xmon.c:
  Code is under the check of CONFIG_SMP from line 521 hence the same
  check of CONFIG_SMP at line 646 is a duplicate.

No functional change is intended here. It only aims to improve code
readability.

[1] https://lore.kernel.org/all/20240118080326.13137-1-sshegde@linux.ibm.com/

Signed-off-by: Shrikanth Hegde &lt;sshegde@linux.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://msgid.link/20240216053016.528906-1-sshegde@linux.ibm.com

</content>
</entry>
<entry>
<title>powerpc: Don't include lppaca.h in paca.h</title>
<updated>2023-08-24T12:33:16+00:00</updated>
<author>
<name>Michael Ellerman</name>
<email>mpe@ellerman.id.au</email>
</author>
<published>2023-08-23T05:53:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1aa000667669fa855853decbb1c69e974d8ff716'/>
<id>urn:sha1:1aa000667669fa855853decbb1c69e974d8ff716</id>
<content type='text'>
By adding a forward declaration for struct lppaca we can untangle paca.h
and lppaca.h. Also move get_lppaca() into lppaca.h for consistency.

Add includes of lppaca.h to some files that need it.

Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://msgid.link/20230823055317.751786-3-mpe@ellerman.id.au

</content>
</entry>
<entry>
<title>powerpc: powernv: Fix KCSAN datarace warnings on idle_state contention</title>
<updated>2023-06-21T05:13:57+00:00</updated>
<author>
<name>Rohan McLure</name>
<email>rmclure@linux.ibm.com</email>
</author>
<published>2023-05-10T03:31:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b0c5b4f1ee3687c57dab65ac0729a4d61967f032'/>
<id>urn:sha1:b0c5b4f1ee3687c57dab65ac0729a4d61967f032</id>
<content type='text'>
The idle_state entry in the PACA on PowerNV features a bit which is
atomically tested and set through ldarx/stdcx. to be used as a spinlock.
This lock then guards access to other bit fields of idle_state. KCSAN
cannot differentiate between any of these bitfield accesses as they all
are implemented by 8-byte store/load instructions, thus cores contending
on the bit-lock appear to data race with modifications to idle_state.

Separate the bit-lock entry from the data guarded by the lock to avoid
the possibility of data races being detected by KCSAN.

Suggested-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Rohan McLure &lt;rmclure@linux.ibm.com&gt;
Reviewed-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://msgid.link/20230510033117.1395895-7-rmclure@linux.ibm.com

</content>
</entry>
<entry>
<title>powerpc/64: vmlinux support building with PCREL addresing</title>
<updated>2023-04-20T02:59:21+00:00</updated>
<author>
<name>Nicholas Piggin</name>
<email>npiggin@gmail.com</email>
</author>
<published>2023-04-08T02:17:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7e3a68be42e10f5fa5890e97afc0afd992355bc3'/>
<id>urn:sha1:7e3a68be42e10f5fa5890e97afc0afd992355bc3</id>
<content type='text'>
PC-Relative or PCREL addressing is an extension to the ELF ABI which
uses Power ISA v3.1 PC-relative instructions to calculate addresses,
rather than the traditional TOC scheme.

Add an option to build vmlinux using pcrel addressing. Modules continue
to use TOC addressing.

- TOC address helpers and r2 are poisoned with -1 when running vmlinux.
  r2 could be used for something useful once things are ironed out.

- Assembly must call C functions with @notoc annotation, or the linker
  complains aobut a missing nop after the call. This is done with the
  CFUNC macro introduced earlier.

- Boot: with the exception of prom_init, the execution branches to the
  kernel virtual address early in boot, before any addresses are
  generated, which ensures 34-bit pcrel addressing does not miss the
  high PAGE_OFFSET bits. TOC relative addressing has a similar
  requirement. prom_init does not go to the virtual address and its
  addresses should not carry over to the post-prom kernel.

- Ftrace trampolines are converted from TOC addressing to pcrel
  addressing, including module ftrace trampolines that currently use the
  kernel TOC to find ftrace target functions.

- BPF function prologue and function calling generation are converted
  from TOC to pcrel.

- copypage_64.S has an interesting problem, prefixed instructions have
  alignment restrictions so the linker can add padding, which makes the
  assembler treat the difference between two local labels as
  non-constant even if alignment is arranged so padding is not required.
  This may need toolchain help to solve nicely, for now move the prefix
  instruction out of the alternate patch section to work around it.

This reduces kernel text size by about 6%.

Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://msgid.link/20230408021752.862660-6-npiggin@gmail.com
</content>
</entry>
<entry>
<title>powerpc/64: Move paca allocation to early_setup()</title>
<updated>2023-02-10T11:19:56+00:00</updated>
<author>
<name>Nicholas Piggin</name>
<email>npiggin@gmail.com</email>
</author>
<published>2022-12-16T11:59:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dc222fa7737212fe0da513e5b8937c156d02225d'/>
<id>urn:sha1:dc222fa7737212fe0da513e5b8937c156d02225d</id>
<content type='text'>
The early paca and boot cpuid dance is complicated and currently does
not quite work as expected for boot cpuid != 0 cases.

early_init_devtree() currently allocates the paca_ptrs and boot cpuid
paca, but until that returns and early_setup() calls setup_paca(), this
thread is currently still executing with smp_processor_id() == 0.

One problem this causes is the paca_ptrs[smp_processor_id()] pointer is
poisoned, so valid_emergency_stack() (any backtrace) and any similar
users will crash.

Another is that the hardware id which is set here will not be returned
by get_hard_smp_processor_id(smp_processor_id()), but it would work
correctly for boot_cpuid == 0, which could lead to difficult to
reproduce or find bugs. The hard id does not seem to be used by the rest
of early_init_devtree(), it just looks like all this code might have
been put here to allocate somewhere to store boot CPU hardware id while
scanning the devtree.

Rearrange things so the hwid is put in a global variable like
boot_cpuid, and do all the paca allocation and boot paca setup in the
64-bit early_setup() after we have everything ready to go.

The paca_ptrs[0] re-poisoning code in early_setup does not seem to have
ever worked, because paca_ptrs[0] was never not-poisoned when boot_cpuid
is not 0.

Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
[mpe: Fix build error on 32-bit]
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20221216115930.2667772-4-npiggin@gmail.com

</content>
</entry>
<entry>
<title>powerpc: Remove CONFIG_PPC_BOOK3E</title>
<updated>2022-09-26T13:00:13+00:00</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@csgroup.eu</email>
</author>
<published>2022-09-19T17:01:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e0d68273d7069537701bb91c51d90d1e12aacc33'/>
<id>urn:sha1:e0d68273d7069537701bb91c51d90d1e12aacc33</id>
<content type='text'>
CONFIG_PPC_BOOK3E is redundant with CONFIG_PPC_BOOK3E_64.

The later is more explicit about the fact that it's a 64 bits target.

Remove CONFIG_PPC_BOOK3E.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/5d0891490813c19cdcfc04678f512ea68cba3e64.1663606876.git.christophe.leroy@csgroup.eu

</content>
</entry>
<entry>
<title>Revert "powerpc/rtas: Implement reentrant rtas call"</title>
<updated>2022-09-14T12:43:13+00:00</updated>
<author>
<name>Nathan Lynch</name>
<email>nathanl@linux.ibm.com</email>
</author>
<published>2022-09-07T22:01:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f88aabad33ea22be2ce1c60d8901942e4e2a9edb'/>
<id>urn:sha1:f88aabad33ea22be2ce1c60d8901942e4e2a9edb</id>
<content type='text'>
At the time this was submitted by Leonardo, I confirmed -- or thought
I had confirmed -- with PowerVM partition firmware development that
the following RTAS functions:

- ibm,get-xive
- ibm,int-off
- ibm,int-on
- ibm,set-xive

were safe to call on multiple CPUs simultaneously, not only with
respect to themselves as indicated by PAPR, but with arbitrary other
RTAS calls:

https://lore.kernel.org/linuxppc-dev/875zcy2v8o.fsf@linux.ibm.com/

Recent discussion with firmware development makes it clear that this
is not true, and that the code in commit b664db8e3f97 ("powerpc/rtas:
Implement reentrant rtas call") is unsafe, likely explaining several
strange bugs we've seen in internal testing involving DLPAR and
LPM. These scenarios use ibm,configure-connector, whose internal state
can be corrupted by the concurrent use of the "reentrant" functions,
leading to symptoms like endless busy statuses from RTAS.

Fixes: b664db8e3f97 ("powerpc/rtas: Implement reentrant rtas call")
Cc: stable@vger.kernel.org # v5.8+
Signed-off-by: Nathan Lynch &lt;nathanl@linux.ibm.com&gt;
Reviewed-by: Laurent Dufour &lt;laurent.dufour@fr.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220907220111.223267-1-nathanl@linux.ibm.com
</content>
</entry>
<entry>
<title>powerpc/64: Include cache.h directly in paca.h</title>
<updated>2022-05-27T12:20:09+00:00</updated>
<author>
<name>Michael Ellerman</name>
<email>mpe@ellerman.id.au</email>
</author>
<published>2022-05-27T11:15:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dcf280e6f80be280ca7dd1b058f038654e4a18dd'/>
<id>urn:sha1:dcf280e6f80be280ca7dd1b058f038654e4a18dd</id>
<content type='text'>
paca.h uses ____cacheline_aligned without directly including cache.h,
where it's defined.

For Book3S builds that's OK because paca.h includes lppaca.h, and it
does include cache.h.

But Book3E builds have been getting cache.h indirectly via printk.h,
which is dicey, and in fact that include was recently removed, leading
to build errors such as:

  ld: fs/isofs/dir.o:(.bss+0x0): multiple definition of `____cacheline_aligned'; fs/isofs/namei.o:(.bss+0x0): first defined here

So include cache.h directly to fix the build error.

Fixes: 534aa1dc975a ("printk: stop including cache.h from printk.h")
Reported-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/mm: Remove CONFIG_PPC_MM_SLICES</title>
<updated>2022-05-05T12:11:57+00:00</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@csgroup.eu</email>
</author>
<published>2022-04-09T17:17:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f693d38d9468101587175b1e62d7e4483b51d8f5'/>
<id>urn:sha1:f693d38d9468101587175b1e62d7e4483b51d8f5</id>
<content type='text'>
CONFIG_PPC_MM_SLICES is always selected by hash book3s/64.
CONFIG_PPC_MM_SLICES is never selected by other platforms.

Remove it.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Reviewed-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/dc2cdc204de8978574bf7c02329b6cfc4db0bce7.1649523076.git.christophe.leroy@csgroup.eu

</content>
</entry>
<entry>
<title>powerpc/mce: Avoid using irq_work_queue() in realmode</title>
<updated>2022-03-07T13:05:00+00:00</updated>
<author>
<name>Ganesh Goudar</name>
<email>ganeshgr@linux.ibm.com</email>
</author>
<published>2022-01-20T12:19:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cc15ff3275694fedc33cd3d53212a43eec7aa0bc'/>
<id>urn:sha1:cc15ff3275694fedc33cd3d53212a43eec7aa0bc</id>
<content type='text'>
In realmode mce handler we use irq_work_queue() to defer
the processing of mce events, irq_work_queue() can only
be called when translation is enabled because it touches
memory outside RMA, hence we enable translation before
calling irq_work_queue and disable on return, though it
is not safe to do in realmode.

To avoid this, program the decrementer and call the event
processing functions from timer handler.

Signed-off-by: Ganesh Goudar &lt;ganeshgr@linux.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220120121931.517974-1-ganeshgr@linux.ibm.com

</content>
</entry>
</feed>
