* Re: [PATCH 0/2] Replace of_device with platform_device
From: Grant Likely @ 2010-06-11 3:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Michal Simek, microblaze-uclinux, linuxppc-dev,
sparclinux, David Miller
In-Reply-To: <1276218990.1962.81.camel@pasglop>
On Thu, Jun 10, 2010 at 7:16 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Thu, 2010-06-10 at 10:46 -0600, Grant Likely wrote:
>>
>> It shouldn't need any fixing because I'm not touching the driver side
>> of the equation (unlike the last breakage where macio_driver had its
>> own copy of the match table which I missed). =A0In fact, there aren't
>> even any logic changes other than dealing with moving some of the
>> structure members in the sparc arch code. =A0If I did miss anything,
>> then it should show up in build testing.
>
> Ok, but I though you were actually replacing occurences of "of_device"
> with "platform_device", and so was wondering why you aren't changing the
> ones in macio. But yes, the #define you did might do the trick as long
> as the resources are still named the same etc...
I will, but it is a big job, so the #define lets me do it in chunks.
I made sure the member names in of_device were identical to
platform_device so that it works as a drop-in.
g.
^ permalink raw reply
* Re: 2.6.35-rc2 : OOPS with LTP memcg regression test run.
From: Sachin Sant @ 2010-06-11 5:39 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Linux/PPC Development, linux-mm, linux-kernel, maciej.rutecki
In-Reply-To: <20100611103509.520671b2.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki wrote:
> On Thu, 10 Jun 2010 22:00:57 +0200
> Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
>
>
>> I created a Bugzilla entry at
>> https://bugzilla.kernel.org/show_bug.cgi?id=16178
>> for your bug report, please add your address to the CC list in there, thanks!
>>
>>
>
> Hmm... It seems a panic in SLUB or SLAB.
> Is .config available ?
>
I think the root cause for this problem was same as the one
mentioned in this thread (Bug kmalloc-4096 : Poison overwritten)
http://marc.info/?l=linux-kernel&m=127586004308747&w=2 <http://marc.info/?l=linux-kernel&m=127586004308747&w=2>
I verified that the problem goes away after applying the commit 386f40c.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [PATCH 3/5] Removing dead CONFIG_SMP_750
From: Benjamin Herrenschmidt @ 2010-06-11 6:41 UTC (permalink / raw)
To: Christoph Egger; +Cc: Paul Mackerras, vamos, linux-kernel, linuxppc-dev
In-Reply-To: <20100610122311.GA3885@stud.informatik.uni-erlangen.de>
On Thu, 2010-06-10 at 14:23 +0200, Christoph Egger wrote:
> On Thu, Jun 10, 2010 at 04:14:21PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2010-06-09 at 08:35 -0400, Josh Boyer wrote:
> > > On Wed, Jun 09, 2010 at 12:00:21PM +0200, Christoph Egger wrote:
> > > >CONFIG_SMP_750 doesn't exist in Kconfig, therefore removing all
> > > >references for it from the source code.
> > >
> > > Yeah, we don't support SMP on 750 at the moment. This code was carried over
> > > from the arch/ppc days, and that code was present pre-git. I think we can
> > > drop it, but I'll leave that up to Ben. Maybe he has crazy plans for a 750 SMP
> > > board.
> >
> > Nope :-) Though it would be nice to also remove the call sites too and
> > thus remove the macro entirely.
>
> SOmething like below?
Excellent. Thanks. I'll add that to the batch I'm preparing for Linus.
Cheers,
Ben.
> -----
> From: Christoph Egger <siccegge@cs.fau.de>
> Subject: [PATCH 3/5] Removing dead CONFIG_SMP_750
>
> CONFIG_SMP_750 doesn't exist in Kconfig, therefore removing all
> references for it from the source code.
>
> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
>
> diff --git a/arch/powerpc/mm/tlb_hash32.c b/arch/powerpc/mm/tlb_hash32.c
> index 8aaa8b7..09c7820 100644
> --- a/arch/powerpc/mm/tlb_hash32.c
> +++ b/arch/powerpc/mm/tlb_hash32.c
> @@ -94,11 +94,6 @@ void tlb_flush(struct mmu_gather *tlb)
> * the cache operations on the bus. Hence we need to use an IPI
> * to get the other CPU(s) to invalidate their TLBs.
> */
> -#ifdef CONFIG_SMP_750
> -#define FINISH_FLUSH smp_send_tlb_invalidate(0)
> -#else
> -#define FINISH_FLUSH do { } while (0)
> -#endif
>
> static void flush_range(struct mm_struct *mm, unsigned long start,
> unsigned long end)
> @@ -138,7 +133,6 @@ static void flush_range(struct mm_struct *mm, unsigned long start,
> void flush_tlb_kernel_range(unsigned long start, unsigned long end)
> {
> flush_range(&init_mm, start, end);
> - FINISH_FLUSH;
> }
> EXPORT_SYMBOL(flush_tlb_kernel_range);
>
> @@ -162,7 +156,6 @@ void flush_tlb_mm(struct mm_struct *mm)
> */
> for (mp = mm->mmap; mp != NULL; mp = mp->vm_next)
> flush_range(mp->vm_mm, mp->vm_start, mp->vm_end);
> - FINISH_FLUSH;
> }
> EXPORT_SYMBOL(flush_tlb_mm);
>
> @@ -179,7 +172,6 @@ void flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr)
> pmd = pmd_offset(pud_offset(pgd_offset(mm, vmaddr), vmaddr), vmaddr);
> if (!pmd_none(*pmd))
> flush_hash_pages(mm->context.id, vmaddr, pmd_val(*pmd), 1);
> - FINISH_FLUSH;
> }
> EXPORT_SYMBOL(flush_tlb_page);
>
> @@ -192,6 +184,5 @@ void flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
> unsigned long end)
> {
> flush_range(vma->vm_mm, start, end);
> - FINISH_FLUSH;
> }
> EXPORT_SYMBOL(flush_tlb_range);
^ permalink raw reply
* [PATCH] powerpc: rtas_flash needs to use rtas_data_buf
From: Milton Miller @ 2010-06-09 6:01 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100610-reply@mdm.bga.com>
When trying to flash a machine via the update_flash command, Anton received the
following error:
Restarting system.
FLASH: kernel bug...flash list header addr above 4GB
The code in question has a comment that the flash list should be in
the kernel data and therefore under 4GB:
/* NOTE: the "first" block list is a global var with no data
* blocks in the kernel data segment. We do this because
* we want to ensure this block_list addr is under 4GB.
*/
Unfortunately the Kconfig option is marked tristate which means the variable
may not be in the kernel data and could be above 4GB.
Instead of relying on the data segment being below 4GB, use the static
data buffer allocated by the kernel for use by rtas. Since we don't
use the header struct directly anymore, convert it to a simple pointer.
Reported-By: Anton Blanchard <anton@samba.org>
Signed-Off-By: Milton Miller <miltonm@bga.com
---
not even compile tested, but at least code to backup the complaint
--- a/arch/powerpc/kernel/rtas_flash.c.orig 2010-06-11 01:56:26.658583560 +0000
+++ a/arch/powerpc/kernel/rtas_flash.c 2010-06-11 02:43:37.244966477 +0000
@@ -93,12 +93,8 @@ struct flash_block_list {
struct flash_block_list *next;
struct flash_block blocks[FLASH_BLOCKS_PER_NODE];
};
-struct flash_block_list_header { /* just the header of flash_block_list */
- unsigned long num_blocks;
- struct flash_block_list *next;
-};
-static struct flash_block_list_header rtas_firmware_flash_list = {0, NULL};
+static struct flash_block_list *rtas_firmware_flash_list;
/* Use slab cache to guarantee 4k alignment */
static struct kmem_cache *flash_block_cache = NULL;
@@ -107,13 +103,14 @@ static struct kmem_cache *flash_block_ca
/* Local copy of the flash block list.
* We only allow one open of the flash proc file and create this
- * list as we go. This list will be put in the
- * rtas_firmware_flash_list var once it is fully read.
+ * list as we go. The rtas_firmware_flash_list varable will be
+ * set once the data is fully read.
*
* For convenience as we build the list we use virtual addrs,
* we do not fill in the version number, and the length field
* is treated as the number of entries currently in the block
- * (i.e. not a byte count). This is all fixed on release.
+ * (i.e. not a byte count). This is all fixed when calling
+ * the flash routine.
*/
/* Status int must be first member of struct */
@@ -200,16 +197,16 @@ static int rtas_flash_release(struct ino
if (uf->flist) {
/* File was opened in write mode for a new flash attempt */
/* Clear saved list */
- if (rtas_firmware_flash_list.next) {
- free_flash_list(rtas_firmware_flash_list.next);
- rtas_firmware_flash_list.next = NULL;
+ if (rtas_firmware_flash_list) {
+ free_flash_list(rtas_firmware_flash_list);
+ rtas_firmware_flash_list = NULL;
}
if (uf->status != FLASH_AUTH)
uf->status = flash_list_valid(uf->flist);
if (uf->status == FLASH_IMG_READY)
- rtas_firmware_flash_list.next = uf->flist;
+ rtas_firmware_flash_list = uf->flist;
else
free_flash_list(uf->flist);
@@ -592,7 +589,7 @@ static void rtas_flash_firmware(int rebo
unsigned long rtas_block_list;
int i, status, update_token;
- if (rtas_firmware_flash_list.next == NULL)
+ if (rtas_firmware_flash_list == NULL)
return; /* nothing to do */
if (reboot_type != SYS_RESTART) {
@@ -609,20 +606,25 @@ static void rtas_flash_firmware(int rebo
return;
}
- /* NOTE: the "first" block list is a global var with no data
- * blocks in the kernel data segment. We do this because
- * we want to ensure this block_list addr is under 4GB.
+ /*
+ * NOTE: the "first" block must be under 4GB, so we create
+ * an entry with no data blocks in the reserved buffer in
+ * the kernel data segment.
*/
- rtas_firmware_flash_list.num_blocks = 0;
- flist = (struct flash_block_list *)&rtas_firmware_flash_list;
+ spin_lock(&rtas_data_buf_lock);
+ flist = (struct rtas_flash_list *)&rtas_data_buf[0];
+ flist.num_blocks = 0;
+ flist.next = rtas_firmware_flash_list;
rtas_block_list = virt_to_abs(flist);
if (rtas_block_list >= 4UL*1024*1024*1024) {
printk(KERN_ALERT "FLASH: kernel bug...flash list header addr above 4GB\n");
+ spin_unlock(&rtas_data_buf_lock);
return;
}
printk(KERN_ALERT "FLASH: preparing saved firmware image for flash\n");
/* Update the block_list in place. */
+ rtas_firmware_flash_list = NULL; /* too hard to backout on error */
image_size = 0;
for (f = flist; f; f = next) {
/* Translate data addrs to absolute */
@@ -663,6 +665,7 @@ static void rtas_flash_firmware(int rebo
printk(KERN_ALERT "FLASH: unknown flash return code %d\n", status);
break;
}
+ spin_unlock(&rtas_data_buf_lock);
}
static void remove_flash_pde(struct proc_dir_entry *dp)
^ permalink raw reply
* Re: [PATCH] powerpc: rtas_flash cannot be a module
From: Milton Miller @ 2010-06-09 6:01 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100609060110.GM28295@kryten>
On Wed, 9 Jun 2010 at about 16:01:10 +1000 Anton Blanchard wrote:
>
> When trying to flash a machine via the update_flash command, I received the
> following error:
>
>
> Restarting system.
> FLASH: kernel bug...flash list header addr above 4GB
>
>
> The code in question has a comment that the flash list should be in
> the kernel data and therefore under 4GB:
>
> /* NOTE: the "first" block list is a global var with no data
> * blocks in the kernel data segment. We do this because
> * we want to ensure this block_list addr is under 4GB.
> */
>
> Unfortunately the Kconfig option is marked tristate which means the variable
> may not be in the kernel data and could be above 4GB.
So we should use that rtas_data_buf with its lock ...
Oh look, the driver already uses that buffer for the call to verify_flash
untested patch to follow
milton
^ permalink raw reply
* Re: PCIe bus seems work while 'dma' can't under linux
From: Benjamin Herrenschmidt @ 2010-06-11 7:21 UTC (permalink / raw)
To: jxnuxdy
Cc: linuxppc-dev, Michal Simek, devicetree-discuss,
microblaze-uclinux, Stephen Rothwell
In-Reply-To: <c3ef46.1e4c.12924a10776.Coremail.jxnuxdy@163.com>
On Fri, 2010-06-11 at 09:30 +0800, jxnuxdy wrote:
> Hi guys,
>
> I encountered a PCIe problem under linux, the two PCIe bus on my board seems work,
> at least I can access the registers through the PCIe bus, however the dma for the
> PCIe bus can't work, so I just dumped the pci device, but I am curiously to find
> there is no regions displayed on PCIe controlers, why? is it relate with my 'dma' issue then?
It would help if you told us a bit more what the HW is, what you are
doing with it, etc...
IE. What is your host, what is your device, what platform, etc...
DMA should work provided that your platform code sets it up properly.
The DMA regions don't appear in /proc/pci or lspci.
Cheers,
Ben.
>
> bash-2.04# cat /proc/pci
> PCI devices found:
> Bus 0, device 0, function 0:
> Class 0b20 Header Type 01: PCI device 1957:0032 (rev 17).
> Bus 1, device 0, function 0:
> Class 0580 Header Type 00: PCI device 11ab:db90 (rev 1).
> Prefetchable 64 bit memory at 0x80000000 [0x800fffff].
> Prefetchable 64 bit memory at 0x84000000 [0x87ffffff].
> Bus 9, device 0, function 0:
> Class 0b20 Header Type 01: PCI device 1957:0032 (rev 17).
> Bus 10, device 0, function 0:
> Class 0580 Header Type 00: PCI device 11ab:db90 (rev 1).
> Prefetchable 64 bit memory at 0xa0000000 [0xa00fffff].
> Prefetchable 64 bit memory at 0xa4000000 [0xa7ffffff].
> bash-2.04# lspci -vv
> 00:00.0 Power PC: Unknown device 1957:0032 (rev 11)
> !!! Invalid class 0b20 for header type 01
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0, cache line size 08
> Bus: primary=00, secondary=01, subordinate=06, sec-latency=0
> I/O behind bridge: 00000000-00000fff
> Memory behind bridge: 80000000-9fffffff
> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [4c] #10 [0041]
>
> 01:00.0 Memory controller: Galileo Technology Ltd.: Unknown device db90 (rev 01)
> Subsystem: Galileo Technology Ltd.: Unknown device 11ab
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0, cache line size 08
> Interrupt: pin A routed to IRQ 0
> Region 0: Memory at 80000000 (64-bit, prefetchable) [size=1M]
> Region 2: Memory at 84000000 (64-bit, prefetchable) [size=64M]
> Capabilities: [40] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
> Address: 0000000000000000 Data: 0000
> Capabilities: [60] #10 [0011]
>
> 09:00.0 Power PC: Unknown device 1957:0032 (rev 11)
> !!! Invalid class 0b20 for header type 01
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0, cache line size 08
> Bus: primary=00, secondary=0a, subordinate=0f, sec-latency=0
> I/O behind bridge: 00000000-00000fff
> Memory behind bridge: a0000000-bfffffff
> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [4c] #10 [0041]
>
> 0a:00.0 Memory controller: Galileo Technology Ltd.: Unknown device db90 (rev 01)
> Subsystem: Galileo Technology Ltd.: Unknown device 11ab
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0, cache line size 08
> Interrupt: pin A routed to IRQ 0
> Region 0: Memory at a0000000 (64-bit, prefetchable) [size=1M]
> Region 2: Memory at a4000000 (64-bit, prefetchable) [size=64M]
> Capabilities: [40] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
> Address: 0000000000000000 Data: 0000
> Capabilities: [60] #10 [0011]
>
> bash-2.04#
>
> Thanks
> Denny
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Mac Mini suspend issues - misidentified model
From: Benjamin Herrenschmidt @ 2010-06-11 7:24 UTC (permalink / raw)
To: Mark Crichton; +Cc: linuxppc-dev
In-Reply-To: <4C10EDA2.2080303@gmail.com>
On Thu, 2010-06-10 at 09:50 -0400, Mark Crichton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've dug up and revived my old Mac Mini (PPC) and been trying to get it
> to work again. I was looking at getting the system to suspend to ram,
> but it didn't seem to be working. So, I tried to trace down the problem.
Well, for one, we never got the code to resume the on board video card
on it right... I have ways to sort it out and an old Mac mini here so I
suppose I could give it a go but I really don't have the time to do so
at the moment.
Basically, we need to run the MacOS ATI driver for it within the shell
of my "ndrver" utility to generate a trace of all the accesses it
performs to the chip to suspend and resume it, and use that to improve
the support in radeonfb for it.
> I took a look at the kernel code, and I think I may have found the
> issue. According to /proc/cpuinfo, my model is a "PowerMac10,2". Looking
> at platforms/powermac/feature.c, I only see an entry for "PowerMac10,1".
> - From my understanding of the code, this means my machine doesn't get
> PMAC_MB_MAY_SLEEP set, hence no suspend to ram.
Indeed, it looks like I never encountered a 10,2 before. Can you send me
a tarball of /proc/device-tree so I can compare it to see if there's any
other interesting difference ?
> I can easily get a patch together to just copy the PowerMac10,1 entry in
> pmac_mb_defs, for the PowerMac10,2, but I also was wondering if there's
> some issues I may run into. However, from what I see in the code, this
> seems to be a pretty risk-free operation.
>
> Am I on the right track for this one?
You are on the right track but at the very beginning of it :-)
Cheers,
Ben.
> Thanks,
> Mark Crichton
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkwQ7aIACgkQOfj2Ja/u/oBxYACeOX5jUQOJ5XloojtoZJXneZL/
> 734An1mP41QPuLg/RtVllmgQjgdBxdBJ
> =LLH3
> -----END PGP SIGNATURE-----
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 0/5] Removing dead code
From: Reinhard Tartler @ 2010-06-11 7:26 UTC (permalink / raw)
To: Joe Perches
Cc: Robert P. J. Day, vamos, Christoph Egger, linux-kernel,
linuxppc-dev
In-Reply-To: <1276195612.1556.279.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
> (cc's trimmed and rpjday added)
>
> On Wed, 2010-06-09 at 11:58 +0200, Christoph Egger wrote:
>> I've been running a check on the arch/powerpc sourcetree for
>> config Items not defined in Kconfig and found5 such chases.
>
> Are you aware of
> http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup_scripts
Yes, we are. These scripts aim at a very similar goal. However, we are
using a more sound approach that actually involves parsing CPP
statements and the kconfig language and checking the resulting
constraints with SAT solving tools. This way, we get way more precise
results.
You can read about our approach in [1].
[1] http://portal.acm.org/citation.cfm?id=1629732
--
Reinhard Tartler Department of Computer Science IV
Martensstr 1, 91058 Erlangen Germany, University of Erlangen-Nuremberg
http://www4.informatik.uni-erlangen.de/~tartler
^ permalink raw reply
* [PATCH V5] powerpc/mpc512x: Add gpio driver
From: Anatolij Gustschin @ 2010-06-11 8:35 UTC (permalink / raw)
To: linuxppc-dev
Cc: Anatolij Gustschin, Wolfgang Denk, Detlev Zundel, Matthias Fuchs
In-Reply-To: <AANLkTik7pTXHdY9_sjL9Lyz68gk2qRUs0NaGpj_7nL7K@mail.gmail.com>
From: Matthias Fuchs <matthias.fuchs@esd.eu>
This patch adds a gpio driver for MPC512X PowerPCs.
It has been tested on our CAN-CBX-CPU5201 module that
uses a MPC5121 CPU. This platform comes with a couple of
LEDs and configuration switches that have been used for testing.
After change to the of-gpio api the reworked driver has been
tested on pdm360ng board with some configuration switches.
Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
Please consider this patch for inclusion in 2.6.36. Thanks!
v4 -> v5:
- reworked after change to the of-gpio api,
tested on top of the next-devicetree branch.
arch/powerpc/platforms/512x/Kconfig | 9 +
arch/powerpc/platforms/512x/Makefile | 1 +
arch/powerpc/platforms/512x/mpc512x.h | 3 +
arch/powerpc/platforms/512x/mpc512x_gpio.c | 202 ++++++++++++++++++++++++++
arch/powerpc/platforms/512x/mpc512x_shared.c | 3 +
5 files changed, 218 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/512x/mpc512x_gpio.c
diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index 4dac9b0..bd763ee 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -30,3 +30,12 @@ config MPC5121_GENERIC
Compatible boards include: Protonic LVT base boards (ZANMCU
and VICVT2).
+
+config MPC512x_GPIO
+ bool "MPC512x GPIO support"
+ depends on PPC_MPC512x
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here if you're going to use hardware that connects to the
+ MPC512x GPIOs.
diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile
index 90be2f5..12518e3 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -4,3 +4,4 @@
obj-y += clock.o mpc512x_shared.o
obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o mpc5121_ads_cpld.o
obj-$(CONFIG_MPC5121_GENERIC) += mpc5121_generic.o
+obj-$(CONFIG_MPC512x_GPIO) += mpc512x_gpio.o
diff --git a/arch/powerpc/platforms/512x/mpc512x.h b/arch/powerpc/platforms/512x/mpc512x.h
index b2daca0..4a1b094 100644
--- a/arch/powerpc/platforms/512x/mpc512x.h
+++ b/arch/powerpc/platforms/512x/mpc512x.h
@@ -16,4 +16,7 @@ extern void __init mpc512x_init(void);
extern int __init mpc5121_clk_init(void);
void __init mpc512x_declare_of_platform_devices(void);
extern void mpc512x_restart(char *cmd);
+#ifdef CONFIG_MPC512x_GPIO
+extern int mpc512x_add_gpiochips(void);
+#endif
#endif /* __MPC512X_H__ */
diff --git a/arch/powerpc/platforms/512x/mpc512x_gpio.c b/arch/powerpc/platforms/512x/mpc512x_gpio.c
new file mode 100644
index 0000000..346942e
--- /dev/null
+++ b/arch/powerpc/platforms/512x/mpc512x_gpio.c
@@ -0,0 +1,202 @@
+/*
+ * MPC512x gpio driver
+ *
+ * Copyright (c) 2010 Matthias Fuchs <matthias.fuchs@esd.eu>, esd gmbh
+ *
+ * derived from ppc4xx gpio driver
+ *
+ * Copyright (c) 2008 Harris Corporation
+ * Copyright (c) 2008 Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Steve Falco <sfalco@harris.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/spinlock.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/gpio.h>
+#include <linux/types.h>
+
+#define MPC512x_GPIO_MASK(gpio) (0x80000000 >> (gpio))
+
+struct mpc512x_gpio_regs {
+ u32 gpdir;
+ u32 gpodr;
+ u32 gpdat;
+ u32 gpier;
+ u32 gpimr;
+ u32 gpicr1;
+ u32 gpicr2;
+};
+
+struct mpc512x_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadow registers */
+ u32 dat;
+ u32 odr;
+ u32 dir;
+};
+
+/*
+ * GPIO LIB API implementation for GPIOs
+ *
+ * There are a maximum of 32 gpios in each gpio controller.
+ */
+static inline struct mpc512x_chip *
+to_mpc512x_gpiochip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct mpc512x_chip, mm_gc);
+}
+
+static int mpc512x_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+
+ return in_be32(®s->gpdat) & MPC512x_GPIO_MASK(gpio);
+}
+
+static inline void
+__mpc512x_gpio_set(struct of_mm_gpio_chip *mm_gc, unsigned int gpio, int val)
+{
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+
+
+ if (val)
+ chip->dat |= MPC512x_GPIO_MASK(gpio);
+ else
+ chip->dat &= ~MPC512x_GPIO_MASK(gpio);
+
+ out_be32(®s->gpdat, chip->dat);
+}
+
+static void
+mpc512x_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ unsigned long flags;
+
+ spin_lock_irqsave(&chip->lock, flags);
+
+ __mpc512x_gpio_set(mm_gc, gpio, val);
+
+ spin_unlock_irqrestore(&chip->lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+}
+
+static int mpc512x_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+ unsigned long flags;
+
+ spin_lock_irqsave(&chip->lock, flags);
+
+ /* Disable open-drain function */
+ chip->odr &= ~MPC512x_GPIO_MASK(gpio);
+ out_be32(®s->gpodr, chip->odr);
+
+ /* Float the pin */
+ chip->dir &= ~MPC512x_GPIO_MASK(gpio);
+ out_be32(®s->gpdir, chip->dir);
+
+ spin_unlock_irqrestore(&chip->lock, flags);
+
+ return 0;
+}
+
+static int
+mpc512x_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+ unsigned long flags;
+
+ spin_lock_irqsave(&chip->lock, flags);
+
+ /* First set initial value */
+ __mpc512x_gpio_set(mm_gc, gpio, val);
+
+ /* Disable open-drain function */
+ chip->odr &= ~MPC512x_GPIO_MASK(gpio);
+ out_be32(®s->gpodr, chip->odr);
+
+ /* Drive the pin */
+ chip->dir |= MPC512x_GPIO_MASK(gpio);
+ out_be32(®s->gpdir, chip->dir);
+
+ spin_unlock_irqrestore(&chip->lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+
+ return 0;
+}
+
+void __init mpc512x_add_gpiochips(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,mpc5121-gpio") {
+ int ret;
+ struct mpc512x_chip *chip;
+ struct of_mm_gpio_chip *mm_gc;
+ struct gpio_chip *gc;
+ struct mpc512x_gpio_regs __iomem *regs;
+
+ chip = kzalloc(sizeof(*chip), GFP_KERNEL);
+ if (!chip) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ spin_lock_init(&chip->lock);
+
+ mm_gc = &chip->mm_gc;
+ gc = &mm_gc->gc;
+
+ gc->ngpio = 32;
+ gc->direction_input = mpc512x_gpio_dir_in;
+ gc->direction_output = mpc512x_gpio_dir_out;
+ gc->get = mpc512x_gpio_get;
+ gc->set = mpc512x_gpio_set;
+
+ ret = of_mm_gpiochip_add(np, mm_gc);
+ if (ret)
+ goto err;
+
+ regs = mm_gc->regs;
+ chip->dat = in_be32(®s->gpdat);
+ chip->dir = in_be32(®s->gpdir);
+ chip->odr = in_be32(®s->gpodr);
+ continue;
+err:
+ pr_err("%s: registration failed with status %d\n",
+ np->full_name, ret);
+ kfree(chip);
+ /* try others anyway */
+ }
+}
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index 707e572..15da1bc 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -178,4 +178,7 @@ void __init mpc512x_init(void)
mpc5121_clk_init();
mpc512x_restart_init();
mpc512x_psc_fifo_init();
+#ifdef CONFIG_MPC512x_GPIO
+ mpc512x_add_gpiochips();
+#endif
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] gianfar: Fix TX ring processing on SMP machines
From: Esben Haabendal @ 2010-06-11 8:45 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Paul Gortmaker, netdev, Martyn Welch, linuxppc-dev,
Sandeep Gopalpet, David Miller
In-Reply-To: <20100303181858.GA458@oksana.dev.rtsoft.ru>
On Wed, Mar 3, 2010 at 8:18 PM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> Starting with commit a3bc1f11e9b867a4f49505 ("gianfar: Revive SKB
> recycling") gianfar driver sooner or later stops transmitting any
> packets on SMP machines.
>
> start_xmit() prepares new skb for transmitting, generally it does
> three things:
>
> 1. sets up all BDs (marks them ready to send), except the first one.
> 2. stores skb into tx_queue->tx_skbuff so that clean_tx_ring()
> =A0 would cleanup it later.
> 3. sets up the first BD, i.e. marks it ready.
>
> Here is what clean_tx_ring() does:
>
> 1. reads skbs from tx_queue->tx_skbuff
> 2. checks if the *last* BD is ready. If it's still ready [to send]
> =A0 then it it isn't transmitted, so clean_tx_ring() returns.
> =A0 Otherwise it actually cleanups BDs. All is OK.
>
> Now, if there is just one BD, code flow:
>
> - start_xmit(): stores skb into tx_skbuff. Note that the first BD
> =A0(which is also the last one) isn't marked as ready, yet.
> - clean_tx_ring(): sees that skb is not null, *and* its lstatus
> =A0says that it is NOT ready (like if BD was sent), so it cleans
> =A0it up (bad!)
> - start_xmit(): marks BD as ready [to send], but it's too late.
>
> We can fix this simply by reordering lstatus/tx_skbuff writes.
>
> Reported-by: Martyn Welch <martyn.welch@ge.com>
> Bisected-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> Tested-by: Martyn Welch <martyn.welch@ge.com>
> Cc: Sandeep Gopalpet <Sandeep.Kumar@freescale.com>
> Cc: Stable <stable@vger.kernel.org> [2.6.33]
> ---
> =A0drivers/net/gianfar.c | =A0 =A05 ++++-
> =A01 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 8bd3c9f..cccb409 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -2021,7 +2021,6 @@ static int gfar_start_xmit(struct sk_buff *skb, str=
uct net_device *dev)
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0/* setup the TxBD length and buffer pointer for the first =
BD */
> - =A0 =A0 =A0 tx_queue->tx_skbuff[tx_queue->skb_curtx] =3D skb;
> =A0 =A0 =A0 =A0txbdp_start->bufPtr =3D dma_map_single(&priv->ofdev->dev, =
skb->data,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0skb_headlen(skb), DMA_TO_D=
EVICE);
>
> @@ -2053,6 +2052,10 @@ static int gfar_start_xmit(struct sk_buff *skb, st=
ruct net_device *dev)
>
> =A0 =A0 =A0 =A0txbdp_start->lstatus =3D lstatus;
>
> + =A0 =A0 =A0 eieio(); /* force lstatus write before tx_skbuff */
> +
> + =A0 =A0 =A0 tx_queue->tx_skbuff[tx_queue->skb_curtx] =3D skb;
> +
> =A0 =A0 =A0 =A0/* Update the current skb pointer to the next entry we wil=
l use
> =A0 =A0 =A0 =A0 * (wrapping if necessary) */
> =A0 =A0 =A0 =A0tx_queue->skb_curtx =3D (tx_queue->skb_curtx + 1) &
This patch also makes gianfar work stable on mpc8313 with 2.6.33/RT_PREEMPT=
.
WIthout it, I see exactly the same problems as reported by Anton on SMP.
/Esben
--=20
Esben Haabendal, Senior Software Consultant
Dor=E9Development ApS, Ved Stranden 1, 9560 Hadsund, DK-Denmark
Phone: +45 51 92 53 93, E-mail: eha@doredevelopment.dk
WWW: http://www.doredevelopment.dk
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/fsl_soc.c: prepare for addition of mpc5121 USB code
From: Anatolij Gustschin @ 2010-06-11 11:24 UTC (permalink / raw)
To: Grant Likely
Cc: Greg Kroah-Hartman, Wolfgang Denk, Detlev Zundel, linux-usb,
linuxppc-dev, David Brownell
In-Reply-To: <AANLkTim0TVjoVdLZE_QOSi-WPSoisdF7Gv0Y_YF-tajL@mail.gmail.com>
On Wed, 19 May 2010 14:47:47 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, May 6, 2010 at 1:18 PM, Anatolij Gustschin <agust@denx.de> wrote:
> > Hi Grant,
> >
> > On Tue, 27 Apr 2010 10:51:21 -0600
> > Grant Likely <grant.likely@secretlab.ca> wrote:
> >
> >> On Tue, Apr 27, 2010 at 10:11 AM, Anatolij Gustschin <agust@denx.de> w=
rote:
> >> > Factor out common code for registering a FSL EHCI platform
> >> > device into new fsl_usb2_register_device() function. This
> >> > is done to avoid code duplication while adding code for
> >> > instantiating of MPC5121 dual role USB platform devices.
> >> > Then, the subsequent patch can use
> >> > for_each_compatible_node(np, NULL, "fsl,mpc5121-usb2-dr") {
> >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0...
> >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0fsl_usb2_register_device();
> >> > }
> >> >
> >> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
> >> > Cc: Kumar Gala <galak@kernel.crashing.org>
> >> > Cc: Grant Likely <grant.likely@secretlab.ca>
> >> > ---
> >> > =C2=A0arch/powerpc/sysdev/fsl_soc.c | =C2=A0231 +++++++++++++++++++-=
--------------------
> >>
> >> Hi Anatolij,
> >>
> >> Thanks for this work. =C2=A0However, I've got concerns.
> >>
> >> Forgive me for ragging on code that you didn't write, but this
> >> fsl_soc.c code for registering the USB device really doesn't belong
> >> here anymore. =C2=A0It should be part of the drivers/usb/host/ehci-fsl=
.c
> >> and the driver should do of-style binding (Which should be a lot
> >> easier if I manage to get the merge of platform bus and of_platform
> >> bus into 2.6.35).
> >
> > Now I moved the USB devices registration code to
> > drivers/usb/host/ehci-fsl.c and added of-style binding there. It
> > works for one platform driver based on your test-devicetree branch.
> > It seems I can't bind more than one driver to the device described
> > in the tree. But I need to bind at least 2 drivers, ehci-hcd and
> > fsl-usb2-udc. For USB OTG support I need additional one to be bound
> > to the same USB dual role device (also tree different drivers
> > simultaneously).
> > I also can't register UDC device in the ehci-fsl.c since registering
> > of the UDC device should also be possible independent of the EHCI-HDC
> > driver (for USB device support we do not need host controller driver).
> > Is it possible to bind more than one driver to the same device
> > simultaneously? If so, how can I implement this?
>=20
> No, the linux driver model can bind exactly one driver to a struct
> device. However, that doesn't mean you can't have multiple struct
> devices (in whatever form they come) to tell the Linux kernel about
> all the details of a single hardware device.
>=20
> >> This patch series makes the fsl_soc.c code even more complicated, and
> >> scatters what is essentially driver code over even more places in the
> >> arch/powerpc tree. =C2=A0I'm really not keen on it being merged in this
> >> form.
> >
> > Now I see one reason why it has been originally implemented
> > this way.
>=20
> Should be a solvable problem. The fsl_soc.c stuff was originally
> written simply because the infrastructure wasn't there for doing it
> any other way. We're long past that point now. I don't have time to
> dig into the details now (merge window and all), but ping me in a few
> weeks and I'll take another look to see if I can help you.
Hi Grant,
Ping. Do you have any suggestions how to realize this using current
infrastructure? Thanks!
Anatolij
^ permalink raw reply
* [PATCH 1/2] lite5200: add dts descriptions for onboard I2C eeprom and flash
From: Dmitry Eremin-Solenikov @ 2010-06-11 11:52 UTC (permalink / raw)
To: linuxppc-dev
Add dts descriptions for onboard 256 byte I2C eeprom (pcf8582C-2)
and 16MB NOR flash (am29lv652d).
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/dts/lite5200.dts | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index 2b64d8e..da1dafb 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -255,6 +255,12 @@
compatible = "fsl,mpc5200-i2c","fsl-i2c";
reg = <0x3d40 0x40>;
interrupts = <2 16 0>;
+
+ eeprom@50 {
+ compatible = "nxp,pcf8582c", "at24,24c02";
+ reg = <0x50>;
+ };
+
};
sram@8000 {
compatible = "fsl,mpc5200-sram";
@@ -281,4 +287,22 @@
0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
0x01000000 0 0x00000000 0xb0000000 0 0x01000000>;
};
+
+ localbus {
+ compatible = "fsl,mpc5200b-lpb","fsl,mpc5200-lpb","simple-bus";
+
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ ranges = <0 0 0xff000000 0x00000000>;
+
+ flash@0,00000000 {
+ compatible = "amd,am29lv652d", "cfi-flash";
+ reg = <0 0x00000000 0x01000000>;
+ bank-width = <1>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
+ };
+
};
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] mpc52xx: fix oops during going to standby
From: Dmitry Eremin-Solenikov @ 2010-06-11 11:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1276257155-7297-1-git-send-email-dbaryshkov@gmail.com>
When going to standby mode mpc code maps the whole soc5200 node
to access warious MBAR registers. However as of_iomap uses 'reg'
property of device node, only small part of MBAR is getting mapped.
Thus pm code gets oops when trying to access high parts of MBAR.
As a way to overcome this, make mpc52xx_pm_prepare() explicitly
map whole MBAR (0xc0000).
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/52xx/mpc52xx_pm.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pm.c b/arch/powerpc/platforms/52xx/mpc52xx_pm.c
index a55b0b6..7672253 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pm.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pm.c
@@ -64,10 +64,19 @@ int mpc52xx_pm_prepare(void)
{ .type = "builtin", .compatible = "mpc5200", }, /* efika */
{}
};
+ struct resource res;
/* map the whole register space */
np = of_find_matching_node(NULL, immr_ids);
- mbar = of_iomap(np, 0);
+
+ if (of_address_to_resource(np, 0, &res)) {
+ pr_err("mpc52xx_pm_prepare(): could not get IMMR address\n");
+ of_node_put(np);
+ return -ENOSYS;
+ }
+
+ mbar = ioremap(res.start, 0xc000); /* we should map whole region including SRAM */
+
of_node_put(np);
if (!mbar) {
pr_err("mpc52xx_pm_prepare(): could not map registers\n");
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] gianfar: Fix setup of RX time stamping
From: Anton Vorontsov @ 2010-06-11 12:20 UTC (permalink / raw)
To: Manfred Rudigier
Cc: 'netdev@vger.kernel.org', Richard Cochran,
'David Miller', 'linuxppc-dev@ozlabs.org'
In-Reply-To: <95DC1AA8EC908B48939B72CF375AA5E3F03D8C46@alice.at.omicron.at>
On Fri, Jun 11, 2010 at 01:49:05PM +0200, Manfred Rudigier wrote:
> Previously the RCTRL_TS_ENABLE bit was set unconditionally. However, if
> the RCTRL_TS_ENABLE is set without TMR_CTRL[TE], the driver does not work
> properly on some boards (Anton had problems with the MPC8313ERDB and
> MPC8568EMDS).
>
> With this patch the bit will only be set if requested from user space
> with the SIOCSHWTSTAMP ioctl command, meaning that time stamping is
> disabled during normal operation. Users who are not interested in time
> stamps will not experience problems with buggy CPU revisions or
> performance drops any more.
>
> The setting of TMR_CTRL[TE] is still up to the user. This is considered
> safe because users wanting HW timestamps must initialize the eTSEC clock
> first anyway, e.g. with the recently submitted PTP clock driver.
>
> Signed-off-by: Manfred Rudigier <manfred.rudigier@omicron.at>
> ---
Looks OK. I tested that it doesn't break anything, but I didn't
test the timestamping functionality. So
Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] gianfar: Fix setup of RX time stamping
From: Manfred Rudigier @ 2010-06-11 11:49 UTC (permalink / raw)
To: 'David Miller'
Cc: 'netdev@vger.kernel.org', 'Anton Vorontsov',
Richard Cochran, 'linuxppc-dev@ozlabs.org'
Previously the RCTRL_TS_ENABLE bit was set unconditionally. However, if
the RCTRL_TS_ENABLE is set without TMR_CTRL[TE], the driver does not work
properly on some boards (Anton had problems with the MPC8313ERDB and
MPC8568EMDS).
With this patch the bit will only be set if requested from user space
with the SIOCSHWTSTAMP ioctl command, meaning that time stamping is
disabled during normal operation. Users who are not interested in time
stamps will not experience problems with buggy CPU revisions or
performance drops any more.
The setting of TMR_CTRL[TE] is still up to the user. This is considered
safe because users wanting HW timestamps must initialize the eTSEC clock
first anyway, e.g. with the recently submitted PTP clock driver.
Signed-off-by: Manfred Rudigier <manfred.rudigier@omicron.at>
---
drivers/net/gianfar.c | 21 +++++++++++++++++----
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 46c69cd..227b628 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -381,10 +381,14 @@ static void gfar_init_mac(struct net_device *ndev)
/* Insert receive time stamps into padding alignment bytes */
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER) {
rctrl &=3D ~RCTRL_PAL_MASK;
- rctrl |=3D RCTRL_PRSDEP_INIT | RCTRL_TS_ENABLE | RCTRL_PADDING(8);
+ rctrl |=3D RCTRL_PADDING(8);
priv->padding =3D 8;
}
=20
+ /* Enable HW time stamping if requested from user space */
+ if (priv->hwts_rx_en)
+ rctrl |=3D RCTRL_PRSDEP_INIT | RCTRL_TS_ENABLE;
+
/* keep vlan related bits if it's enabled */
if (priv->vlgrp) {
rctrl |=3D RCTRL_VLEX | RCTRL_PRSDEP_INIT;
@@ -747,7 +751,8 @@ static int gfar_of_init(struct of_device *ofdev, struct=
net_device **pdev)
FSL_GIANFAR_DEV_HAS_CSUM |
FSL_GIANFAR_DEV_HAS_VLAN |
FSL_GIANFAR_DEV_HAS_MAGIC_PACKET |
- FSL_GIANFAR_DEV_HAS_EXTENDED_HASH;
+ FSL_GIANFAR_DEV_HAS_EXTENDED_HASH |
+ FSL_GIANFAR_DEV_HAS_TIMER;
=20
ctype =3D of_get_property(np, "phy-connection-type", NULL);
=20
@@ -805,12 +810,20 @@ static int gfar_hwtstamp_ioctl(struct net_device *net=
dev,
=20
switch (config.rx_filter) {
case HWTSTAMP_FILTER_NONE:
- priv->hwts_rx_en =3D 0;
+ if (priv->hwts_rx_en) {
+ stop_gfar(netdev);
+ priv->hwts_rx_en =3D 0;
+ startup_gfar(netdev);
+ }
break;
default:
if (!(priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER))
return -ERANGE;
- priv->hwts_rx_en =3D 1;
+ if (!priv->hwts_rx_en) {
+ stop_gfar(netdev);
+ priv->hwts_rx_en =3D 1;
+ startup_gfar(netdev);
+ }
config.rx_filter =3D HWTSTAMP_FILTER_ALL;
break;
}
--=20
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 5/5] hvc_console: Fix race between hvc_close and hvc_remove
From: Amit Shah @ 2010-06-11 13:37 UTC (permalink / raw)
To: John Kacur
Cc: Stephen Rothwell, Rusty Russell, Clark Williams,
Greg Kroah-Hartman, Arnaldo Carvalho de Melo, linuxppc-dev,
Thomas Gleixner, Luis Claudio R. Goncalves, Alan Cox
In-Reply-To: <186819076.3013051276262029056.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
On (Fri) Jun 11 2010 [09:13:49], John Kacur wrote:
>
> I was just listing patches that Thomas could potentially include
> in the real-time kernel which is currently based on 2.6.33.5
There's a fix to this patch: 320718ee074acce5ffced6506cb51af1388942aa
that you might want to include as well.
Amit
^ permalink raw reply
* powermac G5 fails to power off with 2.6.33.x and newer
From: acrux@cruxppc.org @ 2010-06-11 13:46 UTC (permalink / raw)
To: linuxppc-dev
hi all,
this powermac G5 ( PowerMac7,2 - dual 1.8 pci-x) fails to power off and just
stops there and after a minute or so the fans start to roar. Reboot works
fine.
Here my kernel config:
http://clinker.cruxppc.org/~acrux/config-2.6.33.5-powermacg5
thanks,
Nico
--
View this message in context: http://old.nabble.com/powermac-G5-fails-to-power-off-with-2.6.33.x-and-newer-tp28855378p28855378.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH] GXT400P and GXT6500P support
From: acrux@cruxppc.org @ 2010-06-11 13:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1243903358.591.17.camel@pasglop>
Benjamin Herrenschmidt wrote:
>
> On Mon, 2009-06-01 at 09:32 +0200, Giuseppe Coviello wrote:
>
>>
>> Signed-off-by: Nico Macrionitis <acrux@cruxppc.org>
>> Signed-off-by: Giuseppe Coviello <cjg@cruxppc.org>
>
> As long as you guys have verified that it actually works, I have
> no objection.
>
> Ack.
>
> Cheers,
> Ben.
>
hi Ben,
can i ask why this patch isn't still applied?
thanks.
Nico
--
View this message in context: http://old.nabble.com/Re%3A--Linux-fbdev-devel---PATCH--GXT400P-and-GXT6500P-support-tp23811001p28855179.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: "event-scan failed" logflood
From: acrux@cruxppc.org @ 2010-06-11 13:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1274233162.29980.13.camel@concordia>
Michael Ellerman wrote:
>
> On Tue, 2010-05-18 at 16:30 +0000, nello martuscielli wrote:
>> Michael Ellerman <michael <at> ellerman.id.au> writes:
>>
>> _omissis__
>> > >
>> > > hi, is there available that patch?
>> > > With the fresh new 2.6.34 the logflood problem is still present.
>> >
>> > You could try this, completely untested:
>> >
>> > diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
>> > index 4190eae..fd68bed 100644
>> > --- a/arch/powerpc/kernel/rtasd.c
>> > +++ b/arch/powerpc/kernel/rtasd.c
>> > @@ -490,6 +490,12 @@ static int __init rtas_init(void)
>> > return -ENODEV;
>> > }
>> >
>> > + if (!rtas_event_scan_rate) {
>> > + /* Broken firmware: take a rate of zero to mean don't
>> scan */
>> > + printk(KERN_DEBUG "rtasd: scan rate is 0, not
>> scanning\n");
>> > + return 0;
>> > + }
>> > +
>> > /* Make room for the sequence number */
>> > rtas_error_log_max = rtas_get_error_log_max();
>> > rtas_error_log_buffer_max = rtas_error_log_max + sizeof(int);
>> >
>>
>>
>> hi Michael, thanks for pointing me to that patch, now my Pegasos2 G4
>> seems to
>> work fine.
>
> Great. Can I add Tested-by you?
>
>
hi Michael,
thanks, this patch seems to solve that problem on my Pegasos2 too.
thanks,
Nico
--
View this message in context: http://old.nabble.com/Re%3A-%22event-scan-failed%22-logflood-tp28585064p28855222.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 5/5] hvc_console: Fix race between hvc_close and hvc_remove
From: John Kacur @ 2010-06-11 13:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Rusty Russell, Clark Williams, Greg Kroah-Hartman,
Arnaldo Carvalho de Melo, linuxppc-dev, Amit Shah,
Thomas Gleixner, Luis Claudio R. Goncalves, Alan Cox
In-Reply-To: <1683892268.3009511276260172853.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
----- "Stephen Rothwell" <sfr@canb.auug.org.au> wrote:
> Hi John,
>
> On Thu, 10 Jun 2010 13:03:00 +0200 John Kacur <jkacur@redhat.com>
> wrote:
> >
> > From: Amit Shah <amit.shah@redhat.com>
> >
> > Alan pointed out a race in the code where hvc_remove is invoked.
> The
> > recent virtio_console work is the first user of hvc_remove().
>
> I am not sure where this comes from (linuxppc-dev only got 5/5) but
> this
> patch was applied to Linus' tree quite some time age (and fixed since
> then).
>
Thanks for responding Stephen.
I was just listing patches that Thomas could potentially include
in the real-time kernel which is currently based on 2.6.33.5
I hadn't intended for git-send-email to cc everyone, but it
automatically included authors. sigh. I'll make sure to suppress that
next time.
John
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/fsl_soc.c: prepare for addition of mpc5121 USB code
From: Grant Likely @ 2010-06-11 15:47 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: Greg Kroah-Hartman, Wolfgang Denk, Detlev Zundel, linux-usb,
linuxppc-dev, David Brownell
In-Reply-To: <20100611132443.567daf79@wker>
On Fri, Jun 11, 2010 at 5:24 AM, Anatolij Gustschin <agust@denx.de> wrote:
> On Wed, 19 May 2010 14:47:47 -0600
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> On Thu, May 6, 2010 at 1:18 PM, Anatolij Gustschin <agust@denx.de> wrote=
:
>> > Hi Grant,
>> >
>> > On Tue, 27 Apr 2010 10:51:21 -0600
>> > Grant Likely <grant.likely@secretlab.ca> wrote:
>> >
>> >> On Tue, Apr 27, 2010 at 10:11 AM, Anatolij Gustschin <agust@denx.de> =
wrote:
>> >> > Factor out common code for registering a FSL EHCI platform
>> >> > device into new fsl_usb2_register_device() function. This
>> >> > is done to avoid code duplication while adding code for
>> >> > instantiating of MPC5121 dual role USB platform devices.
>> >> > Then, the subsequent patch can use
>> >> > for_each_compatible_node(np, NULL, "fsl,mpc5121-usb2-dr") {
>> >> > =A0 =A0 =A0 =A0...
>> >> > =A0 =A0 =A0 =A0fsl_usb2_register_device();
>> >> > }
>> >> >
>> >> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
>> >> > Cc: Kumar Gala <galak@kernel.crashing.org>
>> >> > Cc: Grant Likely <grant.likely@secretlab.ca>
>> >> > ---
>> >> > =A0arch/powerpc/sysdev/fsl_soc.c | =A0231 +++++++++++++++++++------=
---------------
>> >>
>> >> Hi Anatolij,
>> >>
>> >> Thanks for this work. =A0However, I've got concerns.
>> >>
>> >> Forgive me for ragging on code that you didn't write, but this
>> >> fsl_soc.c code for registering the USB device really doesn't belong
>> >> here anymore. =A0It should be part of the drivers/usb/host/ehci-fsl.c
>> >> and the driver should do of-style binding (Which should be a lot
>> >> easier if I manage to get the merge of platform bus and of_platform
>> >> bus into 2.6.35).
>> >
>> > Now I moved the USB devices registration code to
>> > drivers/usb/host/ehci-fsl.c and added of-style binding there. It
>> > works for one platform driver based on your test-devicetree branch.
>> > It seems I can't bind more than one driver to the device described
>> > in the tree. But I need to bind at least 2 drivers, ehci-hcd and
>> > fsl-usb2-udc. For USB OTG support I need additional one to be bound
>> > to the same USB dual role device (also tree different drivers
>> > simultaneously).
>> > I also can't register UDC device in the ehci-fsl.c since registering
>> > of the UDC device should also be possible independent of the EHCI-HDC
>> > driver (for USB device support we do not need host controller driver).
>> > Is it possible to bind more than one driver to the same device
>> > simultaneously? If so, how can I implement this?
>>
>> No, the linux driver model can bind exactly one driver to a struct
>> device. =A0However, that doesn't mean you can't have multiple struct
>> devices (in whatever form they come) to tell the Linux kernel about
>> all the details of a single hardware device.
>>
>> >> This patch series makes the fsl_soc.c code even more complicated, and
>> >> scatters what is essentially driver code over even more places in the
>> >> arch/powerpc tree. =A0I'm really not keen on it being merged in this
>> >> form.
>> >
>> > Now I see one reason why it has been originally implemented
>> > this way.
>>
>> Should be a solvable problem. =A0The fsl_soc.c stuff was originally
>> written simply because the infrastructure wasn't there for doing it
>> any other way. =A0We're long past that point now. =A0I don't have time t=
o
>> dig into the details now (merge window and all), but ping me in a few
>> weeks and I'll take another look to see if I can help you.
>
> Hi Grant,
>
> Ping. Do you have any suggestions how to realize this using current
> infrastructure? Thanks!
It sounds like the USB OTG controller is effectively a compound device
with one host controller and one device controller plus some logic to
switch between the two. I'm not a USB expert, so correct me if I'm
wrong here.
You've got 2 choices for implementing this:
A) create a 'master' of_driver which registers 2 platform devices it
it's probe routine.
B) Rework the drivers so that both fsl-ehci and fsl-usb2-udc bits are
called directly (essentially one driver handles both modes)
Option A probably makes the most sense as it has the least amount of
impact on current code. Essentially, you create an of_driver and put
into it's probe hook the code that is currently in fsl_soc.c. Then it
will bind in the normal of_platform_bus_type manner and can register
the appropriate platform devices for each platform.
Some important points though; when you create the platform devices,
make sure you set the parent pointer correctly so the new devices are
registered as children of the of_device.
Second, you can eliminate the call to platform_device_add_data() by
setting the of_node pointer in the platform device (the of_node is now
part of struct device). Make the driver look up its own data from the
device tree instead of passing it in an anonymous data structure.
On that note, the current code looks racy anyway because it registers
the device before attaching the platform_data. It's probably okay
because of how early it is run and no drivers are registered yet, but
it is still wrong. It should be: allocate; add data; then register.
But I digress. Eliminating the platform data makes this problem go
away.
I hope this helps.
g.
^ permalink raw reply
* [PATCH] gianfar: Fix oversized packets handling
From: Anton Vorontsov @ 2010-06-11 20:51 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, Andy Fleming, Sandeep Gopalpet, netdev
Issuing the following command on host:
$ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1
Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0)
oops like this:
skb_over_panic: text:c0195914 len:1537 put:1537 head:c79e4800 data:c79e4880 tail:0xc79e4e81 end:0xc79e4e80 dev:eth1
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:127!
Oops: Exception in kernel mode, sig: 5 [#1]
MPC831x RDB
last sysfs file: /sys/kernel/uevent_seqnum
Modules linked in:
NIP: c01c1840 LR: c01c1840 CTR: c016d918
[...]
NIP [c01c1840] skb_over_panic+0x48/0x5c
LR [c01c1840] skb_over_panic+0x48/0x5c
Call Trace:
[c0339d50] [c01c1840] skb_over_panic+0x48/0x5c (unreliable)
[c0339d60] [c01c3020] skb_put+0x5c/0x60
[c0339d70] [c0195914] gfar_clean_rx_ring+0x25c/0x3d0
[c0339dc0] [c01976e8] gfar_poll+0x170/0x1bc
Dumped buffer descriptors showed that eTSEC's length/truncation
logic sometimes passes oversized packets, i.e. for the above ICMP
packet the following two buffer descriptors may become ready:
status=1400 length=1536
status=1800 length=1541
So, it seems that gianfar actually receives the whole big frame,
and it tries to place the packet into two BDs. This situation
confuses the driver, and so the skb_put() sanity check fails.
This patch fixes the issue by adding an appropriate check, i.e.
the driver should not try to process frames with buffer
descriptor's length over rx_buffer_size (i.e. maxfrm and mrblr).
Note that sometimes eTSEC works correctly, i.e. in the second
(last) buffer descriptor bits 'truncated' and 'crcerr' are set,
and so there's no oops. Though I couldn't find any logic when
it works correctly and when not.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/gianfar.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 46c69cd..7c31f0f 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2642,6 +2642,10 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
dma_unmap_single(&priv->ofdev->dev, bdp->bufPtr,
priv->rx_buffer_size, DMA_FROM_DEVICE);
+ if (unlikely(!(bdp->status & RXBD_ERR) &&
+ bdp->length > priv->rx_buffer_size))
+ bdp->status = RXBD_LARGE;
+
/* We drop the frame if we failed to allocate a new buffer */
if (unlikely(!newskb || !(bdp->status & RXBD_LAST) ||
bdp->status & RXBD_ERR)) {
--
1.7.0.5
^ permalink raw reply related
* [PATCH 2.6.35 & stable (v2)] powerpc: fix logic error in fixup_irqs
From: Johannes Berg @ 2010-06-11 20:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, alastair.bridgewater
In-Reply-To: <1276289669.3918.3.camel@jlt3.sipsolutions.net>
When SPARSE_IRQ is set, irq_to_desc() can
return NULL. While the code here has a
check for NULL, it's not really correct.
Fix it by separating the check for it.
This fixes CPU hot unplug for me.
Reported-by: Alastair Bridgewater <alastair.bridgewater@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
v2: cc Alastair, sorry
arch/powerpc/kernel/irq.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- wireless-testing.orig/arch/powerpc/kernel/irq.c 2010-06-11 22:51:08.000000000 +0200
+++ wireless-testing/arch/powerpc/kernel/irq.c 2010-06-11 22:54:11.000000000 +0200
@@ -295,7 +295,10 @@ void fixup_irqs(const struct cpumask *ma
for_each_irq(irq) {
desc = irq_to_desc(irq);
- if (desc && desc->status & IRQ_PER_CPU)
+ if (!desc)
+ continue;
+
+ if (desc->status & IRQ_PER_CPU)
continue;
cpumask_and(mask, desc->affinity, map);
^ permalink raw reply
* Re: [git pull] PCI fixes
From: Jesse Barnes @ 2010-06-11 21:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michal Simek, linux-am33-list, linux-pci, linux-kernel,
linuxppc-dev, microblaze-uclinux, Koichi Yasutake
In-Reply-To: <alpine.LFD.2.00.1006091611040.4506@i5.linux-foundation.org>
On Wed, 9 Jun 2010 16:14:10 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, 9 Jun 2010, Jesse Barnes wrote:
> >
> > Nothing too big here; I do have a couple of fixes in the queue that
> > aren't included here though. I'll be pulling them together over the
> > next couple of days.
>
> Hmm. None of these seem to really be relevant. The fact that one is from
> me doesn't make me any more eager to pull. Are any of these real
> regressions (the missing parenthesis one seems to be the only one that
> could be serious, but I didn't grep for actual use).
Ok I've updated the tree to cover the regressions reported so far,
including the printk change so we get fewer spurious reports. Note it
hasn't gone through linux-next yet, but the patches are all small and
have each been tested individually.
There's one change in particular I'd like you (along with the cc'd
arch maintainers) to review:
commit 837c4ef13c44296bb763a0ca0e84a076592474cf
Author: Yinghai Lu <yinghai.lu@oracle.com>
Date: Thu Jun 3 13:43:03 2010 -0700
PCI: clear bridge resource range if BIOS assigned bad one
This fixes a regression rather minimally, but may have side effects I'm
not seeing. An alternative to that fix would be to revert
commit d65245c3297ac63abc51a976d92f45f2195d2854
Author: Yinghai Lu <yinghai@kernel.org>
Date: Fri Jan 22 01:02:23 2010 -0800
PCI: don't shrink bridge resources
but it seems that's a bit more risky at this point, since it could
affect hotplug and rescan cases. Really this code needs to be
reworked, especially in light of the revert of
977d17bb1749517b353874ccdc9b85abc7a58c2a which tried (and failed)
to perform aggressive reallocation when devices weren't configured.
I'll try to find some time next week to work on that.
The following changes since commit 9dda696f0de87a2e5cfabb147e28c76b7d3c6846:
Linus Torvalds (1):
Merge branch 'release' of git://git.kernel.org/.../aegl/linux-2.6
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 for-linus
Bjorn Helgaas (1):
PCI: change resource collision messages from KERN_ERR to KERN_INFO
Jesse Barnes (1):
Revert "PCI: create function symlinks in /sys/bus/pci/slots/N/"
Jiri Slaby (1):
PCI: hotplug/cpqphp, fix NULL dereference
Yinghai Lu (1):
PCI: clear bridge resource range if BIOS assigned bad one
Documentation/ABI/testing/sysfs-bus-pci | 40 -------------------------
arch/microblaze/pci/pci-common.c | 1 +
arch/mn10300/unit-asb2305/pci-asb2305.c | 1 +
arch/powerpc/kernel/pci-common.c | 1 +
arch/x86/pci/i386.c | 2 +
drivers/pci/hotplug/cpqphp_core.c | 7 ++++
drivers/pci/pci-sysfs.c | 37 -----------------------
drivers/pci/setup-res.c | 10 +++---
drivers/pci/slot.c | 48 -------------------------------
9 files changed, 17 insertions(+), 130 deletions(-)
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 2.6.35 & stable (v2)] powerpc: fix logic error in fixup_irqs
From: Johannes Berg @ 2010-06-11 21:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, alastair.bridgewater
In-Reply-To: <1276289756.3918.4.camel@jlt3.sipsolutions.net>
On Fri, 2010-06-11 at 22:55 +0200, Johannes Berg wrote:
> When SPARSE_IRQ is set, irq_to_desc() can
> return NULL. While the code here has a
> check for NULL, it's not really correct.
> Fix it by separating the check for it.
Incidentally, there's another quirk in fixup_irqs():
...
alloc_cpumask_var(&mask, GFP_KERNEL);
...
local_irq_enable();
mdelay(1);
local_irq_disable();
Either it's called with IRQs disabled, in which case it shouldn't do
GFP_KERNEL, or it's called with IRQs enabled, in which case it doesn't
need the local_irq_enable(), no?
johannes
^ 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