WARNING: vmlinux.o(.text+0x8174): Section mismatch: reference to
.init.text:.prom_init (between '.__boot_from_prom' and '.__after_prom_start')
WARNING: vmlinux.o(.text+0x8498): Section mismatch: reference to
.init.text:.early_setup (between '.start_here_multiplatform' and
'.start_here_common')
-Original Message-
From: [EMAIL PROTECTED] [mailto:netdev-
[EMAIL PROTECTED] On Behalf Of Andrew Gallatin
Sent: Monday, July 30, 2007 10:43 AM
To: Linas Vepstas
Cc: Jan-Bernd Themann; netdev; Thomas Klein; Jeff Garzik; Jan-Bernd
Themann; linux-kernel; linux-ppc; Christoph Raisch;
WARNING: vmlinux.o(.text+0x605d4): Section mismatch: reference to
.init.text:.__alloc_bootmem (between '.prealloc' and '.ps3_power_save')
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/platforms/ps3/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Hi,
Thanks for finding these bugs! I'll post an updated version soon (2 patches
with no separate Kconfig patches, one LRO and one eHEA patch). See comments
below.
Thanks,
Jan-Bernd
On Monday 30 July 2007 22:32, Andrew Gallatin wrote:
I was working on testing the myri10ge patch, and I ran into
Stefan Roese wrote:
On Monday 30 July 2007, Valentine Barshak wrote:
A bootwrapper code for Sequoia.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/boot/44x.h |1
arch/powerpc/boot/Makefile |6
arch/powerpc/boot/cuboot-sequoia.c | 31
On Tuesday 31 July 2007, Valentine Barshak wrote:
Is treeboot-* really needed on Sequoia? From my understanding this is
only needed for platforms using OpenBIOS as bootloader.
Right, it's not used for u-boot. I've included it just in case.
I think we should drop it, when it's not used at
Jan-Bernd Themann wrote:
On Monday 30 July 2007 22:32, Andrew Gallatin wrote:
Second, you still need to set skb-ip_summed = CHECKSUM_UNNECESSARY
when modified packets are flushed, else the stack will see bad
checksums for packets from CHECKSUM_COMPLETE drivers using the
skb interface. Fixed
+- #address-cells : Address representation for
rapidio devices.
+ This field represents the number of cells needed to represent
+ the RapidIO address of the registers.
Can you explain this a little further. I'm a bit confused by
'RapidIO address of the registers'.
I want to
+ l) RapidIO
FSL PowerPC bridge RapidIO or something like that -- you
aren't doing a _generic_ rapidio binding here.
+ RapidIO is a definition of a system interconnect. This node add
+ the support for RapidIO processor in kernel. The node name is
+ suggested to be 'rapidio'.
+
+
The ppc64 version appends ',a' to the kprobes.text section line. Is
this needed here as well? Could someone elaborate on exactly what its
purpose is?
It's the (ELF) section attributes for the section. If this
is executable code, it should be ax; if it's writable, it
should be wa; if it's
Howdy!
I just got asked about ipv6 support in yaboot and a quick investigation
showed _no_ knowledge of the address formats in the code.
Should I be submitting an RFC for a full parser that can pick that
apart? Or does has someone have code lurking in the shadows, that
just needed some
Which makes me think (again) that we should have an optional
device_node
pointer in irq_host. I know you said you wanted the irq stuff to be OF
agnostic, but the reality is most of the implementations do have an OF
node. And all of the newer irq_host implementations do, with the
exception
On Tue, 2007-07-31 at 14:21 -0500, Doug Maxey wrote:
Howdy!
I just got asked about ipv6 support in yaboot and a quick investigation
showed _no_ knowledge of the address formats in the code.
We really just use OF for obp-tftp and don't have our own ip stack, as
there is no 1275 standard for
On Tue, 31 Jul 2007 21:11:01 BST, Paul Nasrat wrote:
On Tue, 2007-07-31 at 14:21 -0500, Doug Maxey wrote:
Howdy!
I just got asked about ipv6 support in yaboot and a quick investigation
showed _no_ knowledge of the address formats in the code.
We really just use OF for obp-tftp and don't
I'd like to make an official DTC Version 1.0.0 release soon!
To that end, I've published a repo on jdl.com with a v1.0.0-rc1
tag on it. I anticipate some updates to the Documentation before
a final 1.0.0 release still. However, if you have something
you would like to have be in The Real
Ok, figured out why. When I push, then pop a quilt patch some of the
files end up with their original contents, but changed timestamps.
That altered stat information causes git-diff-index to give false
indications of changed files, so setlocalversion adds the -dirty.
Running git status, or
As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse
controller
on the PegasosPPC. This is because of a feature/bug in the OF device
tree:
the device_type attribute is an empty string instead of 8042 as the
kernel expects. This patch (against 2.6.22.1) adds a secondary
Unless the DTS guys thinks otherwise, just rename to cpu_qe.
qe would then be reserved for true QE mode.
If I understand it correctly, this is a property of how the
driver works, not how the hardware works / is connected; so
there should be _no_ such property in the device tree.
If I
Naming devices for human consumption is a more general problem than
device-id addresses; I'd like to see a standard label property added
to
the device tree spec that software could use to present a
human-friendly
label that corresponds to markings on the case, position on the board,
etc.
Creating a platform device for the PCI error registers in order for the
mpc85xx EDAC driver to pick up proper resources. This is to prevent the EDAC
driver from monopolizing the of_device and thus preventing future PCI code from
using the PCI of_device(s).
Signed-off-by: Dave Jiang [EMAIL
[EMAIL PROTECTED] {
device_type = spi;
+ device-id = 1;
Can we just use the reg value for bus_num in the kernel.
Sure, technically nothing prevents this. But, QE specs names
SPIs by these ids.
As a minimum the property name should start
Freescale MPC85xx SoC support for EDAC. Used on PPC platforms. Development
and testing done on PPC Freescale MPC8548CDS.
The driver provides error reporting for L2 cache error registers, the
memory controller error registers, and the PCI error registers. The error
reporting can be done two ways,
On Tuesday 31 July 2007, Dave Jiang wrote:
Actually it seems that for me to grab the interrupt number I have to do the
platform device creation in fsl_soc.c and call arch_init() instead of doing it
from fsl_add_bridge(). fsl_add_bridge() is called way too early and the mpic
interrupt mapping
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
drivers/macintosh/therm_adt746x.c | 17298 - 17244 (-54 bytes)
drivers/macintosh/therm_adt746x.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- linux-2.6.23-rc1-mm1-a/drivers/macintosh/therm_adt746x.c2007-07-26
On Wednesday 01 August 2007, Dave Jiang wrote:
Doh! I sent out the reworked patches right before your comments. Do you happen
to know where I can find an example of how to do this? In regards to making a
platform_device a child of the PCI host bridge that is Thanks!
When you use an
Which makes me think (again) that we should have an optional
device_node
pointer in irq_host. I know you said you wanted the irq stuff to be
OF
agnostic, but the reality is most of the implementations do have an
OF
node. And all of the newer irq_host implementations do, with the
Arnd Bergmann wrote:
On Tuesday 31 July 2007, Dave Jiang wrote:
Actually it seems that for me to grab the interrupt number I have to do the
platform device creation in fsl_soc.c and call arch_init() instead of doing
it
from fsl_add_bridge(). fsl_add_bridge() is called way too early and the
This doesn't mean that shift is better anyway. If everyone
considers it
better, I give up. But be warned that shift (stride) is not the only
property
characterizing register accesses -- the regs might be only accessible
as
16/32-bit quantities, for example (16-bit is a real world
+ [EMAIL PROTECTED] {
+ compatible = mmio-ide;
+ device_type = ide;
Why not ata?
The hardware is called (E)IDE, the protocol is called ATA.
Or that's what I was told -- I think there's some historic
revisionism involved, too.
Also, what mmio-ide in the compat
I never suggested that -- what I did suggest was make of_serial.c
recognize certain chip types and register them with 8250 driver.
What would be the advantage of maintaining a list of chips whose only
difference is register spacing, rather than just using reg-shift and
being done with it?
+ strncpy(info-driver_name, i2c_devices[i].i2c_driver,
KOBJ_NAME_LEN);
+ strncpy(info-type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
Why not just strcpy(), btw?
Because target strings are finite length, and sources are just
pointers to
some constant strings, which one
The hardware is called (E)IDE, the protocol is called ATA.
Or that's what I was told -- I think there's some historic
revisionism involved, too.
ATA is the interface and standards for the ANSI standards based disk
attachment. IDE Integrated Drive Electronics is a marketing name used
to cover
Arnd Bergmann wrote:
On Wednesday 01 August 2007, Dave Jiang wrote:
Doh! I sent out the reworked patches right before your comments. Do you
happen
to know where I can find an example of how to do this? In regards to making a
platform_device a child of the PCI host bridge that is Thanks!
On Tue, Jul 31, 2007 at 11:11:57PM +0200, Segher Boessenkool wrote:
Ok, figured out why. When I push, then pop a quilt patch some of the
files end up with their original contents, but changed timestamps.
That altered stat information causes git-diff-index to give false
indications of
Some new machines use the ibm,dynamic-reconfiguration-memory property
to provide memory layout information, rather than via memory nodes.
There is a bug in the code to parse this property for start addresses over
4GB, we throw away the high bits and add apparently duplicate regions. This
results
Doug Maxey writes:
I just got asked about ipv6 support in yaboot and a quick investigation
showed _no_ knowledge of the address formats in the code.
Should I be submitting an RFC for a full parser that can pick that
apart? Or does has someone have code lurking in the shadows, that
just
On Mon, Jul 30, 2007 at 07:12:45PM +0400, Valentine Barshak wrote:
This patch adds DCR defines needed for 440EP/440EPx clock initialization.
These defines have been introduced in the Bamboo support by Josh Boyer
and are needed for Sequoia as well.
These should really go in the same patch that
On Tue, Jul 31, 2007 at 01:42:46PM +0200, Stefan Roese wrote:
On Tuesday 31 July 2007, Valentine Barshak wrote:
Is treeboot-* really needed on Sequoia? From my understanding this is
only needed for platforms using OpenBIOS as bootloader.
Right, it's not used for u-boot. I've included it
On Mon, Jul 30, 2007 at 07:16:28PM +0400, Valentine Barshak wrote:
AMCC 440EPx Sequoia board support.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/kernel/cputable.c | 36 +++
arch/powerpc/kernel/head_44x.S |2 -
On Wed, 01 Aug 2007 11:03:12 +1000, Paul Mackerras wrote:
Doug Maxey writes:
I just got asked about ipv6 support in yaboot and a quick investigation
showed _no_ knowledge of the address formats in the code.
Should I be submitting an RFC for a full parser that can pick that
apart?
Hi,
This patch fixes some interrrupt - interrupt typos and the comments in
it_lp_naca.h
Signed-off-by: Gabriel Craciunescu [EMAIL PROTECTED]
---
arch/powerpc/platforms/embedded6xx/holly.c|2 +-
arch/powerpc/platforms/embedded6xx/linkstation.c |2 +-
On Wed, 01 Aug 2007 05:16:27 +0200 Gabriel C [EMAIL PROTECTED] wrote:
arch/powerpc/platforms/iseries/it_lp_naca.h | 87
+++--
NAK this part as it just makes a lot of the lines more than 80 characters
for no real gain on a platform that is moving on ...
--
Cheers,
We sometimes change the vmalloc segment in slb_flush_and_rebolt but we
never updated with slb shadow buffer. This fixes it. Thanks to paulus
for finding this.
Also added some write barriers to ensure the shadow buffer is always
valid.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
+UIC0: interrupt-controller0 {
+compatible = ibm,uic-440gp,ibm,uic;
The first compatible entry should always be the precise model, so in
this case ibm,uic-440epx.
This isn't really _required_, but it is a very good idea in
almost all cases (the exception is for very generic
+{ /* 440EPX - without Security/Kasumi */
+.pvr_mask = 0xffff,
+.pvr_value = 0x28D4,
+.cpu_name = 440EPX - no Security/Kasumi,
+.cpu_features = CPU_FTRS_44X,
+
On Wed, Aug 01, 2007 at 03:04:22PM +1000, David Gibson wrote:
On Wed, Aug 01, 2007 at 06:57:33AM +0200, Segher Boessenkool wrote:
+UIC0: interrupt-controller0 {
+compatible = ibm,uic-440gp,ibm,uic;
The first compatible entry should always be the precise model,
On Wed, 1 Aug 2007, Segher Boessenkool wrote:
+ strncpy(info-driver_name, i2c_devices[i].i2c_driver,
KOBJ_NAME_LEN);
+ strncpy(info-type, i2c_devices[i].i2c_type,
I2C_NAME_SIZE);
Why not just strcpy(), btw?
Because target strings are finite
47 matches
Mail list logo
