{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
Hi!
On Mon, Nov 07, 2022 at 02:31:59PM +1100, Rohan McLure wrote:
> Add Kconfig option for enabling clearing of registers on arrival in an
> interrupt handler. This reduces the speculation influence of registers
> on kernel internals.
Assuming you are talking about existing PowerPC CPUs from the
On Mon, Oct 31, 2022 at 03:54:22PM +1000, Nicholas Piggin wrote:
> Could the user set r1 to be equal to the address matching the first
> interrupt frame - STACK_INT_FRAME_SIZE, which is in the previous page
> due to the kernel redzone, and induce the kernel to load the marker from
> there? Possibly
On Mon, Oct 17, 2022 at 09:53:04AM +0200, Christian Zigotzky wrote:
> > On 17. Oct 2022, at 02:43, Michael Ellerman wrote:
> > Previously BIG_ENDIAN && GENERIC_CPU would use -mcpu=power5, now it uses
> > -mcpu=power4.
>
> Maybe this is the issue. We will wait and not release the RC1 for testing
On Fri, Oct 14, 2022 at 06:11:21PM +0200, Christian Zigotzky wrote:
> make oldconfig has asked because of the CPU family. I choosed GENERIC for my
> P.A. Semi PWRficient PA6T-1682M. Is this correct? Maybe this is the problem.
>
> config GENERIC_CPU
> - bool "Generic (POWER4 and above)"
> +
On Fri, Oct 07, 2022 at 10:03:38AM +1000, Nicholas Piggin wrote:
> On Fri Oct 7, 2022 at 9:23 AM AEST, Segher Boessenkool wrote:
> > > For pcrel addressing? Bootstrapping the C environment is one, the
> > > module dynamic linker is another.
> >
> > I don't kno
On Fri, Oct 07, 2022 at 04:31:28PM +1100, Michael Ellerman wrote:
> "Nicholas Piggin" writes:
> > On Fri Oct 7, 2022 at 9:23 AM AEST, Segher Boessenkool wrote:
> >> On Fri, Oct 07, 2022 at 07:56:09AM +1000, Nicholas Piggin wrote:
> >> > On Fri Oct 7, 2022 a
On Fri, Oct 07, 2022 at 07:56:09AM +1000, Nicholas Piggin wrote:
> On Fri Oct 7, 2022 at 5:54 AM AEST, Segher Boessenkool wrote:
> > On Fri, Sep 23, 2022 at 01:30:04PM +1000, Nicholas Piggin wrote:
> > > This adds basic POWER10_CPU option, which builds with -mcpu=power10.
> &g
On Thu, Oct 06, 2022 at 08:50:31PM +, Christophe Leroy wrote:
> Le 06/10/2022 à 22:45, Segher Boessenkool a écrit :
> > I meant just an indicative code size number... 100 bytes, 100kB, 100MB,
> > or something like that :-) And, on 64 bit, which is what the question
> &g
On Thu, Oct 06, 2022 at 06:38:00PM +, Christophe Leroy wrote:
> Le 06/10/2022 à 20:22, Segher Boessenkool a écrit :
> > Long ago I built kernels that fit together with the boot firmware and a
> > root fs (busybox+dropbear essentially) in 4MB, but I doubt we can get
> >
Hi!
On Thu, Oct 06, 2022 at 06:07:32PM +, Christophe Leroy wrote:
> Le 23/09/2022 à 08:23, Nicholas Piggin a écrit :
> > I would rather complete prefixed support in the kernel and use pcrel
> > addressing. Actually even if we don't compile with pcrel or prefixed,
> > there are some instruction
Hi!
On Fri, Sep 23, 2022 at 01:30:04PM +1000, Nicholas Piggin wrote:
> This adds basic POWER10_CPU option, which builds with -mcpu=power10.
> +# No prefix or pcrel
> +KBUILD_CFLAGS += $(call cc-option,-mno-prefixed)
> +KBUILD_CFLAGS += $(call cc-option,-mno-pcrel)
Why do you disable all prefixed
On Thu, Oct 06, 2022 at 11:39:50AM +1100, Michael Ellerman wrote:
> Christophe Leroy writes:
> > However, thinking out loudly, I'm wondering, could we make things any
> > simpler when CONFIG_MODULES is not selected, or is that a too much
> > corner case on PPC64 ?
>
> I'd say it's mostly a corn
On Fri, Sep 23, 2022 at 05:15:43PM -0500, Segher Boessenkool wrote:
> On Sat, Sep 24, 2022 at 02:26:52AM +1000, Nicholas Piggin wrote:
> > I still don't see what clauses guarantees asm("%0" ::"r"(foo)) to give
> > 13. It doesn't say access via inline as
On Sat, Sep 24, 2022 at 02:00:55PM +1000, Nicholas Piggin wrote:
> On Sat Sep 24, 2022 at 8:15 AM AEST, Segher Boessenkool wrote:
> > Never it is guaranteed that all accesses through this variable will use
> > the register directly: this fundamentally cannot work on all archs, and
On Sat, Sep 24, 2022 at 02:26:52AM +1000, Nicholas Piggin wrote:
> I still don't see what clauses guarantees asm("%0" ::"r"(foo)) to give
> 13. It doesn't say access via inline assembly is special,
But it is. It is for all register variables, local and global. I agree
this isn't documented clear
On Fri, Sep 23, 2022 at 05:17:45PM +1000, Nicholas Piggin wrote:
> On Thu Sep 22, 2022 at 4:50 AM AEST, Segher Boessenkool wrote:
> > On Wed, Sep 21, 2022 at 11:41:02AM +1000, Nicholas Piggin wrote:
> > > Big-endian GENERIC_CPU supports 970, but builds with -mcpu=power5.
> &g
On Fri, Sep 23, 2022 at 05:08:13PM +1000, Nicholas Piggin wrote:
> On Tue Sep 20, 2022 at 4:41 PM AEST, Christophe Leroy wrote:
> > local_paca is declared as global register asm("r13"), it is therefore
> > garantied to always ever be r13.
> >
> > It is therefore not required to opencode r13 in the
> This also updates the ISA versions document to add Power4/Power4+
> because I didn't realise Power4+ used 2.01.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Segher Boessenkool
Cheers,
Segher
er4.
>
> Fixes: 471d7ff8b51b ("powerpc/64s: Remove POWER4 support")
> Signed-off-by: Nicholas Piggin
Reviewed-by: Segher Boessenkool
Thank you!
Maybe superfluous, but some more context: GCC's -mcpu=power4 means
POWER4+, ISA 2.01, according to our documentation. There is no
diff
Hi!
On Wed, Sep 21, 2022 at 11:01:18AM +1000, Nicholas Piggin wrote:
> On Wed Sep 21, 2022 at 8:16 AM AEST, Segher Boessenkool wrote:
> > On Tue, Sep 20, 2022 at 12:01:47AM +1000, Nicholas Piggin wrote:
> > > Update the 64s GENERIC_CPU option. POWER4 support has been dropped,
Hi!
On Tue, Sep 20, 2022 at 12:01:47AM +1000, Nicholas Piggin wrote:
> Update the 64s GENERIC_CPU option. POWER4 support has been dropped, so
> make that clear in the option name.
AFAIR the minimum now is POWER4+ (ISA 2.01), not POWER5 (ISA 2.02).
> -mtune= before power8 is dropped because the m
On Wed, Sep 14, 2022 at 04:55:27PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 14, 2022 at 02:28:26PM +, Michael Matz wrote:
> > Don't mix DWARF debug info with DWARF-based unwinding info, the latter
> > doesn't imply the former. Out of interest: how does ORC get around the
> > need for CFI a
On Wed, Sep 14, 2022 at 11:21:00AM +0100, Josh Poimboeuf wrote:
> On Mon, Sep 12, 2022 at 06:31:14AM -0500, Segher Boessenkool wrote:
> > On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote:
> > > 2) Noreturn functions:
> > >
> > >There&
Hi!
On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote:
> 2) Noreturn functions:
>
>There's no reliable way to determine which functions are designated
>by the compiler to be noreturn (either explictly via function
>attribute, or implicitly via a static function which i
Hi!
On Thu, Sep 08, 2022 at 05:07:24PM +0200, Arnd Bergmann wrote:
> - if the XOR code has its frame size explode like this, it's
> probably an indication of the compiler doing something wrong,
> not the kernel code.
On the contrary, it is most likely an indication that the kernel code
wants
On Thu, Sep 08, 2022 at 06:00:24AM +, Christophe Leroy wrote:
> Looking at it more deeply, I see strange things.
I'll have to see full generated machine code to be able to see strange
things, there isn't enough information at all here yet. Sorry.
Use private mail if it is too big or unintere
Hi!
On Mon, Sep 05, 2022 at 04:15:07PM +0530, Naveen N. Rao wrote:
> Segher Boessenkool wrote:
> >>> + if ((insn & 3) == 1) {
> >>> + *type = INSN_CALL;
> >>> + *immediate = insn & 0x3fc;
>
On Fri, Sep 02, 2022 at 10:57:27AM -0500, Peter Bergner wrote:
> On 8/31/22 5:45 PM, Segher Boessenkool wrote:
> > Yes, this is guaranteed.
>
> Agree with Segher here. That said, there was a gcc bug a long time
> ago where gcc copied r13 into a temporary register and used i
Hi!
On Fri, Sep 02, 2022 at 09:11:48AM -0700, Nathan Chancellor wrote:
> On Fri, Sep 02, 2022 at 10:59:54AM -0500, Segher Boessenkool wrote:
> > Maybe add -Wno-implicit-fallthrough? This code is a copy from outside
> > the kernel, no one has ever wanted to maintain it, if no
On Fri, Sep 02, 2022 at 08:37:23AM -0700, Nathan Chancellor wrote:
> On Fri, Sep 02, 2022 at 12:08:55PM +0200, Christophe Leroy wrote:
> > This should have been detected by gcc at build time, but due to
> > '-w' flag it went undetected.
> >
> > Removing that flag leads to many warnings hence error
Hi!
On Fri, Sep 02, 2022 at 09:57:09AM +0200, Christophe Leroy wrote:
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -128,7 +128,8 @@ extra-y += vmlinux.lds
>
> obj-$(CONFIG_RELOCATABLE)+= reloc_$(BITS).o
>
> -obj-$(CONFIG_PPC32)
On Fri, Sep 02, 2022 at 08:43:49AM +, Christophe Leroy wrote:
> Le 01/09/2022 à 21:47, Segher Boessenkool a écrit :
> > On Thu, Sep 01, 2022 at 05:41:33AM +, Christophe Leroy wrote:
> >> I think it would be worth a GCC bug report.
> >
> > We need a stand-alon
1 - 100 of 1266 matches
Mail list logo