Re: Problem with full speed devices on PowerPC MPC5121 host port

2012-01-06 Thread Matthias Fuchs
On 22.12.2011 18:39, Greg KH wrote: On Thu, Dec 22, 2011 at 12:48:45PM +0100, Matthias Fuchs wrote: Hi, I ran into trouble when using the MPC5121 with full speed USB devices. I've seen the issue with USB serial converters based on FTDI and Prolific chips. After connecting the device they

Re: [RFC PATCH 0/9] Remove useless on_each_cpu return value

2012-01-06 Thread Peter Zijlstra
On Tue, 2012-01-03 at 16:19 +0200, Gilad Ben-Yossef wrote: on_each_cpu() returns as its own return value the return value of smp_call_function(). smp_call_function() in turn returns a hard coded value of zero. Some callers to on_each_cpu() waste cycles and bloat code space by checking the

Re: Cannot wake-up from standby with MPC8313

2012-01-06 Thread Norbert van Bolhuis
On 01/05/12 19:22, Scott Wood wrote: On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote: thanks for your response. not setting MSR_POW gives same result. OK, so you're not getting an interrupt regardless of low-power state. Check whether the interrupt is getting masked during standby

Re: Problem with full speed devices on PowerPC MPC5121 host port

2012-01-06 Thread Alan Stern
On Fri, 6 Jan 2012, Matthias Fuchs wrote: For my eyes it does not really look like a general USB issue. It looks like a problem with the Freescale EHCI implementation that is influenced by high interrupt or internal bus load caused by the flood ping. Indeed, it might be a problem with the

[PATCH/RFC] gianfar: Add support for byte queue limits.

2012-01-06 Thread Paul Gortmaker
Add support for byte queue limits (BQL), based on the similar modifications made to intel/igb/igb_main.c from Eric Dumazet in commit bdbc063129e811264cd6c311d8c2d9b95de01231. A local variable for tx_queue-qindex was introduced in gfar_clean_tx_ring, since it is now used often enough to warrant

Re: Cannot wake-up from standby with MPC8313

2012-01-06 Thread Scott Wood
On 01/06/2012 07:53 AM, Norbert van Bolhuis wrote: On 01/05/12 19:22, Scott Wood wrote: On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote: thanks for your response. not setting MSR_POW gives same result. OK, so you're not getting an interrupt regardless of low-power state. Check whether

[PATCH] powerpc: fix kernel log of oops/panic instruction dump

2012-01-06 Thread Ira W. Snyder
A kernel oops/panic prints an instruction dump showing several instructions before and after the instruction which caused the oops/panic. The code intended that the faulting instruction be enclosed in angle brackets, however a bug caused the faulting instruction to be interpreted by printk() as

Re: [PATCH] powerpc: fix kernel log of oops/panic instruction dump

2012-01-06 Thread Benjamin Herrenschmidt
On Fri, 2012-01-06 at 14:34 -0800, Ira W. Snyder wrote: A kernel oops/panic prints an instruction dump showing several instructions before and after the instruction which caused the oops/panic. The code intended that the faulting instruction be enclosed in angle brackets, however a bug

Re: [PATCH] powerpc: fix kernel log of oops/panic instruction dump

2012-01-06 Thread Ira W. Snyder
On Sat, Jan 07, 2012 at 09:50:10AM +1100, Benjamin Herrenschmidt wrote: On Fri, 2012-01-06 at 14:34 -0800, Ira W. Snyder wrote: A kernel oops/panic prints an instruction dump showing several instructions before and after the instruction which caused the oops/panic. The code intended

Re: [PATCH v2] of: Change logic to overwrite cmd_line with CONFIG_CMDLINE

2012-01-06 Thread Doug Anderson
I know this is a long-dead thread, but I was a little curious about the motivation here. I'm looking at trying to support CONFIG_CMDLINE_EXTEND (an ARM Kconfig) in this function and don't know in which cases I should look at the CONFIG_CMDLINE and in which cases I should use whatever happened to