GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
This breaks the bootwrapper as we'd need to link with libgcc to get the
implementation of the register save/restores.
To workaround this issue
David Gibson writes:
> Do you even need the processor ID test at all? The boot processor
> should always have its stack covered by SLB entry 0 when we come
> through here, shouldn't it?
I was concerned that get_paca()->kstack wouldn't have been initialized
by the time the boot cpu calls slb_init
GCC 4.4.x looks to be adding support for generating out-of-line
register
saves/restores based on:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
This breaks the bootwrapper as we'd need to link with libgcc to get the
implementation of the register save/restores.
To workaround this iss
On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote:
> GCC 4.4.x looks to be adding support for generating out-of-line register
> saves/restores based on:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
>
> This breaks the bootwrapper as we'd need to link with libgcc to get the
> impl
On May 2, 2008, at 6:54 AM, Segher Boessenkool wrote:
GCC 4.4.x looks to be adding support for generating out-of-line
register
saves/restores based on:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
This breaks the bootwrapper as we'd need to link with libgcc to get
the
implemen
On May 2, 2008, at 7:13 AM, Josh Boyer wrote:
On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote:
GCC 4.4.x looks to be adding support for generating out-of-line
register
saves/restores based on:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
This breaks the bootwrapper as we'd n
On Thu, May 1, 2008 at 11:56 PM, Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Linus,
>
> Please do:
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
Hmmm; none of these commits appear in your public git server ATM. Top
of tree is still "[POWERPC] Fix cras
Why can't we link with libgcc, instead?
we possibly could, the problem is knowing the path of libgcc to link
with.
gcc -print-libgcc-file-name
This seemed easier to me than the makefile headaches to ensure that
we get that right.
Ah come on, make syntax is fun!
Segher
___
On May 2, 2008, at 8:37 AM, Segher Boessenkool wrote:
Why can't we link with libgcc, instead?
we possibly could, the problem is knowing the path of libgcc to
link with.
gcc -print-libgcc-file-name
It wasn't clear if we used a multilib toolchain if we always get the
proper libgcc since
Hi Geoff,
what about adding these defaults:
- CONFIG_SCHED_SMT
- CONFIG_HUGETLBFS (needed by ibm cell sdk)
not sure about:
- CONFIG_SPU_FS_64K_LS
Greetings
Marvin
On Thursday 01 May 2008 00:25:36 Geoff Levand wrote:
> Update ps3_defconfig.
>
> Signed-off-
On Fri, 2 May 2008 08:32:12 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On May 2, 2008, at 7:13 AM, Josh Boyer wrote:
>
> > On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote:
> >> GCC 4.4.x looks to be adding support for generating out-of-line
> >> register
> >> saves/restores based on:
On May 2, 2008, at 8:53 AM, Josh Boyer wrote:
On Fri, 2 May 2008 08:32:12 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
On May 2, 2008, at 7:13 AM, Josh Boyer wrote:
On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote:
GCC 4.4.x looks to be adding support for generating out-of-line
register
On 2/19/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > i2c->irq = platform_get_irq(pdev, 0);
> > - if (i2c->irq < 0) {
> > + if (i2c->irq < NO_IRQ) {
>
>
> I am skeptical about this one. Can platform_get_irq() really return
> NO_IRQ? I thought that the IRQ resource would be plain
GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
This breaks the kernel build as we'd have to link with libgcc to get the
implementation of the register save/restores.
To workaround this issu
On May 2, 2008, at 6:54 AM, Segher Boessenkool wrote:
GCC 4.4.x looks to be adding support for generating out-of-line
register
saves/restores based on:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
This breaks the bootwrapper as we'd need to link with libgcc to get
the
implemen
Hi Jon,
On Fri, 2 May 2008 10:23:01 -0400, Jon Smirl wrote:
> On 2/19/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > > i2c->irq = platform_get_irq(pdev, 0);
> > > - if (i2c->irq < 0) {
> > > + if (i2c->irq < NO_IRQ) {
> >
> >
> > I am skeptical about this one. Can platform_get_ir
On Fri, May 02, 2008 at 09:21:08AM -0500, Kumar Gala wrote:
> GCC 4.4.x looks to be adding support for generating out-of-line register
> saves/restores based on:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
>
> This breaks the kernel build as we'd have to link with libgcc to get th
On Fri, 2 May 2008, Paul Mackerras wrote:
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
"Already up-to-date."
Forgot to push?
Linus
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
http
On Fri, May 02, 2008 at 08:41:27AM -0500, Kumar Gala wrote:
> I assume there is a reason we don't link libgcc w/the kernel.
Inertia?
BTW, it looks like ARM, SuperH, PA-Risc, and a few others do link in
libgcc.
-Scott
___
Linuxppc-dev mailing list
Linux
On May 2, 2008, at 10:07 AM, Scott Wood wrote:
On Fri, May 02, 2008 at 09:21:08AM -0500, Kumar Gala wrote:
GCC 4.4.x looks to be adding support for generating out-of-line
register
saves/restores based on:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
This breaks the kernel build
New version with your fix.
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index bbe787b..b141057 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned
timeout, int writing)
Hi Jon,
On Fri, 2 May 2008 12:02:27 -0400, Jon Smirl wrote:
> New version with your fix.
>
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index bbe787b..b141057 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -99,7 +99,7 @@ stati
Why can't we link with libgcc, instead?
Do you have or can you generate a ppc64 toolchain with this patch in
it?
I'm not sure what you mean.
I build GCC TOT toolchains sort-of daily, and build the kernel
with it (all architectures). I don't build any 4xx config though,
maybe I should.
Seg
Acked-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
Grant, please pick this up.
Steve
> -Original Message-
> From: Adrian Bunk [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 23, 2008 2:52 AM
> To: Stephen Neuendorffer; Grant Likely; [EMAIL PROTECTED]
> Cc: linuxppc-dev@ozlabs.org; [E
gcc -print-libgcc-file-name
It wasn't clear if we used a multilib toolchain if we always get the
proper libgcc since we are building bootwrappers for all kinda of
variants. (e500, 40x, 6xx, etc.).
gcc -mthe-options-to-select-some-target -print-libgcc-file-name
My patch seemed the least pa
I attached the diff file. I had forgot that I renamed the file so it
wasn't getting compiled. I compiled it this time. I've made too many
other changes to it to test this version on my current hardware.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/
If someone using cutting edge toolchains for ppc64 could test and make
sure if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE things work that would be
nice.
Current linus tree + some more stuff + this patch, ppc64_defconfig,
powerpc64-linux-gcc (GCC) 4.4.0 20080429 (experimental), builds just
fine. CON
Why don't we just link with libgcc?
Its something of a PITA to do that in the kernel at this point since
we've duplicated libgcc functionality in it. I'm sure there are some
historical reasons this wasn't done to start with.
That's the same as saying that it would be a nice cleanup to rem
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 25f8bc7..12f68ab 100644
--- a/arch/po
Mostly having to do with not marking things __iomem. And some failure
to use appropriate accessors to read MMIO regs.
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/qe_lib/qe.c |6 ++--
arch/powerpc/sysdev/qe_lib/ucc.c |6 ++--
arch/powerpc/sysdev/qe_l
The 8568 MDS needs some configuration changes to the PHY in order to work
properly. These are done in the firmware, normally, but Linux shouldn't
need to rely on the firmware running such things (someone could disable
the PHY support in the firmware to save space, for instance).
Signed-off-by: An
The old code assumed there was only one, but the 8572 actually has 3.
Also, our usual id, 0xe0024520, gets resolved to -1 somewhere, and this was
preventing the multiple buses from having different ids. So we only keep
the low 20 bits, which have the interesting info, anyway.
Signed-off-by: Andy
Andy Fleming wrote:
+ struct qe_iram __iomem iram; /* I-RAM */
+ struct qe_ic_regs __iomem ic; /* Interrupt Controller */
+ struct cp_qe __iomemcp; /* Communications Processor */
+ struct qe_mux __iomem qmx;/* QE Multiplex
Andy Fleming wrote:
> int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private **
> uccf_ret)
> {
> struct ucc_fast_private *uccf;
> - struct ucc_fast *uf_regs;
> + struct ucc_fast __iomem *uf_regs;
> u32 gumr;
> int ret;
>
> @@ -216,10 +216,10 @@ in
This driver has been superseded by fs_enet and is no longer in use.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |1 -
drivers/net/Makefile|1 -
drivers/net/fec_8xx/Kconfig | 20 -
drivers/net/fec_8xx/Makefile|
Phil,
When you have a chance, could you please take a look at the
arch-independent pieces of the OProfile kernel driver that this patch
touches? In short, this patch fixes a bug that I was responsible for in
my original OProfile-Cell SPE port (argh! :-[ ) where I was
improperly adding events
I added:
int __init iDoNothingUseful(struct cpu_spec *s,struct cpu_spec *t)
{
return s-t;
}
right before the definition of identify_cpu() in cputable.c and:
// (void) (*PTRRELOC(&iDoNothingUseful))(s,t);
(void) iDoNothingUseful(s,t);
right b
On Fri, 2 May 2008 13:19:44 -0400, Jon Smirl wrote:
> I attached the diff file. I had forgot that I renamed the file so it
> wasn't getting compiled. I compiled it this time. I've made too many
> other changes to it to test this version on my current hardware.
Applied, thanks.
--
Jean Delvare
__
From: Daniel Walker <[EMAIL PROTECTED]>
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/macintosh/therm_pm72.c | 31 --
From: Daniel Walker <[EMAIL PROTECTED]>
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/macintosh/windfarm_smu_sat.c | 10 +-
1 file chang
From: Emil Medve <[EMAIL PROTECTED]>
We provide an ioremap_flags so provide a corresponding devm_ioremap_prot. The
slight name difference is at Ben Herrenschmidt request as he plans on changing
ioremap_flags to ioremap_prot in the future.
Signed-off-by: Emil Medve <[EMAIL PROTECTED]>
Signed-off-
From: "Denis V. Lunev" <[EMAIL PROTECTED]>
Simply replace proc_create and further data assigned with proc_create_data.
No need to check for data!=NULL after that.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
Cc: Alexey Dobriyan <[EMAIL PROTECTED]>
Cc: Eric W. Biederman <[EMAIL PROTECTED]>
C
From: Daniel Walker <[EMAIL PROTECTED]>
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/macintosh/adb.c | 30 +++---
1 fil
On May 2, 2008, at 12:11 PM, Segher Boessenkool wrote:
Why can't we link with libgcc, instead?
Do you have or can you generate a ppc64 toolchain with this patch
in it?
I'm not sure what you mean.
Sorry, I meant the gcc patch. I'm not sure if this has been committed
to FSF head or not
On May 2, 2008, at 12:33 PM, Segher Boessenkool wrote:
If someone using cutting edge toolchains for ppc64 could test and
make
sure if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE things work that
would be
nice.
Current linus tree + some more stuff + this patch, ppc64_defconfig,
powerpc64-linux-g
On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote:
Why don't we just link with libgcc?
Its something of a PITA to do that in the kernel at this point
since we've duplicated libgcc functionality in it. I'm sure there
are some historical reasons this wasn't done to start with.
That
Kumar Gala wrote:
On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote:
Why don't we just link with libgcc?
Its something of a PITA to do that in the kernel at this point since
we've duplicated libgcc functionality in it. I'm sure there are some
historical reasons this wasn't done to s
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Fri, 2 May 2008 16:28:36 -0500
> Sorry, I meant the gcc patch. I'm not sure if this has been committed
> to FSF head or not.
If that's the case it would be a good idea to suggest a command line
option to disable the new out-of-line code generation fea
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Fri, 2 May 2008 16:34:13 -0500
> We'll hopefully this thread might spark either an explanation for why
> we aren't just linking libgcc in a statement that says we should and
> we can remove the code that implements libgcc functionality.
>
> How would
David Miller wrote:
If you link in libgcc, all of a sudden you have a whole new class of
potential problems, don't do it.
All it takes is one of these libgcc libcalls the kernel actually
references, needing something else in libc, to make this exercise
futile.
What in libgcc references libc, a
On May 2, 2008, at 4:40 PM, David Miller wrote:
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Fri, 2 May 2008 16:28:36 -0500
Sorry, I meant the gcc patch. I'm not sure if this has been
committed
to FSF head or not.
If that's the case it would be a good idea to suggest a command line
option
From: Scott Wood <[EMAIL PROTECTED]>
Date: Fri, 02 May 2008 16:45:45 -0500
> David Miller wrote:
> > If you link in libgcc, all of a sudden you have a whole new class of
> > potential problems, don't do it.
> >
> > All it takes is one of these libgcc libcalls the kernel actually
> > references, n
David Miller wrote:
The problem only occurs once you reference a function that references
libc stuff, and those guys are just lucky so far.
Yeah, lucky they don't need to reinvent the wheel every time the
GCC/libgcc interface changes. :-)
If GCC generates a call to a libgcc function that cal
Benjamin Herrenschmidt wrote:
> On Thu, 2008-05-01 at 14:46 -0700, Geoff Levand wrote:
>>
>> It doesn't seem to cause problems on PS3, and I added it into
>> ps3-linux.git
>> as other/powerpc-vmemmap-variable-page-size.diff, but I couldn't get
>> it to
>> fail without the patch...
>>
>> Could yo
From: Scott Wood <[EMAIL PROTECTED]>
Date: Fri, 02 May 2008 17:16:07 -0500
> If GCC generates a call to a libgcc function that calls a libc function,
> I'd consider that a pretty serious bug, given that said libc function is
> likely to consist of GCC-generated code, which could call the same
>
David Miller wrote:
From: Scott Wood <[EMAIL PROTECTED]>
Date: Fri, 02 May 2008 17:16:07 -0500
If GCC generates a call to a libgcc function that calls a libc function,
I'd consider that a pretty serious bug, given that said libc function is
likely to consist of GCC-generated code, which could
From: Scott Wood <[EMAIL PROTECTED]>
Date: Fri, 02 May 2008 17:38:21 -0500
> David Miller wrote:
> > The kernel is a special environment. Therefore even if you start
> > linking with libgcc, it is inevitable that you will need some
> > changed local version for some of those routines in the kerne
On Fri, 2008-05-02 at 19:03 +1000, Paul Mackerras wrote:
> David Gibson writes:
>
> > Do you even need the processor ID test at all? The boot processor
> > should always have its stack covered by SLB entry 0 when we come
> > through here, shouldn't it?
>
> I was concerned that get_paca()->kstac
On Fri, 2008-05-02 at 16:34 -0500, Kumar Gala wrote:
> On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote:
>
> >>>
> >>> Why don't we just link with libgcc?
> >>>
> >>
> >> Its something of a PITA to do that in the kernel at this point
> >> since we've duplicated libgcc functionality in it
On Fri, 2008-05-02 at 14:42 -0700, David Miller wrote:
> From: Kumar Gala <[EMAIL PROTECTED]>
> Date: Fri, 2 May 2008 16:34:13 -0500
>
> > We'll hopefully this thread might spark either an explanation for why
> > we aren't just linking libgcc in a statement that says we should and
> > we can
On Fri, 2008-05-02 at 14:40 -0700, David Miller wrote:
> From: Kumar Gala <[EMAIL PROTECTED]>
> Date: Fri, 2 May 2008 16:28:36 -0500
>
> > Sorry, I meant the gcc patch. I'm not sure if this has been committed
> > to FSF head or not.
>
> If that's the case it would be a good idea to suggest a
On Fri, 2008-05-02 at 13:42 -0700, Kevin Diggs wrote:
> I added:
>
> int __init iDoNothingUseful(struct cpu_spec *s,struct cpu_spec *t)
> {
> return s-t;
> }
>
> right before the definition of identify_cpu() in cputable.c and:
>
> // (void) (*PTRRELOC(&iDoNothingUs
Linus Torvalds writes:
> On Fri, 2 May 2008, Paul Mackerras wrote:
> >
> > git pull \
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
>
> "Already up-to-date."
>
> Forgot to push?
Yep. :(
Try again now.
Thanks,
Paul.
___
Hi,
On Fri, May 02, 2008 at 01:03:42PM -0500, Andy Fleming wrote:
> +static int __init board_fixups(void)
> +{
> + char phy_id[BUS_ID_SIZE];
> + char *compstrs[2] = {"fsl,gianfar-mdio", "fsl,ucc-mdio"};
> + struct device_node *mdio;
> + struct resource res;
> + int i;
> +
> +
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Sat, 03 May 2008 09:27:55 +1000
> That is, it would be fairly non-sensical for module code to go through
> the trampoline to call those stubs in the kernel (and having to
> EXPORT_SYMBOL them).
Oh, I forgot about how far function calls are do
On May 2, 2008, at 18:49, Olof Johansson wrote:
Hi,
On Fri, May 02, 2008 at 01:03:42PM -0500, Andy Fleming wrote:
+static int __init board_fixups(void)
+{
+ char phy_id[BUS_ID_SIZE];
+ char *compstrs[2] = {"fsl,gianfar-mdio", "fsl,ucc-mdio"};
+ struct device_node *mdio;
+
The 8568 MDS needs some configuration changes to the PHY in order to
work properly. These are done in the firmware, normally, but Linux
shouldn't need to rely on the firmware running such things (someone
could disable the PHY support in the firmware to save space, for instance).
Signed-off-by: An
On May 2, 2008, at 13:07, Scott Wood wrote:
Andy Fleming wrote:
+ struct qe_iram __iomem iram; /* I-RAM */
+ struct qe_ic_regs __iomem ic; /* Interrupt Controller */
+ struct cp_qe __iomemcp; /* Communications Processor */
+ struct q
On May 2, 2008, at 13:37, Timur Tabi wrote:
Andy Fleming wrote:
int ucc_fast_init(struct ucc_fast_info * uf_info, struct
ucc_fast_private ** uccf_ret)
{
struct ucc_fast_private *uccf;
- struct ucc_fast *uf_regs;
+ struct ucc_fast __iomem *uf_regs;
u32 gumr;
That is, it would be fairly non-sensical for module code to go through
the trampoline to call those stubs in the kernel (and having to
EXPORT_SYMBOL them).
You can link every module to libgcc separately. Probably it can also
be set up so that some libgcc routines get linked into the kernel,
and
The following adds local bus, flash and MTD partition nodes for
sbc8548. As well, a compatible field for the soc node, so that
of_platform_bus_probe() will pick it up.
Something that is provided through this newly added epld node
is the Hardware Revision is now being reported at bootup.
Signed-of
What in libgcc references libc, and why isn't this a problem for
Linux/ARM, Linux/SH, U-boot, and the many other libc-less programs
that
use libgcc?
The problem only occurs once you reference a function that references
libc stuff, and those guys are just lucky so far.
The only calls to the C
Benjamin Herrenschmidt wrote:
On Fri, 2008-05-02 at 13:42 -0700, Kevin Diggs wrote:
I added:
int __init iDoNothingUseful(struct cpu_spec *s,struct cpu_spec *t)
{
return s-t;
}
right before the definition of identify_cpu() in cputable.c and:
// (void) (*PTRRELOC(&
73 matches
Mail list logo
