Re: enabling COMPILE_TEST support for GCC plugins in v4.11

On Fri, Jun 23, 2017 at 03:43:58PM +1000, Michael Ellerman wrote: > [Old thread just popped up in my inbox] > > Kees Cook writes: > > On Thu, Dec 8, 2016 at 5:52 PM, Paul Gortmaker > > wrote: > >> On Thu, Dec 8, 2016 at 2:00 PM, Kees Cook

Re: enabling COMPILE_TEST support for GCC plugins in v4.11

On Fri, Jun 23, 2017 at 03:43:58PM +1000, Michael Ellerman wrote: > [Old thread just popped up in my inbox] > > Kees Cook writes: > > On Thu, Dec 8, 2016 at 5:52 PM, Paul Gortmaker > > wrote: > >> On Thu, Dec 8, 2016 at 2:00 PM, Kees Cook wrote: > >>> Hi, > >>> > >>> I'd like to get the GCC

Re: crosstool builds - https://www.kernel.org/pub/tools/crosstool/

On Thu, May 19, 2016 at 11:48:39PM -0400, Jon Masters wrote: > Hi Tony, > > I'm wondering whether you know of anyone who has picked up where you > left off, building cross toolchains for various and sundry alternative > architectures? I wanted to download an IA64 compiler recently (really) > and

Re: crosstool builds - https://www.kernel.org/pub/tools/crosstool/

On Thu, May 19, 2016 at 11:48:39PM -0400, Jon Masters wrote: > Hi Tony, > > I'm wondering whether you know of anyone who has picked up where you > left off, building cross toolchains for various and sundry alternative > architectures? I wanted to download an IA64 compiler recently (really) > and

Re: [tip:timers/core] timekeeping: Fixup typo in update_vsyscall_old definition

On Tue, Aug 12, 2014 at 08:30:40AM -0700, John Stultz wrote: > Thanks for pointing it out. I'll send a fix here shortly (though I only > have the ppc64le toolchain handy, so forgive me if its not quite right). /me pimps the kernel.org toolchains:

Re: [tip:timers/core] timekeeping: Fixup typo in update_vsyscall_old definition

On Tue, Aug 12, 2014 at 08:30:40AM -0700, John Stultz wrote: Thanks for pointing it out. I'll send a fix here shortly (though I only have the ppc64le toolchain handy, so forgive me if its not quite right). /me pimps the kernel.org toolchains:

Re: [PATCH 3.2 153/200] powerpc/le: Ensure that the 'stop-self' RTAS token is handled correctly

On Mon, Mar 31, 2014 at 12:23:35AM +0100, Ben Hutchings wrote: > 3.2.56-rc1 review patch. If anyone has any objections, please let me know. This patch doesn't need to go back beyond 3.10, so it's safe to drop from your queue. Thanks Ben. Yours Tony pgpWVFxHj6PTy.pgp Description: PGP

Re: [PATCH 3.2 153/200] powerpc/le: Ensure that the 'stop-self' RTAS token is handled correctly

On Mon, Mar 31, 2014 at 12:23:35AM +0100, Ben Hutchings wrote: 3.2.56-rc1 review patch. If anyone has any objections, please let me know. This patch doesn't need to go back beyond 3.10, so it's safe to drop from your queue. Thanks Ben. Yours Tony pgpWVFxHj6PTy.pgp Description: PGP signature

Re: Linux kernel cross-compilers

On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: > Yes, xtensa compiler/linker is known to have issues with link-time > relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? Yours Tony

Re: Linux kernel cross-compilers

On Thu, Aug 15, 2013 at 02:07:05AM -0700, Guenter Roeck wrote: > Hi Tony, > > would it be possible to provide an arm64 cross-compiler on > https://www.kernel.org/pub/tools/crosstool/ ? I have one built I just need to upload it. I'll try and do it this weekend. > Also, the xtensa compiler

Re: Linux kernel cross-compilers

On Thu, Aug 15, 2013 at 02:07:05AM -0700, Guenter Roeck wrote: Hi Tony, would it be possible to provide an arm64 cross-compiler on https://www.kernel.org/pub/tools/crosstool/ ? I have one built I just need to upload it. I'll try and do it this weekend. Also, the xtensa compiler fails for

Re: Linux kernel cross-compilers

On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? Yours Tony

