* Re: [PATCH] FCC: fix confused base / offset
From: Scott Wood @ 2008-04-09 17:39 UTC (permalink / raw)
To: Sascha Hauer; +Cc: linuxppc-dev
In-Reply-To: <20080409165324.GF10465@pengutronix.de>
Sascha Hauer wrote:
> Right, so it's probably not worth the effort. I stumbled on this while
> porting my board to the new binding code. I was quite confused when
> seeing this so I made this fix to understand what's going on here.
>
> BTW have you tested the FCC driver with the new binding code?
Yes.
> I do not
> manage to get it working. Everything seems to be fine but
> fs_enet_start_xmit does not send a packet and no interrupts are
> arriving.
What does your device tree look like? Are all the pins and clocks set
up properly? Does the PHY negotiate OK? Is any error reported in the
descriptor?
>> Does this break arch/ppc, BTW?
>
> Yes. arch=ppc is out of my scope, so I forget about it regularly, sorry.
> It breaks arch/ppc/platforms/mpc8272ads_setup.c which can be easily
> fixed though. But as the mpc8272ads is supported with arch=powerpc,
> shouldn't it go away anyway?
arch/ppc is going away entirely in June or so. !CONFIG_PPC_NEW_BINDING
in arch/powerpc is going away as soon as I can unlazy myself enough to
send a patch. :-)
-Scott
^ permalink raw reply
* Re: ppc440 caches - change proposal [RFC]
From: John Bonesio @ 2008-04-09 18:00 UTC (permalink / raw)
To: Grant Likely; +Cc: Linuxppc-dev
In-Reply-To: <fa686aa40804081615n284aa750n12ceb0bf1d1bcce1@mail.gmail.com>
Hi Grant,
I have a question about your patch. It appears as if the cache setup code is in a file that would be used only on Xilinx FPGA devices.
I understand that many people are using a bootloader that already sets up the cache for the kernel, but I'm wondering if Xilinx boards are really a special case, or if there may be other non-Xilinx related systems that would also not be using a bootloader.
I also understand the desire to avoid code that does the same work more than once, but I wonder if in this case, it's creating too strong a dependence on the specific behavior of a certain bootloader.
I also wonder if arch/powerpc is being made more complex by trying to split out this code change into a Xilinx specific area, when the change could just be rolled into head_40x.S and we could do away with virtex405-head.S.
Just some thoughts,
- John
On Tuesday 08 April 2008 16:15, you wrote:
> On Tue, Apr 8, 2008 at 4:56 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
> > > I was thinking it might be good to have the kernel initialize these
> > > cache control registers in it's own start up code. Or perhaps this
> > > could be done in the kernel's simple bootloader. We could probably put
> > > this change in a Xilinx specific startup file, but this change doesn't
> > > seem specific to Xilinx FPGA boards.
> >
> > The kernel's wrapper would be a good place to put that I suspect. That's
> > the kind of thing that should be provided as a "library" function to be
> > optionally called by platform code. Either in the wrapper or the main
> > kernel platform code.
>
> Code is already queued up for 2.6.26 to do exactly this on ppc405
> virtex platforms. We can do the same thing for 440. Look at
> virtex405-head.S in the following patch:
>
> http://patchwork.ozlabs.org/linuxppc/patch?person=486&id=17410
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
>
^ permalink raw reply
* Signal backtrace function
From: Joakim Tjernlund @ 2008-04-09 18:16 UTC (permalink / raw)
To: 'linuxppc-dev Development'
Hi
I made my own backtrace function for printing
a trace from within a signal handler. Maybe it
can be useful for the kernel too? General
comments welcome.
Jocke
#include <stdio.h>
#include <signal.h>
#include <execinfo.h>
#include <unistd.h>
#define __USE_GNU
#include <ucontext.h>
/* This is the stack layout we see with every stack frame.
Note that every routine is required by the ABI to lay out the stack
like this.
+----------------+ +-----------------+
%r1 -> | %r1 last frame--------> | %r1 last frame--->... --> NULL
| | | |
| (unused) | | return address |
+----------------+ +-----------------+
*/
/* Prints a backtrace when invoked from a signal handler */
int
sigbacktrace (void **array, int size, void *sp,
void *lr, void *exec_addr)
{
int count=1, loop;
void *ret_addr;
struct layout {
struct layout * next;
void * return_address;
} *current;
if (!size)
return size;
current = sp;
array[0] = exec_addr;
for (loop = 0;
current != NULL && count < size;
current = current->next, loop++) {
ret_addr = current->return_address;
#if DEBUG
printf("next:%p, ret:%p, LR:%p\n", current->next, ret_addr, lr);
#endif
if (lr == ret_addr) /* false frame ? */
continue;
if (!loop)
if (lr != ret_addr) /* Leaf function ? */
ret_addr = lr;
else
continue;
array[count++] = ret_addr;
}
/* It's possible the second-last stack frame can't return in which
case the CRT startup code will have set its LR to 'NULL'. */
if (count > 0 && array[count-1] == NULL)
count--;
return count;
}
#define EXEC_ADDR (*regs)[32]
#define STK_PTR (*regs)[1]
#define LINK (*regs)[36]
void bt_sighandler(int sig, siginfo_t *info,
void *secret)
{
void *trace[16];
char **messages = (char **)NULL;
int i, trace_size = 0;
ucontext_t *uc = (ucontext_t *)secret;
gregset_t *regs = &uc->uc_mcontext.uc_regs->gregs;
/* Do something useful with siginfo_t */
if (sig == SIGSEGV || sig == SIGBUS)
printf("Got signal %d, faulty address is %p, "
"from %p\n", sig, info->si_addr,
EXEC_ADDR);
else
printf("Got signal %d\n", sig);
trace_size = sigbacktrace(trace, 16, (void*) STK_PTR,
(void*) LINK, (void*) EXEC_ADDR);
messages = backtrace_symbols(trace, trace_size);
printf("[bt] Execution path:\n");
for (i=0; i<trace_size; ++i)
printf("[bt] %s\n", messages[i]);
if (sig != SIGUSR1)
exit(0);
}
void dummy(void)
{
unsigned long *current;
asm volatile ("" : "=l"(current));
}
int func_a(int a, char b) {
char *p = (char *)0xdeadbeef;
//dummy(); /* Test with and without this call */
a = a + b;
*p = 10; /* CRASH here!! */
dummy(); /* Test with and without this call */
return 2*a;
}
int func_b() {
int res, a = 5;
res = 5 + func_a(a, 't');
return res;
}
int main() {
/* Install our signal handler */
struct sigaction sa;
sa.sa_sigaction = (void *)bt_sighandler;
sigemptyset (&sa.sa_mask);
sa.sa_flags = SA_RESTART | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
sigaction(SIGUSR1, &sa, NULL);
/* ... add any other signal here */
/* Do something */
printf("%d\n", func_b());
}
^ permalink raw reply
* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Olof Johansson @ 2008-04-09 18:30 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47FCFEEF.6020607@austin.ibm.com>
On Wed, Apr 09, 2008 at 12:37:51PM -0500, Manish Ahuja wrote:
> Olof Johansson wrote:
> >> +static inline unsigned long phyp_dump_calculate_reserve_size(void)
> >> +{
> >> + unsigned long tmp;
> >> +
> >> + if (phyp_dump_info->phyp_dump_reserve_bootvar)
> >> + return phyp_dump_info->phyp_dump_reserve_bootvar;
> >> +
> >> + /* divide by 20 to get 5% of value */
> >> + tmp = lmb_end_of_DRAM();
> >> + do_div(tmp, 20);
> >> +
> >> + /* round it down in multiples of 256 */
> >> + tmp = tmp & ~0x000000001FFFFFFF;
> >
> > That's 512MB, isn't it?
>
> My calculations in the example I gave in the last email were wrong.
>
> In mentally did 10% instead of 5%. But the premise is same.
>
> So assuming 5% of some memory is 400 MB, it rounds it down to 256MB etc.
But 0x1fffffff is 512MB, not 256MB. So you're rounding it down to a
multiple of 512MB.
-Olof
^ permalink raw reply
* Re: [PATCH] ide: make ide_pci_check_iomem() actually work
From: Bartlomiej Zolnierkiewicz @ 2008-04-09 18:34 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <47FB6747.2050301@ru.mvista.com>
[ added Akira & Kou to cc: ]
On Tuesday 08 April 2008, Sergei Shtylyov wrote:
> Hi, I just wrote:
>
> >>> This function didn't actually check if a given BAR is in I/O space
> >>> because of
> >>> using the bogus PCI_BASE_ADDRESS_IO_MASK (which equals ~3) to test
> >>> the resource
> >>> flags instead of IORESOURCE_IO -- fix this, make ide_hwif_configure()
> >>> check the
> >>> results failing if necessary, and move the printk() call to the
> >>> failure path.
>
> >> This change is OK in itself but I worry that ide_pci_check_iomem() may
> >> now
> >> return "false" errors (bogus PCI_BASE_ADDRESS_IO_MASK check resulted
> >> in MEM
> >> resources always surviving ide_pci_check_iomem() calls before the fix)
> >> for
> >> some host drivers (siimage, scc_pata...) resulting in failed
> >> initialization.
>
> > The SiI chips do have normal I/O resources at BAR0..BAR3. As for
> > scc_pata, the control should not even get there because BAR0..BAR3 are
> > *not* IDE command/control block bases on this chip (BAR0/1 are
> > control/DMA bases if you look into setup_mmio_scc()) but they are
> > treated as such by the code immediately following ide_pci_check_iomem()
> > calls in ide_hwif_configure(), i.e. we might have an error here. The
> > same can be said about the PowerMAC driver which has all its MMIO
> > registers at BAR0.
>
> >> How's about removing this dead/broken function instead for now?
>
> > If we indeed have a MMIO problem here, it's not in this function but
> > in its callers.
>
> Looks like we actually have this problem with scc_pata -- it calls
> ide_setup_pci_device() which should lead to calling ide_hwif_configure(). But
> this is broken since this call chain expects a normal PCI IDE controller with
> BAR0..BAR3 either non-existant or being primary/secondary port bases in I/O space.
Yep, scc_pata needs fixing before your patch can be applied.
Looks like it just needs to do all the needed setup itself in init_setup_scc()
instead of calling ide_setup_pci_device() [ similarly to how cs5520 host driver
handles this in cs5520.c::cs5520_init_one() ].
PS it would be also nice to call pci_enable_device() before setup_mmio_scc()
(which accesses PCI BARs, calls pci_set_master() etc.) while we are at it
(driver seems to work fine without it ATM but it may break in future).
Thanks,
Bart
^ permalink raw reply
* Re: [PATCH] siimage: fix kernel oops on PPC 44x
From: Bartlomiej Zolnierkiewicz @ 2008-04-09 18:14 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <47FB6EA5.4070606@ru.mvista.com>
On Tuesday 08 April 2008, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> >>Fix kernel oops due to machine check occuring in init_chipset_siimage() on PPC
> >>44x platforms. These 32-bit CPUs have 36-bit physical address and PCI I/O and
> >>memory spaces are mapped beyond 4 GB; arch/ppc/ code has a fixup in ioremap()
> >>that creates an illusion of the PCI I/O and memory resources being mapped below
> >>4 GB, while arch/powerpc/ code got rid of this fixup with PPC 44x having instead
> >>CONFIG_RESOURCES_64BIT=y -- this causes the resources to be truncated to 32-bit
> >>'unsigned long' type in this driver, and so non-existant memory being ioremap'ed
> >>and then accessed...
>
> >>Thanks to Valentine Barshak for providing an initial patch and explanations.
>
> >>Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>
> > applied and pushed to Linus, thanks!
>
> > I guess that it would be worth to audit the rest of IDE code for
>
> Already done. Some drivers, like sgiioc4, scc_pata, and pmac are prone to
> that at least in theory. Although I doubt that they ever get used in such
> environments as PPC 44x platform kernels, i.e. 32-bit kernel and PCI mapped
> beyond 4 GB.
>
> > pci_resource_{start,end}() vs 'unsigned long' occurences and fix them.
>
> There are quite a lot of those overall but they only pose danger if the
> resource in question is in memory space since the I/O space always uses
> 'unsigned long' addresses. So, IDE core and drivers using only I/O resources
> should not be prone to that kind of issue.
Thanks for taking a look (good to hear that we are fine for now).
> > [ Even if they work at the moment they are just bugs waiting to happened
> > when we add support for some new platforms or rewrite the code... ]
I still think that it is worth to switch to always using resource_size_t
with pci_resource{start,end}() - increase of the code size should be minimal
and negligable (also it would happen only for CONFIG_RESOURCES_64BIT=y)
but in the return we will keep the code consistent and hint people who're
writing new code (and are looking at the existing code as a base).
[ this is kernel-wide comment, w.r.t. to IDE - I'll try updating it when
I have some time (unless of course somebody sends me a patch earlier :) ]
Thanks,
Bart
^ permalink raw reply
* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Manish Ahuja @ 2008-04-09 18:43 UTC (permalink / raw)
To: Olof Johansson; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <20080409183032.GA2360@lixom.net>
Hmmm,
You are possibly right.
Okay I can check and fix that.
-Manish
Olof Johansson wrote:
>>> That's 512MB, isn't it?
>> My calculations in the example I gave in the last email were wrong.
>>
>> In mentally did 10% instead of 5%. But the premise is same.
>>
>> So assuming 5% of some memory is 400 MB, it rounds it down to 256MB etc.
>
> But 0x1fffffff is 512MB, not 256MB. So you're rounding it down to a
> multiple of 512MB.
>
>
> -Olof
^ permalink raw reply
* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Olof Johansson @ 2008-04-09 18:59 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47FD0E67.1090802@austin.ibm.com>
On Wed, Apr 09, 2008 at 01:43:51PM -0500, Manish Ahuja wrote:
> Hmmm,
>
> You are possibly right.
>
> Okay I can check and fix that.
Well, fix the comments if you prefer, I just pointed out the
discreptancy.
-Olof
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Scott Wood @ 2008-04-09 18:57 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linuxppc-dev
In-Reply-To: <47FCBC73.40703@matrix-vision.de>
Andre Schwarz wrote:
> -> find_legacy_serial_port()
> stdout is /soc8343@e0000000/serial@4500
It looks like you have some memory corruption between here...
> clocksource: timebase mult[3c00001] shift[22] registered
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> -> check_legacy_serial_console()
> can't find stdout package /soc8343@e0000000/serial@4500 !
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
...and here.
-Scott
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Andre Schwarz @ 2008-04-09 19:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47FD118F.8050407@freescale.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8; format=flowed, Size: 1355 bytes --]
Scott Wood schrieb:
> Andre Schwarz wrote:
>> -> find_legacy_serial_port()
>> stdout is /soc8343@e0000000/serial@4500
>
> It looks like you have some memory corruption between here...
>
>> clocksource: timebase mult[3c00001] shift[22] registered
>>
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> -> check_legacy_serial_console()
>> can't find stdout package /soc8343@e0000000/serial@4500 !
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> ...and here.
>
> -Scott
Scott,
are you talking about a possible hardware problem or misbehaving code ?
Does it look like something gets overwritten during initrd
extraction/movement ?
The system has 512MB RAM which means that we need 2 BAT regs to map the
memory. I've found comments in Freescale u-boot header files that
currently a max of 256MB is supported. I never understood why ? Could
this problem be related to this ?
Do I need to supply reserved memory regions ? I thought u-boot is doing
so for initrd and the kernel don't need it ...
I'll rebuild u-boot with 256MB memory size and do an extra run with
memory test - just to make sure.
Any hints where to look else ?
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Scott Wood @ 2008-04-09 19:15 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linuxppc-dev
In-Reply-To: <47FD1485.6070209@matrix-vision.de>
Andre Schwarz wrote:
> Scott Wood schrieb:
>> Andre Schwarz wrote:
>>> -> find_legacy_serial_port()
>>> stdout is /soc8343@e0000000/serial@4500
>>
>> It looks like you have some memory corruption between here...
>>
>>> clocksource: timebase mult[3c00001] shift[22] registered
>>>
>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>> -> check_legacy_serial_console()
>>> can't find stdout package /soc8343@e0000000/serial@4500 !
>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>
>> ...and here.
>>
>> -Scott
>
> Scott,
>
> are you talking about a possible hardware problem or misbehaving code ?
Either. The same OF call is done in both places with the same argument,
but is getting different results.
> Does it look like something gets overwritten during initrd
> extraction/movement ?
Don't know.
> The system has 512MB RAM which means that we need 2 BAT regs to map the
> memory. I've found comments in Freescale u-boot header files that
> currently a max of 256MB is supported. I never understood why ? Could
> this problem be related to this ?
Kim's probably be the best one to answer u-boot questions.
-Scott
^ permalink raw reply
* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Segher Boessenkool @ 2008-04-09 19:39 UTC (permalink / raw)
To: Manish Ahuja; +Cc: Olof Johansson, mahuja, linasvepstas, paulus, linuxppc-dev
In-Reply-To: <47FCFDA4.10709@austin.ibm.com>
>>> + tmp = tmp & ~0x000000001FFFFFFF;
Note that this only works as you expect because the constant is
signed here -- the extra zeroes do not magically make it a 64-bit
number. So it goes 32-bit 0x1fffffff -> 32-bit -0x20000000 ->
64-bit -0x20000000.
Please consider writing it with an "L" suffix, or "UL" even, to
reduce trickiness and surprises if ever that number is changed.
Segher
^ permalink raw reply
* Re: ppc440 caches - change proposal [RFC]
From: Grant Likely @ 2008-04-09 19:50 UTC (permalink / raw)
To: John Bonesio; +Cc: Linuxppc-dev
In-Reply-To: <20080409180042.511531370055@mail134-sin.bigfish.com>
On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio <john.bonesio@xilinx.com> wrote:
> Hi Grant,
>
> I have a question about your patch. It appears as if the cache setup code is
> in a file that would be used only on Xilinx FPGA devices.
That is correct.
>
> I understand that many people are using a bootloader that already sets up the
> cache for the kernel, but I'm wondering if Xilinx boards are really a special
> case, or if there may be other non-Xilinx related systems that would also not
> be using a bootloader.
I think there are very few cases of platforms not using some form of firmware.
>
> I also understand the desire to avoid code that does the same work more than
> once, but I wonder if in this case, it's creating too strong a dependence on
> the specific behavior of a certain bootloader.
> I also wonder if arch/powerpc is being made more complex by trying to split
> out this code change into a Xilinx specific area, when the change could just
> be rolled into head_40x.S and we could do away with virtex405-head.S.
In general, I think that the wrapper does not want to touch the cache
settings. In the common case where firmware exists and sets up the
cache then to turn off the cache again would throw away what firmware
already had in cache and slow down the boot.
That being said, I'm not the bootwrapper expert. If other think that
it belongs in head_40x.S then I have no objections.
Josh, any thoughts?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Kernel 2.6.23 Error with make bzImage
From: Sam Karp @ 2008-04-09 20:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <800687fe0804071536t1f94e1a0x793bd39836dc09d2@mail.gmail.com>
Hey all,
I've been looking through the archives for a ramdisk.image.gz for a
ppc (ml403) but most of the links are broken. Does anyone have a
working link to one that I could use?
Thanks,
Sam
On 4/7/08, Sam Karp <sam.d.karp@gmail.com> wrote:
> I've been trying to build the linux 2.6.23 kernel for the PPC405 on the
> xilinx ml403. I copied over my xparameters.h and xparameters_ml40x.h files
> and added the following options through menuconfig.
> Enable loadable module support: DISABLE
> Processor:
>
> - Type 40x
> - Math emulation: ENABLE
> - IBM 40x options:
> - Machine Type: "Xilinx-ML403"
>
> Platform options:
>
> - Kernel command line: "console=ttyUL0 root=/dev/ram"
>
> Bus options:
>
> - PCI support: DISABLE
> - PCCARD (PCMCIA/CardBus) support:
> - PCCARD (PCMCIA/CardBus) support: DISABLE
>
> Drivers
>
> - Block Devices:
> - Xilinx SystemACE support: ENABLE
> - Character devices:
> - Serial drivers:
> - Xilinx uartlite serial port support: ENABLE
> - Support for console on Xilinx uartlite serial port:
> ENABLE
>
> I then ran make bzImage and got the following errors. I'm guessing there
> are two options I chose that conflict. Any insight?
>
> CC arch/powerpc/kernel/swsusp.o
> arch/powerpc/kernel/swsusp.c 19 error: redefinition of
> 'save_processor_state'
> include/asm/suspend.h 7 : previous definition of 'save_processor_state' was
> here
> arch/powerpc/kernel/swsusp.c 35 error: redefinition of
> 'restore_processor_state'
> include/asm/suspend.h 11 : previous definition of 'restore_processor_state'
> was here
>
> Thanks,
> Sam
>
^ permalink raw reply
* [patch] PS3: Fix gelic net module dependency
From: Geoff Levand @ 2008-04-09 21:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, Jeff Garzik
The PS3 gelic network driver depends on the wake-on-lan support
provided by the PS3 sys manager driver. Add that dependency
to the GELIC_NET Kconfig option.
Prevents these build errors:
ps3_gelic_net.c:1277: undefined reference to `.ps3_sys_manager_get_wol'
ps3_gelic_net.c:1337: undefined reference to `.ps3_sys_manager_set_wol'
CC: Masakazu Mokuno <mokuno@sm.sony.co.jp>
CC: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Hi Paul,
This fixes an error introduced in my 2.6.26 WOL patches now
queued in your powerpc tree. Please apply.
-Geoff
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2358,6 +2358,7 @@ config TSI108_ETH
config GELIC_NET
tristate "PS3 Gigabit Ethernet driver"
depends on PPC_PS3
+ select PS3_SYS_MANAGER
help
This driver supports the network device on the PS3 game
console. This driver has built-in support for Ethernet.
^ permalink raw reply
* Re: [PATCH 5/6] [POWERPC] properly declare onstack completion in iseries veth
From: Benjamin Herrenschmidt @ 2008-04-09 21:03 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080409083616.GA24712@lst.de>
On Wed, 2008-04-09 at 10:36 +0200, Christoph Hellwig wrote:
> On Wed, Apr 09, 2008 at 05:21:34PM +1000, Benjamin Herrenschmidt wrote:
> > The iSeries veth driver uses an on-stack struct completion that
> > it initializes using the COMPLETION_INITIALIZER instead of
> > COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
> > lockdep.
>
> should probably go in ASAP independent of the lockdep series.
I don't think there's any difference between the _ONSTACK variant
and the normal one without lockdep, is there ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] [POWERPC] Make Book-E debug handling SMP safe
From: Kumar Gala @ 2008-04-09 21:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
global_dbcr0 needs to be a per cpu set of save areas instead of a single
global on all processors.
Also, we switch to using DBCR0_IDM to determine if the user space app is
being debugged as its a more consistent way. In the future we should
support features like hardware breakpoint and watchpoints which will
have DBCR0_IDM set but not necessarily DBCR0_IC (single step).
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Paul, you wrote the original code here so please take a look at this.
- k
arch/powerpc/kernel/entry_32.S | 30 +++++++++++++++++++++---------
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 69a91bd..84c8686 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -110,9 +110,9 @@ transfer_to_handler:
stw r11,PT_REGS(r12)
#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
/* Check to see if the dbcr0 register is set up to debug. Use the
- single-step bit to do this. */
+ internal debug mode bit to do this. */
lwz r12,THREAD_DBCR0(r12)
- andis. r12,r12,DBCR0_IC@h
+ andis. r12,r12,DBCR0_IDM@h
beq+ 3f
/* From user and task is ptraced - load up global dbcr0 */
li r12,-1 /* clear all pending debug events */
@@ -120,6 +120,12 @@ transfer_to_handler:
lis r11,global_dbcr0@ha
tophys(r11,r11)
addi r11,r11,global_dbcr0@l
+#ifdef CONFIG_SMP
+ rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
+ lwz r9,TI_CPU(r9)
+ slwi r9,r9,3
+ add r11,r11,r9
+#endif
lwz r12,0(r11)
mtspr SPRN_DBCR0,r12
lwz r12,4(r11)
@@ -238,10 +244,10 @@ ret_from_syscall:
stw r11,_CCR(r1)
syscall_exit_cont:
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
- /* If the process has its own DBCR0 value, load it up. The single
- step bit tells us that dbcr0 should be loaded. */
+ /* If the process has its own DBCR0 value, load it up. The internal
+ debug mode bit tells us that dbcr0 should be loaded. */
lwz r0,THREAD+THREAD_DBCR0(r2)
- andis. r10,r0,DBCR0_IC@h
+ andis. r10,r0,DBCR0_IDM@h
bnel- load_dbcr0
#endif
#ifdef CONFIG_44x
@@ -666,10 +672,10 @@ user_exc_return: /* r10 contains MSR_KERNEL here */
restore_user:
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
- /* Check whether this process has its own DBCR0 value. The single
- step bit tells us that dbcr0 should be loaded. */
+ /* Check whether this process has its own DBCR0 value. The internal
+ debug mode bit tells us that dbcr0 should be loaded. */
lwz r0,THREAD+THREAD_DBCR0(r2)
- andis. r10,r0,DBCR0_IC@h
+ andis. r10,r0,DBCR0_IDM@h
bnel- load_dbcr0
#endif
@@ -879,6 +885,12 @@ load_dbcr0:
mfspr r10,SPRN_DBCR0
lis r11,global_dbcr0@ha
addi r11,r11,global_dbcr0@l
+#ifdef CONFIG_SMP
+ rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
+ lwz r9,TI_CPU(r9)
+ slwi r9,r9,3
+ add r11,r11,r9
+#endif
stw r10,0(r11)
mtspr SPRN_DBCR0,r0
lwz r10,4(r11)
@@ -891,7 +903,7 @@ load_dbcr0:
.section .bss
.align 4
global_dbcr0:
- .space 8
+ .space 8*NR_CPUS
.previous
#endif /* !(CONFIG_4xx || CONFIG_BOOKE) */
--
1.5.4.1
^ permalink raw reply related
* Re: [patch] PS3: Fix gelic net module dependency
From: Jeff Garzik @ 2008-04-09 21:42 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <47FD2EC1.8030600@am.sony.com>
Geoff Levand wrote:
> The PS3 gelic network driver depends on the wake-on-lan support
> provided by the PS3 sys manager driver. Add that dependency
> to the GELIC_NET Kconfig option.
>
> Prevents these build errors:
>
> ps3_gelic_net.c:1277: undefined reference to `.ps3_sys_manager_get_wol'
> ps3_gelic_net.c:1337: undefined reference to `.ps3_sys_manager_set_wol'
>
> CC: Masakazu Mokuno <mokuno@sm.sony.co.jp>
> CC: Jeff Garzik <jgarzik@pobox.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> Hi Paul,
>
> This fixes an error introduced in my 2.6.26 WOL patches now
> queued in your powerpc tree. Please apply.
>
> -Geoff
>
> drivers/net/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2358,6 +2358,7 @@ config TSI108_ETH
> config GELIC_NET
> tristate "PS3 Gigabit Ethernet driver"
> depends on PPC_PS3
> + select PS3_SYS_MANAGER
> help
> This driver supports the network device on the PS3 game
> console. This driver has built-in support for Ethernet.
looks sane to me, but I do not have enough knowledge to ACK. Thanks for
the CC :)
^ permalink raw reply
* [PATCH] mpc8540 : Fix restart
From: Philippe De Muyter @ 2008-04-09 22:12 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody,
Previously, with the arch/ppc tree, mpc8540 boards could reboot.
Now with the arch/powerpc tree, they can not anymore.
Fix that.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000 +0000
+++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000 +0000
@@ -1428,13 +1433,17 @@
arch_initcall(setup_rstcr);
+extern void abort(void);
+
void fsl_rstcr_restart(char *cmd)
{
local_irq_disable();
if (rstcr)
/* set reset control register */
out_be32(rstcr, 0x2); /* HRESET_REQ */
-
+ else
+ abort();
while (1) ;
+
}
#endif
^ permalink raw reply
* [PATCH] fsl_soc : add support for m41t81 rtc chip
From: Philippe De Muyter @ 2008-04-09 22:22 UTC (permalink / raw)
To: linuxppc-dev
Hello everybody,
Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
board.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000 +0000
+++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000 +0000
@@ -405,7 +405,10 @@
{"dallas,ds1339", "rtc-ds1307", "ds1339",},
{"dallas,ds1340", "rtc-ds1307", "ds1340",},
{"stm,m41t00", "rtc-ds1307", "m41t00"},
+#ifdef CONFIG_RTC_DRV_M41T80
+ {"stm,m41t81", "rtc-m41t80", "m41t81"},
+#endif
{"dallas,ds1374", "rtc-ds1374", "rtc-ds1374",},
};
static int __init of_find_i2c_driver(struct device_node *node,
^ permalink raw reply
* Re: [PATCH] fsl_soc : add support for m41t81 rtc chip
From: Olof Johansson @ 2008-04-09 22:37 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080409222252.GA1006@frolo.macqel>
Hi,
On Thu, Apr 10, 2008 at 12:22:52AM +0200, Philippe De Muyter wrote:
> Hello everybody,
>
> Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
> board.
>
> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
>
> --- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000 +0000
> +++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000 +0000
> @@ -405,7 +405,10 @@
> {"dallas,ds1339", "rtc-ds1307", "ds1339",},
> {"dallas,ds1340", "rtc-ds1307", "ds1340",},
> {"stm,m41t00", "rtc-ds1307", "m41t00"},
> +#ifdef CONFIG_RTC_DRV_M41T80
> + {"stm,m41t81", "rtc-m41t80", "m41t81"},
> +#endif
Don't add ifdef here. It doesn't hurt to have it in the table even if
the driver is not enabled.
-Olof
^ permalink raw reply
* Re: [PATCH 2/6] [POWERPC] lockdep stacktrace support
From: Benjamin Herrenschmidt @ 2008-04-09 22:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20080409072223.7DE7BDDE20@ozlabs.org>
On Wed, 2008-04-09 at 17:21 +1000, Benjamin Herrenschmidt wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> I recently tried to work on lockdep for powerpc. I have preliminary
> version of the stacktrace code, but had to give up on trace irqflags
> support because I'm not that knowledgeable on lowlevel ppc details.
>
> Maybe someone more faimilar with the code wants to give it another try?
>
> My stacktrace code is below:
it's
BTW. I know this patch is still missing (c) boilerplate on the new file
and catch up with some other comments I got last week... I was busy
making the stuff actually work :-) I'll fix that up today.
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> ---
> arch/powerpc/Kconfig | 4 +++
> arch/powerpc/kernel/Makefile | 1
> arch/powerpc/kernel/stacktrace.c | 52 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 57 insertions(+)
>
> --- linux-work.orig/arch/powerpc/Kconfig 2008-04-02 15:46:07.000000000 +1100
> +++ linux-work/arch/powerpc/Kconfig 2008-04-02 16:47:46.000000000 +1100
> @@ -49,6 +49,10 @@ config IRQ_PER_CPU
> bool
> default y
>
> +config STACKTRACE_SUPPORT
> + bool
> + default y
> +
> config RWSEM_GENERIC_SPINLOCK
> bool
>
> Index: linux-work/arch/powerpc/kernel/Makefile
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/Makefile 2008-04-02 15:46:07.000000000 +1100
> +++ linux-work/arch/powerpc/kernel/Makefile 2008-04-02 16:46:07.000000000 +1100
> @@ -67,6 +67,7 @@ obj-$(CONFIG_BOOTX_TEXT) += btext.o
> obj-$(CONFIG_SMP) += smp.o
> obj-$(CONFIG_KPROBES) += kprobes.o
> obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
> +obj-$(CONFIG_STACKTRACE) += stacktrace.o
>
> pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
> obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
> Index: linux-work/arch/powerpc/kernel/stacktrace.c
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-work/arch/powerpc/kernel/stacktrace.c 2008-04-02 16:46:07.000000000 +1100
> @@ -0,0 +1,52 @@
> +
> +#include <linux/sched.h>
> +#include <linux/stacktrace.h>
> +
> +
> +#ifdef CONFIG_PPC64
> +#define MIN_STACK_FRAME 112 /* same as STACK_FRAME_OVERHEAD, in fact */
> +#define FRAME_LR_SAVE 2
> +#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD + 288)
> +#define REGS_MARKER 0x7265677368657265ul
> +#define FRAME_MARKER 12
> +#else
> +#define MIN_STACK_FRAME 16
> +#define FRAME_LR_SAVE 1
> +#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD)
> +#define REGS_MARKER 0x72656773ul
> +#define FRAME_MARKER 2
> +#endif
> +
> +
> +/*
> + * Save stack-backtrace addresses into a stack_trace buffer.
> + * If all_contexts is set, all contexts (hardirq, softirq and process)
> + * are saved. If not set then only the current context is saved.
> + */
> +void save_stack_trace(struct stack_trace *trace)
> +{
> + unsigned long sp;
> +
> + asm("mr %0,1" : "=r" (sp));
> +
> + for (;;) {
> + unsigned long *stack = (unsigned long *) sp;
> + unsigned long newsp, ip;
> +
> + if (!validate_sp(sp, current, MIN_STACK_FRAME))
> + return;
> +
> + newsp = stack[0];
> + ip = stack[FRAME_LR_SAVE];
> +
> + if (!trace->skip)
> + trace->entries[trace->nr_entries++] = ip;
> + else
> + trace->skip--;
> +
> + if (trace->nr_entries >= trace->max_entries)
> + return;
> +
> + sp = newsp;
> + }
> +}
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] fsl_soc : add support for m41t81 rtc chip
From: Philippe De Muyter @ 2008-04-09 22:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080409222252.GA1006@frolo.macqel>
Hello everybody,
Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
board.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
--
I have removed the ifdef as pointed by Olof
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000 +0000
+++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000 +0000
@@ -405,7 +405,8 @@
{"dallas,ds1339", "rtc-ds1307", "ds1339",},
{"dallas,ds1340", "rtc-ds1307", "ds1340",},
{"stm,m41t00", "rtc-ds1307", "m41t00"},
+ {"stm,m41t81", "rtc-m41t80", "m41t81"},
{"dallas,ds1374", "rtc-ds1374", "rtc-ds1374",},
};
static int __init of_find_i2c_driver(struct device_node *node,
^ permalink raw reply
* Re: [PATCH] mpc8540 : Fix restart
From: Kumar Gala @ 2008-04-09 22:51 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080409221256.GA927@frolo.macqel>
On Apr 9, 2008, at 5:12 PM, Philippe De Muyter wrote:
> Hi everybody,
>
> Previously, with the arch/ppc tree, mpc8540 boards could reboot.
> Now with the arch/powerpc tree, they can not anymore.
> Fix that.
>
> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
>
> --- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000
> +0000
> +++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000
> +0000
> @@ -1428,13 +1433,17 @@
>
> arch_initcall(setup_rstcr);
>
> +extern void abort(void);
> +
> void fsl_rstcr_restart(char *cmd)
> {
> local_irq_disable();
> if (rstcr)
> /* set reset control register */
> out_be32(rstcr, 0x2); /* HRESET_REQ */
> -
> + else
> + abort();
> while (1) ;
> +
> }
This was on purpose. abort() doesn't really do a restart and thus I
didn't want it to be used that way.
- k
^ permalink raw reply
* Re: [PATCH] mpc8540 : Fix restart
From: Philippe De Muyter @ 2008-04-09 23:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <64B092F9-7790-4655-AA12-B9010D87D0A4@kernel.crashing.org>
On Wed, Apr 09, 2008 at 05:51:40PM -0500, Kumar Gala wrote:
>
> On Apr 9, 2008, at 5:12 PM, Philippe De Muyter wrote:
>> Hi everybody,
>>
>> Previously, with the arch/ppc tree, mpc8540 boards could reboot.
>> Now with the arch/powerpc tree, they can not anymore.
>> Fix that.
>>
>> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
>>
>> --- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000 +0000
>> +++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000 +0000
>> @@ -1428,13 +1433,17 @@
>>
>> arch_initcall(setup_rstcr);
>>
>> +extern void abort(void);
>> +
>> void fsl_rstcr_restart(char *cmd)
>> {
>> local_irq_disable();
>> if (rstcr)
>> /* set reset control register */
>> out_be32(rstcr, 0x2); /* HRESET_REQ */
>> -
>> + else
>> + abort();
>> while (1) ;
>> +
>> }
>
> This was on purpose. abort() doesn't really do a restart and thus I didn't
> want it to be used that way.
>
What do you propose then ? The ability to reboot without power-off is
really needed for embedded targets. And abort() from head_fsl.S seems
really close to reboot.
Philippe
^ 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