From: Milton Miller
show_stack uses up to 4 printks per line and other CPUs using printk
can corrupt the output. This patch calls printk once per stack frame
line to produce more readable output.
Signed-off-by: Milton Miller
Signed-off-by: Anton Blanchard
---
Index: linux-build/arch/powerpc/k
During kdump stress testing I sometimes see the kdump kernel panic
with:
Interrupt 0x306 (real) is invalid, disabling it.
Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000306
Instead of panicing print the error message, dump the stack the first
time it happens and contin
On a 64bit book3s machine I have an oops from a system reset that
claims the book3e CE bit was set:
MSR: 80021032 CR: 24004082 XER: 0010
On a book3s machine system reset sets IBM bit 46 and 47 depending on
the power saving mode. Separate the definitions by type and for
completenes
On Fri, 2011-11-18 at 10:33 +0530, Prashant Bhole wrote:
> Hi,
> I have been facing problem with ibm_newemac driver (v3.54).
> The board gets disconnected and can not be pinged in between
> some heavy network traffic. In my case I am running IOmeter
> "All-in-One" 8 threads on the iSCSI target. MTU
On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
> I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
> correct backtrace but I cannot turn on frame pointers for the ppc kernel.
> Isn't frame pointers needed for pcc? what about user space?
PowerPC always has frame p
Hi Linus !
Here are a handful of tiny fixes for ppc, essentially embedded bits and
all reasonably trivial.
Cheers,
Ben.
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)
are available in the git repository at:
git://git.k
On Tue, 2011-10-25 at 17:54 -0500, Matthew McClintock wrote:
> boot_cpuid and init_thread_info.cpu are redundant, just use the
> var that stays around longer and add a define to make boot_cpuid
> point at the correct value
Breaks pseries build. Looks trivial but I haven't had a chance to fix
it (o
On Thu, 24 Nov 2011, Alan Cox wrote:
> Given the change should work for all hardware do we really need the
> ifdefs. Far better I would have thought to just change it so we don't
> have to maintain what is effectively two versions of the code between
> now and 2038.
I agree.
>
> So no ack f
Hi Michael,
On Fri, 25 Nov 2011 11:54:55 +1100 Stephen Rothwell
wrote:
>
> Just wondering why you move pci_iomap but not pic_iounmap.
I figured this out. Arches have their own.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpeYVeEJS
Hi Michael,
On Thu, 24 Nov 2011 22:17:02 +0200 "Michael S. Tsirkin" wrote:
>
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 9120887..c8a67345 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -19,6 +19,8 @@
> #include
> #endif
>
> +#inc
On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote:
.../...
> #ifdef CONFIG_PPC_MM_SLICES
> - psize = mmu_get_tsize(get_slice_psize(mm, ea));
> - tsize = mmu_get_psize(psize);
> + psize = get_slice_psize(mm, ea);
> + tsize = mmu_get_tsize(psize);
> shift = mmu_psize_defs
On Tue, Nov 15, 2011 at 08:43:34PM +0530, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> Documentation for firmware-assisted dump. This document is based on the
> original documentation written for phyp assisted dump by Linas Vepstas
> and Manish Ahuja, with few changes to reflect the c
On Tue, Nov 15, 2011 at 08:43:43PM +0530, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> Reserve the memory during early boot to preserve CPU state data, HPTE region
> and RMR region data in case of kernel crash. At the time of crash, powerpc
> firmware will store CPU state data, HPTE r
On Thursday 24 November 2011 22:17:02 Michael S. Tsirkin wrote:
> Many architectures want a generic pci_iomap but
> not the rest of iomap.c. Split that to a separate .c
> file and add a new config symbol. select automatically
> by GENERIC_IOMAP.
>
> Signed-off-by: Michael S. Tsirkin
Very nice!
sparc copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
Signed-off-by: Michael S. Tsirkin
---
arch/sparc/Kconfig |1 +
arch/sparc/include/asm/io_32.h |5 -
ar
sh copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
Signed-off-by: Michael S. Tsirkin
---
arch/sh/Kconfig |1 +
arch/sh/drivers/pci/pci.c | 23 --
powerpc copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
The only difference is handling of nocache flag,
that turns out to be done correctly by the
generic code since arch/powerpc/in
parisc copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
Signed-off-by: Michael S. Tsirkin
---
arch/parisc/Kconfig |1 +
arch/parisc/lib/iomap.c | 23 --
mips copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
Signed-off-by: Michael S. Tsirkin
---
arch/mips/Kconfig |1 +
arch/mips/lib/iomap-pci.c | 26
microblaze copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
The only difference is handling of nocache flag,
that turns out to be done correctly by the
generic code since arch/microbl
arm copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
Signed-off-by: Michael S. Tsirkin
---
arch/arm/Kconfig |1 +
arch/arm/include/asm/io.h |2 +-
arch/arm/mm/iomap
alpha copied pci_iomap from generic code to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
The only difference is handling of nocache flag,
that turns out to be done correctly by the
generic code since arch/alpha/include/asm/io.h
Many architectures want a generic pci_iomap but
not the rest of iomap.c. Split that to a separate .c
file and add a new config symbol. select automatically
by GENERIC_IOMAP.
Signed-off-by: Michael S. Tsirkin
---
include/asm-generic/io.h|5 +--
include/asm-generic/iomap.h |7 +
define GENERIC_IOMAP in a central location
instead of all architectures. This will be helpful
for the follow-up patch which makes it select
other configs. Code is also a bit shorter this way.
Signed-off-by: Michael S. Tsirkin
---
arch/alpha/Kconfig |4
arch/cris/Kconfig
On Thu, 2011-11-24 at 15:28 +, David Laight wrote:
> > On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
> > masked. This can be a problem when pmac_zilog starts up.
>
> Wouldn't this also happen if the interrupt were shared?
> Hopefully nothing vaguely modern uses the bor
On Thu, 2011-11-24 at 14:56 +, Alan Cox wrote:
> > This patch has been tested on a variety of m68k Macs but no
> PowerMacs.
> >
> > I am re-sending this patch Cc linux-serial. It still needs a
> suitable ack
> > so that Geert can push it through his tree.
>
> Given the change should work for
arch/powerpc/mm/hugetlbpage.c: In function 'reserve_hugetlb_gpages':
arch/powerpc/mm/hugetlbpage.c:312:2: error: implicit declaration of function
'parse_args'
Signed-off-by: Kumar Gala
---
arch/powerpc/mm/hugetlbpage.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arc
On Nov 24, 2011, at 4:41 AM, Jiri Slaby wrote:
> When spi_fsl_espi is chosen to be built as a module, there is a build
> error because we test only CONFIG_SPI_FSL_ESPI in declaration of
> struct mpc8xxx_spi in drivers/spi/spi_fsl_lib.h. Also some called
> functions are not exported.
>
> So we fo
On Nov 24, 2011, at 9:26 AM, Paul Gortmaker wrote:
> On 11-11-24 03:14 AM, Kumar Gala wrote:
>>
>> On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
>>
>>> Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
>>> chips seems to cause a short lived IRQ storm (/proc/interrupts
>>> ty
Yes, I sent a patch. Then he sent another patch which breaks things
differently. I have not yet submitted my fix. My fix is to revert his patch,
and then modify your updated device trees to automatically set the tbi to
something.
On Nov 24, 2011, at 1:51, "Kumar Gala" wrote:
>
> On Nov 9, 20
Hello all,
I have a flash memory in a custom device and I'd like to place a standard
filesystem on it, so I guess there must be a way
to tell the kernel to use it.
Here's the DTS definition:
Flash_Serie: gpio@8146 {
compatible = "xlnx,xps-gpio-2.00.a",
> On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
> masked. This can be a problem when pmac_zilog starts up.
Wouldn't this also happen if the interrupt were shared?
Hopefully nothing vaguely modern uses the borked Zilog 8530 SCC
(which I presume is the part in question - b
On 11-11-24 03:14 AM, Kumar Gala wrote:
>
> On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
>
>> Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
>> chips seems to cause a short lived IRQ storm (/proc/interrupts
>> typically shows somewhere between 300 and 1500 events). Unfort
On Fri, 25 Nov 2011 01:34:58 +1100 (EST)
Finn Thain wrote:
>
> On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
> masked. This can be a problem when pmac_zilog starts up.
>
> For example, the serial debugging code in arch/m68k/kernel/head.S may be
> used beforehand. It di
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
masked. This can be a problem when pmac_zilog starts up.
For example, the serial debugging code in arch/m68k/kernel/head.S may be
used beforehand. It disables the SCC interrupts at the chip but doesn't
ack them. Then when a
On Nov 22, 2011, at 9:41 PM, Kumar Gala wrote:
>
> On Oct 31, 2011, at 4:38 AM,
> wrote:
>
>> From: Liu Shuo
>>
>> Integrated Flash Controller supports various flashes like NOR, NAND
>> and other devices using NOR, NAND and GPCM Machine available on it.
>> IFC supports four chip selects.
>
On Nov 24, 2011, at 1:55 AM, Kumar Gala wrote:
>>
>> I'll have to check. But this patch can't be applied as-is unless it's
>> proven safe for all QE-enabled chips.
>
> Any update on trying this on a MPC8323?
Haiying said it should be ok, but I haven't tried it yet. I'll try it on
Monday.
_
On Nov 24, 2011, at 1:12 AM, Kumar Gala wrote:
>
> If you want me to apply this please also provided a 32-bit .dts for p1022ds.
> This should be pretty trivial based on my recent .dts cleanups.
Ok, I'll do that.
___
Linuxppc-dev mailing list
Linuxpp
Hello Josh,
Thanks for the review. The comments are appreciated. Please see my inline
replies.
Thanks,
Tanmay
On Wed, Nov 23, 2011 at 7:40 PM, Josh Boyer wrote:
> On Wed, Nov 23, 2011 at 4:44 AM, Tanmay Inamdar wrote:
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index
On Thu, 2011-11-24 at 18:02 +0800, LiuShuo wrote:
> 于 2011年11月24日 16:16, Artem Bityutskiy 写道:
> > On Thu, 2011-11-24 at 07:49 +, Li Yang-R58472 wrote:
> >>> Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to
> >>> support
> >>> large-page Nand chip
> >>>
> >>> On Thu, 2011-11-
When spi_fsl_espi is chosen to be built as a module, there is a build
error because we test only CONFIG_SPI_FSL_ESPI in declaration of
struct mpc8xxx_spi in drivers/spi/spi_fsl_lib.h. Also some called
functions are not exported.
So we forbid CONFIG_SPI_FSL_ESPI to be tristate here.
The error look
> Subject: [PATCH 2/2] powerpc/85xx: Renamed mpc85xx_common.c
> to common.c
>
> The file name is already scoped by the directory its in.
...
> rename from arch/powerpc/platforms/85xx/mpc85xx_common.c
> rename to arch/powerpc/platforms/85xx/common.c
All very well until you only have a reference
于 2011年11月24日 16:16, Artem Bityutskiy 写道:
On Thu, 2011-11-24 at 07:49 +, Li Yang-R58472 wrote:
Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support
large-page Nand chip
On Thu, 2011-11-24 at 08:41 +0800, b35...@freescale.com wrote:
+ /*
+
On Wed, Nov 23, 2011 at 08:12:56PM +0800, Li Yang wrote:
> The original implementation of dequeuing a request in progress
> is not correct. Change to use a correct process and also clean
> up the related functions a little bit.
>
> Signed-off-by: Li Yang
> Cc: Peter Chen
applied, thanks
--
b
On Tue, Nov 22, 2011 at 09:55:45AM +0800, Peter Chen wrote:
> Some ISO gadgets, like audio, has SYNC attribute as well as
> USB_ENDPOINT_XFER_ISOC for their bmAttributes at ISO endpoint
> descriptor. So, it needs to use usb_endpoint_xfer_isoc to judge
> ISO XFER.
>
> Signed-off-by: Peter Chen
ap
On Wed, Nov 23, 2011 at 08:20:54AM +, Li Yang-R58472 wrote:
> >Leo, I have debugged this issue at my board just now, the reason of
> >failure is we only have one ep struct for ep0, so when talking about ep0,
> >it always pointers to udc->ep[0]. So even we initialize the current qh
> >address fo
On Tue, Nov 22, 2011 at 02:26:24AM +0100, Michal Nazarewicz wrote:
> >On Tue, 22 Nov 2011 02:15:21 +0100, Peter Chen
> >wrote:
> >>@@ -877,7 +877,7 @@ fsl_ep_queue(struct usb_ep *_ep, struct usb_request
> >>*_req, gfp_t gfp_flags)
> >>VDBG("%s, bad ep", __func__);
> >>ret
Ben,
'next' branch pull request that includes 'merge' as well.
- k
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
Ben,
Pulled in a bunch of other minor fixes that have been sitting around for a
while.
- k
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kerne
On Jun 18, 2010, at 8:22 AM, Chuck Meade wrote:
> From: Chuck Meade
>
> The UCC UART driver is missing a call to uart_update_timeout().
> Without this call, attempting to close the port after outputting large
> amounts of data (i.e. using tty and uart buffering) results in long
> timeouts befor
On Oct 31, 2011, at 5:06 PM, Timur Tabi wrote:
> On Freescale parts with multiple MSI controllers, the controllers are
> combined into one "pool" of interrupts. Whenever a device requests an MSI
> interrupt, the next available interrupt from the pool is selected,
> regardless of which MSI contro
On Nov 15, 2011, at 4:52 PM, a...@linux-foundation.org wrote:
> From: Shaohui Xie
> Subject: drivers/edac/mpc85xx_edac.c: fix memory controller compatible for
> edac
>
> compatible in dts has been changed, so the driver needs to be updated
> accordingly.
>
> Signed-off-by: Shaohui Xie
> Cc:
On Thu, 2011-11-24 at 07:49 +, Li Yang-R58472 wrote:
> > Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support
> > large-page Nand chip
> >
> > On Thu, 2011-11-24 at 08:41 +0800, b35...@freescale.com wrote:
> > > + /*
> > > +* Freescale FCM c
On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
> Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
> chips seems to cause a short lived IRQ storm (/proc/interrupts
> typically shows somewhere between 300 and 1500 events). Unfortunately
> this renders SysRQ over the serial cons
Hi Ira,
Thanks for your review.
After second thought, I think your scenario may not occur.
Because the cookie 20 we query must be returned by fsl_dma_tx_submit(...) in
practice.
We never query a cookie not returned by fsl_dma_tx_submit(...).
When we call fsl_tx_status(20), the chan->common.coo
55 matches
Mail list logo
