On Tue, Sep 16, 2025 at 12:10:14PM +1000, Ash Logan wrote:
> On 15/9/25 00:14, Segher Boessenkool wrote:
> > On Sat, Sep 13, 2025 at 08:53:08PM +1000, Ash Logan wrote:
> > > Wii (2006)
> > > - 1x PowerPC 750CL "Broadway" @ 729MHz
> > > - 24MB &quo
On Tue, Sep 16, 2025 at 11:57:00AM +1000, Ash Logan wrote:
> On 13/9/25 23:52, Arnd Bergmann wrote:
> > The smaller devices are probable getting problematic sooner, 96MB
> > in the Wii is already really tight and this only gets worse over
> > time.
>
> The maintainer of that downstream claims to b
Hi!
On Sat, Sep 13, 2025 at 08:53:08PM +1000, Ash Logan wrote:
> Wii (2006)
> - 1x PowerPC 750CL "Broadway" @ 729MHz
> - 24MB "MEM1" + 64MB "MEM2" (non-contiguous - MEM2 starts 256MiB in)
> - Kernel 4.19 (+ CIP patchset), dev has been working on forward-porting all
> the drivers one major version
Hi!
On Fri, Sep 12, 2025 at 08:21:10PM +0100, Mark Cave-Ayland wrote:
> Whilst the patch is fairly complete, the problem I have is that there
> doesn't appear to be a concise list of CPUs that use BLRM (as opposed to
> proper LE memory accesses) when MSR_LE is enabled.
*All* older PowerPC have ev
Hi!
On Fri, Sep 12, 2025 at 10:37:34AM +0200, Christophe Leroy wrote:
> BEGIN_FTR_SECTION
> + lwarx r0,0,r1
> +END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
> stwcx. r0,0,r1 /* to clear the reservation */
> -FTR_SECTION_ELSE
> - lwarx r0,0,r1
> -ALT_FTR_SECTION_END_I
Hi!
On Wed, Sep 03, 2025 at 02:14:42PM -0700, Nathan Chancellor wrote:
> On Wed, Sep 03, 2025 at 01:15:38AM -0500, Segher Boessenkool wrote:
> > On Tue, Sep 02, 2025 at 04:52:34PM -0700, Nathan Chancellor wrote:
> > > When building powerpc configurations in linux-5.4.y with binu
Hi!
On Tue, Sep 02, 2025 at 04:52:34PM -0700, Nathan Chancellor wrote:
> When building powerpc configurations in linux-5.4.y with binutils 2.43
> or newer, there is an assembler error in arch/powerpc/boot/util.S:
>
> arch/powerpc/boot/util.S: Assembler messages:
> arch/powerpc/boot/util.S:44:
On Fri, Aug 15, 2025 at 11:34:56AM -0500, Segher Boessenkool wrote:
> On Thu, Aug 07, 2025 at 03:16:35PM +0530, Madhavan Srinivasan wrote:
> > making them eligible for compiler optimization.
>
> You can instead use GCC for this. __builtin_ffs () exists since 2003,
Erm, 1992 actu
Hi!
On Thu, Aug 07, 2025 at 03:16:35PM +0530, Madhavan Srinivasan wrote:
> making them eligible for compiler optimization.
You can instead use GCC for this. __builtin_ffs () exists since 2003,
and has this attribute built-in, as well as tens of other optimisations
that the kernel thing misses.
On Sun, Aug 03, 2025 at 03:14:38PM -0700, Eric Biggers wrote:
> On Sun, Aug 03, 2025 at 05:07:10PM -0500, Segher Boessenkool wrote:
> > On Sun, Aug 03, 2025 at 01:44:29PM -0700, Eric Biggers wrote:
> > > MD5 is insecure,
> >
> > Really? Have you found an attack?
On Sun, Aug 03, 2025 at 01:44:29PM -0700, Eric Biggers wrote:
> MD5 is insecure,
Really? Have you found an attack? Can you explain it to the rest of
the world?
MD5 is not recommended for future cryptographic purposes, there have
been some collission "attacks" on it (quotes because such a thing
solve these self-inflicted
problems is to just use the libgcc that your version of GCC want to use,
the one it ships with itself, it being a necessary portion of the
compiler!
Here, an old patch of mine, this one for SuperH (I have stacks of such
patches, for many archs):
===
commit 9289694955c
On Fri, Jul 11, 2025 at 12:32:57AM -0700, Christoph Hellwig wrote:
> On Fri, Jul 11, 2025 at 09:30:31AM +0200, Greg Kroah-Hartman wrote:
> > That's a crazy exception, and one that should probably be talked about
> > with the FSF to determine exactly what the SPDX lines should be.
>
> It is called
On Fri, Jul 11, 2025 at 05:02:18PM -0400, Richard Fontana wrote:
> On Fri, Jul 11, 2025 at 3:38 AM Greg Kroah-Hartman
> wrote:
> >
> > On Fri, Jul 11, 2025 at 12:32:57AM -0700, Christoph Hellwig wrote:
> > > On Fri, Jul 11, 2025 at 09:30:31AM +0200, Greg Kroah-Hartman wrote:
> > > > That's a crazy
See https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt for example)
That looks good, this is indeed the newer GPLv2 text.
Acked-by: Segher Boessenkool
> diff --git a/arch/powerpc/boot/crtsavres.S b/arch/powerpc/boot/crtsavres.S
Segher
> index 085fb2b9a8b89..a710a49a5dbca 100644
> ---
Hi!
On Sat, Jul 05, 2025 at 10:05:38PM +0100, David Laight wrote:
> On Sat, 5 Jul 2025 15:15:57 -0500
> Segher Boessenkool wrote:
>
> ...
> > The isel machine instruction is super expensive on p8: it is marked as
> > first in an instruction group, and has latency 5 for
Hi!
On Sat, Jul 05, 2025 at 07:33:32PM +0100, David Laight wrote:
> On Thu, 26 Jun 2025 17:01:48 -0500
> Segher Boessenkool wrote:
> > On Thu, Jun 26, 2025 at 07:56:10AM +0200, Christophe Leroy wrote:
> ...
> > I have no idea why you think power9 has it while older CPUS do
Hi!
On Sat, Jul 05, 2025 at 12:55:06PM +0200, Christophe Leroy wrote:
> > > For book3s64, GCC only use isel with -mcpu=power9 or -mcpu=power10
> >
> > I have no idea what "book3s64" means.
>
> Well that's the name given in Linux kernel to the 64 bits power CPU
> processors.
A fantasy name. Gre
producing dynamic objects, so this code just sets that text and
that's all, no side effect to be worried of.
Acked-by: Segher Boessenkool
(Maybe this could or should be in generic code though, not architecture
code?)
Segher
On Thu, Jun 26, 2025 at 07:56:10AM +0200, Christophe Leroy wrote:
> Le 24/06/2025 à 23:08, David Laight a écrit :
> >On Tue, 24 Jun 2025 13:25:05 -0500
> >Segher Boessenkool wrote:
> >>>>isel (which is base PowerPC, not something "e500" only) is a
> >
Hi!
On Tue, Jun 24, 2025 at 10:08:16PM +0100, David Laight wrote:
> On Tue, 24 Jun 2025 13:25:05 -0500
> Segher Boessenkool wrote:
> > On Tue, Jun 24, 2025 at 05:50:01PM +0100, David Laight wrote:
> > > On Tue, 24 Jun 2025 08:17:14 -0500
> > > Segher Boessenkool
Hi!
On Tue, Jun 24, 2025 at 09:32:58AM +0100, David Laight wrote:
> > So GCC uses the 'unlikely' variant of the branch instruction to force
> > the correct prediction, doesn't it ?
>
> Nope...
> Most architectures don't have likely/unlikely variants of branches.
In GCC, "likely" means 80%. "Ver
Hi!
On Tue, Jun 24, 2025 at 05:50:01PM +0100, David Laight wrote:
> On Tue, 24 Jun 2025 08:17:14 -0500
> Segher Boessenkool wrote:
>
> > On Tue, Jun 24, 2025 at 07:27:47AM +0200, Christophe Leroy wrote:
> > > Ah ok, I overlooked that, I didn't know the cmove instru
On Tue, Jun 24, 2025 at 07:27:47AM +0200, Christophe Leroy wrote:
> Ah ok, I overlooked that, I didn't know the cmove instruction, seem
> similar to the isel instruction on powerpc e500.
cmove does a move (register or memory) when some condition is true.
isel (which is base PowerPC, not something
Hi!
On Sun, Jun 22, 2025 at 06:13:51PM +0100, David Laight wrote:
> On Sun, 22 Jun 2025 11:52:43 +0200
> Christophe Leroy wrote:
> > e500 has the isel instruction which allows selecting one value or
> > the other without branch and that instruction is not speculative, so
> > use it. Allthough GCC
On Wed, Jun 11, 2025 at 07:55:45AM +0200, Thomas Huth wrote:
> On 10/06/2025 22.26, Segher Boessenkool wrote:
> >On Tue, Jun 10, 2025 at 06:01:28PM +0200, Thomas Huth wrote:
> >>From: Thomas Huth
> >>
> >>While the GCC and Clang compilers already define
On Tue, Jun 10, 2025 at 06:01:28PM +0200, Thomas Huth wrote:
> From: Thomas Huth
>
> While the GCC and Clang compilers already define __ASSEMBLER__
> automatically when compiling assembly code, __ASSEMBLY__ is a
> macro that only gets defined by the Makefiles in the kernel.
And it should not, th
:-) )
The patch looks fine, thanks!
Acked-by: Segher Boessenkool
Segher
On Tue, Jun 10, 2025 at 06:01:26PM +0200, Thomas Huth wrote:
> The kernel Makefiles define the __ASSEMBLY__ macro to provide
> a way to use headers in both, assembly and C source code.
> However, all the supported versions of the GCC and Clang compilers
> also define the macro __ASSEMBLER__ automat
On Mon, May 19, 2025 at 04:05:05PM +0200, Arnd Bergmann wrote:
> On Tue, May 13, 2025, at 12:08, Arnd Bergmann wrote:
> > On Mon, May 12, 2025, at 20:13, LEROY Christophe wrote:
> >> Hi Arnd,
> >>
> >> Do you know when you will be able to add GCC 15 to
> >> https://mirrors.edge.kernel.org/pub/tool
Hi!
On Mon, May 12, 2025 at 01:31:34PM +1000, Michael Ellerman wrote:
> Paul Mackerras writes:
> Are you building with pcrel? Otherwise r2 shouldn't be getting used as
> an ordinary register.
With any ELFv2 in fact, which is implied by the target triple. PCrel
has nothing to do with it (well, i
Hi!
On Fri, May 09, 2025 at 10:33:08PM -0700, Eric Biggers wrote:
> On Sat, May 10, 2025 at 01:10:22PM +0800, Herbert Xu wrote:
> > On Fri, May 09, 2025 at 09:44:50PM -0700, Eric Biggers wrote:
> > >
> > > This fixes "-cpu Power10", but older CPUs (e.g. "-cpu POWER9") are still
> > > failing.
> >
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) +=
1 - 100 of 1330 matches
Mail list logo