Re: [patch 02/34] arch: Consolidate tsk_is_polling()

On Thu, Mar 21, 2013 at 09:52:57PM -, Thomas Gleixner wrote: > +/* > + * Idle thread specific functions to determine the need_resched > + * polling state. We have two versions, one based on TS_POLLING in > + * thread_info.status and one based on TIF_POLLING_NRFLAG in > + * thread_info.flags

Re: [patch 02/34] arch: Consolidate tsk_is_polling()

On Thu, Mar 21, 2013 at 09:52:57PM -, Thomas Gleixner wrote: > Index: linux-2.6/arch/powerpc/include/asm/thread_info.h > === > --- linux-2.6.orig/arch/powerpc/include/asm/thread_info.h > +++

Re: [patch 02/34] arch: Consolidate tsk_is_polling()

On Thu, Mar 21, 2013 at 09:52:57PM -, Thomas Gleixner wrote: Index: linux-2.6/arch/powerpc/include/asm/thread_info.h === --- linux-2.6.orig/arch/powerpc/include/asm/thread_info.h +++

Re: [patch 02/34] arch: Consolidate tsk_is_polling()

On Thu, Mar 21, 2013 at 09:52:57PM -, Thomas Gleixner wrote: +/* + * Idle thread specific functions to determine the need_resched + * polling state. We have two versions, one based on TS_POLLING in + * thread_info.status and one based on TIF_POLLING_NRFLAG in + * thread_info.flags + */

Re: [Lguest] lguest breaks i386 allmodconfig

