* Re: [PATCH] ps3: Fix no storage devices found
From: Geoff Levand @ 2007-08-14 16:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Hiroyuki Machida, Andrew Morton,
Olaf Hering
In-Reply-To: <Pine.LNX.4.62.0708141828170.3886@pademelon.sonytel.be>
Geert Uytterhoeven wrote:
> Fix probing of PS3 storage devices: in the success case, we should set `error'
> to zero, not `result'.
>
> Without this patch no storage devices are found.
>
> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> ---
> This brown paper bag bug slipped in due to bad patch splitting.
> Please apply as soon as possible. Thanks!
Looks good.
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
^ permalink raw reply
* [PATCH] ps3: Fix no storage devices found
From: Geert Uytterhoeven @ 2007-08-14 16:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux/PPC Development, Hiroyuki Machida, Olaf Hering
In-Reply-To: <46C1D0D6.7030403@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1379 bytes --]
Fix probing of PS3 storage devices: in the success case, we should set `error'
to zero, not `result'.
Without this patch no storage devices are found.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
This brown paper bag bug slipped in due to bad patch splitting.
Please apply as soon as possible. Thanks!
arch/powerpc/platforms/ps3/device-init.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -372,7 +372,7 @@ static int ps3_storage_wait_for_device(c
notify_event->dev_type == repo->dev_type) {
pr_debug("%s:%u: device ready: dev_id %u\n", __func__,
__LINE__, repo->dev_id);
- result = 0;
+ error = 0;
break;
}
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
From: Olaf Hering @ 2007-08-14 16:24 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1187092392.3707.74.camel@shinybook.infradead.org>
On Tue, Aug 14, David Woodhouse wrote:
> On Tue, 2007-08-14 at 13:49 +0200, Olaf Hering wrote:
> > On Wed, Apr 04, Paul Mackerras wrote:
> >
> > > David Woodhouse writes:
> > >
> > > > There are proper device numbers registered for pmac_zilog now. Use them.
> >
> > Which numbers?
>
> shinybook /shiny/git/mtd-utils $ ls -l /dev/ttyPZ*
> crw-rw---- 1 root uucp 204, 192 2007-08-13 11:48 /dev/ttyPZ0
> crw-rw---- 1 root uucp 204, 193 2007-08-13 11:48 /dev/ttyPZ1
I dont see 204:192 in devices.txt
^ permalink raw reply
* Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Scott Wood @ 2007-08-14 16:16 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <1B668DF2-9909-4D43-AAFF-3A2ADFA283B2@freescale.com>
Andy Fleming wrote:
> It's actually a per-tsec property. There's not one tbi, there's one
> per TSEC. The one on TSEC 0 is special in that it can interfere with
> PHYs on the MDIO bus.
>
> So I would suggest making it a property of the ethernet node:
>
> ethernet@24000 {
> ...
> tbipa = <1f>;
> ...
> }
"tbipa" isn't likely to pass the Segher test. :-)
If the TBI address is in PHY-space, then it should go in the MDIO bus.
For the second TSEC, create a second MDIO bus node.
-Scott
^ permalink raw reply
* Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Andy Fleming @ 2007-08-14 16:04 UTC (permalink / raw)
To: joe.hamman; +Cc: linuxppc-embedded
In-Reply-To: <013b01c7de23$5baa7d70$6f00a8c0@ESIDT>
On Aug 13, 2007, at 22:29, Joe Hamman wrote:
>>
>>
>> On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
>>
>>> Allow the address of the Ten Bit Interface (TBI) to be changed in
>>> the
>>> event of a conflict with another device.
>>>
>>> Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
>>> ---
>>>
>>> Please ignore the last patch - I missed a cut & paste error on the
>>> range
>>> that my testing didn't catch.
>>
>> I think we'd rather this came from the device tree.
>>
> Duh, that makes sense ;-)
>
> Has there been any discussion yet? Maybe something like this:
>
> mdio@24520 {
>
...
> phy3: ethernet-phy@3 {
> interrupt-parent = <&mpic>;
> interrupts = <a 1>;
> reg = <3>;
> device_type = "ethernet-phy";
> };
> tbi: ethernet-tbi@1f {
> reg = <1f>;
> device_type = "ethernet-tbi";
> };
It's actually a per-tsec property. There's not one tbi, there's one
per TSEC. The one on TSEC 0 is special in that it can interfere with
PHYs on the MDIO bus.
So I would suggest making it a property of the ethernet node:
ethernet@24000 {
...
tbipa = <1f>;
...
}
etc
Andy
^ permalink raw reply
* MPC755
From: Chuck Brown @ 2007-08-14 15:45 UTC (permalink / raw)
To: linuxppc-embedded
Are you still checking this account?
^ permalink raw reply
* RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Joe Hamman @ 2007-08-14 12:47 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-embedded
In-Reply-To: <013b01c7de23$5baa7d70$6f00a8c0@ESIDT>
Hi Kumar,
Or do you think it should be added to gianfar_mdio_data? Easier, but does
it belong there?
Thanks,
Joe
> -----Original Message-----
> From: linuxppc-embedded-
> bounces+joe.hamman=embeddedspecialties.com@ozlabs.org [mailto:linuxppc-
> embedded-bounces+joe.hamman=embeddedspecialties.com@ozlabs.org] On Behalf
> Of Joe Hamman
> Sent: Monday, August 13, 2007 10:30 PM
> To: 'Kumar Gala'
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
> configurable
>
>
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > Sent: Monday, August 13, 2007 10:10 PM
> > To: joe.hamman@embeddedspecialties.com
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
> > configurable
> >
> >
> > On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
> >
> > > Allow the address of the Ten Bit Interface (TBI) to be changed in the
> > > event of a conflict with another device.
> > >
> > > Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
> > > ---
> > >
> > > Please ignore the last patch - I missed a cut & paste error on the
> > > range
> > > that my testing didn't catch.
> >
> > I think we'd rather this came from the device tree.
> >
> Duh, that makes sense ;-)
>
> Has there been any discussion yet? Maybe something like this:
>
> mdio@24520 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "mdio";
> compatible = "gianfar";
> reg = <24520 20>;
> phy0: ethernet-phy@0 {
> interrupt-parent = <&mpic>;
> interrupts = <a 1>;
> reg = <0>;
> device_type = "ethernet-phy";
> };
> phy1: ethernet-phy@1 {
> interrupt-parent = <&mpic>;
> interrupts = <a 1>;
> reg = <1>;
> device_type = "ethernet-phy";
> };
> phy2: ethernet-phy@2 {
> interrupt-parent = <&mpic>;
> interrupts = <a 1>;
> reg = <2>;
> device_type = "ethernet-phy";
> };
> phy3: ethernet-phy@3 {
> interrupt-parent = <&mpic>;
> interrupts = <a 1>;
> reg = <3>;
> device_type = "ethernet-phy";
> };
> tbi: ethernet-tbi@1f {
> reg = <1f>;
> device_type = "ethernet-tbi";
> };
> };
>
> Thanks,
> Joe
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
From: David Woodhouse @ 2007-08-14 11:53 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20070814114931.GA13319@aepfle.de>
On Tue, 2007-08-14 at 13:49 +0200, Olaf Hering wrote:
> On Wed, Apr 04, Paul Mackerras wrote:
>
> > David Woodhouse writes:
> >
> > > There are proper device numbers registered for pmac_zilog now. Use them.
>
> Which numbers?
shinybook /shiny/git/mtd-utils $ ls -l /dev/ttyPZ*
crw-rw---- 1 root uucp 204, 192 2007-08-13 11:48 /dev/ttyPZ0
crw-rw---- 1 root uucp 204, 193 2007-08-13 11:48 /dev/ttyPZ1
--
dwmw2
^ permalink raw reply
* Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
From: Olaf Hering @ 2007-08-14 11:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Woodhouse, linux-kernel
In-Reply-To: <17938.57292.870224.132415@cargo.ozlabs.ibm.com>
On Wed, Apr 04, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > There are proper device numbers registered for pmac_zilog now. Use them.
Which numbers?
> Sigh. I guess this is inevitable, but IMNSHO this exposes a weakness
> in our serial subsystem.
So, when will the name of pmac_zilog get changed?
What major/minor pair will the two ports get?
^ permalink raw reply
* Re: [patch 07/12] powerpc: Fix size check for hugetlbfs
From: David Gibson @ 2007-08-14 7:56 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Ts'o, Zwane Mwaikambo, torvalds, Justin Forbes,
linux-kernel, Chris Wedgwood, Domenico Andreoli,
linuxppc-dev list, Randy Dunlap, Paul Mackerras, Chuck Ebbert,
Dave Jones, Michael Krufky, akpm, Chuck Wolber, stable, alan
In-Reply-To: <20070814072918.GG15025@kroah.com>
On Tue, Aug 14, 2007 at 12:29:18AM -0700, Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> My "slices" address space management code that was added in 2.6.22
> implementation of get_unmapped_area() doesn't properly check that the
> size is a multiple of the requested page size. This allows userland to
> create VMAs that aren't a multiple of the huge page size with hugetlbfs
> (since hugetlbfs entirely relies on get_unmapped_area() to do that
> checking) which leads to a kernel BUG() when such areas are torn down.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: patch powerpc-fix-size-check-for-hugetlbfs.patch queued to -stable tree
From: David Gibson @ 2007-08-14 7:48 UTC (permalink / raw)
To: gregkh, benh, linuxppc-dev, paulus, stable-commits
In-Reply-To: <20070814064534.GE8791@localhost.localdomain>
On Tue, Aug 14, 2007 at 04:45:34PM +1000, David Gibson wrote:
> On Mon, Aug 13, 2007 at 04:26:27PM -0700, gregkh@suse.de wrote:
> >
> > This is a note to let you know that we have just queued up the patch titled
> >
> > Subject: powerpc: Fix size check for hugetlbfs
> >
> > to the 2.6.22-stable tree. Its filename is
> >
> > powerpc-fix-size-check-for-hugetlbfs.patch
> >
> > A git repo of this tree can be found at
> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> >
> >
> > >From benh@kernel.crashing.org Mon Aug 13 16:17:09 2007
> > From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Date: Wed, 08 Aug 2007 15:44:15 +1000
> > Subject: powerpc: Fix size check for hugetlbfs
> > To: linuxppc-dev list <linuxppc-dev@ozlabs.org>
> > Cc: Paul Mackerras <paulus@samba.org>, stable@kernel.org
> > Message-ID: <1186551855.938.164.camel@localhost.localdomain>
> >
> > From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> > My "slices" address space management code that was added in 2.6.22
> > implementation of get_unmapped_area() doesn't properly check that the
> > size is a multiple of the requested page size. This allows userland to
> > create VMAs that aren't a multiple of the huge page size with hugetlbfs
> > (since hugetlbfs entirely relies on get_unmapped_area() to do that
> > checking) which leads to a kernel BUG() when such areas are torn down.
>
> Ok, I said I was going to look into a libhugetlbfs testcase for this.
> Doesn't appear there's specifically a testcase for misaligned size -
> I'll add one.
>
> However, it seems the current kernel, on ppc64, gives a testcase
> failure on 'misaligned_offset', because it's not failing a mapping
> with a non-hugepage aligned file offset. I'm not sure (yet) if this
> failure is also caused by the new slice code, but it seems a likely
> candidate.
I have written a new test for the handling of misaligned addresses,
lengths and offsets for libhugetlbfs. With it I've verified that this
patch does correct a serious problem with length handling - without
the patch this new testcase causes an oops for me. It's simpler than
the 'misaligned_offset' testcase in which the misaligned mapping was
just a step to triggering a different and much more subtle kernel bug
(where the misaligned mapping failed, but corrupted some pagetables in
the process).
But the testcase still fails because a mapping with misaligned offset
still succeeds. Still don't know if this is related to the same slice
changes or not. Need to do a bisect, but I'm putting it off because I
have some other bugs to chase.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [patch 07/12] powerpc: Fix size check for hugetlbfs
From: Greg KH @ 2007-08-14 7:29 UTC (permalink / raw)
To: linux-kernel, stable, linuxppc-dev list
Cc: Theodore Ts'o, Zwane Mwaikambo, Justin Forbes,
Domenico Andreoli, Chris Wedgwood, Paul Mackerras, Randy Dunlap,
Michael Krufky, Chuck Ebbert, Dave Jones, Chuck Wolber, akpm,
torvalds, alan
In-Reply-To: <20070814072813.GA15025@kroah.com>
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
My "slices" address space management code that was added in 2.6.22
implementation of get_unmapped_area() doesn't properly check that the
size is a multiple of the requested page size. This allows userland to
create VMAs that aren't a multiple of the huge page size with hugetlbfs
(since hugetlbfs entirely relies on get_unmapped_area() to do that
checking) which leads to a kernel BUG() when such areas are torn down.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/powerpc/mm/slice.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -405,6 +405,8 @@ unsigned long slice_get_unmapped_area(un
if (len > mm->task_size)
return -ENOMEM;
+ if (len & ((1ul << pshift) - 1))
+ return -EINVAL;
if (fixed && (addr & ((1ul << pshift) - 1)))
return -EINVAL;
if (fixed && addr > (mm->task_size - len))
--
^ permalink raw reply
* Re: patch powerpc-fix-size-check-for-hugetlbfs.patch queued to -stable tree
From: David Gibson @ 2007-08-14 6:45 UTC (permalink / raw)
To: gregkh; +Cc: stable-commits, paulus, linuxppc-dev
In-Reply-To: <20070813234218.4796D14540D0@imap.suse.de>
On Mon, Aug 13, 2007 at 04:26:27PM -0700, gregkh@suse.de wrote:
>
> This is a note to let you know that we have just queued up the patch titled
>
> Subject: powerpc: Fix size check for hugetlbfs
>
> to the 2.6.22-stable tree. Its filename is
>
> powerpc-fix-size-check-for-hugetlbfs.patch
>
> A git repo of this tree can be found at
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
>
> >From benh@kernel.crashing.org Mon Aug 13 16:17:09 2007
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Wed, 08 Aug 2007 15:44:15 +1000
> Subject: powerpc: Fix size check for hugetlbfs
> To: linuxppc-dev list <linuxppc-dev@ozlabs.org>
> Cc: Paul Mackerras <paulus@samba.org>, stable@kernel.org
> Message-ID: <1186551855.938.164.camel@localhost.localdomain>
>
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> My "slices" address space management code that was added in 2.6.22
> implementation of get_unmapped_area() doesn't properly check that the
> size is a multiple of the requested page size. This allows userland to
> create VMAs that aren't a multiple of the huge page size with hugetlbfs
> (since hugetlbfs entirely relies on get_unmapped_area() to do that
> checking) which leads to a kernel BUG() when such areas are torn down.
Ok, I said I was going to look into a libhugetlbfs testcase for this.
Doesn't appear there's specifically a testcase for misaligned size -
I'll add one.
However, it seems the current kernel, on ppc64, gives a testcase
failure on 'misaligned_offset', because it's not failing a mapping
with a non-hugepage aligned file offset. I'm not sure (yet) if this
failure is also caused by the new slice code, but it seems a likely
candidate.
Still investigating...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Best Linux tree for Xilinx support.
From: Wolfgang Reissnegger @ 2007-08-14 5:07 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C02053A10@ehost011-3.exch011.intermedia.net>
Hi Leonid,
I am in the process of publishing a Xilinx Linux git tree which will
contain most of the drivers for Xilinx IP including recent contributions
from Grant Likely, John Williams, Joachim Foerster and others.
This tree will be available on the Xilinx git server soon, however it
will be a non-supported (and likely unstable) tree. Its main purpose is
to provide a common code base for development and a channel to push new
driver code out into the community.
I am still waiting on IT to set up the new server machine. I will post
an announcement once the server is up and running.
Cheers,
Wolfgang
Leonid wrote:
> Hi:
>
> I have several boards with different architectures (Microblaze, PPC),
> running Linux/uClinux and using Xilinx IP cores. I use both Virtex and
> Spartan FPGAs.
>
> Historically I'm using different kernels for them, starting from uClinux
> 2.4, all way through Linux 2.6.16 and 2.6.19. I patched them here and
> there to get working.
>
> I certainly feel a need to move to some standard kernel tree.
>
> I understand that you guys are in some advanced steps of integrating
> Xilinx into Linux. What would be my best choice of Linux kernel now?
>
> I see the following options:
>
> - download some GIT tree your are using (which one?).
> - get latest tree from kernel.org and patch it using your patches (where
> I can get them?).
> - ??
>
> Please advise,
>
> Thanks,
>
> Leonid.
>
^ permalink raw reply
* [PATCH 3/3] Improve robustness of the UIC cascade handler
From: David Gibson @ 2007-08-14 3:52 UTC (permalink / raw)
To: Paul Mackerras, Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070814034811.GA8791@localhost.localdomain>
At present the cascade interrupt handler for the UIC (interrupt
controller on 4xx embedded chips) will misbehave badly if it is called
spuriously - that is if the handler is invoked when no interrupts are
asserted in the child UIC.
Although spurious interrupts shouldn't happen, it's good to behave
robustly if they do. This patch does so by checking for and ignoring
spurious interrupts.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/sysdev/uic.c | 3 +++
1 file changed, 3 insertions(+)
Index: working-2.6/arch/powerpc/sysdev/uic.c
===================================================================
--- working-2.6.orig/arch/powerpc/sysdev/uic.c 2007-08-14 13:46:02.000000000 +1000
+++ working-2.6/arch/powerpc/sysdev/uic.c 2007-08-14 13:46:02.000000000 +1000
@@ -266,6 +266,9 @@ irqreturn_t uic_cascade(int virq, void *
int subvirq;
msr = mfdcr(uic->dcrbase + UIC_MSR);
+ if (!msr) /* spurious interrupt */
+ return IRQ_HANDLED;
+
src = 32 - ffs(msr);
subvirq = irq_linear_revmap(uic->irqhost, src);
^ permalink raw reply
* [PATCH 1/3] Fix setting of irq trigger type in UIC driver
From: David Gibson @ 2007-08-14 3:52 UTC (permalink / raw)
To: Paul Mackerras, Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070814034811.GA8791@localhost.localdomain>
The UIC (interrupt controller in 4xx embedded CPUs) driver currently
missets the IRQ_lEVEL flag in desc->status, due to a thinko. This
patch fixes the bug.
Currently this is only a cosmetic problem (affects the output in
/proc/interrupts), however subsequent patches will use the IRQ_LEVEL
flag to affect flow handling.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/sysdev/uic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: working-2.6/arch/powerpc/sysdev/uic.c
===================================================================
--- working-2.6.orig/arch/powerpc/sysdev/uic.c 2007-08-14 13:17:44.000000000 +1000
+++ working-2.6/arch/powerpc/sysdev/uic.c 2007-08-14 13:17:52.000000000 +1000
@@ -142,7 +142,7 @@ static int uic_set_irq_type(unsigned int
desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
- if (trigger)
+ if (!trigger)
desc->status |= IRQ_LEVEL;
spin_unlock_irqrestore(&uic->lock, flags);
^ permalink raw reply
* [PATCH 2/3] Fix irq flow handler for 4xx UIC
From: David Gibson @ 2007-08-14 3:52 UTC (permalink / raw)
To: Paul Mackerras, Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070814034811.GA8791@localhost.localdomain>
At present the driver for the UIC (the embedded interrupt controller
in 4xx chips) uses the handle_level_irq() flow handler. It turns out
this does not correctly handle level triggered interrupts on the UIC.
Specifically, acknowledging an irq on the UIC (i.e. clearing the
relevant bit in UIC_SR) will have no effect for a level interrupt
which is still asserted by the external device, even if the irq is
already masked. Therefore, unlike handle_level_irq() we must ack the
interrupt after invoking the ISR (which should cause the device to
stop asserting the irq) instead of acking it when we mask it, before
the ISR.
This patch implements this change, in a new handle_uic_irq(), a
customised irq flow handler for the UIC. For edge triggered
interrupts, handle_uic_irq() still uses the old flow - we must ack
edge triggered interrupt before the ISR not after, or we could miss a
second event which occurred between invoking the ISR and acking the
irq.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/sysdev/uic.c | 61 +++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 60 insertions(+), 1 deletion(-)
Index: working-2.6/arch/powerpc/sysdev/uic.c
===================================================================
--- working-2.6.orig/arch/powerpc/sysdev/uic.c 2007-08-14 13:17:52.000000000 +1000
+++ working-2.6/arch/powerpc/sysdev/uic.c 2007-08-14 13:17:57.000000000 +1000
@@ -24,6 +24,7 @@
#include <linux/spinlock.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
+#include <linux/kernel_stat.h>
#include <asm/irq.h>
#include <asm/io.h>
#include <asm/prom.h>
@@ -159,6 +160,64 @@ static struct irq_chip uic_irq_chip = {
.set_type = uic_set_irq_type,
};
+/**
+ * handle_uic_irq - irq flow handler for UIC
+ * @irq: the interrupt number
+ * @desc: the interrupt description structure for this irq
+ *
+ * This is modified version of the generic handle_level_irq() suitable
+ * for the UIC. On the UIC, acking (i.e. clearing the SR bit) a level
+ * irq will have no effect if the interrupt is still asserted by the
+ * device, even if the interrupt is already masked. Therefore, unlike
+ * the standard handle_level_irq(), we must ack the interrupt *after*
+ * invoking the ISR (which should have de-asserted the interrupt in
+ * the external source). For edge interrupts we ack at the beginning
+ * instead of the end, to keep the window in which we can miss an
+ * interrupt as small as possible.
+ */
+void fastcall handle_uic_irq(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cpu = smp_processor_id();
+ struct irqaction *action;
+ irqreturn_t action_ret;
+
+ spin_lock(&desc->lock);
+ if (desc->status & IRQ_LEVEL)
+ desc->chip->mask(irq);
+ else
+ desc->chip->mask_ack(irq);
+
+ if (unlikely(desc->status & IRQ_INPROGRESS))
+ goto out_unlock;
+ desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
+ kstat_cpu(cpu).irqs[irq]++;
+
+ /*
+ * If its disabled or no action available
+ * keep it masked and get out of here
+ */
+ action = desc->action;
+ if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+ desc->status |= IRQ_PENDING;
+ goto out_unlock;
+ }
+
+ desc->status |= IRQ_INPROGRESS;
+ desc->status &= ~IRQ_PENDING;
+ spin_unlock(&desc->lock);
+
+ action_ret = handle_IRQ_event(irq, action);
+
+ spin_lock(&desc->lock);
+ desc->status &= ~IRQ_INPROGRESS;
+ if (desc->status & IRQ_LEVEL)
+ desc->chip->ack(irq);
+ if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
+ desc->chip->unmask(irq);
+out_unlock:
+ spin_unlock(&desc->lock);
+}
+
static int uic_host_match(struct irq_host *h, struct device_node *node)
{
struct uic *uic = h->host_data;
@@ -173,7 +232,7 @@ static int uic_host_map(struct irq_host
set_irq_chip_data(virq, uic);
/* Despite the name, handle_level_irq() works for both level
* and edge irqs on UIC. FIXME: check this is correct */
- set_irq_chip_and_handler(virq, &uic_irq_chip, handle_level_irq);
+ set_irq_chip_and_handler(virq, &uic_irq_chip, handle_uic_irq);
/* Set default irq type */
set_irq_type(virq, IRQ_TYPE_NONE);
^ permalink raw reply
* [0/3] UIC fixes
From: David Gibson @ 2007-08-14 3:48 UTC (permalink / raw)
To: Paul Mackerras, Josh Boyer, Benjamin Herrenschmidt,
Valentine Barshak, linuxppc-dev
This series fixes several small problems with the driver for the UIC
interrupt controller found in PowerPC 4xx embedded CPUs.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Joe Hamman @ 2007-08-14 3:29 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-embedded
In-Reply-To: <3FE16C0A-892F-4481-999A-A699C0C70BF9@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Monday, August 13, 2007 10:10 PM
> To: joe.hamman@embeddedspecialties.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
> configurable
>
>
> On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
>
> > Allow the address of the Ten Bit Interface (TBI) to be changed in the
> > event of a conflict with another device.
> >
> > Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
> > ---
> >
> > Please ignore the last patch - I missed a cut & paste error on the
> > range
> > that my testing didn't catch.
>
> I think we'd rather this came from the device tree.
>
Duh, that makes sense ;-)
Has there been any discussion yet? Maybe something like this:
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&mpic>;
interrupts = <a 1>;
reg = <0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <a 1>;
reg = <1>;
device_type = "ethernet-phy";
};
phy2: ethernet-phy@2 {
interrupt-parent = <&mpic>;
interrupts = <a 1>;
reg = <2>;
device_type = "ethernet-phy";
};
phy3: ethernet-phy@3 {
interrupt-parent = <&mpic>;
interrupts = <a 1>;
reg = <3>;
device_type = "ethernet-phy";
};
tbi: ethernet-tbi@1f {
reg = <1f>;
device_type = "ethernet-tbi";
};
};
Thanks,
Joe
^ permalink raw reply
* Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Kumar Gala @ 2007-08-14 3:09 UTC (permalink / raw)
To: joe.hamman; +Cc: linuxppc-embedded
In-Reply-To: <1187044669.10295.4.camel@server>
On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
> Allow the address of the Ten Bit Interface (TBI) to be changed in the
> event of a conflict with another device.
>
> Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
> ---
>
> Please ignore the last patch - I missed a cut & paste error on the
> range
> that my testing didn't catch.
I think we'd rather this came from the device tree.
- k
^ permalink raw reply
* Best Linux tree for Xilinx support.
From: Leonid @ 2007-08-14 2:47 UTC (permalink / raw)
To: Grant Likely, Wolfgang Reissnegger; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708102137o25b83daar82a40471756a3f2b@mail.gmail.com>
Hi:
I have several boards with different architectures (Microblaze, PPC),
running Linux/uClinux and using Xilinx IP cores. I use both Virtex and
Spartan FPGAs.
Historically I'm using different kernels for them, starting from uClinux
2.4, all way through Linux 2.6.16 and 2.6.19. I patched them here and
there to get working.
I certainly feel a need to move to some standard kernel tree.
I understand that you guys are in some advanced steps of integrating
Xilinx into Linux. What would be my best choice of Linux kernel now?
I see the following options:
- download some GIT tree your are using (which one?).
- get latest tree from kernel.org and patch it using your patches (where
I can get them?).
- ??
Please advise,
Thanks,
Leonid.
^ permalink raw reply
* Bestcomm Firmware update
From: Frank Bennett @ 2007-08-14 2:10 UTC (permalink / raw)
To: linuxppc-embedded, jonsmirl
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]
I wrote the disassembler below but never was able to get MPC5200/I2S
DMA running. Hope you can further BestComm code....
Copy of Posting 3/30/2006:
BestComm Dudes:
I was able to contact Davide Santo, AN2604 "Introduction to BestComm".
He admitted the short commings of his document in the area of Firmware
instruction info and gave me a name of a guy, Ed.Nuckolls@freescale.com
in the ASIC design area in Austin. Ed has agreed to answer questions,
push for resources to provide a support tool and provided me with a
document from their head programmer "SmartDMA Hand-Assembly Guides" (see
attached pdf).
With this secret decoded ring I was able to put together a disassembler,
see attached disasm.c. Cut and paste your favorite Task into fw[] array
at the beginning, "cc -o d disasm.c ; d" It's not perfect, but useful-
Enjoy.
If we can formulate a list of questions Ed might be able to help, I'll
start:
o what does init=31 mean?
AN2604 say init=0 means always requestor and 31 is reserved but
referenced alot in the F/W comments
o Need more info on how MORE works
o Tell us about LCD levels. Only 2? (let's call a LCD indent a level)
LCD seems to reset DRD to 1A. DRD2B1or2 follow a DRD2A (ext=1)?
o LCD[28:23]orLCD[20:15] or LCD[11:6] what is extraN?
drop 101nnn - extraN
add 1nnnnn - indexN
o how many DRD2B1[2] can be stacked up?
o when is/can a LDC Literal used? and how?
Frank Bennett
[-- Attachment #2: disasm.c --]
[-- Type: text/x-c, Size: 11341 bytes --]
/*
* disasm.c - disassembler for MPC5200 Bestcomm DMA Firmware
* copy and paste task code into fw, compile a run
* by Frank bennett, 3/29/2006
*
* Based on Freescale pdf "SmartDMA Hand-Assembly Guides"
*
* TODO:
* o add inc[0:7] array (maybe var) to deternmine proper term condition (upper 3 bits)
* o need to review sheet 3 of the pdf
* o simulator would be nice
*
*/
// Task12 (TASK_GEN_TX_BD) : Start of TDT -> 0xf0008528
// linuxppc_2_4_devel/arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos1/"dma_image.reloc.c
//
// 31,30,29,28|27,26,25,24|23,22,21,20|19,18,17,16|15,14,13,12|11,10, 9, 8| 7, 6, 5, 4| 3, 2, 1, 0
// 0 0 0 1 0 0| 0 0 0 0 0| 0 0| 0 0| 0| 0 0 0 1 0 0| 1| 1 0 0 0 0 1| 0 0 0
// 0x10001308, /* 000C DRD1A: var4 = idx1; FN=0 MORE init=0 WS=0 RS=2 */
// 1 0 0| 1 1 0 0 1 0| 0| 0| 1 1 0 0 1 0| 0 0| 0| 0 0 0 0 0 0| 1 1 0| 1 1 0
// 0x99190036, /* 002C LCD: idx2 = idx2; idx2 once var0; idx2 += inc6 */
// 31,30,29,28|27,26,25,24|23,22,21,20|19,18,17,16|15,14,13,12|11,10, 9, 8| 7, 6, 5, 4| 3, 2, 1, 0
// 1 0| 0 1 1 0, 0 1 0 1, 1 0 0, 0 0 1| 1 0| 1 0 0 1 0 0 0 0 1 0 0 0 0
// 0x9950d210
/* Task12(TASK_GEN_TX_BD): Start of TDT -> 0xf0008528 */
unsigned long fw[] = {
0x800220e3, /* 0000 LCD: idx0 = var0, idx1 = var4; idx1 <= var3; idx0 += inc4, idx1 += inc3 */
0x13e01010, /* 0004 DRD1A: var4 = var2; FN=0 MORE init=24 WS=0 RS=0 */
0xb8808264, /* 0008 LCD: idx2 = *idx1, idx3 = var1; idx2 < var9; idx2 += inc4, idx3 += inc4 */
0x10001308, /* 000C DRD1A: var4 = idx1; FN=0 MORE init=0 WS=0 RS=2 */
0x60140002, /* 0010 DRD2A: EU0=0 EU1=0 EU2=0 EU3=2 EXT init=0 WS=2 RS=2 */
0x0cccfcca, /* 0014 DRD2B1: *idx3 = EU3(); EU3(*idx3,var10) */
0xd9190300, /* 0018 LCDEXT: idx2 = idx2; idx2 > var12; idx2 += inc0 */
0xb8c5e009, /* 001C LCD: idx3 = *(idx1 + var00000015); ; idx3 += inc1 */
0x03fec398, /* 0020 DRD1A: *idx0 = *idx3; FN=0 init=24 WS=3 RS=2 */
0x9919826a, /* 0024 LCD: idx2 = idx2, idx3 = idx3; idx2 > var9; idx2 += inc5, idx3 += inc2 */
0x0feac398, /* 0028 DRD1A: *idx0 = *idx3; FN=0 TFD INT init=24 WS=1 RS=2 */
0x99190036, /* 002C LCD: idx2 = idx2; idx2 once var0; idx2 += inc6 */
0x60000005, /* 0030 DRD2A: EU0=0 EU1=0 EU2=0 EU3=5 EXT init=0 WS=0 RS=0 */
0x0c4cf889, /* 0034 DRD2B1: *idx1 = EU3(); EU3(idx2,var9) */
0x000001f8, /* 0038 NOP */
0x9950d210,
0x2c4cf889,
0
};
union
{
unsigned long i;
struct
{
unsigned sb:3; // [02:00] increment #2
unsigned sa:3; // [05:03] increment #1
unsigned tc:6; // [11:06] variable to which idx is compared
unsigned drtc:1; // [12] dr ? *(tc) : (tc)
unsigned tu:2; // [14:13] term usage 00-idx_a, 01-idx_b, 10- lit init 11-no cond
unsigned ib:6; // [20:15] init_b
unsigned drib:1; // [21] dr ? *(init_a) : (init_a)
unsigned p:1; // [22] indx plus offset
unsigned ia:6; // [28:23] init_a
unsigned dria:1; // [29] dr ? *(init_a) : (init_a)
unsigned ext:1; // [30] = 2 or 3 for LCD
unsigned op:1; // [31] = 2 or 3 for LCD
} lcd;
struct
{
unsigned ll:13; // [12:00] literal init low
unsigned tu:2; // [14:13] term usage == 2
unsigned lh:15; // [29:15] literal init hi
unsigned bas:1; // [30] = 2 or 3 for LCD
unsigned op:1; // [31] = 2 or 3 for LCD
} lcdl;
struct
{
unsigned fn:3; // [02:00]
unsigned src:6; // [08:03]
unsigned drs:1; // [09] deref src?
unsigned dst:6; // [15:10]
unsigned drd:1; // [16] deref dst? scal?
unsigned ws:2; // [18:17] 0-32bit, 1-1 byte, 2-16 word, 3-dynamic/reserved??
unsigned rs:2; // [20:19] 0-32bit, 1-1 byte, 2-16 word, 3-dynamic/reserved??
unsigned init:5; // [25:21]
unsigned intr:1; // [26]
unsigned tfd:1; // [27]
unsigned more:1; // [28]
unsigned type:1; // [29]
unsigned ext:1; // [30]
unsigned op:1; // [31] = 0 for DRD
} drd1a;
struct
{
unsigned eu3:4; // [03:00] Execution Unit3 Function number
unsigned eu2:4; // [07:04] Execution Unit3 Function number
unsigned eu1:4; // [11:08] Execution Unit3 Function number
unsigned eu0:4; // [15:12] Execution Unit3 Function number
unsigned drd:1; // [16] deref dst? scal?
unsigned ws:2; // [18:17] 0-32bit, 1-1 byte, 2-16 word, 3-dynamic/reserved??
unsigned rs:2; // [20:19] 0-32bit, 1-1 byte, 2-16 word, 3-dynamic/reserved??
unsigned init:5; // [25:21]
unsigned int:1; // [26]
unsigned tfd:1; // [27]
unsigned more:1; // [28]
unsigned type:1; // [29]
unsigned ext:1; // [30]
unsigned op:1; // [31] = 0 for DRD
} drd2a;
struct
{
unsigned od1:6; // [05:00] EU operand 1
unsigned od0:6; // [11:06] EU operand 0
unsigned eu:2; // [13:12] EU#, only #3 available on MPC5200
unsigned mems:6; // [19:14] memory write source
unsigned drds:1; // [20]
unsigned rsv2:1; // [21]
unsigned memd:6; // [27:22] memory write destination
unsigned rsv1:1; // [28] reserved?
unsigned type:1; // [29]
unsigned ext:1; // [30]
unsigned op:1; // [31] = 0 for DRD
} drd2b1;
struct
{
unsigned odb1:6; // [05:00] EUb operand 1/3/5/7
unsigned odb0:6; // [11:06] EUb operand 0/2/4/6
unsigned eub:2; // [13:12] EUb#, only #3 available on MPC5200
unsigned oda1:6; // [19:14] EUa operand 1/3/5/7
unsigned oda0:6; // [25:20] EUa operand 0/2/4/6
unsigned eua:2; // [27:26] EUa#, only #3 available on MPC5200
unsigned rsv1:1; // [28]
unsigned type:1; // [29]
unsigned ext:1; // [30]
unsigned op:1; // [31] = 0 for DRD
} drd2b2;
} x;
// Condition codes (first 4 bits of the increments)
// >= c
// > 4
// once 0
// != 6
// <= a
// < 2
char *ft[] = {
"ld_acc", "unld_acc", "and", "or", "xor" "andn", "not",
"add", "sub", "lsh", "rsh", "crc8", "crc16", "crc32",
"endian32", "endian16"
};
char s[8];
indvar (int i)
{
switch ((i & 0x3f) >> 4)
{
case 0:
sprintf (s, "var%d", i & 0x1f); // varN
break;
case 1:
sprintf (s, "inc%d", i & 0x07); // incN
break;
case 2: // extraN
case 3:
sprintf (s, "idx%d", i & 0x0f); // idxN
break;
}
}
#define L2 LLev*2
main ()
{
int i, j, LLev = 0, drdt, ex = 0, ml;
char in[12];
for (i = 0; fw[i]; i++)
{
x.i = fw[i];
if (x.i == 0x1f8)
printf ("0x%08x, // NOP\n", x.i);
else if (x.lcd.op) // LCD
{
if (LLev == 0)
strcpy (in, "");
else
strcpy (in, " ");
if (x.lcd.ext) // LCDEXT
{
indvar (x.lcd.tc);
printf
("0x%08x, // %sLCDEXT: idx%d=idx%d; idx%d >%s%s ; idx%d += inc%d\n",
x.i, in, L2, L2, L2, x.lcd.drtc ? "*" : " ", s, L2,
x.lcd.sb);
} else if (x.lcd.tu == 2) // LCDLIT
{
printf ("0x%08x, // %sLCDLIT: idx%d = 0x%07x ??\n",
x.i, in, L2, (x.lcdl.lh << 13) | x.lcdl.ll);
} else // LCD
{
printf ("0x%08x, // %sLCD: ", x.i, in);
if (x.lcd.p) // indexed p-plus
{
indvar (x.lcd.ia);
printf ("idx%d = %s(%s + ", L2 + 1, x.lcd.dria ? "*" : " ", s);
indvar (x.lcd.ib);
printf ("%s%s); ; ", x.lcd.drib ? "*" : " ", s);
} else
{
indvar (x.lcd.ia);
printf ("idx%d=%s%s, ", L2, x.lcd.dria ? "*" : " ", s);
indvar (x.lcd.ib);
printf ("idx%d=%s%s, ", L2 + 1, x.lcd.drib ? "*" : " ", s);
}
if (x.lcd.tu < 2)
{
indvar (x.lcd.tc);
printf ("idx%d <=%s%s, ", (x.lcd.tu == 0) ? L2 : L2 + 1,
x.lcd.drtc ? "*" : " ", s);
}
if (x.lcd.tu != 3)
printf ("idx%d += inc%01x, ", L2, x.lcd.sa);
printf ("idx%d += inc%01x\n", L2 + 1, x.lcd.sb);
ex = 0;
}
}
else
{
// DRD
if (LLev == 0)
strcpy (in, " ");
else
strcpy (in, " ");
drdt = (ex << 2) | (x.drd1a.ext << 1) | x.drd1a.type;
switch (drdt)
{
case 0: // DRD1A
printf ("0x%08x, // %sDRD1A: ", x.i, in);
indvar (x.drd1a.dst);
printf ("%s%s =", x.drd1a.drd ? "*" : " ", s);
indvar (x.drd1a.src);
printf ("%s%s; ", x.drd1a.drs ? "*" : " ", s);
printf ("FN=%d (%s) ", x.drd1a.fn, ft[x.drd1a.fn]);
if (x.drd1a.more)
printf ("MORE ");
if (x.drd1a.tfd)
printf ("TFD ");
if (x.drd1a.intr)
printf ("INT ");
printf ("init=%d ", x.drd1a.init);
printf ("WS=%d RS=%d \n", x.drd1a.ws, x.drd1a.rs);
break;
case 3: // DRD2A
ex = x.drd2a.ext;
printf ("0x%08x, // %sDRD2A: ", x.i, in);
printf ("EU0=0 EU1=0 EU2=0 EU3=%d (%s) EXT init=%d ",
x.drd2a.eu3, ft[x.drd2a.eu3], x.drd2a.init);
printf ("WS=%d RS=%d \n", x.drd2a.ws, x.drd2a.rs);
break;
case 4: // DRD2B1
printf ("0x%08x, // %sDRD2B1: ", x.i, in);
indvar (x.drd2b1.memd); // mems ??
printf ("*%s=EU%d(); ", s, x.drd2b1.eu);
indvar (x.drd2b1.od0); printf ("EU%d(%s, ", x.drd2b1.eu, s);
indvar (x.drd2b1.od1); printf ("%s) \n", s);
break;
case 5: // DRD2B2
case 7: // DRD2B2?
printf ("0x%08x, // %sDRD2B2: ", x.i, in);
indvar (x.drd2b2.oda0); printf ("EU%d(%s, ", x.drd2b2.eub, s);
indvar (x.drd2b2.oda1); printf ("%s) , ", s);
indvar (x.drd2b2.odb0); printf ("EU%d(%s, ", x.drd2b2.eua, s);
indvar (x.drd2b2.odb1); printf ("%s) ??\n", s);
break;
case 1:
case 2:
case 6:
printf ("fix_me\n");
ex = x.drd1a.ext;
break;
}
LLev |= 1;
}
}
}
[-- Attachment #3: sdHandAssemblyLcdDrd.pdf --]
[-- Type: application/pdf, Size: 9985 bytes --]
^ permalink raw reply
* Xilinx EMAC driver for Linux in polling mode.
From: Leonid @ 2007-08-14 2:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1187044134.9536.4.camel@server>
Does anyboady have adapter.c file (or any source code) for Linux kernel
driver for Xilinx EMAC IP core, WORKING in POLLING mode? For certain
reasons I cannot use interrupt in my system.
Thanks,
Leonid.=20
^ permalink raw reply
* Re: [ PATCH ] PowerPC cascade UIC IRQ handler fix.
From: David Gibson @ 2007-08-14 1:35 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46C04F07.3040909@ru.mvista.com>
On Mon, Aug 13, 2007 at 04:31:03PM +0400, Valentine Barshak wrote:
[snip]
> >> Ok, here's a patch which fixes up the flow handling on the UIC. It
> >> needs some polish yet, but should be ok to test. Valentine, can you
> >> test this on your setup, *without* your original proposed patch.
> >> Eventually, for robustness, we'll want something like your original
> >> patch as well for robustness, but in the meantime leaving it out
> >> should tell us if my patch is actually having the intended effect.
> >
> > Valentine, it would be really helpful if you could test this on the
> > problem you observed with the cascade interrupt. Any word on this?
> >
>
> Thanks David,
> the patch works fine here (without the original one).
Ok, great.
> Don't think we really need a "fastcall" here on a powerpc though.
Oh, yeah, that's just copied from the generic handle_level_irq().
> The original patch also fixes a minor issue with /proc/interrupts
> (the the "if (trigger)" stuff).
> Currently level-triggered interrupts are displayed as edge-triggered
> ones and vice versa.
Yes, we'll still want two patches similar to your original: one to fix
the cosmetic /proc/interrupts problem, the other to make the cascade
handler more robust against spurious interrupts. I just wanted to see
if this flow handler change fixed the basic problem.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* patch powerpc-fix-size-check-for-hugetlbfs.patch queued to -stable tree
From: gregkh @ 2007-08-13 23:26 UTC (permalink / raw)
To: benh, gregkh, linuxppc-dev, paulus; +Cc: stable-commits
In-Reply-To: <1186551855.938.164.camel@localhost.localdomain>
This is a note to let you know that we have just queued up the patch titled
Subject: powerpc: Fix size check for hugetlbfs
to the 2.6.22-stable tree. Its filename is
powerpc-fix-size-check-for-hugetlbfs.patch
A git repo of this tree can be found at
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>From benh@kernel.crashing.org Mon Aug 13 16:17:09 2007
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 08 Aug 2007 15:44:15 +1000
Subject: powerpc: Fix size check for hugetlbfs
To: linuxppc-dev list <linuxppc-dev@ozlabs.org>
Cc: Paul Mackerras <paulus@samba.org>, stable@kernel.org
Message-ID: <1186551855.938.164.camel@localhost.localdomain>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
My "slices" address space management code that was added in 2.6.22
implementation of get_unmapped_area() doesn't properly check that the
size is a multiple of the requested page size. This allows userland to
create VMAs that aren't a multiple of the huge page size with hugetlbfs
(since hugetlbfs entirely relies on get_unmapped_area() to do that
checking) which leads to a kernel BUG() when such areas are torn down.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
--- linux-work.orig/arch/powerpc/mm/slice.c 2007-08-08 15:16:06.000000000 +1000
+++ linux-work/arch/powerpc/mm/slice.c 2007-08-08 15:16:41.000000000 +1000
@@ -405,6 +405,8 @@ unsigned long slice_get_unmapped_area(un
if (len > mm->task_size)
return -ENOMEM;
+ if (len & ((1ul << pshift) - 1))
+ return -EINVAL;
if (fixed && (addr & ((1ul << pshift) - 1)))
return -EINVAL;
if (fixed && addr > (mm->task_size - len))
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
Patches currently in stable-queue which might be from benh@kernel.crashing.org are
queue-2.6.22/ppc-revert-don-t-complain-if-size-cells-0-in-prom_parse.patch
queue-2.6.22/ppc-revert-add-mdio-to-bus-scan-id-list-for-platforms-with-qe-uec.patch
queue-2.6.22/powerpc-fix-size-check-for-hugetlbfs.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox