Li Yang-R58472 writes:
> Thanks for bringing [CONFIG_MPC8315_DS] up again. Looks like we do
> have a problem here.
My impression is that the simplest fix is Adrian's patch, which simply
keys off CONFIG_MPC831x_RDB. It's not very satisfying, but I'll take
"working" vs. "rare lockups at boot".
On Wed, May 23, 2012 at 03:14:05PM +1000, Stephen Rothwell wrote:
> OK, it seem that most of this has been in Andrew's tree for a while,
> sorry about that.
Grr... *Another* missing prereq for task_work_add() series, this time on
ppc64. Could somebody familiar with that beast take a look at this
On 12-05-25 03:51 PM, Joe Perches wrote:
> On Fri, 2012-05-25 at 11:58 -0400, Paul Gortmaker wrote:
>> But you really shouldn't need the hardware to validate this kind of
>> patch anyways -- aside from your code flow change in the irq routine of
>> gianfar_ptp, you should have been simply able to c
On Fri, 2012-05-25 at 11:58 -0400, Paul Gortmaker wrote:
> But you really shouldn't need the hardware to validate this kind of
> patch anyways -- aside from your code flow change in the irq routine of
> gianfar_ptp, you should have been simply able to check for object file
> equivalence before and
On Thu, May 24, 2012 at 2:18 AM, Dmitry Eremin-Solenikov
wrote:
> Hello, colleagues,
>
> I'm trying to enable an AGP slot (again) on my Maple board (dual PPC970FX
> board, with CPC925 (U3H) north bridge).
>
> For now I'm stuck with a problem: I use radeon card, drm-radeon driver with
> KMS.
>
> I
[Re: [PATCH] gianfar:don't add FCB length to hard_header_len] On 24/05/2012
(Thu 09:16) Joe Perches wrote:
> On Thu, 2012-05-24 at 17:04 +0200, Jan Ceuleers wrote:
> > On 05/22/2012 09:18 PM, David Miller wrote:
> > > From: Jiajun Wu
> > > Date: Tue, 22 May 2012 17:00:48 +0800
> > >
> > >> FCB(
On Fri, May 25, 2012 at 02:29:06PM +0100, David Laight wrote:
> We have a system with linux 2.6.32 and the somewhat archaic
> uClibc 0.9.27 (but I'm not sure the current version is
> any better, and I think there are binary compatibility
> if we update).
>
> I've just discovered that pread() is 'i
We have a system with linux 2.6.32 and the somewhat archaic
uClibc 0.9.27 (but I'm not sure the current version is
any better, and I think there are binary compatibility
if we update).
I've just discovered that pread() is 'implemented'
by using 3 lseek() system calls and read().
(the same is true
Hi,
The basic question is, has the GPR r11 a dedicated function (to point to the
previous stack frame)
or is it still a volatile GPR, according to EABI definition ?
In the case of a dedicated function was assigned, the trampoline code
generation in
arch/powerpc/kernel/module_32.c
must be
