* Re: Problem with OF interrupt parsing code
From: Segher Boessenkool @ 2007-10-01 23:36 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191279244.6310.32.camel@pasglop>
>> This is an interrupt controller (it has an "interrupt-controller"
>> property, and it has no interrupt parent (there is no
>> "interrupt-parent"
>> property, for interrupt controllers you do not follow the "normal"
>> tree
>> parent), so it is the root interrupt controller and there is no loop.
>>
>> It seems from your description that the Linux code is using the tree
>> parent as interrupt parent even for interrupt controller nodes. This
>> is wrong behaviour.
>
> It shoudn't normally happen. The reason it -does- happen in fact is
> that
> the above node is also missing the #interrupt-cells property, which
> cause the parent-lookup routine to skip it before it gets a chance to
> see that there's an "interrupt-controller" property in there.
>
> I'm not sure whether linux behaviour is a bug or not since I believe we
> are clearly in undefined-land as an interrupt controller should always
> have a #interrupt-cells property.
That isn't required for legacy (pieces of) trees that don't go
through an interrupt-map, actually (but strongly recommended of
course) -- and I'm not sure how valid a tree that uses the imap
recommended practice for only part of the tree is really ;-)
Either way, the Linux code should use the explicit information (the
lack of "interrupt-parent" in a node with "interrupt-controller")
to determine whether a node is the root interrupt controller, instead
of some implicit information. You can then more clearly do sanity
checking on "#interrupt-cells" etc.
Segher
^ permalink raw reply
* Re: [PATCH 2/7] [POWERPC] Fix QEIC->MPIC cascading
From: Benjamin Herrenschmidt @ 2007-10-01 23:14 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070925143429.GB5323@localhost.localdomain>
On Tue, 2007-09-25 at 18:34 +0400, Anton Vorontsov wrote:
> set_irq_chained_handler overwrites MPIC's handle_irq function
> (handle_fasteoi_irq) thus MPIC never gets eoi event from the
> cascaded IRQ. This situation hangs MPIC on MPC8568E.
>
> Patch adds flow level "end" handler to the MPIC, and QEIC calls
> it when QEIC's interrupt processing finished.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Not sure if I already NAKed it on the list, so if I didn't here's it :-)
The proper way of doing that is to have the cascade handler perform the
EOI call to mpic. Look at how it's done for i8259 mpic cascade handlers.
Basically, when doing a cascade nowadays, you can either just do a
normal request_irq() of the cascade, in which case your handler don't
have to care about the parent controller at all, but you get various
limitations and/or overhead from being a full blown interrupt handler,
or you can use the chained handler mechanism which is a "shortcut" but
implies that your cascade handler "knows" what needs to be done to the
parent (and thus is specific to the combination parent/child).
Cheers,
Ben.
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Benjamin Herrenschmidt @ 2007-10-01 22:55 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1191279244.6310.32.camel@pasglop>
On Tue, 2007-10-02 at 08:54 +1000, Benjamin Herrenschmidt wrote:
> It shoudn't normally happen. The reason it -does- happen in fact is
> that
> the above node is also missing the #interrupt-cells property, which
> cause the parent-lookup routine to skip it before it gets a chance to
> see that there's an "interrupt-controller" property in there.
>
> I'm not sure whether linux behaviour is a bug or not since I believe
> we
> are clearly in undefined-land as an interrupt controller should always
> have a #interrupt-cells property.
That's btw something we could add as a warning to dtc...
A node with "interrupt-controller" or "interrupt-map" in it should
always have a #interrupt-cells property.
Ben.
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Benjamin Herrenschmidt @ 2007-10-01 22:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <d3eb2341d21ed1f9f7e71f097878731f@kernel.crashing.org>
On Tue, 2007-10-02 at 00:33 +0200, Segher Boessenkool wrote:
> > i8259: interrupt-controller@20 {
> > device_type = "interrupt-controller";
> > compatible = "pnpPNP,000";
> > interrupt-controller;
> > reg = <00000001 00000020 00000002
> > 00000001 000000a0 00000002
> > 00000001 000004d0 00000002>;
> > reserved-interrupts = <2>;
> > };
>
> This is an interrupt controller (it has an "interrupt-controller"
> property, and it has no interrupt parent (there is no "interrupt-parent"
> property, for interrupt controllers you do not follow the "normal" tree
> parent), so it is the root interrupt controller and there is no loop.
>
> It seems from your description that the Linux code is using the tree
> parent as interrupt parent even for interrupt controller nodes. This
> is wrong behaviour.
It shoudn't normally happen. The reason it -does- happen in fact is that
the above node is also missing the #interrupt-cells property, which
cause the parent-lookup routine to skip it before it gets a chance to
see that there's an "interrupt-controller" property in there.
I'm not sure whether linux behaviour is a bug or not since I believe we
are clearly in undefined-land as an interrupt controller should always
have a #interrupt-cells property.
Ben.
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-10-01 22:41 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20071001201247.GN12049@parisc-linux.org>
On Mon, Oct 01, 2007 at 02:12:47PM -0600, Matthew Wilcox wrote:
>
> I think the fundamental problem is that completions aren't really
> supposed to be used like this. Here's one attempt at using completions
> perhaps a little more the way they're supposed to be used,
Yes, that looks very good to me. I see it solves a bug that
I hadn't been quite aware of. I don't understand why
struct host_data is preferable to struct sym_shcb (is it because
this is the structure that is "naturally protectected" by the
spinlock?)
My gut instinct is to say "ack", although prudence dictates that
I should test first. Which might take a few days...
> although now
> I've written it, I wonder if we shouldn't just use a waitqueue instead.
I thought that earlier versions of the driver used waitqueues (I vaguely
remember "eh_wait" in the code), which were later converted to
completions (I also vaguely recall thinking that the new code was
more elegant/simpler). I converted my patch to use the completions
likewise, and, as you've clearly shown, did a rather sloppy job in
the conversion.
I'm tempted to go with this patch; but if you prod, I could attempt
a wait-queue based patch.
--linas
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Segher Boessenkool @ 2007-10-01 22:33 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071001211120.156280@gmx.net>
> i8259: interrupt-controller@20 {
> device_type = "interrupt-controller";
> compatible = "pnpPNP,000";
> interrupt-controller;
> reg = <00000001 00000020 00000002
> 00000001 000000a0 00000002
> 00000001 000004d0 00000002>;
> reserved-interrupts = <2>;
> };
This is an interrupt controller (it has an "interrupt-controller"
property, and it has no interrupt parent (there is no "interrupt-parent"
property, for interrupt controllers you do not follow the "normal" tree
parent), so it is the root interrupt controller and there is no loop.
It seems from your description that the Linux code is using the tree
parent as interrupt parent even for interrupt controller nodes. This
is wrong behaviour.
Segher
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Benjamin Herrenschmidt @ 2007-10-01 22:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47016B11.3070609@freescale.com>
On Mon, 2007-10-01 at 16:48 -0500, Scott Wood wrote:
> Benjamin Herrenschmidt wrote:
> > On Mon, 2007-10-01 at 16:37 -0500, Scott Wood wrote:
> >> Scott Wood wrote:
> >> Actually, it doesn't -- it should stop when it sees the
> >> interrupt-controller property in the i8259 node, at which point it'll be
> >> trying to use the raw PCI IRQ pin number as an i8259 IRQ. This is
> >> Unlikely To Work(tm).
> >
> > It will work in the specific 8259 case I suppose since it gets the
> > legacy 1:1 mapping... but it sucks :-)
>
> The mapping between INTA-D and i8259 numbers isn't generally 1:1, and it
> looked as if it'd try using the former... though the code is
> sufficiently complicated that I could easily be missing something.
If the whole of_* thing totally fails, pci_read_irq_line should pickup
the value in the config space PCI_INTERRUPT_LINE. That will work on
things like Pegasos and possibly on this AmigaOne but it sucks.
Ben.
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Scott Wood @ 2007-10-01 21:48 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191274981.6310.19.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Mon, 2007-10-01 at 16:37 -0500, Scott Wood wrote:
>> Scott Wood wrote:
>> Actually, it doesn't -- it should stop when it sees the
>> interrupt-controller property in the i8259 node, at which point it'll be
>> trying to use the raw PCI IRQ pin number as an i8259 IRQ. This is
>> Unlikely To Work(tm).
>
> It will work in the specific 8259 case I suppose since it gets the
> legacy 1:1 mapping... but it sucks :-)
The mapping between INTA-D and i8259 numbers isn't generally 1:1, and it
looked as if it'd try using the former... though the code is
sufficiently complicated that I could easily be missing something.
-Scott
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Benjamin Herrenschmidt @ 2007-10-01 21:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <470168B4.7090005@freescale.com>
On Mon, 2007-10-01 at 16:37 -0500, Scott Wood wrote:
> Scott Wood wrote:
> >> The problem occurs now, if there is no device node defined for another
> >> PCI device. In this case, of_irq_map_pci() checks for an interrupt pin,
> >> searches again for the host bridge node and calls of_irq_map_raw() with
> >> the device node of the host bridge. The function finds the
> >> #interrupt-cells, #address-cells, interrupt-controller properties, but
> >> fails to find the interrupt-map property (because it's missing in the
> >> device tree). Therefore the function then tries to find a new parent,
> >> which leads to an endless loop (it always selects the PCI2ISA southbridge
> >> in the device tree).
> >
> > That seems likely... there should probably be some loop detection.
>
> Actually, it doesn't -- it should stop when it sees the
> interrupt-controller property in the i8259 node, at which point it'll be
> trying to use the raw PCI IRQ pin number as an i8259 IRQ. This is
> Unlikely To Work(tm).
It will work in the specific 8259 case I suppose since it gets the
legacy 1:1 mapping... but it sucks :-)
Ben.
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Benjamin Herrenschmidt @ 2007-10-01 21:39 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071001211120.156280@gmx.net>
On Mon, 2007-10-01 at 23:11 +0200, Gerhard Pircher wrote:
> pci@80000000 {
> device_type = "pci";
> compatible = "mai-logic,articia-s";
> bus-frequency = <01fca055>; // 33.3MHz
> bus-range = <0 ff>;
> ranges = <01000000 0 00000000 fe000000 0
> 00c00000 // PCI I/O
> 02000000 0 80000000 80000000 0
> 7d000000 // PCI memory
> 02000000 0 fd000000 fd000000 0
> 01000000>; // PCI alias memory
> 8259-interrupt-acknowledge = <fef00000>;
> interrupt-parent = <&i8259>;
> #interrupt-cells = <1>;
> #address-cells = <3>;
> #size-cells = <2>;
>
Part of your problem is that interrupt-parent property. You shouldn't
have such a property in a PCI host bridge. It's not technically illegal,
but it's triggering the "loop" you've been experiencing.
If you want the parsing to fail for PCI devices (to get the fallback to
config space values), you need to make sure it does fail.
Another option is to put an empty interrupt-map in there. That will
guarantee failure.
But that's all very ugly. I don't understand why you don't setup a
proper map either from your bootloader, zImage wrapper or even prom_init
or platform code.
Ben.
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Scott Wood @ 2007-10-01 21:37 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <470165F6.7030505@freescale.com>
Scott Wood wrote:
>> The problem occurs now, if there is no device node defined for another
>> PCI device. In this case, of_irq_map_pci() checks for an interrupt pin,
>> searches again for the host bridge node and calls of_irq_map_raw() with
>> the device node of the host bridge. The function finds the
>> #interrupt-cells, #address-cells, interrupt-controller properties, but
>> fails to find the interrupt-map property (because it's missing in the
>> device tree). Therefore the function then tries to find a new parent,
>> which leads to an endless loop (it always selects the PCI2ISA southbridge
>> in the device tree).
>
> That seems likely... there should probably be some loop detection.
Actually, it doesn't -- it should stop when it sees the
interrupt-controller property in the i8259 node, at which point it'll be
trying to use the raw PCI IRQ pin number as an i8259 IRQ. This is
Unlikely To Work(tm).
-Scott
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Benjamin Herrenschmidt @ 2007-10-01 21:36 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071001210025.314240@gmx.net>
On Mon, 2007-10-01 at 23:00 +0200, Gerhard Pircher wrote:
> Hi,
>
> I think I found an issue in the OF interrupt parsing code, although I
> have to admit that my device tree source doesn't really follow the
> specification.
>
> First some information about my target setup. I didn't specify an
> interrupt-map and interrupt-map-mask property in the pci node, because
> AFAIK there are three different AmigaOne models with different IRQ
> routing. Secondly the AmigaOne is a desktop system with 4 PCI/AGP slots,
> thus I can't specify device nodes for all possible devices. By looking at
> pci_read_irq_line() in pci_common.c it should be possible for the kernel
> to fall back to the interrupt settings in the PCI config space of every
> device.
That's deprecated and only support for legacy stuff that predates the
current device-tree support & old/crappy firmware.
You should be able to generate the appropriate interrupt-map from your
loader or wrapper to provide the routing for your slots. It should be
easy enough to have 3 static arrays in your wrapper and use the right
one to "set" the property value.
> Unfortunately I couldn't capture the kernel log, because the serial
> console is not yet working, so here comes a description of what I think
> is going on.
> Well, pci_read_irq_line() starts with PCI device 00:00.0 (PCI host bridge)
> and invokes of_irq_map_pci() in prom_parse.c. It find the predefined
> device node in the device tree. Since of_irq_map_one() can't find an
> interrupt property in the device node, it returns to pci_read_irq_line()
> and setups the interrupt mapping based on the settings in the PCI config
> space. So far so good.
> The problem occurs now, if there is no device node defined for another
> PCI device. In this case, of_irq_map_pci() checks for an interrupt pin,
> searches again for the host bridge node and calls of_irq_map_raw() with
> the device node of the host bridge. The function finds the
> #interrupt-cells, #address-cells, interrupt-controller properties, but
> fails to find the interrupt-map property (because it's missing in the
> device tree). Therefore the function then tries to find a new parent,
> which leads to an endless loop (it always selects the PCI2ISA southbridge
> in the device tree).
>
> Can somebody confirm my explanation? It would help, if the kernel could
> fall back to the PCI settings in this case, too.
I'm not sure what you are trying to explain above... It looks like your
tree layout is somewhat broken though I think I see how...
One option would be to make the PCI specific IRQ parsing stop & fail if
the host bridge doesn't provide a map instead of following up an
interrupt-parent link (which is I think what you have in there).
But I don't like that. Just fixup your maps properly and everything
should work just fine.
Ben.
^ permalink raw reply
* nap/dfs on 7448
From: Leisner, Martin @ 2007-10-01 21:32 UTC (permalink / raw)
To: linuxppc-dev
I asked this on linuxppc-embedded a week ago (I didn't even know this
list existed until last week -- another reason to get rid of
linuxpcc-embedded).
Has anyone gotten NAP/DFS to reliably work on a 7448?
I'm seeing strange problems with peripherals...(using a ram disk
works fine).
marty
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Scott Wood @ 2007-10-01 21:26 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071001210025.314240@gmx.net>
Gerhard Pircher wrote:
> First some information about my target setup. I didn't specify an
> interrupt-map and interrupt-map-mask property in the pci node, because
> AFAIK there are three different AmigaOne models with different IRQ
> routing.
So detect which one you're running on in the bootwrapper, and fix up (or
select) the device tree appropriately.
> Secondly the AmigaOne is a desktop system with 4 PCI/AGP slots,
> thus I can't specify device nodes for all possible devices. By looking at
> pci_read_irq_line() in pci_common.c it should be possible for the kernel
> to fall back to the interrupt settings in the PCI config space of every
> device.
Those interrupt settings are purely a communication vector from firmware
to OS. Is your firmware putting i8259 interrupt numbers in there, and
did you set the default interrupt controller?
> The problem occurs now, if there is no device node defined for another
> PCI device. In this case, of_irq_map_pci() checks for an interrupt pin,
> searches again for the host bridge node and calls of_irq_map_raw() with
> the device node of the host bridge. The function finds the
> #interrupt-cells, #address-cells, interrupt-controller properties, but
> fails to find the interrupt-map property (because it's missing in the
> device tree). Therefore the function then tries to find a new parent,
> which leads to an endless loop (it always selects the PCI2ISA southbridge
> in the device tree).
That seems likely... there should probably be some loop detection.
-Scott
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Gerhard Pircher @ 2007-10-01 21:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071001210025.314240@gmx.net>
And here comes the device tree source:
/*
* AmigaOne Device Tree Source
*
* Copyright 2007 Gerhard Pircher (gerhard_pircher@gmx.net)
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/ {
model = "AmigaOne";
compatible = "eyetech,amigaone","mai-logic,teron";
coherency-off;
#address-cells = <1>;
#size-cells = <1>;
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <0>; // 33.3 MHz, from U-boot
clock-frequency = <0>; // From U-boot
bus-frequency = <0>; // From U-boot
32-bit;
};
};
memory {
device_type = "memory";
reg = <0 0>; // From U-boot
};
pci@80000000 {
device_type = "pci";
compatible = "mai-logic,articia-s";
bus-frequency = <01fca055>; // 33.3MHz
bus-range = <0 ff>;
ranges = <01000000 0 00000000 fe000000 0 00c00000 // PCI I/O
02000000 0 80000000 80000000 0 7d000000 // PCI memory
02000000 0 fd000000 fd000000 0 01000000>; // PCI alias memory
8259-interrupt-acknowledge = <fef00000>;
interrupt-parent = <&i8259>;
#interrupt-cells = <1>;
#address-cells = <3>;
#size-cells = <2>;
host@0 {
compatible = "pciclass,0600";
vendor-id = <000010cc>;
device-id = <00000660>;
revision-id = <00000001>;
class-code = <00060000>;
subsystem-id = <0>;
subsystem-vendor-id = <0>;
devsel-speed = <00000001>;
66mhz-capable;
min-grant = <0>;
max-latency = <0>;
// AGP aperture is unset.
reg = <42000010 0 00000000 0 00400000>;
assigned-addresses = <42000010 0 00000000 0 00400000>;
};
isa@7 {
device_type = "isa";
compatible = "pciclass,0601";
vendor-id = <00001106>;
device-id = <00000686>;
revision-id = <00000010>;
class-code = <00060100>;
subsystem-id = <0>;
subsystem-vendor-id = <0>;
devsel-speed = <00000001>;
min-grant = <0>;
max-latency = <0>;
/* First 64k for I/O at 0x0 on PCI mapped to 0x0 on ISA. */
ranges = <00000001 0 01000000 0 00000000 00010000>;
interrupt-parent = <&i8259>;
#interrupt-cells = <2>;
#address-cells = <2>;
#size-cells = <1>;
dma-controller@0 {
device_type = "dma-controller";
compatible = "pnpPNP,200";
reg = <00000001 00000000 00000020
00000001 00000080 00000010
00000001 000000c0 00000020>;
/* Channel 4 reserverd, cascade mode, 2x32k transfer/counter
* widths and bus master capability. Is this really necessary?
*/
/* dma = <4 4 20 20 1>; */
};
i8259: interrupt-controller@20 {
device_type = "interrupt-controller";
compatible = "pnpPNP,000";
interrupt-controller;
reg = <00000001 00000020 00000002
00000001 000000a0 00000002
00000001 000004d0 00000002>;
reserved-interrupts = <2>;
};
timer@40 {
/* device_type = "timer"; */ // No device type binding for now.
compatibe = "pnpPNP,100"; // Also add pcspkr to platform devices.
reg = <00000001 00000040 00000020>;
};
8042@60 {
device_type = "8042";
reg = <00000001 00000060 00000001
00000001 00000064 00000001>;
interrupts = <1 3 c 3>; // IRQ1, IRQ12 (rising edge)
#address-cells = <1>;
#size-cells = <0>;
keyboard@0 {
device_type = "keyboard";
compatible = "pnpPNP,303";
reg = <0>;
};
mouse@1 {
device_type = "mouse";
compatible = "pnpPNP,f03";
reg = <1>;
};
};
rtc@70 {
device_type = "rtc";
compatible = "pnpPNP,b00";
reg = <00000001 00000070 00000002>;
interrupts = <8 3>;
};
serial@2f8 {
device_type = "serial";
compatible = "pnpPNP,501","pnpPNP,500"; // "ns16550"; add property check to OF serial code.
reg = <00000001 000002f8 00000008>;
interrupts = <3 3>; // IRQ3 (rising edge)
clock-frequency = <001C2000>; // Not necessary?
};
serial@3f8 {
device_type = "serial";
compatible = "pnpPNP,501","pnpPNP,500"; // "ns16550"; add property check to OF serial code.
reg = <00000001 000003f8 00000008>;
interrupts = <4 3>; // IRQ4 (rising edge)
clock-frequency = <001C2000>; // Not necessary?
};
parallel@378 {
device_type = "parallel";
compatible = "pnpPNP,400"; // "pnpPNP,401" // No ECP support for now.
reg = <00000001 00000378 00000003
00000001 00000778 00000003>;
/* interrupts = <7>; */
/* dma = <3 0 0 0>; */ // Parallel port DMA mode?
};
fdc@3f0 {
device_type = "fdc";
compatible = "pnpPNP,700";
reg = <00000001 000003f0 00000008>;
interrupts = <6 3>; // IRQ6 (rising edge)
/* dma = < >; */ // Floppy DMA mode?
#address-cells = <1>;
#size-cells = <0>;
disk@0 {
device_type = "block";
reg = <0>;
};
};
};
ide@7,1 {
compatible = "pciclass,01018f";
vendor-id = <00001106>;
device-id = <00000571>;
revision-id = <00000006>;
// Class code with PCI IDE programming interface indicator.
class-code = <0001018f>;
subsystem-id = <0>;
subsystem-vendor-id = <0>;
devsel-speed = <00000001>;
min-grant = <0>;
max-latency = <0>;
fast-back-to-back;
// Assume base addresses are relocateable, even if
// controller operates in compatibility mode.
reg = <21003910 0 00000000 0 00000000
21003914 0 00000000 0 00000000
21003918 0 00000000 0 00000000
2100391c 0 00000000 0 00000000
21003920 0 00000000 0 00000000>;
assigned-addresses = <01003910 0 000001f0 0 00000008
01003914 0 000003f4 0 00000004
01003918 0 00000170 0 00000008
0100391c 0 00000374 0 00000004
01003920 0 0000cc00 0 00000010>;
interrupt-parent = <&i8259>;
interrupts = <e 3 f 3>;
#interrupt-cells = <2>;
};
};
chosen {
linux,stdout-path = "/pci@80000000/isa@7/serial@2f8";
};
};
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: Powerbook shuts down hard when hot, patch found
From: Michael Buesch @ 2007-10-01 20:58 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev
In-Reply-To: <1191225602.28457.22.camel@thor.sulgenrain.local>
On Monday 01 October 2007 10:00:02 Michel D=C3=A4nzer wrote:
>=20
> On Sun, 2007-09-30 at 12:16 +0200, Michael Buesch wrote:
> >=20
> > Ah, forgot to say.
> > It does not crash immediately when the register is written. It takes ab=
out two seconds
> > to crash. And when the machine is colder to begin with, it takes slight=
ly
> > longer to trigger. That _might_ support your overheating theory.
> >=20
> > Though, it does not trigger when it's up and running, no matter how hot=
you drive it.
>=20
> Maybe the thermal control module prevents it from overheating. Have you
> tried unloading it or loading it ASAP on bootup to see if that makes any
> difference either way?
I'm not sure how that works. Can I unload the framebuffer module? I mean,
when I unloaded it, how does the console access the display?
Your suggestion might be less trivial to do than it sounds like. :)
I currently have compiled the stuff into the kernel image.
=2D-=20
Greetings Michael.
^ permalink raw reply
* Problem with OF interrupt parsing code
From: Gerhard Pircher @ 2007-10-01 21:00 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I think I found an issue in the OF interrupt parsing code, although I
have to admit that my device tree source doesn't really follow the
specification.
First some information about my target setup. I didn't specify an
interrupt-map and interrupt-map-mask property in the pci node, because
AFAIK there are three different AmigaOne models with different IRQ
routing. Secondly the AmigaOne is a desktop system with 4 PCI/AGP slots,
thus I can't specify device nodes for all possible devices. By looking at
pci_read_irq_line() in pci_common.c it should be possible for the kernel
to fall back to the interrupt settings in the PCI config space of every
device.
Unfortunately I couldn't capture the kernel log, because the serial
console is not yet working, so here comes a description of what I think
is going on.
Well, pci_read_irq_line() starts with PCI device 00:00.0 (PCI host bridge)
and invokes of_irq_map_pci() in prom_parse.c. It find the predefined
device node in the device tree. Since of_irq_map_one() can't find an
interrupt property in the device node, it returns to pci_read_irq_line()
and setups the interrupt mapping based on the settings in the PCI config
space. So far so good.
The problem occurs now, if there is no device node defined for another
PCI device. In this case, of_irq_map_pci() checks for an interrupt pin,
searches again for the host bridge node and calls of_irq_map_raw() with
the device node of the host bridge. The function finds the
#interrupt-cells, #address-cells, interrupt-controller properties, but
fails to find the interrupt-map property (because it's missing in the
device tree). Therefore the function then tries to find a new parent,
which leads to an endless loop (it always selects the PCI2ISA southbridge
in the device tree).
Can somebody confirm my explanation? It would help, if the kernel could
fall back to the PCI settings in this case, too.
Thanks!
regards,
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: [RFC] Get rid of linuxppc-embedded?
From: Grant Likely @ 2007-10-01 20:59 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071001192459.GB5785@mag.az.mvista.com>
On 10/1/07, Mark A. Greer <mgreer@mvista.com> wrote:
> With the merging of the powerpc trees I'm not sure there is a clear
> reason why we have 2 separate powerpc lists anymore (linuxppc-dev and
> linuxppc-embedded).
>
> linuxppc-embedded is fairly low volume/noise but there is still the occasional
> patch posted there that should really be posted to linuxppc-dev. I think
> it would be nice to have just one list where all eyes are focused.
>
> Is it time to get rid of linuxppc-embedded?
Ack Ack Ack!
I agree 100%
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] powerpc: Implement logging of unhandled signals
From: Olof Johansson @ 2007-10-01 20:32 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Implement exception-trace sysctl + support to print when a process is
killed due to unhandled signals just as i386 and x86_64 does.
Just like on x86, it can be disabled by setting the sysctl variable
debug.exception-trace, and the messages are rate limited to not create
a DoS exposure.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6.23/arch/powerpc/kernel/traps.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/traps.c
+++ 2.6.23/arch/powerpc/kernel/traps.c
@@ -172,11 +172,21 @@ int die(const char *str, struct pt_regs
void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr)
{
siginfo_t info;
+ char fmt32[] = KERN_INFO "%s[%d]: unhandled signal %d " \
+ "at %08lx nip %08lx lr %08lx code %x\n";
+ char fmt64[] = KERN_INFO "%s[%d]: unhandled signal %d " \
+ "at %016lx nip %016lx lr %016lx code %x\n";
if (!user_mode(regs)) {
if (die("Exception in kernel mode", regs, signr))
return;
- }
+ } else if (show_unhandled_signals &&
+ unhandled_signal(current, signr) &&
+ printk_ratelimit()) {
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, signr,
+ addr, regs->nip, regs->link, code);
+ }
memset(&info, 0, sizeof(info));
info.si_signo = signr;
Index: 2.6.23/arch/powerpc/kernel/signal_64.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/signal_64.c
+++ 2.6.23/arch/powerpc/kernel/signal_64.c
@@ -64,6 +64,11 @@ struct rt_sigframe {
char abigap[288];
} __attribute__ ((aligned (16)));
+static char fmt32[] = KERN_INFO \
+ "%s[%d]: bad frame in %s: %08lx nip %08lx lr %08lx\n";
+static char fmt64[] = KERN_INFO \
+ "%s[%d]: bad frame in %s: %016lx nip %016lx lr %016lx\n";
+
/*
* Set up the sigcontext for the signal frame.
*/
@@ -315,6 +320,11 @@ badframe:
printk("badframe in sys_rt_sigreturn, regs=%p uc=%p &uc->uc_mcontext=%p\n",
regs, uc, &uc->uc_mcontext);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, "rt_sigreturn",
+ uc, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
@@ -398,6 +408,11 @@ badframe:
printk("badframe in setup_rt_frame, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, "setup_rt_frame",
+ frame, regs->nip, regs->link);
+
force_sigsegv(signr, current);
return 0;
}
Index: 2.6.23/kernel/sysctl.c
===================================================================
--- 2.6.23.orig/kernel/sysctl.c
+++ 2.6.23/kernel/sysctl.c
@@ -1221,7 +1221,7 @@ static ctl_table fs_table[] = {
};
static ctl_table debug_table[] = {
-#ifdef CONFIG_X86
+#if defined(CONFIG_X86) || defined(CONFIG_PPC)
{
.ctl_name = CTL_UNNUMBERED,
.procname = "exception-trace",
Index: 2.6.23/arch/powerpc/kernel/signal_32.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/signal_32.c
+++ 2.6.23/arch/powerpc/kernel/signal_32.c
@@ -705,11 +705,13 @@ int handle_rt_signal32(unsigned long sig
{
struct rt_sigframe __user *rt_sf;
struct mcontext __user *frame;
+ void __user *addr;
unsigned long newsp = 0;
/* Set up Signal Frame */
/* Put a Real Time Context onto stack */
rt_sf = get_sigframe(ka, regs, sizeof(*rt_sf));
+ addr = rt_sf;
if (unlikely(rt_sf == NULL))
goto badframe;
@@ -728,6 +730,7 @@ int handle_rt_signal32(unsigned long sig
/* Save user registers on the stack */
frame = &rt_sf->uc.uc_mcontext;
+ addr = frame;
if (vdso32_rt_sigtramp && current->mm->context.vdso_base) {
if (save_user_regs(regs, frame, 0))
goto badframe;
@@ -742,6 +745,7 @@ int handle_rt_signal32(unsigned long sig
/* create a stack frame for the caller of the handler */
newsp = ((unsigned long)rt_sf) - (__SIGNAL_FRAMESIZE + 16);
+ addr = (void __user *)regs->gpr[1];
if (put_user(regs->gpr[1], (u32 __user *)newsp))
goto badframe;
@@ -762,6 +766,12 @@ badframe:
printk("badframe in handle_rt_signal, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in handle_rt_signal32: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ addr, regs->nip, regs->link);
+
force_sigsegv(sig, current);
return 0;
}
@@ -886,6 +896,12 @@ long sys_rt_sigreturn(int r3, int r4, in
return 0;
bad:
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in sys_rt_sigreturn: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ rt_sf, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
@@ -967,6 +983,13 @@ int sys_debug_setcontext(struct ucontext
* We kill the task with a SIGSEGV in this situation.
*/
if (do_setcontext(ctx, regs, 1)) {
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in "
+ "sys_debug_setcontext: %p nip %08lx "
+ "lr %08lx\n",
+ current->comm, current->pid,
+ ctx, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
goto out;
}
@@ -1048,6 +1071,12 @@ badframe:
printk("badframe in handle_signal, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in handle_signal32: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ frame, regs->nip, regs->link);
+
force_sigsegv(sig, current);
return 0;
}
@@ -1061,12 +1090,14 @@ long sys_sigreturn(int r3, int r4, int r
struct sigcontext __user *sc;
struct sigcontext sigctx;
struct mcontext __user *sr;
+ void __user *addr;
sigset_t set;
/* Always make any pending restarted system calls return -EINTR */
current_thread_info()->restart_block.fn = do_no_restart_syscall;
sc = (struct sigcontext __user *)(regs->gpr[1] + __SIGNAL_FRAMESIZE);
+ addr = sc;
if (copy_from_user(&sigctx, sc, sizeof(sigctx)))
goto badframe;
@@ -1083,6 +1114,7 @@ long sys_sigreturn(int r3, int r4, int r
restore_sigmask(&set);
sr = (struct mcontext __user *)from_user_ptr(sigctx.regs);
+ addr = sr;
if (!access_ok(VERIFY_READ, sr, sizeof(*sr))
|| restore_user_regs(regs, sr, 1))
goto badframe;
@@ -1091,6 +1123,12 @@ long sys_sigreturn(int r3, int r4, int r
return 0;
badframe:
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in sys_sigreturn: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ addr, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
Index: 2.6.23/arch/powerpc/kernel/signal.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/signal.c
+++ 2.6.23/arch/powerpc/kernel/signal.c
@@ -16,6 +16,12 @@
#include "signal.h"
+/* Log an error when sending an unhandled signal to a process. Controlled
+ * through debug.exception-trace sysctl.
+ */
+
+int show_unhandled_signals = 1;
+
/*
* Allocate space for the signal frame
*/
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Matthew Wilcox @ 2007-10-01 20:12 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070927233437.GF18686@austin.ibm.com>
On Thu, Sep 27, 2007 at 06:34:37PM -0500, Linas Vepstas wrote:
> Good catch. But no ... and I had to study this a bit. Bear with me:
I agree with the analysis which I've now snipped.
> I think the race you describe above is harmless. The first time
> that sym_eh_handler() will run, it will be with SYM_EH_ABORT,
> in it doesn't matter if we lose that, since the device is hosed
> anyway. At some later time, it will run with SYM_EH_DEVICE_RESET
> and then SYM_EH_BUS_RESET and then SYM_EH_HOST_RESET, and we won't
> miss those, since, by now, sym2_io_error_detected() will have run.
>
> So, by my reading, I'd say that init_completion() in
> sym2_io_error_detected() has to stay (although perhaps
> it should be replaced by the INIT_COMPLETION() macro.)
> Removing it will prevent correct operation on the second
> and subsequent errors.
I think the fundamental problem is that completions aren't really
supposed to be used like this. Here's one attempt at using completions
perhaps a little more the way they're supposed to be used, although now
I've written it, I wonder if we shouldn't just use a waitqueue instead.
diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c
index e8a4361..b425b89 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.c
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.c
@@ -602,6 +602,7 @@ static int sym_eh_handler(int op, char *opname, struct scsi_cmnd *cmd)
struct sym_hcb *np = SYM_SOFTC_PTR(cmd);
struct sym_ucmd *ucmd = SYM_UCMD_PTR(cmd);
struct Scsi_Host *host = cmd->device->host;
+ struct pci_dev *pdev = np->s.device;
SYM_QUEHEAD *qp;
int cmd_queued = 0;
int sts = -1;
@@ -616,9 +617,19 @@ static int sym_eh_handler(int op, char *opname, struct scsi_cmnd *cmd)
* point in hurrying; take a leisurely wait.
*/
#define WAIT_FOR_PCI_RECOVERY 35
- if (pci_channel_offline(np->s.device)) {
- int finished_reset = wait_for_completion_timeout(
- &np->s.io_reset_wait, WAIT_FOR_PCI_RECOVERY*HZ);
+ if (pci_channel_offline(pdev)) {
+ struct host_data *hostdata = shost_priv(host);
+ int finished_reset = 0;
+ init_completion(&eh_done);
+ spin_lock_irq(host->host_lock);
+ if (!hostdata->io_reset)
+ hostdata->io_reset = &eh_done;
+ if (!pci_channel_offline(pdev))
+ finished_reset = 1;
+ spin_unlock_irq(host->host_lock);
+ if (!finished_reset)
+ finished_reset = wait_for_completion_timeout(
+ hostdata->io_reset, WAIT_FOR_PCI_RECOVERY*HZ);
if (!finished_reset)
return SCSI_FAILED;
}
@@ -1396,7 +1407,6 @@ static struct Scsi_Host * __devinit sym_attach(struct scsi_host_template *tpnt,
np->maxoffs = dev->chip.offset_max;
np->maxburst = dev->chip.burst_max;
np->myaddr = dev->host_id;
- init_completion(&np->s.io_reset_wait);
/*
* Edit its name.
@@ -1842,15 +1852,12 @@ static void __devexit sym2_remove(struct pci_dev *pdev)
static pci_ers_result_t sym2_io_error_detected(struct pci_dev *pdev,
enum pci_channel_state state)
{
- struct sym_hcb *np = pci_get_drvdata(pdev);
-
/* If slot is permanently frozen, turn everything off */
if (state == pci_channel_io_perm_failure) {
sym2_remove(pdev);
return PCI_ERS_RESULT_DISCONNECT;
}
- init_completion(&np->s.io_reset_wait);
disable_irq(pdev->irq);
pci_disable_device(pdev);
@@ -1912,7 +1919,7 @@ static pci_ers_result_t sym2_io_slot_reset(struct pci_dev *pdev)
sym_name(np));
if (pci_enable_device(pdev)) {
- printk(KERN_ERR "%s: Unable to enable afer PCI reset\n",
+ printk(KERN_ERR "%s: Unable to enable after PCI reset\n",
sym_name(np));
return PCI_ERS_RESULT_DISCONNECT;
}
@@ -1953,7 +1960,14 @@ static pci_ers_result_t sym2_io_slot_reset(struct pci_dev *pdev)
static void sym2_io_resume(struct pci_dev *pdev)
{
struct sym_hcb *np = pci_get_drvdata(pdev);
- complete_all(&np->s.io_reset_wait);
+ struct Scsi_Host *shost = np->s.host;
+ struct host_data *hostdata = shost_priv(shost);
+
+ spin_lock_irq(shost->host_lock);
+ if (hostdata->io_reset)
+ complete_all(hostdata->io_reset);
+ hostdata->io_reset = NULL;
+ spin_unlock_irq(shost->host_lock);
}
static void sym2_get_signalling(struct Scsi_Host *shost)
diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.h b/drivers/scsi/sym53c8xx_2/sym_glue.h
index a172cc5..b961f70 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.h
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.h
@@ -180,9 +180,6 @@ struct sym_shcb {
char chip_name[8];
struct pci_dev *device;
- /* Waiter for clearing of frozen PCI bus */
- struct completion io_reset_wait;
-
struct Scsi_Host *host;
void __iomem * ioaddr; /* MMIO kernel io address */
@@ -223,6 +220,7 @@ struct sym_device {
*/
struct host_data {
struct sym_hcb *ncb;
+ struct completion *io_reset; /* PCI error handling */
};
static inline struct sym_hcb * sym_get_hcb(struct Scsi_Host *host)
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply related
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Mark A. Greer @ 2007-10-01 20:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20071001145911.77194814@weaponx.rchland.ibm.com>
On Mon, Oct 01, 2007 at 02:59:11PM -0500, Josh Boyer wrote:
> On Mon, 01 Oct 2007 15:49:22 -0400
> Ben Warren <bwarren@qstreams.com> wrote:
> > Perhaps my perspective is unique, but I doubt it. I find it nice that
> > this list is low volume and not filled with endless patches about CHRP
> > and P series and open firmware syntax blah blah blah...
> >
> > No offense intended to all the people who are doing wonderful work
> > expanding the Linux universe, but for your average dude or dudette
> > working on embedded boards that happen to have a PowerPC processor, this
> > list is a pretty good forum.
>
> I think the original thought was to have patches go to linuxppc-dev.
> Not necessarily all discussion.
That's where I started but I moved to completely getting of
linuxppc-embedded. As Ben points out, I may have gone too far.
Mark
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Ben Warren @ 2007-10-01 20:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20071001145911.77194814@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 01 Oct 2007 15:49:22 -0400
> Ben Warren <bwarren@qstreams.com> wrote:
>
>
>> Mark A. Greer wrote:
>>
>>> On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote:
>>>
>>>
>>>> On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote:
>>>>
>>>>
>>>>> On Thu, 27 Sep 2007 12:53:51 -0700
>>>>> "Mark A. Greer" <mgreer@mvista.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
>>>>>>
>>>>>>
>>>>>>> Thanks for the advice, but I was just basing the list to post to on the
>>>>>>> MAINTAINERS file which states that this is the one for Embedded PPC83XX.
>>>>>>> If you still think that I should post to linuxppc-dev, let me know.
>>>>>>>
>>>>>>>
>>>>>> Yes, I think it would be better to repost to linuxppc-dev.
>>>>>>
>>>>>> Does anyone have an objection to changing all of the:
>>>>>>
>>>>>> "L: linuxppc-embedded@ozlabs.org"
>>>>>>
>>>>>> in MAINTAINERS to:
>>>>>>
>>>>>> "L: linuxppc-dev@ozlabs.org" ??
>>>>>>
>>>>>> Kumar, Josh, Vitaly, et. al.?
>>>>>>
>>>>>>
>>>>> I personally don't care either way. I'm already subscribed to both
>>>>> lists.
>>>>>
>>>>> Makes sense to go to linuxppc-dev given the arch/powerpc migration.
>>>>>
>>>>>
>>>> I thought the -embedded list was created in the first place to keep some
>>>> of the "noise" off of -dev (i.e. "I can't get interface <foo> to work on
>>>> my custom <embedded eval board>-lookalike board, HELP!"). If people still
>>>> care about keeping that on a separate list, then we shouldn't change it.
>>>>
>>>>
>>> Yes, IIRC, that was the reason but now with the merge and low volume on this
>>> list, it makes sense to me to just get rid of -embedded.
>>>
>>>
>>>
>> Perhaps my perspective is unique, but I doubt it. I find it nice that
>> this list is low volume and not filled with endless patches about CHRP
>> and P series and open firmware syntax blah blah blah...
>>
>> No offense intended to all the people who are doing wonderful work
>> expanding the Linux universe, but for your average dude or dudette
>> working on embedded boards that happen to have a PowerPC processor, this
>> list is a pretty good forum.
>>
>
> I think the original thought was to have patches go to linuxppc-dev.
> Not necessarily all discussion.
>
> josh
>
>
True, and that makes sense. Patches should go where the right people
will see them quickly. At least two people have advocated getting rid of
the linuxppc-embedded list, though. Maybe I misunderstood.
regards,
Ben
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Josh Boyer @ 2007-10-01 19:59 UTC (permalink / raw)
To: Ben Warren; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <47014F42.1010106@qstreams.com>
On Mon, 01 Oct 2007 15:49:22 -0400
Ben Warren <bwarren@qstreams.com> wrote:
> Mark A. Greer wrote:
> > On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote:
> >
> >> On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote:
> >>
> >>> On Thu, 27 Sep 2007 12:53:51 -0700
> >>> "Mark A. Greer" <mgreer@mvista.com> wrote:
> >>>
> >>>
> >>>> On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
> >>>>
> >>>>> Thanks for the advice, but I was just basing the list to post to on the
> >>>>> MAINTAINERS file which states that this is the one for Embedded PPC83XX.
> >>>>> If you still think that I should post to linuxppc-dev, let me know.
> >>>>>
> >>>> Yes, I think it would be better to repost to linuxppc-dev.
> >>>>
> >>>> Does anyone have an objection to changing all of the:
> >>>>
> >>>> "L: linuxppc-embedded@ozlabs.org"
> >>>>
> >>>> in MAINTAINERS to:
> >>>>
> >>>> "L: linuxppc-dev@ozlabs.org" ??
> >>>>
> >>>> Kumar, Josh, Vitaly, et. al.?
> >>>>
> >>> I personally don't care either way. I'm already subscribed to both
> >>> lists.
> >>>
> >>> Makes sense to go to linuxppc-dev given the arch/powerpc migration.
> >>>
> >> I thought the -embedded list was created in the first place to keep some
> >> of the "noise" off of -dev (i.e. "I can't get interface <foo> to work on
> >> my custom <embedded eval board>-lookalike board, HELP!"). If people still
> >> care about keeping that on a separate list, then we shouldn't change it.
> >>
> >
> > Yes, IIRC, that was the reason but now with the merge and low volume on this
> > list, it makes sense to me to just get rid of -embedded.
> >
> >
> Perhaps my perspective is unique, but I doubt it. I find it nice that
> this list is low volume and not filled with endless patches about CHRP
> and P series and open firmware syntax blah blah blah...
>
> No offense intended to all the people who are doing wonderful work
> expanding the Linux universe, but for your average dude or dudette
> working on embedded boards that happen to have a PowerPC processor, this
> list is a pretty good forum.
I think the original thought was to have patches go to linuxppc-dev.
Not necessarily all discussion.
josh
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Ben Warren @ 2007-10-01 19:49 UTC (permalink / raw)
To: Mark A. Greer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20071001191937.GA5785@mag.az.mvista.com>
Mark A. Greer wrote:
> On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote:
>
>> On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote:
>>
>>> On Thu, 27 Sep 2007 12:53:51 -0700
>>> "Mark A. Greer" <mgreer@mvista.com> wrote:
>>>
>>>
>>>> On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
>>>>
>>>>> Thanks for the advice, but I was just basing the list to post to on the
>>>>> MAINTAINERS file which states that this is the one for Embedded PPC83XX.
>>>>> If you still think that I should post to linuxppc-dev, let me know.
>>>>>
>>>> Yes, I think it would be better to repost to linuxppc-dev.
>>>>
>>>> Does anyone have an objection to changing all of the:
>>>>
>>>> "L: linuxppc-embedded@ozlabs.org"
>>>>
>>>> in MAINTAINERS to:
>>>>
>>>> "L: linuxppc-dev@ozlabs.org" ??
>>>>
>>>> Kumar, Josh, Vitaly, et. al.?
>>>>
>>> I personally don't care either way. I'm already subscribed to both
>>> lists.
>>>
>>> Makes sense to go to linuxppc-dev given the arch/powerpc migration.
>>>
>> I thought the -embedded list was created in the first place to keep some
>> of the "noise" off of -dev (i.e. "I can't get interface <foo> to work on
>> my custom <embedded eval board>-lookalike board, HELP!"). If people still
>> care about keeping that on a separate list, then we shouldn't change it.
>>
>
> Yes, IIRC, that was the reason but now with the merge and low volume on this
> list, it makes sense to me to just get rid of -embedded.
>
>
Perhaps my perspective is unique, but I doubt it. I find it nice that
this list is low volume and not filled with endless patches about CHRP
and P series and open firmware syntax blah blah blah...
No offense intended to all the people who are doing wonderful work
expanding the Linux universe, but for your average dude or dudette
working on embedded boards that happen to have a PowerPC processor, this
list is a pretty good forum.
regards,
Ben
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Mark A. Greer @ 2007-10-01 19:19 UTC (permalink / raw)
To: Olof Johansson; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20070927212830.GA9610@lixom.net>
On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote:
> On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote:
> > On Thu, 27 Sep 2007 12:53:51 -0700
> > "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > > On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
> > > > Thanks for the advice, but I was just basing the list to post to on the
> > > > MAINTAINERS file which states that this is the one for Embedded PPC83XX.
> > > > If you still think that I should post to linuxppc-dev, let me know.
> > >
> > > Yes, I think it would be better to repost to linuxppc-dev.
> > >
> > > Does anyone have an objection to changing all of the:
> > >
> > > "L: linuxppc-embedded@ozlabs.org"
> > >
> > > in MAINTAINERS to:
> > >
> > > "L: linuxppc-dev@ozlabs.org" ??
> > >
> > > Kumar, Josh, Vitaly, et. al.?
> >
> > I personally don't care either way. I'm already subscribed to both
> > lists.
> >
> > Makes sense to go to linuxppc-dev given the arch/powerpc migration.
>
> I thought the -embedded list was created in the first place to keep some
> of the "noise" off of -dev (i.e. "I can't get interface <foo> to work on
> my custom <embedded eval board>-lookalike board, HELP!"). If people still
> care about keeping that on a separate list, then we shouldn't change it.
Yes, IIRC, that was the reason but now with the merge and low volume on this
list, it makes sense to me to just get rid of -embedded.
> I think the relevant people probably monitor this list (maybe not quite as
> frequently) to catch things. I even caught the first PWRficient-related
> question in a timely manner the other day. :-)
:)
> Still, that being said, patches will clearly get better exposure on -dev,
> especially device tree crap.
Definitely. I'll propose this on -dev and see what people say.
Mark
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox