Hello list,
Just a little update and one question.
I spent this night to create a DTS file for the board. I took the
output of the existing /proc/device-tree as basis and added
information regarding the TBI's.
Then I created a simpleImage.
/dts-v1/;
/ {
linux,phandle = <0x100>;
Hey Michael,
I just wanted to let you know that I'm reading your questions, and I'm
crafting a reply, but it's not trivial and I'm also swamped under at
the moment. I should have something for you in the next few days. I
just didn't want you to think you were being ignored.
g.
On Thu, Feb 26,
Hello all,
We completed a 2.6.25 build for MPC8349E-mITX platform, and u-booting using
the
device tree under ...boot/dts/mpc8349emitx.dts
But the standard platform device IRQs are assigned wrong under
/proc/interrupts:
16 i2c-mpc
17 i2c-mpc
20 serial
According to the device tree, and the proce
On Fri, 27 Feb 2009, Roland McGrath wrote:
>
> I don't know any other arch well enough to be sure that TIF_32BIT isn't the
> wrong test there too. I'd like to leave that worry to the arch maintainers.
Agreed - it may be that others will want to not use TIF_32BIT too. It
really does make much
Still looking for some help... I need to be able to locate
the kernel platform_device which corresponds to an instance
from my OF tree. Basically, I have a [somewhat] unrelated
driver which needs to know these things, so the drivers in
question should not have to be affected.
In particular, I'm
On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote:
> On Fri, 27 Feb 2009, Roland McGrath wrote:
> > But here is the patch you asked for.
>
> Yes, this looks much more straightforward.
>
> And I guess the seccomp interaction means that this is potentially a
> 2.6.29 thing. Not that
On Sat, 28 Feb 2009 09:46:01 -0800
Greg KH wrote:
> On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote:
> > On Fri, 27 Feb 2009, Roland McGrath wrote:
> > > But here is the patch you asked for.
> >
> > Yes, this looks much more straightforward.
> >
> > And I guess the seccomp inter
On Sat, Feb 28, 2009 at 10:46 AM, Gary Thomas wrote:
> Still looking for some help... I need to be able to locate
> the kernel platform_device which corresponds to an instance
> from my OF tree. Basically, I have a [somewhat] unrelated
> driver which needs to know these things, so the drivers in
Grant Likely wrote:
> On Sat, Feb 28, 2009 at 10:46 AM, Gary Thomas wrote:
>> Still looking for some help... I need to be able to locate
>> the kernel platform_device which corresponds to an instance
>> from my OF tree. Basically, I have a [somewhat] unrelated
>> driver which needs to know these
On Sat, Feb 28, 2009 at 09:54:33AM -0800, Arjan van de Ven wrote:
> On Sat, 28 Feb 2009 09:46:01 -0800
> Greg KH wrote:
>
> > On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote:
> > > On Fri, 27 Feb 2009, Roland McGrath wrote:
> > > > But here is the patch you asked for.
> > >
> > >
On Sat, Feb 28, 2009 at 11:21 AM, Gary Thomas wrote:
> Grant Likely wrote:
>> Once you have a handle to the node, you can iterate through the
>> of_platform bus devices and look for a node which has a matching node
>> pointer stored in archdata. That will give you a struct device which
>> is cont
Grant Likely wrote:
> On Sat, Feb 28, 2009 at 11:21 AM, Gary Thomas wrote:
>> Grant Likely wrote:
>>> Once you have a handle to the node, you can iterate through the
>>> of_platform bus devices and look for a node which has a matching node
>>> pointer stored in archdata. That will give you a stru
On Sat, Feb 28, 2009 at 12:18 PM, Gary Thomas wrote:
> Grant Likely wrote:
>>> How do I find the platform_device which was created when this
>>> particular of_device was instantiated? I made sure that this code
>>> is run late - after all the of_devices have been handled.
>>
>> Again, there is no
Grant Likely wrote:
> On Sat, Feb 28, 2009 at 12:18 PM, Gary Thomas wrote:
>> Grant Likely wrote:
How do I find the platform_device which was created when this
particular of_device was instantiated? I made sure that this code
is run late - after all the of_devices have been handled
On Sat, Feb 28, 2009 at 10:23:13AM -0800, Greg KH wrote:
> On Sat, Feb 28, 2009 at 09:54:33AM -0800, Arjan van de Ven wrote:
> > On Sat, 28 Feb 2009 09:46:01 -0800
> > Greg KH wrote:
> >
> > > On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote:
> > > > On Fri, 27 Feb 2009, Roland McGr
From: Grant Likely
The SystemACE driver does not handle an empty CF slot gracefully. An
empty CF slot ends up hanging the system. This patch adds a check for
the CF state and stops trying to process requests if the slot is empty.
Signed-off-by: Grant Likely
---
drivers/block/xsysace.c | 2
On Sat, 2009-02-28 at 12:18 -0700, Gary Thomas wrote:
> Grant Likely wrote:
> > On Sat, Feb 28, 2009 at 11:21 AM, Gary Thomas wrote:
> >> Grant Likely wrote:
> >>> Once you have a handle to the node, you can iterate through the
> >>> of_platform bus devices and look for a node which has a matching
On Sat, 2009-02-28 at 09:23 -0800, Linus Torvalds wrote:
>
> On Fri, 27 Feb 2009, Roland McGrath wrote:
> >
> > I don't know any other arch well enough to be sure that TIF_32BIT isn't the
> > wrong test there too. I'd like to leave that worry to the arch maintainers.
>
> Agreed - it may be that
From: Grant Likely
This patch updates the Xilinx ML507 device tree to match the released
ML507 powerpc reference design (ml507_ppc440_emb_ref). This patch is
needed to boot Linux on the ML507 powerpc reference design without
manually generating and tweaking a device tree from the project directo
On Fri, Feb 27, 2009 at 4:54 PM, John Linn wrote:
> The driver was not releasing memory when it was removed or
> when there was a failure during probe. This fixes it.
>
> Signed-off-by: John Linn
Looks good.
Acked-by: Grant Likely
I'll pick this up into my -next branch and ask Ben to pull it
20 matches
Mail list logo
