st just to report it. Please let
me known if there is anything else I can do to help solve this outstanding
build breakage.
Cheers,
Nick
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ee(routing);
>> +return ret;
>> +}
>>
>> kfree(routing);
>> return 0;
>
> You could just return ret here. The new "if" is not necessary.
>
> Paolo
>
Ok sure that seems
gt;
> I like the patch, but I don't see it on the kvm-ppc mailing list. It
> doesn't show up on patchwork or spinics. Did something go wrong while
> sending it out?
>
>
> Alex
>
Alex,
Ask Paolo about it as he would be able to explain it better then I.
Nick
___
I can send in a patch removing this lines of
code.
Cheers Nick
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
le where I am doing my board setup, I tried the following.
timer7 = mpc52xx_find_and_map ("mpc5200b-gpt");
How do I specify the timer based on the cell-index?
Thanks
Nick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
in file /kernel/irq/manage.c. It fails because at this line: if (desc->chip ==
&no_irq_chip) .
Is 65 the wrong interrupt number? What do I need to do to properly setup for
external interrupts?
Thanks for any help,
Nick
___
Linuxppc-dev
erial";
compatible = "mpc5200b-psc-uart","mpc5200-psc-uart";
port-number = <5>;
reg = <2c00 100>;
interrupts = <2 4 0>.;
interrupt-parent = <&mpc5200_pic>;
};
Is there anything special I need to do to get this port working?
Thanks,
Nick
I too live in Ottawa and would be interested in sharing a beer with an a
PPC developers. If you have a rough idea of numbers, maybe I can help
in recommend a place for the gathering.
Nick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https
appreciated.
Nick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Today I tested the allyesconfig for powerpc and it seems to be still
failing according to my tests.
Below are the error messages I get before the jobs finish and exit
failing the build.
Cheers Nick
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1331
Just hoped this log may help you in your issues with the train wreck.
If you need any help with the issues here please let me know.
Cheers Nick :)
On Mon, Jul 7, 2014 at 11:03 PM, Benjamin Herrenschmidt
wrote:
> On Mon, 2014-07-07 at 22:45 -0400, Nick Krause wrote:
>> Today I t
On Mon, Jul 7, 2014 at 11:03 PM wrote Benjamin Herrenschmidt
On Mon, 2014-07-07 at 22:45 -0400, Nick Krause wrote:
> Today I tested the allyesconfig for powerpc and it seems to be still
> failing according to my tests.
> Below are the error messages I get before the jobs finish
From: Guenter Roeck on Mon, Jul 7, 2014 at 11:57 PM wrote
Subject: Re: Fwd: Allyesconfig for powerpc still Failing
To: Nick Krause , "linux-ker...@vger.kernel.org"
, "linuxppc-dev@lists.ozlabs.org"
On 07/07/2014 08:38 PM, Nick Krause wrote:
>
> On 07/07/2014 0
s...@canb.auug.org.au
Hey Stephen,
Thanks for the heads up on submitting other people's patches. It would
be great if you can push this up into Linus's tree
for the next developer release.
--
Cheers Nick
signature.asc
Description: PGP signature
t; Hey Guenter,
>> > Would you mind sending me the patch that fixes these errors.
>> > I would like to test it before sending in to Ben.
>> > Cheers Nick
>> >
>>
>> Hi Nick,
>>
>> Just follow the link above, select 'forward',
e/clean
>> fix would not be as urgent. Any chance to get it applied ?
>
> Yes, that definitely helps, I'll include it as a band aid.
>
> Cheers,
> Ben.
>
>> Nick, this doesn't fix the allyesconfig build - it still fails with
>> relocation errors. But it
clean this up
for the next kernel stable release if we still have time before this
mergewindow.
Cheers Nick
allyesconfig
Description: Binary data
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Hey again Ben,
I am hitting quite a few fix mes in this file. I am wondering how you
would like me to fix them.
Cheers Nick
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
:206:3: warning: right shift count >= width of type
arch/powerpc/boot/addnote.c:211:3: warning: right shift count >= width of type
Signed-off-by: Nick Krause
---
arch/powerpc/boot/addnote.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/addn
ranch in Debian? I see in the mailing list, there are
some i2c related fixes. I can run a kernel.org kernel + apply
patches if that should help. See attached full dmesg and lspci
for more details. Thanks!
-Nick
[Aug31 20:54] Allocated 131072 bytes for 32 pacas at cffe
[ +0.00]
@@
> # Makefile for the linux kernel.
> #
>
> -# Avoid clang warnings around longjmp/setjmp declarations
> -CFLAGS_crash.o += -ffreestanding
> -
> obj-y += core.o crash.o core_$(BITS).o
>
> obj-$(CONFIG_PPC32)+= relocate_32.o
> --
> 2.25.1.696.g5e7596f4ac-goog
>
--
Thanks,
~Nick Desaulniers
,-mpower4
> +cpu-as-$(CONFIG_PPC_BOOK3S_64) += $(call
> as-option,-Wa$(comma)-mpower8,-Wa$(comma)-mpower4)
> cpu-as-$(CONFIG_PPC_E500MC)+= $(call as-option,-Wa$(comma)-me500mc)
>
> KBUILD_AFLAGS += $(cpu-as-y)
> --
> 2.17.1
>
--
Thanks,
~Nick Desaulniers
> index 494df26c5988..b9cb797445ac 100644
> --- a/arch/powerpc/math-emu/Makefile
> +++ b/arch/powerpc/math-emu/Makefile
> @@ -18,3 +18,7 @@ CFLAGS_fabs.o = -fno-builtin-fabs
> CFLAGS_math.o = -fno-builtin-fabs
>
> ccflags-y = -I. -Iinclude/math-emu -w
> +
> +ifdef CONFIG_CC_IS_CLANG
> +ccflags-y += -fheinous-gnu-extensions
> +endif
> --
> 2.19.1
>
--
Thanks,
~Nick Desaulniers
c/boot: Set target when cross-compiling for clang
>
> Makefile | 3 +++
> arch/powerpc/boot/Makefile | 7 +++
> 2 files changed, 10 insertions(+)
>
> --
> 2.19.1
>
--
Thanks,
~Nick Desaulniers
IX)
> -KBUILD_CFLAGS += $(call cc-option, -no-integrated-as)
> -KBUILD_AFLAGS += $(call cc-option, -no-integrated-as)
> +KBUILD_CFLAGS += -no-integrated-as
> +KBUILD_AFLAGS += -no-integrated-as
Sorry for the delay in review.
Reviewed-by: Nick Desaulniers
Tested-by: Nick Desaulniers
FLAGS += -no-integrated-as
> +CLANG_FLAGS+= -no-integrated-as
> +KBUILD_CFLAGS += $(CLANG_FLAGS)
> +KBUILD_AFLAGS += $(CLANG_FLAGS)
> endif
>
> RETPOLINE_CFLAGS_GCC := -mindirect-branch=thunk-extern
> -mindirect-branch-register
> --
> 2.7.4
>
Thanks for this p
`-no-integrated-as` is set?
Either way, I think it would be clearer to export this after all the
relevant flags are set.
> KBUILD_CFLAGS += $(CLANG_FLAGS)
> KBUILD_AFLAGS += $(CLANG_FLAGS)
> --
> 2.19.1
>
--
Thanks,
~Nick Desaulniers
gt;-dtb arch/powerpc/boot/dts/bamboo.dtb \
>-initrd ~/ppc32-440-rootfs.cpio \
>-nographic -serial stdio -monitor pty -append "console=ttyS0"
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/261
> Link: https://bugs.llvm.org/show_bug.cgi?id=39556
>
I can of think that add_ss(), sub_ddmmss(), and umul_ppmm()
should be rewritten from the form:
asm("..." : "=r" (USItype)(arg) : ...);
to the form:
USItype temp = (USItype) arg;
asm("..." : "=r" (temp) : ...);
arg = (typeof(arg)) temp;
Rather than the flag being added.
--
Thanks,
~Nick Desaulniers
On Mon, Dec 3, 2018 at 2:24 AM Joel Stanley wrote:
>
> On Sat, 3 Nov 2018 at 04:04, Nick Desaulniers wrote:
> >
> > On Thu, Nov 1, 2018 at 5:45 PM Joel Stanley wrote:
> > >
> > > We cannot build these files with clang as it does not allow altivec
> > &g
On Mon, Dec 3, 2018 at 2:14 PM Joel Stanley wrote:
>
> On Tue, 4 Dec 2018 at 05:15, Nick Desaulniers wrote:
> > > > > +ifdef CONFIG_CC_IS_CLANG
> > > > > +# clang ppc port does not yet support -maltivec when -msoft-float is
> > > > > +# e
.org/linuxppc-dev/20181102033713.31916-1-j...@jms.id.au/
> v2:
> Instead of setting the -fheinous-gnu-extensions for clang, fix the code.
> v3:
> Sync with GCC version instead of GMP version
Thanks for matching these up.
Reviewed-by: Nick Desaulniers
> ---
> arch/powerpc/i
it looks like clang took that *(u8 *)addr as rvalue, and
> stored that in stack, and then used *that* as memory.
What's the %y modifier supposed to mean here? addr is in the list of
inputs, so what's wrong with using it as an rvalue?
>
> Maybe clang simply does not not to treat "Z" the same as "m"? (And "Y"
> and "Q" and "es" and a whole bunch of "w*", what about those?)
--
Thanks,
~Nick Desaulniers
On Mon, Jul 29, 2019 at 1:47 PM Nathan Chancellor
wrote:
>
> On Mon, Jul 29, 2019 at 01:45:35PM -0700, Nick Desaulniers wrote:
> > On Mon, Jul 29, 2019 at 1:32 PM Nathan Chancellor
> > wrote:
> > >
> > > On Mon, Jul 29, 2019 at 01:25:41PM -0700, Nick Desauln
On Fri, Aug 9, 2019 at 1:13 PM Arnd Bergmann wrote:
>
> On Fri, Aug 9, 2019 at 10:02 PM Christophe Leroy
> wrote:
> >
> > Arnd Bergmann a écrit :
> > > On Fri, Aug 9, 2019 at 8:21 PM 'Nick Desaulniers' via Clang Built
> > > Linux wrote:
On Wednesday 04 February 2009 16:13:29 Andrew Morton wrote:
> On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt
> > Do the generic hugetlbfs code provides such an API ? If not, we may need
> > to add one.
>
> I think it's something like
>
> huge_page_size(page_hstate(page))
That wou
On Tue, Feb 10, 2009 at 01:53:51PM +0200, Pekka Enberg wrote:
> On Tue, Feb 10, 2009 at 11:54 AM, Sachin P. Sant wrote:
> > Sachin P. Sant wrote:
> >>
> >> Hi Stephen,
> >>
> >> Todays next randconfig build on powerpc fails with
> >>
> >> CC mm/slqb.o
> >> mm/slqb.c: In function __slab_free:
declared (first use in this
> function)
Hmm, I guess this (SMP=n && NUMA=y) must be a valid config on ppc if
SLQB is the only one tripping on it, so I'll look at code to fix tihs
up.
Thanks,
Nick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
deally the generic code would be able to measure it in case the platform
does not provide it.
But this simple patch at least makes it throttle again.
Signed-off-by: Nick Piggin
---
Index: linux-2.6/arch/powerpc/platforms/powermac/cp
OK, here is this patch again. You didn't think I'd let a 2% performance
improvement be forgotten? :)
Anyway, patch won't work well on architecture without lwsync, but I won't
bother fixing that kind of thing and making it merge worthy until you
guys say something positive about it.
20 runs of tbe
Using lwsync, isync sequence in a microbenchmark is 5 times faster on my G5 than
using sync for smp_mb. Although it takes more instructions.
Running tbench with 4 clients on my 4 core G5 (20 times) gives the
following:
unpatched AVG=920.33 STD=2.36
patched AVG=921.27 STD=2.77
So not a big imp
On Wed, Mar 04, 2009 at 03:03:15PM +1100, Benjamin Herrenschmidt wrote:
> Allright, sorry for the delay, I had those stored into my "need more
> than half a brain cell for review" list and only got to them today :-)
No problem :)
> On Thu, 2009-02-19 at 18:12 +0100
On Wed, Mar 04, 2009 at 03:04:11PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 18:21 +0100, Nick Piggin wrote:
> > OK, here is this patch again. You didn't think I'd let a 2% performance
> > improvement be forgotten? :)
> >
> > Anyway,
On Tue, Apr 28, 2009 at 02:22:06PM +0300, Pekka Enberg wrote:
> Nick,
>
> Here's another one. I think we need to either fix these rather quickly
> or make SLUB the defaut for linux-next again so we don't interfere
> with other testing.
Yeah, I'm working on it. Let
On Tue, Apr 28, 2009 at 02:22:06PM +0300, Pekka Enberg wrote:
> Nick,
>
> Here's another one. I think we need to either fix these rather quickly
> or make SLUB the defaut for linux-next again so we don't interfere
> with other testing.
>
>
On Wed, Apr 29, 2009 at 09:56:19PM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >Does this help?
> >---
> With the patch the machine boots past the failure point, but panics
> immediately with the following trace...
OK good, that solves one problem.
> Unable to hand
On Thu, Apr 30, 2009 at 11:06:36AM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >Well kmalloc is failing. It should not be though, even if the
> >current node is offline, it should be able to fall back to other
> >nodes. Stephen's trace indicates the same thing
On Thu, Apr 30, 2009 at 11:06:36AM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >Well kmalloc is failing. It should not be though, even if the
> >current node is offline, it should be able to fall back to other
> >nodes. Stephen's trace indicates the same thing
On Thu, Apr 30, 2009 at 03:17:12PM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >Hmm, forget that. Actually my last patch had a silly mistake because I
> >forgot MAX_ORDER shift is applied to PAGE_SIZE, rather than 1. So
> >kmalloc(PAGE_SIZE) was failing as too large.
>
On Wed, Feb 10, 2010 at 09:57:28PM +1100, Anton Blanchard wrote:
>
> Recent versions of the PowerPC architecture added a hint bit to the larx
> instructions to differentiate between an atomic operation and a lock
> operation:
>
> > 0 Other programs might attempt to modify the word in storage add
On Wed, Feb 10, 2010 at 10:10:25PM +1100, Anton Blanchard wrote:
>
> Nick Piggin discovered that lwsync barriers around locks were faster than
> isync
> on 970. That was a long time ago and I completely dropped the ball in testing
> his patches across other ppc64 processors.
>
On Wed, Feb 17, 2010 at 08:37:14PM +1100, Anton Blanchard wrote:
>
> Hi Nick,
>
> > Cool. How does it go when there are significant amount of instructions
> > between the lock and the unlock? A real(ish) workload, like dbench on
> > ramdisk (which should hit the dcach
On Wed, Feb 17, 2010 at 08:43:14PM +1100, Anton Blanchard wrote:
>
> Hi Nick,
>
> > Ah, good to see this one come back. I also tested tbench over localhost
> > btw which actually did show some speedup on the G5.
> >
> > BTW. this was the last thing left
---
drivers/macintosh/adb.c | 71 +++
1 files changed, 35 insertions(+), 36 deletions(-)
diff --git a/drivers/macintosh/adb.c b/drivers/macintosh/adb.c
index 1c4ee6e..89891bb 100644
--- a/drivers/macintosh/adb.c
+++ b/drivers/macintosh/adb.c
@@ -115,2
On Wed, Feb 10, 2010 at 10:04:06PM +1100, Anton Blanchard wrote:
>
> For performance reasons we are about to change ISYNC_ON_SMP to sometimes be
> lwsync. Now that the macro name doesn't make sense, change it and
> LWSYNC_ON_SMP
> to better explain what the barriers are doing.
>
> Signed-off-by:
code
that has similar problems).
Thanks,
Nick
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
, rather than
> > simply killing current.
> >
> > Cc: linuxppc-...@ozlabs.org
> > Cc: Benjamin Herrenschmidt
> > Cc: linux-a...@vger.kernel.org
> > Signed-off-by: Nick Piggin
> > ---
> > Index: linux-2.6/arch/powerpc/mm/fault.c
> >
ants to support.
>
> Therefore, also take the RCU read lock along with disabling IRQs to ensure
> the RCU grace period does at least cover these lookups.
>
> Signed-off-by: Peter Zijlstra
> Requested-by: Paul E. McKenney
> Cc: Nick Piggin
> Cc: Benjamin Herrenschmidt
>
gt; > [c0010978fc80] [c008deb4] .do_fork+0x190/0x3cc
> > [c0010978fdc0] [c0011ef4] .sys_clone+0x58/0x70
> > [c0010978fe30] [c00087f0] .ppc_clone+0x8/0xc
> > Instruction dump:
> > 419e0010 7fe3fb78 480774cd 6000 801f0014 e93f0008 7800b842 392
On Fri, Jul 09, 2010 at 09:34:16AM +0200, Jens Axboe wrote:
> On 2010-07-09 08:57, divya wrote:
> > On Friday 02 July 2010 12:16 PM, divya wrote:
> >> On Thursday 01 July 2010 11:55 PM, Maciej Rutecki wrote:
> >>> On środa, 30 czerwca 2010 o 13:22:27 divya wrote:
> While running fs_racer test
On Thu, Apr 30, 2009 at 09:00:04PM +1000, Stephen Rothwell wrote:
> Hi Pekka, Nick,
>
> On Thu, 30 Apr 2009 13:38:04 +0300 Pekka Enberg
> wrote:
> >
> > Stephen, does this patch fix all the boot problems for you as well?
>
> Unfortunately not, I am still getti
On Thu, Apr 30, 2009 at 02:20:29PM +0300, Pekka Enberg wrote:
> On Thu, 2009-04-30 at 13:18 +0200, Nick Piggin wrote:
> > OK thanks. So I think we have 2 problems. One with MAX_ORDER <= 9
> > that is fixed by the previous patch, and another which is probably
> > due to ha
On Thu, Apr 30, 2009 at 02:20:29PM +0300, Pekka Enberg wrote:
> On Thu, 2009-04-30 at 13:18 +0200, Nick Piggin wrote:
> > OK thanks. So I think we have 2 problems. One with MAX_ORDER <= 9
> > that is fixed by the previous patch, and another which is probably
> > due to ha
On Fri, May 01, 2009 at 12:00:33AM +1000, Stephen Rothwell wrote:
> Hi Nick,
>
> On Thu, 30 Apr 2009 15:05:42 +0200 Nick Piggin wrote:
> >
> > Hmm, this might do it. The following code now passes some stress testing
> > in a userspace harness wheras before it did n
> > Page size is 64K with Config DEBUG_PAGEALLOC set.
> >
> > CONFIG_PPC_HAS_HASH_64K=y
> > CONFIG_PPC_64K_PAGES=y
> > CONFIG_DEBUG_PAGEALLOC=y
>
> Hm. We've seen some similar problems at Intel while doing database
> performance tests with SLQB. Any id
On Tue, May 12, 2009 at 03:56:13PM +1000, Stephen Rothwell wrote:
> Hi Nick,
>
> On Tue, 12 May 2009 06:57:16 +0200 Nick Piggin wrote:
> >
> > Hmm, I think (hope) your problems were fixed with the recent memory
> > coruption bug fix for SLQB. (if not, let me know)
On Tue, May 12, 2009 at 04:52:45PM +1000, Stephen Rothwell wrote:
> Hi Nick,
>
> On Tue, 12 May 2009 16:03:52 +1000 Stephen Rothwell
> wrote:
> >
> > This is what I have been getting for the last few days:
>
> bisected into the net changes, I will follow up t
On Mon, Jun 08, 2009 at 05:42:14PM +0530, Sachin Sant wrote:
> Pekka J Enberg wrote:
> >Hi Sachin,
> __slab_alloc_page: nid=2, cache_node=c000de01ba00,
> cache_list=c000de01ba00
> __slab_alloc_page: nid=2, cache_node=c000de01bd00,
> cache_list=c000de01bd00
> __slab_alloc_page: nid
On Fri, Jun 12, 2009 at 11:14:10AM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >I can't really work it out. It seems to be the kmem_cache_cache which has
> >a problem, but there have already been lots of caches created and even
> >this samw cache_node already use
On Fri, Jun 12, 2009 at 01:38:50PM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >>I was able to boot yesterday's next (20090611) on this machine. Not sure
> >>
> >
> >Still with SLQB? With debug options turned on?
> >
> Ah .. spoke too soo
On Wed, Jul 15, 2009 at 05:49:47PM +1000, Benjamin Herrenschmidt wrote:
> Upcoming paches to support the new 64-bit "BookE" powerpc architecture
> will need to have the virtual address corresponding to PTE page when
> freeing it, due to the way the HW table walker works.
>
> Basically, the TLB can
On Mon, Jul 20, 2009 at 05:11:13PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote:
> > > I would like to merge the new support that depends on this in 2.6.32,
> > > so unless there's major objections, I'd like this to go
On Thu, Jul 16, 2009 at 11:54:15AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote:
> > Interesting arrangement. So are these last level ptes modifieable
> > from userspace or something? If not, I wonder if you could manage
> > the
On Mon, Jul 20, 2009 at 08:00:41PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-07-20 at 10:10 +0200, Nick Piggin wrote:
> >
> > Maybe I don't understand your description correctly. The TLB contains
> > PMDs, but you say the HW still logically performs another
On Mon, Jul 20, 2009 at 07:59:21PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-07-20 at 10:05 +0200, Nick Piggin wrote:
> >
> > Unless anybody has other preferences, just send it straight to Linus in
> > the next merge window -- if any conflicts did come up any
On Tue, Jul 21, 2009 at 10:02:26AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-07-20 at 12:38 +0200, Nick Piggin wrote:
> > On Mon, Jul 20, 2009 at 08:00:41PM +1000, Benjamin Herrenschmidt wrote:
> > > On Mon, 2009-07-20 at 10:10 +0200, Nick Piggin wrote:
> > &g
's fleet, and most calls to memcmp don't care
about the position of the mismatch; bcmp is lower overhead (or at
least for our libc implementation, not sure about others).
--
Thanks,
~Nick Desaulniers
en);
#else
static inline
int sed_read_key(char *keyname, char *key, u_int *keylen) {
return -EOPNOTSUPP;
}
static inline
int sed_write_key(char *keyname, char *key, u_int keylen);
return -EOPNOTSUPP;
}
#endif
>
> Is there any real reason to have a separate translation unit for these
> two functions versus just having them living in sed-opal.c? Those two
> object files share the same Kconfig dependency. I am happy to send a
> patch if that is an acceptable approach.
>
> [1]: https://github.com/ClangBuiltLinux/linux/issues/981
>
> Cheers,
> Nathan
>
--
Thanks,
~Nick Desaulniers
On Wed, Sep 27, 2023 at 1:26 PM Greg Joyce wrote:
>
> On Wed, 2023-09-13 at 13:49 -0700, Nick Desaulniers wrote:
> > On Wed, Sep 13, 2023 at 9:56 AM Nathan Chancellor
> > wrote:
> > > Hi Greg,
> > >
> > > On Fri, Sep 08, 2023 at 10:30:54AM
purpose is actually deprecated in favour of
different logic.
Convert every user of napi_reschedule to napi_schedule.
Signed-off-by: Christian Marangi
---
For
drivers/net/ethernet/ibm/ibmveth.c | 2 +-
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
Acke
("scsi: ibmvfc: Use a bitfield for boolean flags")
> Signed-off-by: Nathan Chancellor
Thanks for the patch!
Reviewed-by: Nick Desaulniers
> ---
> drivers/scsi/ibmvscsi/ibmvfc.h | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/dri
and the only call is under
> "#if 0".
Time to remove it then? Or is it a bug that it's not called?
Otherwise the definition should be behind the same preprocessor guards
as the caller. Same for the below.
>
> Same with get_output_lock() and release_output_lock(): they
Hi Nathan,
Patches 1 and 3 LGTM
Regarding this patch, dlpar_memory_remove_by_count() calls
dlpar_add_lmb() and does not free drc on add error.
dlpar_add_lmb() is called here in error recovery so probably
not a big deal.
This is all new code to me but it looks like if the requested
number of lm
8
> [0]
> Link:
> https://github.com/llvm/llvm-project-release-prs/commit/0af7e5e54a8c7ac665773ac1ada328713e8338f5
> [1]
> Reported-by: kernel test robot
> Closes: https://lore.kernel.org/llvm/202307211945.tspcyohh-...@intel.com/
> Suggested-by: Michael Ellerman
> Signed-o
ommit/0af7e5e54a8c7ac665773ac1ada328713e8338f5
[1]
Reported-by: kernel test robot
Closes: https://lore.kernel.org/llvm/202307211945.tspcyohh-...@intel.com/
Suggested-by: Michael Ellerman
Signed-off-by: Nick Desaulniers
---
Changes in v2:
- add 2 missing tabs to PPC_RAW_TLBILX_LPID
- Link to v1:
https://lore.kernel.org/r/202
ommit/0af7e5e54a8c7ac665773ac1ada328713e8338f5
[1]
Reported-by: kernel test robot
Closes: https://lore.kernel.org/llvm/202307211945.tspcyohh-...@intel.com/
Suggested-by: Michael Ellerman
Signed-off-by: Nick Desaulniers
---
Changes in v3:
- left comment @
https://github.com/linuxppc/issues/issues/350#issuecomment-1664417212
- re
On Thu, Aug 3, 2023 at 11:47 AM Christophe Leroy
wrote:
>
>
>
> Le 03/08/2023 à 20:33, Nick Desaulniers a écrit :
> > Clang didn't recognize the instruction tlbilxlpid. This was fixed in
> > clang-18 [0] then backported to clang-17 [1]. To support clang-16 and
>
giuk7-...@intel.com/
Suggested-by: Nathan Chancellor
Reviewed-by: Nathan Chancellor
Signed-off-by: Nick Desaulniers
---
Changes in v2:
- Use ccflags-$(CONFIG_CC_IS_CLANG) as per Nathan.
- Move that to be below the initial setting of ccflags-y as per Nathan.
- Add Nathan's Suggested-by and Review
honov2009-01-29 28
>
> :: The code at line 20 was first introduced by commit
> :: e12401222f749c37277a313d631dc024bbfd3b00 powerpc/44x: Support for
> 256KB PAGE_SIZE
>
> :: TO: Yuri Tikhonov
> :: CC: Josh Boyer
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests
--
Thanks,
~Nick Desaulniers
; in head_booke.h, so it is possible for THREAD_SHIFT to be undefined. Add
> the include to ensure that THREAD_SHIFT is always defined.
>
> Reported-by: kernel test robot
> Link: https://lore.kernel.org/202304050954.yskldczh-...@intel.com/
> Signed-off-by: Nathan Chancellor
Than
filter-out -fprofile-sample-use=%
> -fprofile-use=%,$(KBUILD_CFLAGS))
> +
> # When linking purgatory.ro with -r unresolved symbols are not checked,
> # also link a purgatory.chk binary without -r to check for unresolved
> symbols.
> PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib
>
> --
> 2.40.1.495.gc816e09b53d-goog
>
--
Thanks,
~Nick Desaulniers
Link: https://github.com/llvm/llvm-project/issues/63220
Acked-by: Nick Desaulniers
> ---
> arch/powerpc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index bff5820b7cda14..d85e3cf4016d90 100644
>
://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230201/testrun/14479384/suite/build/test/clang-nightly-tqm8xx_defconfig/history/
> >
> > The bisection pointed to this commit,
> >45f7091aac35 ("powerpc/64: Set default CPU in Kconfig")
> >
> > --
> > Linaro LKFT
> > https://lkft.linaro.org
--
Thanks,
~Nick Desaulniers
from `arch/s390/boot/install.sh`.
Signed-off-by: Nick Child
---
Hoping I am not breaking someones dependency on targeting /boot/vmlinux
so RFC'ing.
I typically have kernelinstall on my LPARs and installing and rebooting
goes peacefully.
Recently, I did not have kernelinstall and `make in
On Fri, Feb 24, 2023 at 7:58 AM Björn Töpel wrote:
>
> Alexandre Ghiti writes:
>
> > +cc linux-kbuild, llvm, Nathan, Nick
> >
> > On 2/15/23 15:36, Alexandre Ghiti wrote:
> >> From: Alexandre Ghiti
> >>
> > I tried a lot of things, but I st
}
Though this return code can be passed to adapter->reset_done_rc, which
is only treated as a boolean.
So, the point of the patch not doing any behavioral differences is still
true.
Personally, I don't have strong opinions on this.
Reviewed-by: Nick Child
e "Y" constraint does not guarantee 4-byte alignment when prefixed
> instructions are enabled.
>
> Unfortunately clang doesn't support the "Y" constraint so that has to be
> behind an ifdef.
Filed: https://github.com/llvm/llvm-project/issues/92939
--
Thanks,
~Nick Desaulniers
was used in
the vdso32.
Fixes: commit f2af201002a8 ("powerpc/build: vdso linker warning for orphan
sections")
Link:
https://lore.kernel.org/lkml/cakwvodnn3wxydjomvnveyd_njwrku3fabwt_bs92duihhyw...@mail.gmail.com/
Signed-off-by: Nick Desaulniers
---
Not sure removing .got is a good
On Mon, Sep 21, 2020 at 11:47 AM Dan Williams wrote:
>
> On Mon, Sep 21, 2020 at 11:35 AM Nick Desaulniers
> wrote:
> >
> > Hello DAX maintainers,
> > I noticed our PPC64LE builds failing last night:
> > https://travis-ci.com/github/ClangBuiltLinux/continuous-int
, not an error. It should be fixed
> > of course, but it is less important; although it may be pointing to a
> > deeper problem.)
> >
> >
> > Segher
>
--
Thanks,
~Nick Desaulniers
1 - 100 of 286 matches
Mail list logo
