On Wed, Jan 29, 2025 at 06:10:43PM +1100, Paul Mackerras wrote:
> > Hate to bikeshed, but would it be annoying to make this an affirmative
> > option?
>
> I guess we'd have to make all the platforms that do have broadcast
> tlbie (and a book3s-64 MMU with radix) select that option. Which
> would
On Wed, Jan 29, 2025 at 09:53:44AM +1100, Paul Mackerras wrote:
> Power ISA v3.1 implementations in the Linux Compliancy Subset and
> lower are not required to implement broadcast TLBIE, and in fact
> Microwatt doesn't.
But this pretty much means that such systems cannot be SMP systems at
all. Im
On Wed, Jan 29, 2025 at 06:20:31PM +1000, Nicholas Piggin wrote:
> Perfectly reasonable to not add broadcast tlbie in microwatt.
If you call "the easy way out" reasonable, then sure. This pretty
trivial hardware addition causes so many software headaches whenn
missing, it isn't funny. "Friends d
On Wed, Jan 29, 2025 at 06:18:54PM +1100, Paul Mackerras wrote:
> Interesting. I looked in my copy of v2.07 (PowerISA_V2.07_PUBLIC.pdf)
> and it mentions rfscv in a couple of places, but has no description of
> scv or rfscv. I'll change it to v3.0.
Huh, rfscv is 3.0 and later according to later
On Wed, Jan 29, 2025 at 04:36:14PM +1000, Nicholas Piggin wrote:
> On Wed Jan 29, 2025 at 8:52 AM AEST, Paul Mackerras wrote:
> > Microwatt now implements ISA v3.1 (SFFS compliancy subset), including
> > prefixed instructions, scv/rfscv, and the FSCR, HFSCR, TAR, and CTRL
> > registers. The privil
On Wed, Jan 29, 2025 at 09:52:09AM +1100, Paul Mackerras wrote:
> - isa = <3000>;
> + isa = <3010>;
Does this mean 3.1, or 3.01? If the former, can this also encode 3.1C?
Should uwatt say to support that?
> little-endian {
> -
On Wed, Jan 29, 2025 at 04:06:03PM +1000, Nicholas Piggin wrote:
> Does wait cause MSR[EE] to be set? If not, do you need to use
> prep_irq_for_idle_irqsoff() here maybe?
Assuming this does implement the standard ISA 2.03 wait instruction
(and it better), this does not do anything other than to st
Hi!
> +static void microwatt_idle(void)
> +{
> + if (!prep_irq_for_idle())
> + return;
> +
> + __asm__ __volatile__ ("wait");
> +}
All asm without outputs is always implicitly volatile (if it wasn't, it
could always be transfirmed whatever way you want, like, optimised away
co
Hi!
On Wed, Jan 29, 2025 at 09:49:49AM +1100, Paul Mackerras wrote:
> This patch series updates the kernel support for the Microwatt
> soft-core and its implementation on FPGA systems, particularly the
> Digilent Arty A7-100 FPGA development board.
>
> Microwatt now supports almost all of the fea
On Wed, Jan 29, 2025 at 10:45:10AM +0100, Julian Vetter wrote:
> Remove the eieio() calls in IO functions for PowerPC. While other
> architectures permit prefetching, combining, and reordering, the eieio()
> calls on PowerPC prevent such optimizations.
Yes, and it is crucial to prevent combining,
On Sun, Dec 22, 2024 at 10:09:14PM +0100, Arnd Bergmann wrote:
> On Sun, Dec 22, 2024, at 03:13, A. Wilcox wrote:
> > On Dec 21, 2024, at 3:42 PM, Arnd Bergmann wrote:
> >
> > R0 .. R7 R8 .. R15 R16 .. R23 R24 .. R31
> > 014a1124 0
4 bytes aligned, use bit 30 as flag.
The AA field already is there, so why not, eh :-)
> Also add support for 'b' and 'ba' instructions. Objtool call them jumps.
> Signed-off-by: Christophe Leroy
Reviewed-by: Segher Boessenkool
> --- a/tools/objtool/arch/powerpc/
On Mon, Dec 02, 2024 at 08:18:22AM -0600, Rob Herring wrote:
> On Wed, Nov 27, 2024 at 3:47 PM Segher Boessenkool
> wrote:
> > On Tue, Nov 26, 2024 at 02:36:32PM +1100, Michael Ellerman wrote:
> > > Michael Ellerman writes:
> > > > "Rob Herring (Arm)
On Tue, Nov 26, 2024 at 02:36:32PM +1100, Michael Ellerman wrote:
> Michael Ellerman writes:
> > "Rob Herring (Arm)" writes:
> >> While OpenFirmware originally allowed walking parent nodes and default
> >> root values for #address-cells and #size-cells, FDT has long required
> >> explicit values.
Roadrunner) that
> have since been dismantled, and were not that widely used otherwise.
Sad to see this go as well as native powerpc blades just days ago. But
yeah it is time (and we are all getting old, etc.)
Acked-by: Segher Boessenkool
> Until recently I still had a working QS22, which m
On Tue, Nov 26, 2024 at 02:49:49PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Fri, Nov 15, 2024 at 12:11:04AM +1100, Michael Ellerman wrote:
> >> CHRP (Common Hardware Reference Platform) was a standard developed by
> >> IBM &
On Thu, Nov 21, 2024 at 09:41:36AM +0100, John Paul Adrian Glaubitz wrote:
> >> Pegasos2 users still exist, but admittedly they mainly use MorphOS and
> >> AmigaOS4 on these machines.
> >
> > The Linux CHRP support is still present in v6.12, which will be an LTS
> > for the next 2 years at least, s
y lost. If anyone
> wrote any of this code and would like a CREDITS entry just let me know.
>
> Signed-off-by: Michael Ellerman
Acked-by: Segher Boessenkool
Segher
On Thu, Nov 07, 2024 at 10:35:58PM +1100, Michael Ellerman wrote:
> "Rob Herring (Arm)" writes:
> > While OpenFirmware originally allowed walking parent nodes and default
> > root values for #address-cells and #size-cells, FDT has long required
> > explicit values. It's been a warning in dtc for t
On Thu, Nov 07, 2024 at 10:26:46PM +1100, Michael Ellerman wrote:
> From: Arnd Bergmann
>
> Unlike all other arches, powerpc doesn't allow the user to override CPP,
> because it sets it unconditionally in the arch Makefile. This can lead
> to strange build failures.
>
> Instead add the required
Hi!
On Wed, Nov 06, 2024 at 08:21:14AM -0700, Nathan Chancellor wrote:
> > (r2 is the default for -m32, r13 is the default for -m64, it appears
> > that clang does not implement this option at all, it simply checks if
> > you set the default, and explodes if not).
>
> Not sure that I would say it
Hi!
On Wed, Nov 06, 2024 at 09:55:58AM +0100, Christophe Leroy wrote:
> Le 30/10/2024 à 19:41, Nathan Chancellor a écrit :
> >Under certain conditions, the 64-bit '-mstack-protector-guard' flags may
> >end up in the 32-bit vDSO flags, resulting in build failures due to the
> >structure of clang's
Hi!
On Tue, Nov 05, 2024 at 06:17:51PM +0900, Masami Hiramatsu wrote:
> On Tue, 5 Nov 2024 02:20:18 -0600
> Segher Boessenkool wrote:
> > On Mon, Nov 04, 2024 at 11:06:23PM +0530, Hari Bathini wrote:
> > > Seems like a bit of misunderstanding there. Function entry here inte
Hi!
On Mon, Nov 04, 2024 at 11:06:23PM +0530, Hari Bathini wrote:
> Seems like a bit of misunderstanding there. Function entry here intends
> to mean the actual start of function code (function prologue) - after
> GEP and function profiling sequence (mflr r0; bl mcount).
What you call "function e
Hi!
On Mon, Nov 04, 2024 at 03:40:26PM +0530, Hari Bathini wrote:
> On 04/11/24 3:14 pm, Segher Boessenkool wrote:
> >On Mon, Nov 04, 2024 at 02:51:57PM +0530, Hari Bathini wrote:
> >>On 02/11/24 2:29 am, Segher Boessenkool wrote:
> >>>On Sat, Nov 02, 2024 at 12:49:
Hi!
On Mon, Nov 04, 2024 at 02:51:57PM +0530, Hari Bathini wrote:
> On 02/11/24 2:29 am, Segher Boessenkool wrote:
> >On Sat, Nov 02, 2024 at 12:49:25AM +0530, Hari Bathini wrote:
> >>For ppc64le, depending on the kernel configuration used, offset 16
> >>from functio
Hi!
On Sat, Nov 02, 2024 at 12:49:25AM +0530, Hari Bathini wrote:
> For ppc64le, depending on the kernel configuration used, offset 16
> from function start address can also be considered function entry.
> Update the test case to accommodate such configurations.
(This is true for all ELfv2, not j
mm != mm)
> return;
> if (likely(!(atomic_read(&mm->membarrier_state) &
I'd say "CSE and similar transformations", but yeah, in this case CSE.
The point is that any access to a volatile object is a necessary side-
effect, so it has to be performed on the actual machine just as on the
abstract machine (on all the same paths, and as often). It might be
nice to have an atomic_read (for PowerPC) that can generate better
machine code. Not a trivial task though!
Reviewed-by: Segher Boessenkool
Segher
Hi!
On Fri, Oct 25, 2024 at 11:29:38AM +1100, Michael Ellerman wrote:
> [To += Mathieu]
>
> "Nysal Jan K.A." writes:
> > From: "Nysal Jan K.A"
> >
> > On architectures where ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
> > is not selected, sync_core_before_usermode() is a no-op.
> > In membarrier_mm_sync
Hi!
On Sat, Oct 19, 2024 at 12:50:43PM +1300, Paulo Miguel Almeida wrote:
> On Fri, Oct 18, 2024 at 10:38:43AM -0500, Segher Boessenkool wrote:
> > On Fri, Oct 18, 2024 at 09:28:19PM +1300, Paulo Miguel Almeida wrote:
> > > The C99 standard specifies that {v}snprintf() returns
On Fri, Oct 18, 2024 at 09:28:19PM +1300, Paulo Miguel Almeida wrote:
> The C99 standard specifies that {v}snprintf() returns the length of the
> data that *would have been* written if there were enough space.
Not including the trailing zero byte, and it can also return negative if
there was an en
id);
> #ifdef __VDSO64__
> #define V_FUNCTION_BEGIN(name) \
> .globl name;\
> + .type name,@function; \
> name: \
>
> #define V_FUNCTION_END(name) \
Ha cool! Excellent. Thank you :-)
Reviewed-By: Segher Boessenkool
Segher
{read, write}()
> without volatile")
> Cc: sta...@vger.kernel.org # v2.6.24+
> Reported-by: Stephen Rothwell
> Closes: https://lore.kernel.org/all/20240913125302.0a06b...@canb.auug.org.au
> Signed-off-by: Michael Ellerman
Reviewed-By: Segher Boessenkool
Segher
On Thu, Aug 29, 2024 at 07:36:38PM +0200, Christophe Leroy wrote:
>
>
> Le 28/08/2024 à 19:25, Segher Boessenkool a écrit :
> >
> >>Not sure about static binaries, though: do those even use the VDSO?
> >
> >With "static binary" people usually mean
On Wed, Aug 28, 2024 at 07:12:55PM +0200, Ard Biesheuvel wrote:
> On Wed, 28 Aug 2024 at 18:24, Segher Boessenkool
> wrote:
> > > In my experience, this is likely to do the opposite: it causes the
> > > compiler to 'forget' the semantics of memcpy() and memset
On Wed, Aug 28, 2024 at 02:26:08PM +0200, Jason A. Donenfeld wrote:
> On Wed, Aug 28, 2024 at 2:24 PM Arnd Bergmann wrote:
> >
> > On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:
> > > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> >
On Wed, Aug 28, 2024 at 12:24:12PM +, Arnd Bergmann wrote:
> On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:
> > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> >> On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> >> &g
On Wed, Aug 28, 2024 at 01:18:34PM +0200, Jason A. Donenfeld wrote:
> On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:
> > On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> > > > + for (i = 0; i < ARRAY_S
On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> On Thu, Aug 22, 2024 at 09:13:13AM +0200, Christophe Leroy wrote:
> > With the current implementation, __cvdso_getrandom_data() calls
> > memset(), which is unexpected in the VDSO.
> >
> > Rewrite opaque data initialisation to avoid m
On Sat, Aug 24, 2024 at 09:01:33AM +, LEROY Christophe wrote:
> Le 23/08/2024 à 21:19, Segher Boessenkool a écrit :
> > The memset() code itself could chech for the storage attributes, but
> > that is probably more expensive than just assuming the happy case.
> > Maybe som
Hi!
On Fri, Aug 23, 2024 at 03:54:59PM +0200, Christoph Hellwig wrote:
> On Fri, Aug 23, 2024 at 08:06:00AM -0500, Segher Boessenkool wrote:
> > What does "uncached memory" even mean here? Literally it would be
> > I=1 memory (uncachEABLE memory), but more likely you
Hi!
On Thu, Aug 22, 2024 at 06:39:33AM +, LEROY Christophe wrote:
> Le 22/08/2024 à 07:32, Christoph Hellwig a écrit :
> > On Thu, Aug 22, 2024 at 05:25:10AM +, LEROY Christophe wrote:
> >>> and this results in a call to dma_direct_allocation(), which has one
> >>> innocent looking memset(
On Fri, Jul 05, 2024 at 11:19:39AM +1000, Michael Ellerman wrote:
> + prom_printf("nemo: deleting interrupt-map properties\n");
> + rc = call_prom("interpret", 1, 1,
> + " s\" /pxp@0,e000\" find-device"
> + " s\" interrupt-map\" delete-property"
> +
On Tue, Jun 18, 2024 at 10:12:54PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Mon, Jun 17, 2024 at 10:35:09AM +0800, Jinglin Wen wrote:
> >> + cmplwi cr0,r4,0/* runtime base addr is zero */
> >
> > Just write
> >cmpwi r
he constraint has been incorrect since it was first
> added.
Yes, "m" allows any memory operand, an unaligned one is just fine.
Acked-by: Segher Boessenkool
Segher
Hi!
On Mon, Jun 17, 2024 at 10:35:09AM +0800, Jinglin Wen wrote:
> + cmplwi cr0,r4,0/* runtime base addr is zero */
Just write
cmpwi r4,0
cr0 is the default, also implicit in many other instructions, please
don't clutter the source code. All the extra stuff makes you miss the
th
On Fri, Jun 14, 2024 at 10:43:39AM +1000, Nicholas Piggin wrote:
> On Wed Jun 12, 2024 at 6:28 PM AEST, Segher Boessenkool wrote:
> > On Wed, Jun 12, 2024 at 02:42:32PM +1000, Nicholas Piggin wrote:
> > > arm, powerpc, riscv, build .aux.o targets with implicit pattern rules
&
On Wed, Jun 12, 2024 at 02:42:32PM +1000, Nicholas Piggin wrote:
> arm, powerpc, riscv, build .aux.o targets with implicit pattern rules
> in dependency chains that cause them to be made as intermediate files,
> which get removed when make finishes. This results in unnecessary
> partial rebuilds. I
On Fri, Jun 07, 2024 at 10:42:44PM +1000, Michael Ellerman wrote:
> I use the korg toolchains every day, and kisskb uses them too.
>
> What commit / defconfig are you seeing the errors with?
>
> Is it just the 12.3.0 toolchain or all of them? I just tested 12.3.0
> here and it built OK.
>
> I gu
Hi!
On Thu, May 16, 2024 at 10:06:58PM +1000, Michael Ellerman wrote:
> Andy Polyakov writes:
> >>> +.abiversion 2
> >>
> >> I'd prefer that was left to the compiler flags.
> >
> > Problem is that it's the compiler that is responsible for providing this
> > directive in the intermediate .s p
On Wed, May 15, 2024 at 10:29:56AM +0200, Andy Polyakov wrote:
> >+static void cswap(fe51 p, fe51 q, unsigned int bit)
>
> The "c" in cswap stands for "constant-time," and the problem is that
> contemporary compilers have exhibited the ability to produce
> non-constant-time machine code as resul
On Fri, May 10, 2024 at 04:45:37PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Thu, May 09, 2024 at 10:12:48PM +1000, Michael Ellerman wrote:
> >> cpu_has_feature()/mmu_has_feature() are only able to check a single
> >> feature at a time, but ther
On Thu, May 09, 2024 at 10:12:48PM +1000, Michael Ellerman wrote:
> cpu_has_feature()/mmu_has_feature() are only able to check a single
> feature at a time, but there is no enforcement of that.
>
> In fact, as fixed in the previous commit, there was code that was
> passing multiple values to cpu_h
On Tue, Apr 16, 2024 at 03:02:52PM +0530, Naresh Kamboju wrote:
> In file included from arch/powerpc/include/asm/io.h:672:
> arch/powerpc/include/asm/io-defs.h:43:1: error: performing pointer
> arithmetic on a null pointer has undefined behavior
> [-Werror,-Wnull-pointer-arithmetic]
It is not UB,
On Tue, Mar 26, 2024 at 06:19:38PM +1100, Michael Ellerman wrote:
> Mathieu Desnoyers writes:
> The ISA doesn't specify the cache line size, other than it is smaller
> than a page.
It also says it is "aligned". Nowhere is it said what an aligned size
is, but it seems clear it has to be a power o
On Mon, Mar 25, 2024 at 03:34:30PM -0500, Nathan Lynch wrote:
> Mathieu Desnoyers writes:
> For what it's worth, I found a copy of an IBM Journal of Research &
> Development article confirming that POWER5's L3 had a 256-byte line
> size:
>
> Each slice [of the L3] is 12-way set-associative, wit
All instructions with a primary opcode from 32 to 63 are memory insns,
and no others. It's trivial to see whether it is a load or store, too
(just bit 3 of the insn). Trying to parse disassembled code is much
harder, and you easily make some mistakes here.
On Sat, Mar 09, 2024 at 12:55:12PM +053
On Thu, Feb 29, 2024 at 11:25:21PM +1100, Michael Ellerman wrote:
> From: Christophe Leroy
Acked-by: Segher Boessenkool
Segher
got rid of the __stringify blight as well. Great :-)
Acked-by: Segher Boessenkool
Segher
bt to specify
> which encoding is desired.
>
> Signed-off-by: Michael Ellerman
Looks good, thanks!
Acked-by: Segher Boessenkool
Segher
On Wed, Feb 14, 2024 at 11:37:21AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 14, 2024 at 09:46:33AM +, David Laight wrote:
> > From: Segher Boessenkool
> > > Sent: 13 February 2024 19:13
> > >
> > > On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergm
On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergmann wrote:
> clang warns about explicitly casting between incompatible function
> pointers:
>
> drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void *)'
> to 'void (*)(struct device *)' converts to incompatible function type
rs across all of the affected architectures. Is that likely to
> occur?
I don't know. Here is my PowerPC-specific patch, it's a bit older, it
might not apply cleanly anymore, the changes needed should be obvious
though:
=== 8< ===
commit f16dfa5257eb14549ce22243fb2b465615085134
Author: S
On Mon, Feb 12, 2024 at 11:46:19AM -0600, Timothy Pearson wrote:
> Interesting, that make sense.
>
> How should we proceed from the current situation? Bringing in libgcc seems
> like a fairly invasive change,
I have done it for *all* architectures some ten years ago. Never found
any problem.
>
On Mon, Feb 12, 2024 at 11:09:38AM -0600, Timothy Pearson wrote:
> There is existing code in the kernel right now to provide support functions
> for gpr0 and altivec save/restore. I don't know the full story here, but at
> some point in the kernel's history it seems to have been decided to provi
On Mon, Feb 12, 2024 at 10:41:18AM -0600, Timothy Pearson wrote:
> Implement gpr1 and fpu save/restore functions per the ABI v2 documentation.
There is no "ABI v2". This is the ELFv2 ABI, it is a name, it is not a
version 2 of anything (in fact, it is version 1 everywhere).
The same functions ar
Hi!
On Thu, Jan 25, 2024 at 05:12:28PM +0530, Naveen N Rao wrote:
> diff --git a/arch/powerpc/kernel/interrupt_64.S
> b/arch/powerpc/kernel/interrupt_64.S
> index bd863702d812..5cf3758a19d3 100644
> --- a/arch/powerpc/kernel/interrupt_64.S
> +++ b/arch/powerpc/kernel/interrupt_64.S
> @@ -53,6 +53
On Tue, Jan 09, 2024 at 03:15:35PM +, Christophe Leroy wrote:
> > CFLAGS-$(CONFIG_PPC64)+= $(call cc-option,-mcall-aixdesc)
> > endif
> > endif
> > -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call
> > cc-option,-mminimal-toc))
> > +CFLAGS-$(CONFIG_PPC64) +=
piler uses? There is no reason this
shouldn't work (you don't use any system libraries), but you need to
use the correct compiler command-line flags for that always.
Acked-by: Segher Boessenkool
Segher
On Wed, Dec 06, 2023 at 10:55:46PM +1100, Michael Ellerman wrote:
> But the 64-bit compiler doesn't define powerpc in the first place,
Yes, only __powerpc__ (and __powerpc64__) :-)
Segher
On Tue, Oct 31, 2023 at 09:56:00AM -0500, Bjorn Helgaas wrote:
> That said, the unused functions do look legit:
>
> grackle_set_stg() is a static function and the only call is under
> "#if 0".
It is a static inline. It is *normal* that that is uncalled. It is
very similar to a macro that has no
On Tue, Sep 19, 2023 at 12:00:34AM +, Peter Lafreniere wrote:
> On Monday, September 18th, 2023 at 19:41, Segher Boessenkool
> wrote:
> > On Mon, Sep 18, 2023 at 05:56:09PM +, Peter Lafreniere wrote:
> >
> > > ReiserFS has been considered deprecated
On Mon, Sep 18, 2023 at 05:56:09PM +, Peter Lafreniere wrote:
> ReiserFS has been considered deprecated for 19 months since commit
> eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are
> several architectures that still build it into their defconfig kernels.
>
> As ReiserFS will
On Thu, Jun 15, 2023 at 01:34:25PM +1000, Michael Ellerman wrote:
> Eric DeVolder writes:
> > -config KEXEC_FILE
> > - bool "kexec file based system call"
> > - select KEXEC_CORE
> > - select HAVE_IMA_KEXEC if IMA
> > - select KEXEC_ELF
> > - depends on PPC64
> > - depends on CRYPTO=y
Hi!
On Tue, Jun 06, 2023 at 08:35:22PM +0530, Umesh Kalappa wrote:
> Hi Adnrew,
> Thank you for the quick response and for PPC64 too ,we do have
> mismatches in ABI b/w complex operations like
> https://godbolt.org/z/bjsYovx4c .
>
> Any reason why GCC chose to use GPR 's here ?
What did you expe
On Mon, Apr 24, 2023 at 08:28:55AM -0700, Boqun Feng wrote:
> On Mon, Apr 24, 2023 at 10:13:51AM -0500, Segher Boessenkool wrote:
> > At what points can r13 change? Only when some particular functions are
> > called?
>
> r13 is the local paca:
>
> register str
Hi!
On Mon, Apr 24, 2023 at 11:14:00PM +1000, Michael Ellerman wrote:
> Boqun Feng writes:
> > On Sat, Apr 22, 2023 at 09:28:39PM +0200, Joel Fernandes wrote:
> >> On Sat, Apr 22, 2023 at 2:47 PM Zhouyi Zhou wrote:
> >> > by debugging, I see the r10 is assigned with r13 on c0226eb4,
> >>
Hi!
On Wed, Apr 05, 2023 at 03:32:21PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Tue, Apr 04, 2023 at 08:28:47PM +1000, Michael Ellerman wrote:
> >> The amdgpu driver builds some of its code with hard-float enabled,
> >> whereas the rest of th
he deeper problem is :-/
In either case, the kernel should always use specific types, not rely on
the toolchain to pick a type that may or may not work. The correct size
floating point type alone is not enough, but it is a step in the right
direction certainly.
Reviewed-by: Segher Boessenkool
Segher
Hi!
On Wed, Jan 25, 2023 at 12:57:35PM +0530, Naveen N. Rao wrote:
> Sathvika Vasireddy wrote:
> >--- a/arch/powerpc/kvm/booke.c
> >+++ b/arch/powerpc/kvm/booke.c
> >@@ -917,7 +917,9 @@ static void kvmppc_fill_pt_regs(struct pt_regs *regs)
> > asm("mr %0, 1" : "=r"(r1));
> > asm("m
On Thu, Jan 26, 2023 at 12:09:53AM +1100, Michael Ellerman wrote:
> Andrew Donnellan writes:
> > A number of structures and buffers passed to PKS hcalls have alignment
> > requirements, which could on occasion cause problems:
> >
> > - Authorisation structures must be 16-byte aligned and must not
On Tue, Jan 24, 2023 at 09:14:52AM -0700, Nathan Chancellor wrote:
> On Mon, Jan 23, 2023 at 09:07:16AM -0600, Segher Boessenkool wrote:
> > And here it is even more obviously fine. If you need obfuscation like
> > in your patch, it is better not to do this imo.
>
> I do
Hi!
On Wed, Jan 11, 2023 at 08:05:04PM -0700, Nathan Chancellor wrote:
> When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there
> are several warnings in the PowerPC vDSO:
>
> clang-16: error: -Wl,-soname=linux-vdso32.so.1: 'linker' input unused
> [-Werror,-Wunused-command-line
On Thu, Jan 19, 2023 at 09:31:21PM -0600, Rob Landley wrote:
> On 1/19/23 16:11, Michael.Karcher wrote:
> > I don't see a clear bug at this point. We are talking about the C expression
> >
> > __same_type((void*)0, (void*)0)? 0 : sizeof((void*)0)/sizeof(*((void*0))
(__same_type is a kernel mac
On Mon, Jan 09, 2023 at 05:51:23PM -0700, Nathan Chancellor wrote:
> So for this patch, I have
>
> When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it
> warns:
>
> clang-16: error: argument unused during compilation: '-s'
> [-Werror,-Wunused-command-line-argument]
>
>
On Tue, Jan 10, 2023 at 01:22:38AM +0100, Andreas Schwab wrote:
> On Jan 09 2023, Segher Boessenkool wrote:
>
> > It is required by POSIX (for the c99 command, anyway). It *also* is
> > required to be supported when producing object files (so when no linking
> > is do
On Mon, Jan 09, 2023 at 03:37:53PM -0700, Nathan Chancellor wrote:
> On Mon, Jan 09, 2023 at 04:23:37PM -0600, Segher Boessenkool wrote:
> > Hi! Happy new year all.
> >
> > On Mon, Jan 09, 2023 at 01:58:32PM -0800, Nick Desaulniers wrote:
> > > On Wed, Jan 4, 2023
was this ever supposed to be?
> FWICT it predates git history (looking at
> arch/powerpc/kernel/vdso32/Makefile at fc15351d9d63)
Yeah, good question. This compiler flag does the moral equivalent of
strip -s (aka --strip-all). Maybe this was needed at some point, or
the symbol or debug info was just annoying (during bringup or similar)?
> Reviewed-by: Nick Desaulniers
Reviewed-by: Segher Boessenkool
Segher
On Fri, Dec 16, 2022 at 11:23:59PM +0100, Pali Rohár wrote:
> > It appears the E500MC64 never made it outside of FSL, so it is best not
> > to use it at all, imo.
>
> Yes, it really makes sense to not use e500mc64 flag. Maybe gcc
> documentation could be updated to mention this fact?
Thanks. I f
Hi!
On Thu, Dec 15, 2022 at 09:42:02PM +0100, Pali Rohár wrote:
> On Wednesday 07 December 2022 14:38:40 Christophe Leroy wrote:
> > default "power8" if POWER8_CPU
> > default "power9" if POWER9_CPU
> > default "power10" if POWER10_CPU
> > + default "e500mc64" if E5500_CPU
>
> Now I
On Fri, Dec 16, 2022 at 05:57:46PM +, Christophe Leroy wrote:
> Le 16/12/2022 à 18:18, Segher Boessenkool a écrit :
> > On Fri, Dec 16, 2022 at 09:35:50AM +0100, Christophe Leroy wrote:
> >> Today we have CONFIG_TARGET_CPU which provides the identification of the
> >&g
Hi!
On Fri, Dec 16, 2022 at 09:35:50AM +0100, Christophe Leroy wrote:
> The problem comes from the fact that CONFIG_PPC_E500MC is selected for
> both the e500mc (32 bits) and the e5500 (64 bits), and therefore the
> following makefile rule is wrong:
>
> cpu-as-$(CONFIG_PPC_E500MC)+= $(call
On Thu, Dec 15, 2022 at 10:29:38AM -0600, Segher Boessenkool wrote:
> The kernel does not do any of the more
> problematic cases I think, but no promises (dynamic stack alignment,
> recursive functions
Before people get scared: I meant *nested* functions. With a static
chain and
On Thu, Dec 15, 2022 at 10:52:35AM +1000, Nicholas Piggin wrote:
> On Thu Dec 15, 2022 at 10:17 AM AEST, Segher Boessenkool wrote:
> > On Wed, Dec 14, 2022 at 09:39:25PM +1000, Nicholas Piggin wrote:
> > > What about just copying x86's implementation including using
> >
On Wed, Dec 14, 2022 at 09:39:25PM +1000, Nicholas Piggin wrote:
> What about just copying x86's implementation including using
> __builtin_frame_address(1/2)? Are those builtins reliable for all
> our targets and compiler versions?
__builtin_frame_address(n) with n > 0 is specifically not support
Hi!
On Wed, Dec 14, 2022 at 07:36:32PM +0100, Jan-Benedict Glaw wrote:
> So we have these remaining build issues:
>
> linux-powerpc-cell_defconfig bad asm
> (arch/powerpc/boot/pseries-head.S)
> linux-powerpc-mvme5100_defconfig bad asm
> (arch/powerpc/kernel/epapr_hcalls.S)
> lin
On Wed, Dec 14, 2022 at 03:33:24PM +, Christophe Leroy wrote:
> Le 13/12/2022 à 21:25, Segher Boessenkool a écrit :
> > On Tue, Dec 13, 2022 at 07:03:07PM +0100, Christophe Leroy wrote:
> >> In binutils 2.35, 'nm -D' changed to show symbol versions along with
>
On Tue, Dec 13, 2022 at 07:03:07PM +0100, Christophe Leroy wrote:
> In binutils 2.35, 'nm -D' changed to show symbol versions along with
> symbol names, with the usual @@ separator.
2.37 instead? And --without-symbol-versions is there to restore the
old behaviour. The script is parsing the outpu
On Tue, Dec 13, 2022 at 09:41:59AM +0100, Jan-Benedict Glaw wrote:
> On Tue, 2022-12-13 14:49:20 +1100, Michael Ellerman
> wrote:
> > So your script should exclude all files that end in ".config".
>
> Thanks! Will just drop those.
>
> > To find the names of the generated configs you can use so
Hi!
On Mon, Dec 12, 2022 at 10:51:17PM +0100, Jan-Benedict Glaw wrote:
> Is anybody else routinely building current Binutils + GCC, to try to
> build all the Linux defconfigs?
I do regularly build kernels for powerpc-linux, powerpc64-linux,
powerpc64le-linux; ppc6xx_defconfig and ppc64_defconfig
1 - 100 of 1298 matches
Mail list logo
