Fix typos on Kconfig for PowerPC 4xx on-chip ethernet driver.
Signed-off-by: Satoru Takeuchi [EMAIL PROTECTED]
---
Index: 2.6.25-rc2/drivers/net/ibm_newemac/Kconfig
===
--- 2.6.25-rc2.orig/drivers/net/ibm_newemac/Kconfig
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so that both EMACs
don't use loopback mode as default.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
I'm not sure if this should be done here in the board platform code,
or in the
On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote:
Can I ask; what is the intended usage of such a thing? How large
would a typical binary blob be?
Device firmware?
--
dwmw2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Grant Likely wrote:
On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood [EMAIL PROTECTED] wrote:
A property's data can be populated with a file's contents
as follows:
node {
prop = /incbin/(path/to/data);
};
A subset of a file can be included by passing start and size parameters.
Dear list,
I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
specific gcc.
I then got tan infinity of SPE used in kernel messages. Looking at the
sources I ifdeffed out the printk call in KernelSPE, and I now have a
silent kernel, that seems to work fine.
Is there
On Fri, 22 Feb 2008 02:41:36 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Thu, Feb 21, 2008 at 03:20:10PM -0600, Scott Wood wrote:
Anton Vorontsov wrote:
On Thu, Feb 21, 2008 at 02:06:58PM -0600, Scott Wood wrote:
Current u-boots don't support device trees at all on 8xx.
Yes,
On Tuesday 19 February 2008 03:52, Josh Boyer wrote:
My apologies for taking so long on this. Digging through gcc history
isn't exactly fun :)
No problem. Thanks for tackling the issue.
Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
has been around since 2001. Seeing
I wonder why a kernel configured for E500 and compiled by a E500-specific gcc
triggers this message. Is it invalid to use SPE instructions in the kernel
or do I misunderstand the message ?
I think it's like floating point/altivec, we don't always save the FP
registers on kernel/userspace
Marvell PHY m88e (not sure about other models, but think they too) works in
two modes: fiber and copper. In Marvell PHY driver (that we have in current
community kernels) code supported only copper mode, and this is not
configurable,
bits for copper mode are simply written in registers during
On Fri, Feb 22, 2008 at 2:02 AM, David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote:
Can I ask; what is the intended usage of such a thing? How large
would a typical binary blob be?
Device firmware?
That's what I was wondering about. Is
On Thu, Feb 21, 2008 at 11:05:58PM -0700, Grant Likely wrote:
On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood [EMAIL PROTECTED] wrote:
A property's data can be populated with a file's contents
as follows:
node {
prop = /incbin/(path/to/data);
};
A subset of a file can be
On Fri, Feb 22, 2008 at 10:24:56AM -0600, Jon Loeliger wrote:
So, like, the other day Scott Wood mumbled:
Can I ask; what is the intended usage of such a thing? How large
would a typical binary blob be?
I use it for embedding guest device trees in a hypervisor's device tree.
This patch fixes build and few warnings when ATA_VERBOSE_DEBUG
is defined:
CC drivers/ata/sata_fsl.o
drivers/ata/sata_fsl.c: In function ‘sata_fsl_fill_sg’:
drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’,
but argument 3 has type ‘void *’
So, like, the other day Scott Wood mumbled:
Can I ask; what is the intended usage of such a thing? How large
would a typical binary blob be?
I use it for embedding guest device trees in a hypervisor's device tree.
Why wouldn't we instead, say, extend the source sytax
to allow a
At Fri Feb 22 07:07:58 EST 2008, Gerhard Pircher wrote:
I'm wondering how to disable or enable CPU features based on the board
the
kernel is running on. In my case I want to disable the
CPU_FTR_NEED_COHERENT flag for 74xx CPUs, because it locks up the
machine.
I tried to clear the flag in
On Feb 22, 2008, at 03:50, Philippe De Muyter wrote:
Dear list,
I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
specific gcc.
I then got tan infinity of SPE used in kernel messages. Looking
at the
sources I ifdeffed out the printk call in KernelSPE, and I now
Hi,
Original-Nachricht
Datum: Fri, 22 Feb 2008 11:24:38 -0600
Von: Milton Miller [EMAIL PROTECTED]
An: Gerhard Pircher [EMAIL PROTECTED]
CC: ppcdev linuxppc-dev@ozlabs.org
Betreff: Re: How to dynamically disable/enable CPU features?
We handle cpu features in a couple of
Benjamin Herrenschmidt wrote:
On Thu, 2008-02-21 at 17:46 +0300, Valentine Barshak wrote:
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
and because of that it can't find PHY chip. The older ibm_emac driver had
a workaround for that: the
Move the skb-ip_summed == CHECKSUM_PARTIAL part out of
emac_has_feature parameters.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
and because of that it can't find PHY chip. The older ibm_emac driver had
a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL macros which
toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch
This patch adds ibm_newemac phy clock workaround for 440EP/440GR emacs.
The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
allows controlling each EMAC clock spearately as opposed to global clock
selection for 440GX.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
On Fri, 22 Feb 2008 09:32:12 +0100
Stefan Roese [EMAIL PROTECTED] wrote:
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so that both EMACs
don't use loopback mode as default.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
I'm
Signed-off-by: Segher Boessenkool [EMAIL PROTECTED]
---
arch/powerpc/math-emu/op-2.h | 75 -
1 files changed, 29 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/math-emu/op-2.h b/arch/powerpc/math-emu/op-2.h
index 7d6f17c..16d3e3c 100644
---
On Fri, 22 Feb 2008 22:28:17 +0300
Valentine Barshak [EMAIL PROTECTED] wrote:
This patch adds ibm_newemac phy clock workaround for 440EP/440GR emacs.
The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
allows controlling each EMAC clock spearately as opposed to global
On Fri, 22 Feb 2008 22:15:58 +0300
Valentine Barshak [EMAIL PROTECTED] wrote:
Benjamin Herrenschmidt wrote:
On Thu, 2008-02-21 at 17:46 +0300, Valentine Barshak wrote:
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
and because of that it can't find PHY chip. The
On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote:
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so that both EMACs
don't use loopback mode as default.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
I'm not sure if this
On Friday 22 February 2008, Benjamin Herrenschmidt wrote:
On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote:
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so that both EMACs
don't use loopback mode as default.
On Friday 22 February 2008, Josh Boyer wrote:
On Fri, 22 Feb 2008 09:32:12 +0100
Stefan Roese [EMAIL PROTECTED] wrote:
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so that both EMACs
don't use loopback mode as default.
On Fri, 2008-02-22 at 21:01 +0100, Segher Boessenkool wrote:
Signed-off-by: Segher Boessenkool [EMAIL PROTECTED]
---
Amen !
_However_ there are significant code changes in there, and I don't
actually understand that code (well, I admit I haven't tried),
so it could definitely use a bit of a
On Thu, 2008-02-21 at 21:07 +0100, Gerhard Pircher wrote:
Hi,
I'm wondering how to disable or enable CPU features based on the board the
kernel is running on. In my case I want to disable the
CPU_FTR_NEED_COHERENT flag for 74xx CPUs, because it locks up the machine.
I tried to clear the
The flag is in POSSIBLE. I now use this code in the platform probe
function to nop out the code affected by the flag:
cur_cpu_spec-cpu_features = ~CPU_FTR_NEED_COHERENT;
/* Patch out unwanted feature. */
do_feature_fixups(cur_cpu_spec-cpu_features,
_However_ there are significant code changes in there, and I don't
actually understand that code (well, I admit I haven't tried),
Yeah, it's written in 70's style C. Yuck.
so it could definitely use a bit of a commit message explaining
the rationale
Right. I had to fix git-send-email and
On Monday 10 December 2007, Anton Vorontsov wrote:
On Mon, Dec 10, 2007 at 02:55:24PM -0800, David Brownell wrote:
The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
tell whether that programming interface is available ... starting
from #include asm/gpio.h, and including
This patch restores the reset on restart functionality to 40x-based
platforms that was formerly provided--but not used in arch/powerpc--by
abort() in head_40x.S. This functionality is now provided by
ppc40x_reset_system(char *) in a fashion similar to that of the 44x-based
platforms.
Compiled,
David Gibson wrote:
On Tue, Feb 19, 2008 at 08:18:19PM -0500, Jerry Van Baren wrote:
Jon Loeliger wrote:
So, like, the other day David Gibson mumbled:
In light of the recently discovered bug with NOP handling, this adds
some more testcases for NOP handling. Specifically, it adds a helper
On Fri, Feb 22, 2008 at 03:42:03PM -0800, David Brownell wrote:
On Monday 10 December 2007, Anton Vorontsov wrote:
On Mon, Dec 10, 2007 at 02:55:24PM -0800, David Brownell wrote:
The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
tell whether that programming interface
Stefan Roese writes:
Tested on AMCC Canyonlands eval board.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
With 173 lines of code added, you could spend a paragraph in the patch
description telling us why the patch is doing what it's doing the way
it's doing it. Perhaps even tell us why it
Stefan Roese writes:
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
That's a very uninformative commit message. :)
How about putting a brief description of the AMCC 460 family in here?
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Stefan Roese writes:
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Put a brief description of the Canyonlands in the patch description.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Saturday 23 February 2008, Paul Mackerras wrote:
Stefan Roese writes:
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
That's a very uninformative commit message. :)
How about putting a brief description of the AMCC 460 family in here?
You're right. I was a little bit lazy. :)
I'll add
40 matches
Mail list logo
