> -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 Ra
WARNING: vmlinux.o(.text+0x2a9c4): Section mismatch: reference to
.init.text:.__alloc_bootmem (between '.update_dn_pci_info' and
'.pci_dn_reconfig_notifier')
WARNING: vmlinux.o(.text+0x36430): Section mismatch: reference to
.init.text:.__alloc_bootmem (between '.mpic_msi_init_allocator' and
'.f
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(-)
--
Ch
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-se
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
If you build a multiplatform kernel for iSeries and pSeries, with
ibmvscsic support, the resulting client doesn't work on iSeries.
This patch should fix that, using the appropriate low-level operations
for the machine detected at runtime.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
Th
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 just in case.
>
> I think we should dro
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 interfac
>>> +- #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 regis
> + 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
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 prompti
> 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
> except
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 fo
� wrote:
> Hi all,
>
> looking at the PS3 as one of the few PowerPC workstation options the RAM
> is obviously quite limitted with just 256MB.
Can I recommend in the future you send this kind of PS3 specific inquiry to
the cbe-oss-dev mailing list?
[EMAIL PROTECTED]
https://ozlabs.org/mail
[POWERPC]: Fix num_cpus calculation in smp_call_function_map().
In smp_call_function_map(), num_cpus is set to the number of online CPUs minus
one. However, if the CPU mask does not include all CPUs (except the one we're
running on), the routine will hang in the first while() loop until the 8 seco
Arnd Bergmann wrote:
> On Monday 30 July 2007, Dave Jiang wrote:
>> I don't believe that EDAC core has been loaded at the time of 85xx PCI
>> initialization. Plus, the EDAC driver can be loaded as a kernel module. So
>> that
>> probably won't work
>
> ok, good point.
>
>> Also, instead of ha
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
> 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,
> 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 seconda
On Tue, 2007-07-31 at 21:42 +0200, Segher Boessenkool wrote:
> > 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
> > no
> 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 unde
> 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,
Publish the devices listed in dts under SOC as of_device just like what
mpc85xx_mds platforms do. The 85xx cds and ads platforms currently do not
export the devices in dts as of_device.
I need the memory controller, L2 cache-controller, and the PCI controller
published as of_device so the mpc85xx
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 PROTECT
>>> [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 n
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, v
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 mappin
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
13:07:4
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 op
>>> 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
> + spi1pio:[EMAIL PROTECTED] {
There should be whitespace after the label. @01 should be
spelled @1. Except there is no "reg" property. What is this
stuff, anyway?
> + pio-map = <
> + /* port pin dir open_drain assignment
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 a
> 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 wor
>>> + [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-
>>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 w
>>> + 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
On Wed, 2007-08-01 at 00:13 +0200, Segher Boessenkool wrote:
> >>> 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 hav
>>> In that case, I would display the node full path.
>>
>> Those tend to be quite long, in the cases where there are
>> multiple interrupt controllers in the system; and really
>> useless otherwise. I think the interrupt controllers should
>> still just fill in the names "manually".
>
> They tend
> 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 cov
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
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
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
>
On Mon, Jul 30, 2007 at 07:06:48PM +0400, Valentine Barshak wrote:
> AMCC Sequoia board DTS
>
> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/sequoia.dts | 292
> ++
> 1 files changed, 292 insertions(+)
>
> diff -ruN linu
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 tha
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 i
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 -
> arch/powerpc
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
>
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 +-
arch/powerpc/platforms/
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]>
---
Paulu
>> +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 ve
>> +{ /* 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 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, so in
> > this case "ibm,uic-440epx".
>
> This isn't really _requ
On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:
> >> + { /* 440EPX - without Security/Kasumi */
> >> + .pvr_mask = 0xffff,
> >> + .pvr_value = 0x28D4,
> >> + .cpu_name = "440EPX - no Security/Kasumi",
>>> 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 n
Michael Neuling writes:
> + slb_shadow_update(mk_esid_data(VMALLOC_START, 1),
> + mk_vsid_data(VMALLOC_START, vflags), 1);
Could you re-jig slb_shadow_update to take ea, slot and vflags, and
call mk_[ev]sid_data itself, rather than exposing mk_esid_data a
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 t
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?
> >
> > Becaus
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]>
---
> >
63 matches
Mail list logo
