On Sun, May 26, 2013 at 08:44:35AM +1000, Benjamin Herrenschmidt wrote:
It's not used ... yet. It's needed if we ever are to implement
something like devm_ioremap_wc(). I suspect if things like framebuffer
or even IB drivers start using devm this will be needed.
Any specific reason why you
in an xcompiler, and it passed... no promises
I didn't introduce a header mess on some random variant though.
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -23,6 +23,7 @@
#include linux/init.h
#include linux/list.h
+#include
From: Kyle McMartin k...@redhat.com
For some reason or another (newer gcc?) on Fedora 12 koji builders we're
seeing _restgpr0_$n symbols instead of _restgpr_$n as handled in the
prom_init_check.sh file:
Checking prom_init.o symbol '_restgpr0_14'
Error: External symbol '_restgpr0_14' referenced
On Thu, Sep 17, 2009 at 01:41:44PM -0400, Kyle McMartin wrote:
For some reason or another (newer gcc?) on Fedora 12 koji builders we're
seeing _restgpr0_$n symbols instead of _restgpr_$n as handled in the
prom_init_check.sh file:
Checking prom_init.o symbol '_restgpr0_14'
Error: External
On Fri, Sep 18, 2009 at 11:50:06AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2009-09-17 at 13:41 -0400, Kyle McMartin wrote:
From: Kyle McMartin k...@redhat.com
For some reason or another (newer gcc?) on Fedora 12 koji builders we're
seeing _restgpr0_$n symbols instead of _restgpr_$n
On Tue, Jun 23, 2009 at 03:44:28PM +1000, Stephen Rothwell wrote:
When building with a 4.1.x compiler on powerpc64 (at least) we get
this error:
drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a
section type conflict
This was introduced by commit
On Fri, Jun 12, 2009 at 09:04:52AM -0500, Kumar Gala wrote:
On UP, all the spinlock manipulation goes away and we simply disable
interrupts around each operation. In fact gcc eliminates the whole
atomic64_lock variable as well.
Signed-off-by: Paul Mackerras pau...@samba.org
---
On Thu, Apr 02, 2009 at 11:42:02AM +0200, Geert Uytterhoeven wrote:
On Fri, 13 Mar 2009, Kyle McMartin wrote:
On Wed, Mar 11, 2009 at 06:26:12PM +0100, Geert Uytterhoeven wrote:
On Wed, 11 Mar 2009, Kyle McMartin wrote:
On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote
On Thu, Apr 02, 2009 at 05:04:47PM -0500, Kumar Gala wrote:
+config SPE_EMULATION
+ bool SPE Emulation Support
+ depends on (CLASSIC32 || POWER4) !ALTIVEC !SPE
+ ---help---
+ This option enables kernel support for the Altivec extensions to the
+
Looks like you kind of
On Wed, Mar 11, 2009 at 06:26:12PM +0100, Geert Uytterhoeven wrote:
Hi Kyle,
On Wed, 11 Mar 2009, Kyle McMartin wrote:
On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote:
Is it OK for you to take it through your PA-RISC tree?
If yes, I can resend the patch series
On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote:
Is it OK for you to take it through your PA-RISC tree?
If yes, I can resend the patch series with the collected acks.
That's fine with me, just hit me up with a git tree address and I'll
suck it all into the rtc-parisc tree?
On Wed, Mar 04, 2009 at 05:42:20PM +1100, Benjamin Herrenschmidt wrote:
Thanks, I applied Tony's patch and sent a pull request to Linus.
Works for me. Thanks for being so quick, Ben!
cheers, Kyle
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
From: Kyle McMartin k...@redhat.com
Bug #486511 in Fedora, this is getting applied to any machine with a NEC
USB pci device if this CONFIG_GEF_SBC610 is on (as it was in Fedora.)
Obviously this isn't appropriate to do in any more than the SBC610
case..., so flag that we're a sbc610 board
On Tue, Feb 24, 2009 at 09:40:34AM +0100, Sam Ravnborg wrote:
x86 has a specific .section .eh_frame,a,@progbits in vdso32/int80.S as
one example.
Have you analyzed all these hits?
These aren't effected by the patch. All the occurances of it inside the
kernel are explicitly written for the
script.)
If these .eh_frame sections are eventually used, adding a per-arch
CONFIG_WANT_UNWIND check would be trivial.
(This was reported against Fedora, which appears to be the only distro
doing any building against gcc-4.4 at present: RH bz#486545.)
Signed-off-by: Kyle McMartin k
From: Kyle McMartin k...@redhat.com
On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
sections, which are, for the kernel, fairly pointless. Additionally, on
ppc64 this generates a relocation format which the kernel module loader
does not currently support (R_PPC64_REL32
an ack from the ppc/ia64
folks too.
... That said, please apply it, Linus. :)
Acked-by: Kyle McMartin [EMAIL PROTECTED]
regards, Kyle
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Fri, Jul 04, 2008 at 02:36:21PM -0600, Matthew Wilcox wrote:
It's also true for parisc, fwiw. Added a cc to them.
I posted a patch months ago for kallsyms on parisc, but it looks like
nobody ever responded or cared. Nice.
___
Linuxppc-dev mailing
/processor.h
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
include/asm-ia64/processor.h|6 ++
include/asm-parisc/processor.h |8
include/asm-powerpc/processor.h |8
include/linux/kallsyms.h| 13 -
4 files changed, 26 insertions(+), 9
On Fri, Apr 18, 2008 at 01:58:06PM +1000, Benjamin Herrenschmidt wrote:
Well, looking there, I saw we already used weak symbols for that so what
about the patch below ? If you're ok, I'll re-send with appropriate sob
adapted powerpc part.
This is definitely the cleanest way to do this from
that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with !r-parent
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Acked-by: Kyle McMartin [EMAIL PROTECTED
On Wed, Feb 27, 2008 at 05:04:42PM -0700, Bjorn Helgaas wrote:
Move PERR and SERR enables from pcibios_enable_resources() to
platform_pci_enable_device() so the former matches other
architectures and can be shared.
I don't have any problems with this, but I think the naming needs to
change.
On Mon, Feb 18, 2008 at 09:39:52PM -0700, Bjorn Helgaas wrote:
- PA-RISC always turns on SERR and PARITY, which no other arch does
I suspect this is because we set the host bus adapters to hard fail
(HPMC) on detecting an error, since we don't want to
1) return possibly bogus (-1)
On Mon, Feb 18, 2008 at 09:39:56PM -0700, Bjorn Helgaas wrote:
parisc: checks DEVICE_COUNT_RESOURCE (12) instead of PCI_NUM_RESOURCES
(11) resources at (1),
Good catch.
has no IORESOURCE_{IO,MEM} check at (3),
What else can it be?
has no PCI_ROM_RESOURCE check at (4), has
On Thu, Nov 29, 2007 at 12:35:33AM -0800, Andrew Morton wrote:
ten million is close enough to infinity for me to assume that we broke the
driver and that's never going to terminate.
how about this? doesn't break things on my pa8800:
diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.c
On Fri, Oct 12, 2007 at 11:23:39AM +1000, Paul Mackerras wrote:
Olof Johansson writes:
Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is
26 matches
Mail list logo
