Hello, I had problems with fan speed in my XServe G5. It turned out
drivers/macintosh/Makefile has a max6690 module missing from compilation
list. I was advised to mail the patch to you guys.
I'm not sure what's the proper format of the patch to be submitten (this is
my first time). So I'm includi
On Fri, 22 Nov 2013, Scott Wood wrote:
> This sounds like an incompatible change to userspace API. What about
> older glibc? What about user code that directly manipulates these bits
> rather than going through libc, or uses a libc other than glibc? Where
> is this API requirement documented?
I get a lot of "eth0: hw csum failure" with 3.13-rc1 on my G5.
eth0: hw csum failure
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.13.0-rc1 #1
Call Trace:
[cffef1d0] [c000f97c] .show_stack+0x60/0x14c (unreliable)
[cffef2a0] [c069fad8] .dump_stack+0x80/0xa0
[cf
The corenet64 patch fixes a regression introduced in 3.13-rc1 (commit
ef1313deafb7baa6d3382044e962d5ad5e8c8dd6, "powerpc: Add VMX optimised xor
for RAID5").
The 8xx patch fixes a regression introduced in 3.12 (commit
beb2dc0a7a84be003ce54e98b95d65cc66e6e536, "powerpc: Convert some
mftb/mftbu into
On Mon, 2013-11-04 at 16:52 +, Joseph S. Myers wrote:
> From: Joseph Myers
>
> The e500 SPE floating-point emulation code clears existing exceptions
> (__FPU_FPSCR &= ~FP_EX_MASK;) before ORing in the exceptions from the
> emulated operation. However, these exception bits are the "sticky",
>
Hello,
On Thu, Nov 21, 2013 at 9:08 PM, Alistair Popple wrote:
> The new IBM Akebono board has a PPC476GTR SoC with an AHCI compliant
> SATA controller. This patch adds a compatible property for the new SoC
> to the AHCI platform driver.
>
> Signed-off-by: Alistair Popple
Applied to libata/for-
On Nov 22, 2013, at 2:12 AM, Liu Gang wrote:
> For MPC8572/MPC8536, the status of GPIOs defined as output
> cannot be determined by reading GPDAT register, so the code
> use shadow data register instead. But the code may give the
> wrong status of GPIOs defined as input under some scenarios:
>
On Fri, 2013-11-22 at 16:12 +0800, Liu Gang wrote:
> For MPC8572/MPC8536, the status of GPIOs defined as output
> cannot be determined by reading GPDAT register, so the code
> use shadow data register instead. But the code may give the
> wrong status of GPIOs defined as input under some scenarios:
On PPC_8xx, CRC32_SLICEBY4 is more efficient (almost twice) than CRC32_SLICEBY8,
as shown below:
With CRC32_SLICEBY8:
[1.109204] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
[1.114401] crc32: self tests passed, processed 225944 bytes in 15118910 nsec
[1.130655] crc32c: CRC_LE_BITS = 64
[
Commit beb2dc0a7a84be003ce54e98b95d65cc66e6e536 breaks the MPC8xx which seems
to not support using mfspr SPRN_TBRx instead of mftb/mftbu despite
what is written in the reference manual
This patchs revert to the use of mftb/mftbu when CONFIG_8xx is selected
Signed-off-by: Christophe Leroy
diff -u
Hi all,
I'm sorry to push this. But this series has been an orphan for a while.
Could any one please receive and foster it?
Thank you.
Nicolin Chen
On Wed, Nov 13, 2013 at 10:55:23PM +0800, Nicolin Chen wrote:
> * ! This series of patches has a direct dependency between them. When
> * !
Add initial device tree for T2080/T2081 without DPAA components.
The T2080 SoC includes the following function and features:
- Four dual-threaded 64-bit Power architecture e6500 cores, up to 1.8GHz
- 2MB L2 cache and 512KB CoreNet platform cache (CPC)
- Hierarchical interconnect fabric
- One 32-/6
Signed-off-by: Shengzhou Liu
---
v2: add T2081QDS compatible.
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/
Add support for Freescale T2080/T2081 QDS Development System Board.
T2081QDS board shares the same PCB with T1040QDS with some differences.
The T2080QDS Development System is a high-performance computing,
evaluation, and development platform that supports T2080 QorIQ
Power Architecture processor,
Add elo3-dma-2.dtsi to support the third DMA controller.
This is used on T2080, T4240, etc.
Signed-off-by: Shengzhou Liu
Signed-off-by: Liu Gang
---
v2: no change
arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi | 82 +++
1 file changed, 82 insertions(+)
create mode 10064
For MPC8572/MPC8536, the status of GPIOs defined as output
cannot be determined by reading GPDAT register, so the code
use shadow data register instead. But the code may give the
wrong status of GPIOs defined as input under some scenarios:
1. If some pins were configured as inputs and were asserte
Prior to the completion of PCI enumeration, we actively detects
EEH errors on PCI config cycles and dump PHB diag-data if necessary.
The EEH backend also dumps PHB diag-data in case of frozen PE or
fenced PHB. However, we are using different functions to dump the
PHB diag-data for those 2 cases.
T
When hitting frozen PE or fenced PHB, it's always indicative to
have dumped PHB diag-data for further analysis and diagnosis.
However, we never dump that for the cases. The patch intends to
dump PHB diag-data at the backend of eeh_ops::get_log() for PowerNV
platform.
Signed-off-by: Gavin Shan
---
18 matches
Mail list logo