On Sat, Feb 23, 2008 at 11:32:35PM -0500, Jeff Garzik wrote: > The following > > make ARCH=i386 allmodconfig && \ > make ARCH=i386 -sj5 > > on x86-64 produces the following build breakage at the post-build stage: > > [...] > Root device is (9, 0) > Setup is 12504 bytes (padded to

Re: [Lguest] lguest breaks i386 allmodconfig

On Sat, Feb 23, 2008 at 11:32:35PM -0500, Jeff Garzik wrote: The following make ARCH=i386 allmodconfig \ make ARCH=i386 -sj5 on x86-64 produces the following build breakage at the post-build stage: [...] Root device is (9, 0) Setup is 12504 bytes (padded to 12800 bytes).

Re: [PATCH] Fix building lguest as module.

On Wed, Feb 20, 2008 at 11:01:40AM +0100, Ingo Molnar wrote: > > * Tony Breeds <[EMAIL PROTECTED]> wrote: > > > I've attached the .config FWIW > > indeed you are right... > > I fixed this build failure too - could you check whether x86.git#test > (which has

Re: [PATCH] Fix building lguest as module.

On Wed, Feb 20, 2008 at 11:01:40AM +0100, Ingo Molnar wrote: * Tony Breeds [EMAIL PROTECTED] wrote: I've attached the .config FWIW indeed you are right... I fixed this build failure too - could you check whether x86.git#test (which has all these lguest build fixes) works fine

Re: [PATCH] Fix building lguest as module.

On Tue, Feb 19, 2008 at 02:54:01PM +0100, Ingo Molnar wrote: > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > +#endif > > > + > > > +#if defined(CONFIG_LGUEST) || defined(CONFIG_LGUEST_MODULE) > > > + BLANK(); > > > > hm. Rusty's original fix is now upstream. I've done a delta to your > >

Re: [PATCH] Fix building lguest as module.

On Tue, Feb 19, 2008 at 02:54:01PM +0100, Ingo Molnar wrote: * Ingo Molnar [EMAIL PROTECTED] wrote: +#endif + +#if defined(CONFIG_LGUEST) || defined(CONFIG_LGUEST_MODULE) + BLANK(); hm. Rusty's original fix is now upstream. I've done a delta to your patch, find the fix is

[PATCH] Fix building lguest as module.

: they used to be tied together. Sort out which parts of asm-offsets are needed for Guest and Host. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- Original patch from rusty (http://lkml.org/lkml/2008/2/3/168) didn't completely fix the problem. I think this matches the original intent. No

[PATCH] Fix building lguest as module.

-by: Tony Breeds [EMAIL PROTECTED] --- Original patch from rusty (http://lkml.org/lkml/2008/2/3/168) didn't completely fix the problem. I think this matches the original intent. Not sure of the right way to attribute this patch, clearlyt it's mostly Rusty's work. arch/x86/kernel/asm-offsets_32.c

Re: linux-next build status

On Thu, Feb 14, 2008 at 08:24:27PM -0500, Chris Snook wrote: > Stephen Rothwell wrote: > >Hi all, > > > >Initial status can be seen here > >http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better > >URL soon). Suggestions for more compiler/config combinations are > >welcome, but we

Re: linux-next build status

On Thu, Feb 14, 2008 at 08:24:27PM -0500, Chris Snook wrote: Stephen Rothwell wrote: Hi all, Initial status can be seen here http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better URL soon). Suggestions for more compiler/config combinations are welcome, but we can't

Re: build #345 issue for v2.6.25-rc1 in tuner-core.c

ext+0x8879d): undefined reference to `xc5000_attach' > make: *** [.tmp_vmlinux1] Error 1 Fix Build error for xc5000 tuner when built as module. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- Not 100% certain this is correct but it works for me :) Michael? drivers/media/dvb/fronte

Re: build #345 issue for v2.6.25-rc1 in tuner-core.c

: *** [.tmp_vmlinux1] Error 1 snip Fix Build error for xc5000 tuner when built as module. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- Not 100% certain this is correct but it works for me :) Michael? drivers/media/dvb/frontends/xc5000.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions

[PATCH] Fix powerpc vdso clock_getres().

to use the correct value. This fix doesn't work on older compilers. Below is a fix for powerpc, that introduces a new (generic) #define MONOTONIC_RES_NSEC which is equal to the 64 value stored in KTIME_MONOTONIC_RES. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- Thomas, If this i

[PATCH] [POWERPC] Use a sensible default for clock_getres() in the vdso.

ld you please let me know the reason for this? Is it something that > should be fixed in vdso? Can you try the attached patch and see it if works for you? From: Tony Breeds <[EMAIL PROTECTED]> Subject: [PATCH] [POWERPC] Use a sensible default for clock_getres() in the vdso. This ensures

[PATCH] [POWERPC] Use a sensible default for clock_getres() in the vdso.

that should be fixed in vdso? Can you try the attached patch and see it if works for you? From: Tony Breeds [EMAIL PROTECTED] Subject: [PATCH] [POWERPC] Use a sensible default for clock_getres() in the vdso. This ensures that the syscall and the (fast) vdso versions of clock_getres() will return

Re: [ppc] Disparity between sys_clock_getres and vdso implementation

On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote: > Hi Paul, > > On PPC, I see a disparity between clock_getres implementations in the > vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel > with CONFIG_HIGH_RES_TIMERS=y. > > clock_getres call for CLOCK_REALTIME

Re: [ppc] Disparity between sys_clock_getres and vdso implementation

On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote: Hi Paul, On PPC, I see a disparity between clock_getres implementations in the vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel with CONFIG_HIGH_RES_TIMERS=y. clock_getres call for CLOCK_REALTIME

[PATCH v2] Fix hardware IRQ time accounting problem.

need to not do this, and results in the time accounted as hardware irq time being artificially elevated. Also this patch collapses 2 consecutive '#ifdef CONFIG_VIRT_CPU_ACCOUNTING' checks in time.h into one for neatness. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- The problem wa

[PATCH] Fix hardware IRQ time accounting problem.

as hardware irq time being artificially elevated. Also this patch collapses 2 consecutive '#ifdef CONFIG_VIRT_CPU_ACCOUNTING' checks in time.h into for neatness. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- The problem was seen and reported by Johannes Berg and Frederik Himpe. Paul, I

[PATCH] Fix hardware IRQ time accounting problem.

as hardware irq time being artificially elevated. Also this patch collapses 2 consecutive '#ifdef CONFIG_VIRT_CPU_ACCOUNTING' checks in time.h into for neatness. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- The problem was seen and reported by Johannes Berg and Frederik Himpe. Paul, I think

[PATCH v2] Fix hardware IRQ time accounting problem.

need to not do this, and results in the time accounted as hardware irq time being artificially elevated. Also this patch collapses 2 consecutive '#ifdef CONFIG_VIRT_CPU_ACCOUNTING' checks in time.h into one for neatness. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- The problem was seen

Re: 2.6.24-rc3-git3: usb hardware interrupts using 25% of CPU time

On Wed, Nov 28, 2007 at 10:33:18PM +, Frederik Himpe wrote: > I installed Linux 2.6.24-rc3-git3 on a PPC based Apple Powerbook G4 > system. Now with top I see that over 20% of CPU time is used by hardware > interrupts. Looking at /proc/interrupts, the number in the row > ohci_hcd:usb1 is

Re: 2.6.24-rc3-git3: usb hardware interrupts using 25% of CPU time

On Wed, Nov 28, 2007 at 10:33:18PM +, Frederik Himpe wrote: I installed Linux 2.6.24-rc3-git3 on a PPC based Apple Powerbook G4 system. Now with top I see that over 20% of CPU time is used by hardware interrupts. Looking at /proc/interrupts, the number in the row ohci_hcd:usb1 is

Re: time accounting problem (powerpc only?)

On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote: > Contrary to what I claimed later in the thread, my 64-bit powerpc box > (quad-core G5) doesn't suffer from this problem. > > Does anybody have any idea? I don't even know how to debug it further. I'll see if I can grab an

Re: mm snapshot broken-out-2007-11-20-01-45 Build Fail - net/wireless driver

till somewhat WiP based on the commit message for a2645795713c4374ff2efda960251cdc30b63430 (wireless-2.6.git). Appologies for the uber long CC line, wasn't sure who can be pruned. From: Tony Breeds <[EMAIL PROTECTED]> Temporarily ensure that Realtek 8185 and 8187 aren't compiled together. These two drivers

Re: mm snapshot broken-out-2007-11-20-01-45 Build Fail - net/wireless driver

for a2645795713c4374ff2efda960251cdc30b63430 (wireless-2.6.git). Appologies for the uber long CC line, wasn't sure who can be pruned. From: Tony Breeds [EMAIL PROTECTED] Temporarily ensure that Realtek 8185 and 8187 aren't compiled together. These two drivers share a number of common (global) functions. While RTL8180 is still

Re: time accounting problem (powerpc only?)

On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote: Contrary to what I claimed later in the thread, my 64-bit powerpc box (quad-core G5) doesn't suffer from this problem. Does anybody have any idea? I don't even know how to debug it further. I'll see if I can grab an appropriate

[PATCH] Fix build failure when CONFIG_INFINIBAND_IPOIB_CM is not defined.

is #defined to 0. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- drivers/infiniband/ulp/ipoib/ipoib_main.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c index 6

[PATCH] Fix build failure when CONFIG_INFINIBAND_IPOIB_CM is not defined.

is #defined to 0. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- drivers/infiniband/ulp/ipoib/ipoib_main.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c index 623458e..aeb5a01

Re: mm snapshot broken-out-2007-11-06-02-32 build failure - !CONFIG_PPC_ISERIES

On Thu, Nov 08, 2007 at 02:27:07AM +0530, Kamalesh Babulal wrote: > Hi Andrew, > > The kernel build fails with randconfig, with following error > > CC arch/powerpc/platforms/celleb/setup.o > arch/powerpc/platforms/celleb/setup.c:151: error: ‘generic_calibrate_decr’ > undeclared here (not

Re: mm snapshot broken-out-2007-11-06-02-32 build failure - !CONFIG_PPC_ISERIES

On Thu, Nov 08, 2007 at 02:27:07AM +0530, Kamalesh Babulal wrote: Hi Andrew, The kernel build fails with randconfig, with following error CC arch/powerpc/platforms/celleb/setup.o arch/powerpc/platforms/celleb/setup.c:151: error: ‘generic_calibrate_decr’ undeclared here (not in a

[PATCH] Update zfcp_sg_to_address() for new SG chanegs.

Commit 642f149031d70415d9318b919d50b71e4724adbd Added args to zfcp_sg_to_address() but didn't update the defn. to know about them. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- Only compile tested. drivers/s390/scsi/zfcp_def.h |5 +++-- 1 files changed, 3 insertions(+), 2 del

[PATCH] Update zfcp_sg_to_address() for new SG chanegs.

Commit 642f149031d70415d9318b919d50b71e4724adbd Added args to zfcp_sg_to_address() but didn't update the defn. to know about them. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- Only compile tested. drivers/s390/scsi/zfcp_def.h |5 +++-- 1 files changed, 3 insertions(+), 2 deletions

Re: 2.6.23-rc7-mm1 -- powerpc rtas panic

On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote: > I realise it'll make the patch bigger, but this doesn't seem like a > particularly good name for the variable anymore. Sure, what about? Clarify when RTAS logging is enabled. Signed-off-by: Tony Breeds <[EMAIL

Re: 2.6.23-rc7-mm1 -- powerpc rtas panic

o me that we have logging enabled too early now. I think the following is a reasonable fix? --- Explicitly enable RTAS error logging, when it should be ready. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- arch/powerpc/platforms/pseries/rtasd.c |7 ++- 1 files changed, 6 inser

Re: 2.6.23-rc7-mm1 -- powerpc rtas panic

think the following is a reasonable fix? --- Explicitly enable RTAS error logging, when it should be ready. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- arch/powerpc/platforms/pseries/rtasd.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/powerpc

Re: 2.6.23-rc7-mm1 -- powerpc rtas panic

On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote: I realise it'll make the patch bigger, but this doesn't seem like a particularly good name for the variable anymore. Sure, what about? Clarify when RTAS logging is enabled. Signed-off-by: Tony Breeds [EMAIL PROTECTED

Re: [PATCH] powerpc: add new required termio functions

actually testing whether it > actually broke powerpc? > > Or is something subtler going on? As far as I can see TIOCSLCKTRMIOS and TIOCGLCKTRMIOS aren't protected by TCGETS2 guards. Do they need to be ... Perhaps From: Tony Breeds <[EMAIL PROTECTED]> Add Guards around TIOCSLCKTR

Fix "no_sync_cmos_clock" logic inversion in kernel/time/ntp.c

Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- Seems to me that this timer will only get started on platforms that say they don't want it? kernel/time/ntp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: working/kernel/time

Fix no_sync_cmos_clock logic inversion in kernel/time/ntp.c

Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- Seems to me that this timer will only get started on platforms that say they don't want it? kernel/time/ntp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: working/kernel/time/ntp.c

Re: [PATCH] powerpc: add new required termio functions

? Or is something subtler going on? As far as I can see TIOCSLCKTRMIOS and TIOCGLCKTRMIOS aren't protected by TCGETS2 guards. Do they need to be ... Perhaps From: Tony Breeds [EMAIL PROTECTED] Add Guards around TIOCSLCKTRMIOS and TIOCGLCKTRMIOS. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- drivers

Re: linux-2.6.23-rc4 ppc build failure

e the patch below will probably help. Ensure that BLK_DEV_IDE is built-in befoer allowing BLK_DEV_IDE_PMAC to be selected. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- drivers/ide/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ide/Kconfig b/drivers/ide/

[PATCH] Fix discrepancy between VDSO based gettimeofday() and sys_gettimeofday().

sys_tz is updated they can also updater their copy in the vdso. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Cc: Tony Luck <[EMAIL PROTECTED]> Cc: John Stultz <[EMAIL PROTECTED]> --- Only compile tested for IA64 Testcase at: http://

[PATCH] Fix discrepancy between VDSO based gettimeofday() and sys_gettimeofday().

sys_tz is updated they can also updater their copy in the vdso. Signed-off-by: Tony Breeds [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Cc: Tony Luck [EMAIL PROTECTED] Cc: John Stultz [EMAIL PROTECTED] --- Only compile tested for IA64 Testcase at: http://bakeyournoodle.com/~tony/settimeofday

Re: linux-2.6.23-rc4 ppc build failure

-in befoer allowing BLK_DEV_IDE_PMAC to be selected. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- drivers/ide/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig index e049f65..e55be26 100644 --- a/drivers/ide/Kconfig

Re: [PATCH] Re: 2.6.22-git ppc build failure

t related to the merge after all. With my orginal compile (and the revert below) PCI works and the kernel boots. Please apply both. From: Tony Breeds <[EMAIL PROTECTED]> Subject: [PATCH] Revert "[POWERPC] Do firmware feature fixups after features are initialised&q

Re: [PATCH] Re: 2.6.22-git ppc build failure

after all. With my orginal compile (and the revert below) PCI works and the kernel boots. Please apply both. From: Tony Breeds [EMAIL PROTECTED] Subject: [PATCH] Revert [POWERPC] Do firmware feature fixups after features are initialised This reverts commit

Re: [PATCH] Re: 2.6.22-git ppc build failure

On Tue, Jul 17, 2007 at 06:44:26PM -0700, Linus Torvalds wrote: > Thanks. I assume this has been boot-tested too, and everything else from > the PCI merge was ok? *cough* umm the boot test fails. I'll look harder at the merge, and provide a better patch. Yours Tony linux.conf.au

[PATCH] Re: 2.6.22-git ppc build failure

On Tue, Jul 17, 2007 at 11:04:57AM -0700, Bret Towe wrote: > this is off my g4 mac mini > latest git as of when this email was sent > config file attached Hi Bret, the patch below will fix it. From: Tony Breeds <[EMAIL PROTECTED]> Fix compile failure in arch/powerpc/kern

[PATCH] Re: 2.6.22-git ppc build failure

On Tue, Jul 17, 2007 at 11:04:57AM -0700, Bret Towe wrote: this is off my g4 mac mini latest git as of when this email was sent config file attached Hi Bret, the patch below will fix it. From: Tony Breeds [EMAIL PROTECTED] Fix compile failure in arch/powerpc/kernel/pci-common.c CC

Re: [PATCH] Re: 2.6.22-git ppc build failure

On Tue, Jul 17, 2007 at 06:44:26PM -0700, Linus Torvalds wrote: Thanks. I assume this has been boot-tested too, and everything else from the PCI merge was ok? *cough* umm the boot test fails. I'll look harder at the merge, and provide a better patch. Yours Tony linux.conf.au

Re: [PATCH] mkmakefile: include ARCH on O= builds

On Thu, Jul 12, 2007 at 03:40:04AM +0200, Bodo Eggert wrote: > If you build using O=builddir ARCH=bar, you'll currently need to supply > ARCH= on builds from the builddir, too. With this patch, the generated > Makefile will do that instead. > diff -X dontdiff -pruN

Re: [PATCH] mkmakefile: include ARCH on O= builds

On Thu, Jul 12, 2007 at 03:40:04AM +0200, Bodo Eggert wrote: If you build using O=builddir ARCH=bar, you'll currently need to supply ARCH= on builds from the builddir, too. With this patch, the generated Makefile will do that instead. snip diff -X dontdiff -pruN

Re: [RFC] clocksouce implementation for powerpc

On Wed, Jun 20, 2007 at 02:06:01PM -0700, john stultz wrote: Hi John. > Hey Tony, > Thanks for sending this out! I really appreciate this work, as its been > on my todo forever, and I've just not been able to focus on it. > Currently it seems a bit minimal of a conversion (ideally there

Re: [RFC] clocksouce implementation for powerpc

On Wed, Jun 20, 2007 at 07:57:19AM -0700, Daniel Walker wrote: Hi Daniel. > As I said in our private thread, I do think you should be using > update_vsyscall() .. update_vsyscall() is just called when the time is > set, usually that happens in the timer interrupt and sometimes that > happens in

Re: [RFC] clocksouce implementation for powerpc

On Wed, Jun 20, 2007 at 08:53:47PM +0400, Sergei Shtylyov wrote: Hi Sergei, Thanks for taking the time to look over my patch. >I guess it's been based on the prior work by John Stultz (and me too :-)? At some level I guess so. John did send me a patch a while ago. >If you

Re: [RFC] clocksouce implementation for powerpc

On Wed, Jun 20, 2007 at 08:53:47PM +0400, Sergei Shtylyov wrote: Hi Sergei, Thanks for taking the time to look over my patch. I guess it's been based on the prior work by John Stultz (and me too :-)? At some level I guess so. John did send me a patch a while ago. If you mean

Re: [RFC] clocksouce implementation for powerpc

On Wed, Jun 20, 2007 at 07:57:19AM -0700, Daniel Walker wrote: Hi Daniel. As I said in our private thread, I do think you should be using update_vsyscall() .. update_vsyscall() is just called when the time is set, usually that happens in the timer interrupt and sometimes that happens in

Re: [RFC] clocksouce implementation for powerpc

On Wed, Jun 20, 2007 at 02:06:01PM -0700, john stultz wrote: Hi John. Hey Tony, Thanks for sending this out! I really appreciate this work, as its been on my todo forever, and I've just not been able to focus on it. Currently it seems a bit minimal of a conversion (ideally there should

[RFC] clocksouce implementation for powerpc

On Sat, Jun 16, 2007 at 08:51:23AM -0700, Daniel Walker wrote: > On Sat, 2007-06-16 at 10:36 +, Thomas Gleixner wrote: > > plain text document attachment > > (clocksource-add-settimeofday-hook.patch) > > From: Tony Breeds <[EMAIL PROTECTED] > > >

[RFC] clocksouce implementation for powerpc

On Sat, Jun 16, 2007 at 08:51:23AM -0700, Daniel Walker wrote: On Sat, 2007-06-16 at 10:36 +, Thomas Gleixner wrote: plain text document attachment (clocksource-add-settimeofday-hook.patch) From: Tony Breeds [EMAIL PROTECTED] I'm working on a clocksource implementation for all

Include hrtimer.h in tick.h.

From: Tony Breeds <[EMAIL PROTECTED]> struct tick_shed in tick.h uses struct hrtimer, explictly include the hrtimer header file to make sure this is defined. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- include/linux/tick.h |1 + 1 file changed, 1 insertion(+) In

[PATCH] Add per clocksource hook to settimeofday().

I'm working on a clocksource implementation for all powerpc platforms. some of these platforms needs to do a little work as part of the settimeofday() syscall and I can't see a way to do that without adding this hook to clocksource. From: Tony Breeds <[EMAIL PROTECTED]> Add per clocksourc

[PATCH] Add per clocksource hook to settimeofday().

I'm working on a clocksource implementation for all powerpc platforms. some of these platforms needs to do a little work as part of the settimeofday() syscall and I can't see a way to do that without adding this hook to clocksource. From: Tony Breeds [EMAIL PROTECTED] Add per clocksource hook

Include hrtimer.h in tick.h.

From: Tony Breeds [EMAIL PROTECTED] struct tick_shed in tick.h uses struct hrtimer, explictly include the hrtimer header file to make sure this is defined. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- include/linux/tick.h |1 + 1 file changed, 1 insertion(+) Index: working/include

[PATCH/RFC] Fix build failure for drivers/ata/pata_scc.c

a patch to make ata_bus_post_reset() assesable to drivers be accepted? Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> CC: Tejun Heo <[EMAIL PROTECTED]> CC: Akira Iguchi <[EMAIL PROTECTED]> CC: Jeff Garzik <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] --- drive

[PATCH] Fix warning when building fs/afs/super.c

modify the table so making it const should be safe. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- include/linux/parser.h |2 +- lib/parser.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: working/include/linux/pa

[PATCH] drivers/ata/pata_hpt37x.c Remove unused static variable.

Remove unused static variable. drivers/ata/pata_hpt37x.c: In function 'hpt37x_init_one': drivers/ata/pata_hpt37x.c:935: warning: unused variable 'info_hpt372_50' Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> CC: Jeff Garzik <[EMAIL PROTECTED]> CC: Alan Cox <[EMAIL PROTECT

[PATCH] drivers/ata/pata_hpt37x.c Remove unused static variable.

Remove unused static variable. drivers/ata/pata_hpt37x.c: In function 'hpt37x_init_one': drivers/ata/pata_hpt37x.c:935: warning: unused variable 'info_hpt372_50' Signed-off-by: Tony Breeds [EMAIL PROTECTED] CC: Jeff Garzik [EMAIL PROTECTED] CC: Alan Cox [EMAIL PROTECTED] CC: [EMAIL PROTECTED

[PATCH] Fix warning when building fs/afs/super.c

modify the table so making it const should be safe. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- include/linux/parser.h |2 +- lib/parser.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: working/include/linux/parser.h

[PATCH/RFC] Fix build failure for drivers/ata/pata_scc.c

a patch to make ata_bus_post_reset() assesable to drivers be accepted? Signed-off-by: Tony Breeds [EMAIL PROTECTED] CC: Tejun Heo [EMAIL PROTECTED] CC: Akira Iguchi [EMAIL PROTECTED] CC: Jeff Garzik [EMAIL PROTECTED] CC: [EMAIL PROTECTED] --- drivers/ata/pata_scc.c | 48

[LGUEST] Look in object dir for .config

From: Tony Breeds <[EMAIL PROTECTED]> [LGUEST] Look in object dir for .config If you build with make O= then .config isn't in ../../, this patch goes partway to making sure that you don't dirty the source tree. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- Document

[LGUEST] Look in object dir for .config

From: Tony Breeds [EMAIL PROTECTED] [LGUEST] Look in object dir for .config If you build with make O= then .config isn't in ../../, this patch goes partway to making sure that you don't dirty the source tree. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- Documentation/lguest/Makefile

Re: Powerpc build unhappy in 2.6.20.4?

On Mon, Apr 02, 2007 at 11:51:09PM -0400, Rob Landley wrote: > So "make oldconfig ARCH=powerpc" will accept a config that doesn't have a > platform selected? It seems so. I think the patch below will fix that by forcing at least one platform to be selected. Can you try it and see if it helps

Re: Powerpc build unhappy in 2.6.20.4?

On Mon, Apr 02, 2007 at 11:51:09PM -0400, Rob Landley wrote: So make oldconfig ARCH=powerpc will accept a config that doesn't have a platform selected? It seems so. I think the patch below will fix that by forcing at least one platform to be selected. Can you try it and see if it helps

Re: Powerpc build unhappy in 2.6.20.4?

On Mon, Apr 02, 2007 at 03:14:14PM -0400, Rob Landley wrote: > Sure, quite easily the source of the trouble. Attached in both full .config > and mini.config formats. Okay, I have no idea how it happend but you seem to have an invalid config. It looks to me like you need to select a platform.

Re: Powerpc build unhappy in 2.6.20.4?

On Mon, Apr 02, 2007 at 03:14:14PM -0400, Rob Landley wrote: Sure, quite easily the source of the trouble. Attached in both full .config and mini.config formats. Okay, I have no idea how it happend but you seem to have an invalid config. It looks to me like you need to select a platform.

Re: Powerpc build unhappy in 2.6.20.4?

On Fri, Mar 30, 2007 at 05:53:26PM -0400, Rob Landley wrote: > So doing: > > make ARCH=powerpc CROSS=powerpc- > > Chugs along fine for a while, but then it ends with: > > MODPOST vmlinux There should be a lot of activity between this step and the error below. > ln: accessing

Re: Powerpc build unhappy in 2.6.20.4?

On Fri, Mar 30, 2007 at 05:53:26PM -0400, Rob Landley wrote: So doing: make ARCH=powerpc CROSS=powerpc- Chugs along fine for a while, but then it ends with: MODPOST vmlinux There should be a lot of activity between this step and the error below. ln: accessing

Re: 2.6.21-rc2-mm2: drivers/net/wireless/libertas/debugfs.c addr bogosity

act. I'm not certain using the FIELD_SIZEOF() macro directly is a win. From: Tony Breeds <[EMAIL PROTECTED]> Cleanup drivers/net/wireless/libertas/debugfs.c to use standard kernel macros and functions. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- only compile tested on x86

Re: 2.6.21-rc2-mm2: drivers/net/wireless/libertas/debugfs.c addr bogosity

not certain using the FIELD_SIZEOF() macro directly is a win. From: Tony Breeds [EMAIL PROTECTED] Cleanup drivers/net/wireless/libertas/debugfs.c to use standard kernel macros and functions. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- only compile tested on x86 drivers/net/wireless

Re: 2.6.21-rc2-mm2: drivers/net/wireless/libertas/debugfs.c addr bogosity

64bit architectures. > > Is OK - it is simply yet another reimplementation of offsetof(). Hint. Perhaps something like? Against 2.6.21-rc3-mm2 From: Tony Breeds <[EMAIL PROTECTED]> Cleanup drivers/net/wireless/libertas/debugfs.c to use standard kernel macros and functions. Signed-of

Re: 2.6.21-rc2-mm2: drivers/net/wireless/libertas/debugfs.c addr bogosity

... drivers/net/wireless/libertas/debugfs.c contains: #define item_addr(n) ((u32) ((wlan_adapter *)0)-n) This is wrong on 64bit architectures. Is OK - it is simply yet another reimplementation of offsetof(). Hint. Perhaps something like? Against 2.6.21-rc3-mm2 From: Tony Breeds

[PATCH] Fix soft lockup with iSeries viocd driver

From: Tony Breeds <[EMAIL PROTECTED]> Fix soft lockup with iSeries viocd driver, caused by eventually calling end_that_request_first() with nr_bytes 0. The lockup is triggered by hald, interrogating the device. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> Signed-off-by: Jens A

  1   2   >