* Re: [ewg] [PATCH] IB/ehca: Protect QP against destroying until all async events for it are handled.
From: Roland Dreier @ 2008-05-07 15:32 UTC (permalink / raw)
To: Stefan Roscher; +Cc: LinuxPPC-Dev, fenkes, LKML, raisch, OF-EWG
In-Reply-To: <200805071319.37164.ossrosch@linux.vnet.ibm.com>
> We are not sure if this should be fixed in the driver or in uverbs itself.
> Roland, what's your opinion about this?
Would be nice to be able to fix it in uverbs but I don't see how. In
particular a kernel consumer has to have the same guarantee that no
async events will come in after destroy QP returns. And I don't see any
way generic code can provide a guarantee about what low-level driver
code may do internally.
^ permalink raw reply
* Re: ALSA vs. non coherent DMA
From: Grant Likely @ 2008-05-07 15:44 UTC (permalink / raw)
To: Timur Tabi; +Cc: Takashi Iwai, alsa-devel, Linux Kernel list, linuxppc-dev list
In-Reply-To: <4821BB0E.80000@freescale.com>
On Wed, May 7, 2008 at 8:22 AM, Timur Tabi <timur@freescale.com> wrote:
> Takashi Iwai wrote:
>
> > This is a mmap of the data record to be shared in realtime with apps.
> > The app updates its data pointer (appl_ptr) on the mmapped buffer
> > while the driver updates the data (e.g. DMA position, called hwptr) on
> > the fly on the mmapped record. Due to its real-time nature, it has to
> > be coherent -- at least, it was a problem on ARM.
>
> This doesn't sound like a coherency problem to me, and least not one you'd find
> on PowerPC. Both the driver and the application run on the host CPU, so there
> shouldn't be any coherency problem. My understanding is that a "non coherent"
> platform is one where the host CPU isn't aware when a *hardware device* writes
> directly to memory, e.g. via DMA.
IIRC, some ARMs have a different situation because the dcache is
virtually instead of physically tagged. Therefore, the kernel mapping
may not see data that has not been flushed out of the user space
mappings. (Someone please correct me if I'm wrong).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] gianfar: low gigabit throughput
From: André Schwarz @ 2008-05-07 15:52 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linuxppc-dev
In-Reply-To: <20080506192008.GA30148@polina.dev.rtsoft.ru>
Anton,
we've just built a digital GigEVision camera based on a MPC8343 running=20
at 266/400 csb/core speed.
Transmission is done from a kernel module that allocates skb into which=20
the image data is DMA'd by an external PCI master.
As soon as the image data is complete all buffers are sent out via=20
dev->hard_start_xmit ...
Bandwidth is currently 1.3MPixel @ 50Hz which give 65MBytes/sec=20
(~520MBit/s).
Of course it's UDP _without_ checksumming ....
Actually I have no sensor available that gives higher bandwidth ... but=20
having a look at transmission time I'm sure the MPC8343 can easily go up=20
to +800MBit.
Obviously your cpu time is consumed on a higher level.
Cheers,
Andr=E9
Anton Vorontsov wrote:
> Hi all,
>
> Down here few question regarding networking throughput, I would
> appreciate any thoughts or ideas.
>
> On the MPC8315E-RDB board (CPU at 400MHz, CSB at 133 MHz) I'm observing
> relatively low TCP throughput using gianfar driver...
>
> The maximum value I've seen with the current kernels is 142 Mb/s of TCP
> and 354 Mb/s of UDP (NAPI and interrupts coalescing enabled):
>
> root@b1:~# netperf -l 10 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157=
344 -S 157344
> TCP STREAM TEST to 10.0.1.1
> #Cpu utilization 0.10
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 206848 212992 32768 10.00 142.40
>
> root@b1:~# netperf -l 10 -H 10.0.1.1 -t UDP_STREAM -- -m 32768 -s 157=
344 -S 157344
> UDP UNIDIRECTIONAL SEND TEST to 10.0.1.1
> #Cpu utilization 100.00
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 212992 32768 10.00 13539 0 354.84
> 206848 10.00 13539 354.84
>
>
> Is this normal?
>
> netperf running in loopback gives me 329 Mb/s of TCP throughput:
>
> root@b1:~# netperf -l 10 -H 127.0.0.1 -t TCP_STREAM -- -m 32768 -s 15=
7344 -S 157344
> TCP STREAM TEST to 127.0.0.1
> #Cpu utilization 100.00
> #Cpu utilization 100.00
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 212992 212992 32768 10.00 329.60
>
>
> May I consider this as a something that is close to the Linux'
> theoretical maximum for this setup? Or this isn't reliable test?
>
>
> I can compare with teh MPC8377E-RDB (very similar board - exactly the s=
ame
> ethernet phy, the same drivers are used, i.e. everything is the same fr=
om
> the ethernet stand point), but running at 666 MHz, CSB at 333MHz:
>
> |CPU MHz|BUS MHz|UDP Mb/s|TCP Mb/s|
> ------------------------------------------
> MPC8377| 666| 333| 646| 264|
> MPC8315| 400| 133| 354| 142|
> ------------------------------------------
> RATIO | 1.6| 2.5| 1.8| 1.8|
>
> It seems that things are really dependant on the CPU/CSB speed.
>
> I've tried to tune gianfar driver in various ways... and it gave
> some positive results with this patch:
>
> diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
> index fd487be..b5943f9 100644
> --- a/drivers/net/gianfar.h
> +++ b/drivers/net/gianfar.h
> @@ -123,8 +123,8 @@ extern const char gfar_driver_version[];
> #define GFAR_10_TIME 25600
> =20
> #define DEFAULT_TX_COALESCE 1
> -#define DEFAULT_TXCOUNT 16
> -#define DEFAULT_TXTIME 21
> +#define DEFAULT_TXCOUNT 80
> +#define DEFAULT_TXTIME 105
> =20
> #define DEFAULT_RXTIME 21
>
>
> Basically this raises the tx interrupts coalescing threshold (raising
> it more didn't help, as well as didn't help raising rx thresholds).
> Now:
>
> root@b1:~# netperf -l 3 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344=
-S 157344
> TCP STREAM TEST to 10.0.1.1
> #Cpu utilization 100.00
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 206848 212992 32768 3.00 163.04
>
>
> That is +21 Mb/s (14% up). Not fantastic, but good anyway.
>
> As expected, the latency increased too:
>
> Before the patch:
>
> --- 10.0.1.1 ping statistics ---
> 20 packets transmitted, 20 received, 0% packet loss, time 18997ms
> rtt min/avg/max/mdev =3D 0.108/0.124/0.173/0.022 ms
>
> After:
>
> --- 10.0.1.1 ping statistics ---
> 22 packets transmitted, 22 received, 0% packet loss, time 20997ms
> rtt min/avg/max/mdev =3D 0.158/0.167/0.182/0.004 ms
>
>
> 34% up... heh. Should we sacrifice the latency in favour of throughput?
> Is 34% latency growth bad thing? What is worse, lose 21 Mb/s or 34% of
> latency? ;-)
>
>
> Thanks in advance,
>
> p.s. Btw, the patch above helps even better on the on the -rt kernels,
> since on the -rt kernels the throughput is near 100 Mb/s, with the
> patch the throughput is close to 140 Mb/s.
>
> =20
MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: [ewg] [PATCH] IB/ehca: Protect QP against destroying until all async events for it are handled.
From: Stefan Roscher @ 2008-05-07 16:00 UTC (permalink / raw)
To: Roland Dreier; +Cc: LinuxPPC-Dev, fenkes, LKML, raisch, OF-EWG
In-Reply-To: <adahcdaw2oc.fsf@cisco.com>
On Wednesday 07 May 2008 17:32:03 Roland Dreier wrote:
> > We are not sure if this should be fixed in the driver or in uverbs itself.
> > Roland, what's your opinion about this?
>
> Would be nice to be able to fix it in uverbs but I don't see how. In
> particular a kernel consumer has to have the same guarantee that no
> async events will come in after destroy QP returns. And I don't see any
> way generic code can provide a guarantee about what low-level driver
> code may do internally.
>
I agree, that's why I posted the driver fix first.
So, will you apply it next?
Regards Stefan
^ permalink raw reply
* Re: [RFC] gianfar: low gigabit throughput
From: Anton Vorontsov @ 2008-05-07 16:01 UTC (permalink / raw)
To: André Schwarz; +Cc: netdev, linuxppc-dev
In-Reply-To: <4821D059.7020808@matrix-vision.de>
On Wed, May 07, 2008 at 05:52:57PM +0200, André Schwarz wrote:
> Anton,
>
Much thanks for the information!
> we've just built a digital GigEVision camera based on a MPC8343 running
> at 266/400 csb/core speed.
>
> Transmission is done from a kernel module that allocates skb into which
> the image data is DMA'd by an external PCI master.
> As soon as the image data is complete all buffers are sent out via
> dev->hard_start_xmit ...
Ah. So no userspace and packet generation expenses.. I see. This should
be definitely faster than netperf. But generally this fits into the
picture: MPC8315 running at 266 CSB would probably give better UDP
througput (300 Mb/s currenty).
> Bandwidth is currently 1.3MPixel @ 50Hz which give 65MBytes/sec
> (~520MBit/s).
> Of course it's UDP _without_ checksumming ....
>
> Actually I have no sensor available that gives higher bandwidth ... but
> having a look at transmission time I'm sure the MPC8343 can easily go up
> to +800MBit.
>
>
> Obviously your cpu time is consumed on a higher level.
>
> Cheers,
> André
>
>
> Anton Vorontsov wrote:
>> Hi all,
>>
>> Down here few question regarding networking throughput, I would
>> appreciate any thoughts or ideas.
>>
>> On the MPC8315E-RDB board (CPU at 400MHz, CSB at 133 MHz) I'm observing
>> relatively low TCP throughput using gianfar driver...
>>
>> The maximum value I've seen with the current kernels is 142 Mb/s of TCP
>> and 354 Mb/s of UDP (NAPI and interrupts coalescing enabled):
>>
>> root@b1:~# netperf -l 10 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
>> TCP STREAM TEST to 10.0.1.1
>> #Cpu utilization 0.10
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 206848 212992 32768 10.00 142.40
>>
>> root@b1:~# netperf -l 10 -H 10.0.1.1 -t UDP_STREAM -- -m 32768 -s 157344 -S 157344
>> UDP UNIDIRECTIONAL SEND TEST to 10.0.1.1
>> #Cpu utilization 100.00
>> Socket Message Elapsed Messages
>> Size Size Time Okay Errors Throughput
>> bytes bytes secs # # 10^6bits/sec
>>
>> 212992 32768 10.00 13539 0 354.84
>> 206848 10.00 13539 354.84
>>
>>
>> Is this normal?
>>
>> netperf running in loopback gives me 329 Mb/s of TCP throughput:
>>
>> root@b1:~# netperf -l 10 -H 127.0.0.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
>> TCP STREAM TEST to 127.0.0.1
>> #Cpu utilization 100.00
>> #Cpu utilization 100.00
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 212992 212992 32768 10.00 329.60
>>
>>
>> May I consider this as a something that is close to the Linux'
>> theoretical maximum for this setup? Or this isn't reliable test?
>>
>>
>> I can compare with teh MPC8377E-RDB (very similar board - exactly the same
>> ethernet phy, the same drivers are used, i.e. everything is the same from
>> the ethernet stand point), but running at 666 MHz, CSB at 333MHz:
>>
>> |CPU MHz|BUS MHz|UDP Mb/s|TCP Mb/s|
>> ------------------------------------------
>> MPC8377| 666| 333| 646| 264|
>> MPC8315| 400| 133| 354| 142|
>> ------------------------------------------
>> RATIO | 1.6| 2.5| 1.8| 1.8|
>>
>> It seems that things are really dependant on the CPU/CSB speed.
>>
>> I've tried to tune gianfar driver in various ways... and it gave
>> some positive results with this patch:
>>
>> diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
>> index fd487be..b5943f9 100644
>> --- a/drivers/net/gianfar.h
>> +++ b/drivers/net/gianfar.h
>> @@ -123,8 +123,8 @@ extern const char gfar_driver_version[];
>> #define GFAR_10_TIME 25600
>> #define DEFAULT_TX_COALESCE 1
>> -#define DEFAULT_TXCOUNT 16
>> -#define DEFAULT_TXTIME 21
>> +#define DEFAULT_TXCOUNT 80
>> +#define DEFAULT_TXTIME 105
>> #define DEFAULT_RXTIME 21
>>
>>
>> Basically this raises the tx interrupts coalescing threshold (raising
>> it more didn't help, as well as didn't help raising rx thresholds).
>> Now:
>>
>> root@b1:~# netperf -l 3 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
>> TCP STREAM TEST to 10.0.1.1
>> #Cpu utilization 100.00
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 206848 212992 32768 3.00 163.04
>>
>>
>> That is +21 Mb/s (14% up). Not fantastic, but good anyway.
>>
>> As expected, the latency increased too:
>>
>> Before the patch:
>>
>> --- 10.0.1.1 ping statistics ---
>> 20 packets transmitted, 20 received, 0% packet loss, time 18997ms
>> rtt min/avg/max/mdev = 0.108/0.124/0.173/0.022 ms
>>
>> After:
>>
>> --- 10.0.1.1 ping statistics ---
>> 22 packets transmitted, 22 received, 0% packet loss, time 20997ms
>> rtt min/avg/max/mdev = 0.158/0.167/0.182/0.004 ms
>>
>>
>> 34% up... heh. Should we sacrifice the latency in favour of throughput?
>> Is 34% latency growth bad thing? What is worse, lose 21 Mb/s or 34% of
>> latency? ;-)
>>
>>
>> Thanks in advance,
>>
>> p.s. Btw, the patch above helps even better on the on the -rt kernels,
>> since on the -rt kernels the throughput is near 100 Mb/s, with the
>> patch the throughput is close to 140 Mb/s.
>>
>>
>
>
> MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: MPC5200b MMC over SPI into PSC6
From: Grant Likely @ 2008-05-07 16:34 UTC (permalink / raw)
To: Fabio Tosetto; +Cc: linuxppc-dev
In-Reply-To: <4821A551.3060205@libero.it>
On Wed, May 7, 2008 at 6:49 AM, Fabio Tosetto <tosettofabio83@libero.it> wrote:
>
> I've tried to port my exesting configurations to the powerpc tree but some
> configurations files are missing.
First, create a new .dts file for your board in arch/powerpc/boot/dts.
(just copy the lite5200.dts file). Modify the .dts to have your
board's name (in the form "<vendor>,<boardname>") in the compatible
and model properties.
Next, add your boards name to the list of boards in
arch/powerpc/platforms/52xx/mpc5200_simple.c.
> I need to set PSC3 - PSC4 in uart mode:
> before in file *arch/ppc/platforms/lite5200.c* I added
>
> struct mpc52xx_psc_func mpc52xx_psc_functions[] = {
> { .id = 3,
> .func = "uart",
> },
> { .id = 4,
> .func = "uart",
> },
> { .id = -1, /* End entry */
> .func = NULL,
> }
> };
Edit your boards .dts file and uncomment PSCs 3 and 4. Comment out
PSC1 if you aren't using it.
> I need to set PSC4 as a low level debug: *
> *before in file *arch/ppc/platforms/lite5200.h *I added
>
> #define MPC52xx_PF_CONSOLE_PORT 4 /* PSC4 */
I don't think we have any early debug enabled yet in arch/powerpc for
the mpc5200.
> Finally I need to set the virtual memory translation on a range of 128 MB:
> before in file *arch/ppc/kernel/head.S *I added
>
> /*ori r11,r11,BL_128M<<2|0x2 set up BAT registers for 604 */
>
> ori r11,r11,BL_128M<<2|0x2 /* set up BAT registers for 604 */
>
> could you please explain me how to do the same operations in powerpc tree??
New file is arch/powerpc/kernel/head_32.S. I don't think that is the
cleanest way to do it though. Why do you need to change the BAT
mapping from 256 to 128?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] gianfar: low gigabit throughput
From: Rick Jones @ 2008-05-07 16:33 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linuxppc-dev
In-Reply-To: <20080507132823.GA10988@polina.dev.rtsoft.ru>
>>I have _got_ to make CPU utilization enabled by default one of these
>>days :) At least for mechanisms which don't require calibration.
>
>
> Heh, I've skipped the calibration chapter in the netperf manual. :-D
> Should revert to it.
Under linux, the CPU utilization mechanism in netperf does not require
calibration, so you can add a -c (and -C if the remote is also linux) to
the global command line options. Netperf will the report CPU util and
calculate the "service demand" which will be the quantity of CPU
consumed per unit of work.
> So things becomes much better when the message size increases
> (I think the netperf then eating less cpu, and gives some precessing
> time to the kernel?).
Unless the compiler isn't doing a very good job, or perhaps if you've
enabled histograms (./configure --enable-histogram) and set verbosity to
2 or more (not the case here), netperf itself shouldn't be consuming
very much CPU at all up in user space. Now, as the size of the buffers
passed to the transport increases, it does mean fewer system calls per
KB transferred, which should indeed be more efficient.
>>What is the nature of the DMA stream between the two tests? I find it
>>interesting that the TCP Mb/s went up by more than the CPU MHz and
>>wonder how much the Bus MHz came into play there - perhaps there were
>>more DMA's to setup or across a broader memory footprint for TCP than
>>for UDP.
>
>
> The gianfar indeed does a lot of dma on the "buffer descriptors", so
> probably the bus speed matters a lot. And combination of CPU and Bus
> gives the final result.
Do you have any way to calculate bus utilization - logic analyzer, or
perhaps some performance counters in the hardware?
If you have an HP-UX or Solaris system handy to act as a receiver, you
might give that a try - it would be interesting to see the effect of
their ACK avoidance heuristics on TCP throughput. One non-trivial
difference I keep forgetting to mention is that TCP will have that
returning ACK stream that UDP will not.
rick jones
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix
From: Jochen Roth @ 2008-05-07 16:54 UTC (permalink / raw)
To: Carl Love
Cc: linuxppc-dev, oprofile-list, cbe-oss-dev, Arnd Bergmann,
linux-kernel
In-Reply-To: <1209587712.7531.42.camel@carll-linux-desktop>
Carl,
I applied your patch on Jeremy's latest kernel.org spufs tree.
> +void oprofile_add_value(unsigned long value, int cpu) {
> + struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[cpu];
Shouldn't it be
struct oprofile_cpu_buffer *cpu_buf = &per_cpu(cpu_buffer, cpu);
At least my compiler complained about that.
I booted a kernel with your patches applied and the system locked up
anyway:
Unable to handle kernel paging request for data at address
0xd0000000004fe9a8
Faulting instruction address: 0xd000000000330ad8
cpu 0x0: Vector: 300 (Data Access) at [c00000003c337680]
pc: d000000000330ad8: .alloc_cpu_buffers+0x7c/0x12c [oprofile]
lr: d000000000330abc: .alloc_cpu_buffers+0x60/0x12c [oprofile]
sp: c00000003c337900
msr: 9000000000009032
dar: d0000000004fe9a8
dsisr: 42000000
current = 0xc00000003e128600
paca = 0xc0000000005b3480
pid = 2356, comm = oprofiled
enter ? for help
[c00000003c3379a0] d0000000003302ac .oprofile_setup+0x2c/0x134 [oprofile]
[c00000003c337a30] d00000000033176c .event_buffer_open+0x7c/0xc8 [oprofile]
[c00000003c337ac0] c0000000000d6ca8 .__dentry_open+0x190/0x308
[c00000003c337b70] c0000000000e7a5c .do_filp_open+0x3c4/0x8e8
[c00000003c337d00] c0000000000d6a1c .do_sys_open+0x80/0x14c
[c00000003c337db0] c0000000001192f4 .compat_sys_open+0x24/0x38
[c00000003c337e30] c0000000000076b4 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000ff006f8
SP (ffc6f6a0) is in userspace
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix
From: Carl Love @ 2008-05-07 17:09 UTC (permalink / raw)
To: jroth; +Cc: linuxppc-dev, oprofile-list, cbe-oss-dev, Arnd Bergmann,
linux-kernel
In-Reply-To: <4821DEB0.7050308@linux.vnet.ibm.com>
On Wed, 2008-05-07 at 18:54 +0200, Jochen Roth wrote:
> Carl,
>
> I applied your patch on Jeremy's latest kernel.org spufs tree.
>
> > +void oprofile_add_value(unsigned long value, int cpu) {
> > + struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[cpu];
>
> Shouldn't it be
> struct oprofile_cpu_buffer *cpu_buf = &per_cpu(cpu_buffer, cpu);
No, I don't think so. Take a look at the other functions in
drivers/oprofile/cpu_buffer.c. For example oprofile_add_trace(). You
will see that the cpu_buffer is not accessed using the per_cpu
construct. Not sure why the compiler would complain about the
oprofile_add_value() function but not one of the other functions like
oprofile_add_trace().
What was the compiler error that you saw?
I will try getting Jeremy's kernel and applying the patch there to see
if it works.
>
> At least my compiler complained about that.
>
> I booted a kernel with your patches applied and the system locked up
> anyway:
>
> Unable to handle kernel paging request for data at address
> 0xd0000000004fe9a8
> Faulting instruction address: 0xd000000000330ad8
> cpu 0x0: Vector: 300 (Data Access) at [c00000003c337680]
> pc: d000000000330ad8: .alloc_cpu_buffers+0x7c/0x12c [oprofile]
> lr: d000000000330abc: .alloc_cpu_buffers+0x60/0x12c [oprofile]
> sp: c00000003c337900
> msr: 9000000000009032
> dar: d0000000004fe9a8
> dsisr: 42000000
> current = 0xc00000003e128600
> paca = 0xc0000000005b3480
> pid = 2356, comm = oprofiled
> enter ? for help
> [c00000003c3379a0] d0000000003302ac .oprofile_setup+0x2c/0x134 [oprofile]
> [c00000003c337a30] d00000000033176c .event_buffer_open+0x7c/0xc8 [oprofile]
> [c00000003c337ac0] c0000000000d6ca8 .__dentry_open+0x190/0x308
> [c00000003c337b70] c0000000000e7a5c .do_filp_open+0x3c4/0x8e8
> [c00000003c337d00] c0000000000d6a1c .do_sys_open+0x80/0x14c
> [c00000003c337db0] c0000000001192f4 .compat_sys_open+0x24/0x38
> [c00000003c337e30] c0000000000076b4 syscall_exit+0x0/0x40
> --- Exception: c01 (System Call) at 000000000ff006f8
> SP (ffc6f6a0) is in userspace
>
^ permalink raw reply
* Re: [ewg] [PATCH] IB/ehca: Protect QP against destroying until all async events for it are handled.
From: Roland Dreier @ 2008-05-07 18:02 UTC (permalink / raw)
To: Stefan Roscher; +Cc: LinuxPPC-Dev, fenkes, LKML, raisch, OF-EWG
In-Reply-To: <200805071800.15595.ossrosch@linux.vnet.ibm.com>
> I agree, that's why I posted the driver fix first.
Glad we agree :)
I thought about it a little more and really convinced myself that there
is no good way for generic code to handle this race.
> So, will you apply it next?
Yes, will apply it shortly.
- R.
^ permalink raw reply
* Re: powerpc port for sbc8260-based board problem
From: Sergej Stepanov @ 2008-05-07 17:38 UTC (permalink / raw)
To: Boris Shteinbock; +Cc: linuxppc-dev
In-Reply-To: <733382.15174.qm@web50603.mail.re2.yahoo.com>
Hallo.
I had the same problem.
The following patch can help.
diff -pruN paulus-git/drivers/serial/cpm_uart/cpm_uart_core.c linuxppc-2.6.=
24-ids8247/drivers/serial/cpm_uart/cpm_uart_core.c
--- paulus-git/drivers/serial/cpm_uart/cpm_uart_core.c 2008-03-28 11:03:32.=
000000000 +0100
+++ linuxppc-2.6.24-ids8247/drivers/serial/cpm_uart/cpm_uart_core.c 2008-05=
-07 19:35:21.000000000 +0200
@@ -1350,6 +1349,9 @@ static int __init cpm_uart_console_setup
uart_set_options(port, co, baud, parity, bits, flow);
cpm_line_cr_cmd(pinfo, CPM_CR_RESTART_TX);
=20
+#ifndef CONFIG_PPC_EARLY_DEBUG_CPM
+ cpm_set_brg(pinfo->brg - 1, baud);
+#endif
return 0;
}
=20
Regards
Sergej.
Am Mittwoch, den 07.05.2008, 01:31 -0700 schrieb Boris Shteinbock:
> Hi.
> I am doing a port from ppc to powerpc ARCH on sbc8260 based board.
> The problem is, that I can't get SMC1 UART to work.
> After SMC console is initialized. =20
> cpm_uart_console_write() hangs here
>=20
> /* Wait for transmitter fifo to empty.
> * Ready indicates output is ready, and xmt is doing
> * that, not that it is ready for us to send.
> */
> while ((in_be16(&bdp->cbd_sc) & BD_SC_READY) !=3D 0)
> ;
>=20
> I am using dts tree modified from ep8248 port since it is the only one t=
hat has smc description in it. :
>=20
>=20
> brg@119f0 {
> compatible =3D "fsl,mpc8260-brg",
> "fsl,cpm2-brg",
> "fsl,cpm-brg";
> reg =3D <119f0 10 115f0 10>;
> clock-frequency =3D <135000000>;
> =20
> };
>=20
> /* Monitor port/SMC1 */
> smc1: serial@11a80 {
> device_type =3D "serial";
> compatible =3D "fsl,mpc8260-smc-uart",
> "fsl,cpm2-smc-uart";
> reg =3D <0x11a80 0x20 0x1100 0x40>;
> interrupts =3D <4 8>;
> interrupt-parent =3D <&PIC>;
> fsl,cpm-brg =3D <1>;
> fsl,cpm-command =3D <0x1d000000>;
> linux,my-label =3D "SMC1";
> };
>=20
> I checked a BRG settings against working u-boot configuration and they ar=
e the same. Anyway a wrong BRG setting wouldn't hang this loop
>=20
> So I have a few questions.
> If someone has done sbc8260 dts tree and port to "powerpc" already, I'd b=
e very grateful if he can share it with me.
> I couldn't find anything on the internet.
>=20
> Can someone, also, explain, how "fsl, cpm-command" field works, booting-=
without-of document doesn't provide much information.
> I feel, that just copying this value from ep8248.dts isn't right somehow.
>=20
> Thank you
>=20
>=20
> ___________________________________________________________________=
_________________
> Be a better friend, newshound, and=20
> know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_y=
lt=3DAhu06i62sR8HDtDypao8Wcj9tAcJ
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--=20
Dipl.-Ing. Sergej Stepanov=20
Software-Entwicklung
IDS GmbH=20
E-PA (Entwicklung - Prozess Automatisierung)
Nobelstr. 18,=20
D-76275 Ettlingen=20
T. (0) 72 43/2 18-615=20
F. (0) 72 43/2 18-100=20
E. Sergej.Stepanov@ids.de
<http://www.ids.de>
Gesch=C3=A4ftsf=C3=BChrer: Norbert Wagner, Friedrich Abri=C3=9F=20
Sitz der Gesellschaft: Ettlingen=20
Amtsgericht Mannheim HRB 362503=20
^ permalink raw reply
* [PATCH] Fix for OProfile callgraph for Power 64 bit user apps
From: Carl Love @ 2008-05-07 18:12 UTC (permalink / raw)
To: inuxppc-dev, linux-kernel, Maynard Johnson, cel
The following patch fixes the 64 bit user code backtrace
which currently may hang the system.
Signed-off-by: Carl Love <carll@us.ibm.com>
Index: linux-2.6.25.1/arch/powerpc/oprofile/backtrace.c
===================================================================
--- linux-2.6.25.1.orig/arch/powerpc/oprofile/backtrace.c 2008-05-01 16:45:25.000000000 -0500
+++ linux-2.6.25.1/arch/powerpc/oprofile/backtrace.c 2008-05-07 11:29:02.000000000 -0500
@@ -53,19 +53,40 @@
#ifdef CONFIG_PPC64
static unsigned long user_getsp64(unsigned long sp, int is_first)
{
- unsigned long stack_frame[3];
+ unsigned long stk_frm_lr;
+ unsigned long stk_frm_sp;
+ unsigned long size;
+
+ /* Issue the __copy_from_user_inatomic() third argument currently
+ * only takes sizes 1, 2, 4 or 8 bytes. Don't read more then the
+ * first 48 bytes of the stack frame. That is all that is
+ * guaranteed to exist. Reading more may cause the system to hang.
+ *
+ * 64 bit stack frame layout:
+ * 0-7 bytes is the pointer to previous stack
+ * 8-15 bytes condition register save area
+ * 16-23 bytes link register save area
+ */
+ size = sizeof(unsigned long);
+ if (!access_ok(VERIFY_READ, (void __user *)sp, size))
+ return 0;
- if (!access_ok(VERIFY_READ, (void __user *)sp, sizeof(stack_frame)))
+ if (__copy_from_user_inatomic(&stk_frm_sp, (void __user *)sp,
+ size))
return 0;
- if (__copy_from_user_inatomic(stack_frame, (void __user *)sp,
- sizeof(stack_frame)))
+ /* get the LR from the user stack */
+ if (!access_ok(VERIFY_READ, (void __user *)(sp+16), size))
+ return 0;
+
+ if (__copy_from_user_inatomic(&stk_frm_lr, (void __user *)(sp+16),
+ size))
return 0;
if (!is_first)
- oprofile_add_trace(STACK_LR64(stack_frame));
+ oprofile_add_trace(stk_frm_lr);
- return STACK_SP(stack_frame);
+ return stk_frm_sp;
}
#endif
^ permalink raw reply
* [PATCH v2] powerpc: Fix a bunch of sparse warnings in the qe_lib
From: Andy Fleming @ 2008-05-07 18:19 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, timur.tabi
Mostly having to do with not marking things __iomem. And some failure
to use appropriate accessors to read MMIO regs.
Signed-off-by: Andy Fleming <afleming@freescale.com>
---
arch/powerpc/sysdev/qe_lib/qe.c | 6 +++---
arch/powerpc/sysdev/qe_lib/ucc.c | 6 +++---
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 16 ++++++++--------
include/asm-powerpc/ucc_fast.h | 8 ++++----
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index cff550e..07260a6 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -65,7 +65,7 @@ static phys_addr_t qebase = -1;
phys_addr_t get_qe_base(void)
{
struct device_node *qe;
- unsigned int size;
+ int size;
const u32 *prop;
if (qebase != -1)
@@ -159,7 +159,7 @@ static unsigned int brg_clk = 0;
unsigned int qe_get_brg_clk(void)
{
struct device_node *qe;
- unsigned int size;
+ int size;
const u32 *prop;
if (brg_clk)
@@ -306,7 +306,7 @@ EXPORT_SYMBOL(qe_put_snum);
static int qe_sdma_init(void)
{
- struct sdma *sdma = &qe_immr->sdma;
+ struct sdma __iomem *sdma = &qe_immr->sdma;
unsigned long sdma_buf_offset;
if (!sdma)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/qe_lib/ucc.c
index 0e348d9..4103dc1 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc.c
@@ -87,7 +87,7 @@ int ucc_set_type(unsigned int ucc_num, enum ucc_speed_type speed)
return 0;
}
-static void get_cmxucr_reg(unsigned int ucc_num, __be32 **cmxucr,
+static void get_cmxucr_reg(unsigned int ucc_num, __be32 __iomem **cmxucr,
unsigned int *reg_num, unsigned int *shift)
{
unsigned int cmx = ((ucc_num & 1) << 1) + (ucc_num > 3);
@@ -99,7 +99,7 @@ static void get_cmxucr_reg(unsigned int ucc_num, __be32 **cmxucr,
int ucc_mux_set_grant_tsa_bkpt(unsigned int ucc_num, int set, u32 mask)
{
- __be32 *cmxucr;
+ __be32 __iomem *cmxucr;
unsigned int reg_num;
unsigned int shift;
@@ -120,7 +120,7 @@ int ucc_mux_set_grant_tsa_bkpt(unsigned int ucc_num, int set, u32 mask)
int ucc_set_qe_mux_rxtx(unsigned int ucc_num, enum qe_clock clock,
enum comm_dir mode)
{
- __be32 *cmxucr;
+ __be32 __iomem *cmxucr;
unsigned int reg_num;
unsigned int shift;
u32 clock_bits = 0;
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index bcf88e6..1aecb07 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -46,7 +46,7 @@ void ucc_fast_dump_regs(struct ucc_fast_private * uccf)
printk(KERN_INFO "uccm : addr=0x%p, val=0x%08x\n",
&uccf->uf_regs->uccm, in_be32(&uccf->uf_regs->uccm));
printk(KERN_INFO "uccs : addr=0x%p, val=0x%02x\n",
- &uccf->uf_regs->uccs, uccf->uf_regs->uccs);
+ &uccf->uf_regs->uccs, in_8(&uccf->uf_regs->uccs));
printk(KERN_INFO "urfb : addr=0x%p, val=0x%08x\n",
&uccf->uf_regs->urfb, in_be32(&uccf->uf_regs->urfb));
printk(KERN_INFO "urfs : addr=0x%p, val=0x%04x\n",
@@ -68,7 +68,7 @@ void ucc_fast_dump_regs(struct ucc_fast_private * uccf)
printk(KERN_INFO "urtry : addr=0x%p, val=0x%08x\n",
&uccf->uf_regs->urtry, in_be32(&uccf->uf_regs->urtry));
printk(KERN_INFO "guemr : addr=0x%p, val=0x%02x\n",
- &uccf->uf_regs->guemr, uccf->uf_regs->guemr);
+ &uccf->uf_regs->guemr, in_8(&uccf->uf_regs->guemr));
}
EXPORT_SYMBOL(ucc_fast_dump_regs);
@@ -96,7 +96,7 @@ EXPORT_SYMBOL(ucc_fast_transmit_on_demand);
void ucc_fast_enable(struct ucc_fast_private * uccf, enum comm_dir mode)
{
- struct ucc_fast *uf_regs;
+ struct ucc_fast __iomem *uf_regs;
u32 gumr;
uf_regs = uccf->uf_regs;
@@ -117,7 +117,7 @@ EXPORT_SYMBOL(ucc_fast_enable);
void ucc_fast_disable(struct ucc_fast_private * uccf, enum comm_dir mode)
{
- struct ucc_fast *uf_regs;
+ struct ucc_fast __iomem *uf_regs;
u32 gumr;
uf_regs = uccf->uf_regs;
@@ -139,7 +139,7 @@ EXPORT_SYMBOL(ucc_fast_disable);
int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** uccf_ret)
{
struct ucc_fast_private *uccf;
- struct ucc_fast *uf_regs;
+ struct ucc_fast __iomem *uf_regs;
u32 gumr;
int ret;
@@ -216,10 +216,10 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
uccf->stopped_tx = 0;
uccf->stopped_rx = 0;
uf_regs = uccf->uf_regs;
- uccf->p_ucce = (u32 *) & (uf_regs->ucce);
- uccf->p_uccm = (u32 *) & (uf_regs->uccm);
+ uccf->p_ucce = &uf_regs->ucce;
+ uccf->p_uccm = &uf_regs->uccm;
#ifdef CONFIG_UGETH_TX_ON_DEMAND
- uccf->p_utodr = (u16 *) & (uf_regs->utodr);
+ uccf->p_utodr = &uf_regs->utodr;
#endif
#ifdef STATISTICS
uccf->tx_frames = 0;
diff --git a/include/asm-powerpc/ucc_fast.h b/include/asm-powerpc/ucc_fast.h
index f529f70..fce16ab 100644
--- a/include/asm-powerpc/ucc_fast.h
+++ b/include/asm-powerpc/ucc_fast.h
@@ -156,11 +156,11 @@ struct ucc_fast_info {
struct ucc_fast_private {
struct ucc_fast_info *uf_info;
- struct ucc_fast *uf_regs; /* a pointer to memory map of UCC regs. */
- u32 *p_ucce; /* a pointer to the event register in memory. */
- u32 *p_uccm; /* a pointer to the mask register in memory. */
+ struct ucc_fast __iomem *uf_regs; /* a pointer to the UCC regs. */
+ u32 __iomem *p_ucce; /* a pointer to the event register in memory. */
+ u32 __iomem *p_uccm; /* a pointer to the mask register in memory. */
#ifdef CONFIG_UGETH_TX_ON_DEMAND
- u16 *p_utodr; /* pointer to the transmit on demand register */
+ u16 __iomem *p_utodr; /* pointer to the transmit on demand register */
#endif
int enabled_tx; /* Whether channel is enabled for Tx (ENT) */
int enabled_rx; /* Whether channel is enabled for Rx (ENR) */
--
1.5.4.GIT
^ permalink raw reply related
* Re: powerpc port for sbc8260-based board problem
From: Scott Wood @ 2008-05-07 18:22 UTC (permalink / raw)
To: Boris Shteinbock; +Cc: linuxppc-dev
In-Reply-To: <733382.15174.qm@web50603.mail.re2.yahoo.com>
On Wed, May 07, 2008 at 01:31:52AM -0700, Boris Shteinbock wrote:
> /* Monitor port/SMC1 */
> smc1: serial@11a80 {
> device_type = "serial";
> compatible = "fsl,mpc8260-smc-uart",
> "fsl,cpm2-smc-uart";
> reg = <0x11a80 0x20 0x1100 0x40>;
The second reg resource depends on where your firmware set up the SMC pram
regs. With U-boot, it's usually zero.
Note that as of 2.6.26-rc1, this is set up dynamically instead, and the
second resource should be 0x87fc 2.
> Can someone, also, explain, how "fsl, cpm-command" field works,
It's the device-specific portion of the value that gets written to the CPM
command register (page, sub-block, and mcc channel).
> booting-without-of document doesn't provide much information. I feel, that
> just copying this value from ep8248.dts isn't right somehow.
It should be the same.
-Scott
^ permalink raw reply
* Re: powerpc port for sbc8260-based board problem
From: Sergej Stepanov @ 2008-05-07 18:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080507182209.GA2710@loki.buserror.net>
Hello Scott
Am Mittwoch, den 07.05.2008, 13:22 -0500 schrieb Scott Wood:
> On Wed, May 07, 2008 at 01:31:52AM -0700, Boris Shteinbock wrote:
> > /* Monitor port/SMC1 */
> > smc1: serial@11a80 {
> > device_type =3D "serial";
> > compatible =3D "fsl,mpc8260-smc-uart",
> > "fsl,cpm2-smc-uart";
> > reg =3D <0x11a80 0x20 0x1100 0x40>;
>=20
> The second reg resource depends on where your firmware set up the SMC pra=
m
> regs. With U-boot, it's usually zero.
>=20
> Note that as of 2.6.26-rc1, this is set up dynamically instead, and the
> second resource should be 0x87fc 2.
>=20
You are right with 0x87fc. It is one more point.
Also if your brg clock-frequency-property was correctly fixed from
u-boot.
My story is follow: we have mpc8247 based card.
The problem with smc happens due to the cpm reset.
Of course, if you have not CONFIG_PPC_EARLY_DEBUG_CPM with
CONFIG_PPC_CPM_NEW_BINDING.
May be it is some kind of mistake, but i could fix the problem with the
patch i told above.
Could give me some your note, please? Thank you.
Regards
Sergej.
--=20
Dipl.-Ing. Sergej Stepanov=20
Software-Entwicklung
IDS GmbH=20
E-PA (Entwicklung - Prozess Automatisierung)
Nobelstr. 18,=20
D-76275 Ettlingen=20
T. (0) 72 43/2 18-615=20
F. (0) 72 43/2 18-100=20
E. Sergej.Stepanov@ids.de
<http://www.ids.de>
Gesch=C3=A4ftsf=C3=BChrer: Norbert Wagner, Friedrich Abri=C3=9F=20
Sitz der Gesellschaft: Ettlingen=20
Amtsgericht Mannheim HRB 362503=20
^ permalink raw reply
* Re: powerpc port for sbc8260-based board problem
From: Boris Shteinbock @ 2008-05-07 18:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
On Wed, May 07, 2008 at 01:31:52AM -0700, Boris Shteinbock wrote:
> /* Monitor port/SMC1 */
> smc1: serial@11a80 {
> device_type = "serial";
> compatible = "fsl,mpc8260-smc-uart",
> "fsl,cpm2-smc-uart";
> reg = <0x11a80 0x20 0x1100 0x40>;
>The second reg resource depends on where your firmware set up the SMC pram
>regs. With U-boot, it's usually zero.
>Note that as of 2.6.26-rc1, this is set up dynamically instead, and the
>second resource should be .
Is this correct?
reg = <0x11a80 0x20 0x87fc 2>;
I also understand, that latest development kernel contains some significant changes in SMC UART code, especially
in muram code, is this correct? So does this reg value reflect this change?
>> Can someone, also, explain, how "fsl, cpm-command" field works,
>It's the device-specific portion of the value that gets written to the CPM
>command register (page, sub-block, and mcc channel).
Is it possible to get a quick list of all values for all 8260 soc devices somewhere ? Or do I have to dig specific Freescale reference for it?
I am particularly interested in SMC2 and FCC1,2 and 3 ?
Thank you very much
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
^ permalink raw reply
* Re: powerpc port for sbc8260-based board problem
From: Scott Wood @ 2008-05-07 18:53 UTC (permalink / raw)
To: Boris Shteinbock; +Cc: linuxppc-dev
In-Reply-To: <833555.65590.qm@web50611.mail.re2.yahoo.com>
Boris Shteinbock wrote:
>> The second reg resource depends on where your firmware set up the SMC pram
>> regs. With U-boot, it's usually zero.
>
>> Note that as of 2.6.26-rc1, this is set up dynamically instead, and the
>> second resource should be .
> Is this correct?
>
> reg = <0x11a80 0x20 0x87fc 2>;
Yes.
> I also understand, that latest development kernel contains some significant changes in SMC UART code, especially
> in muram code, is this correct? So does this reg value reflect this change?
Yes, those are the changes I was referring to.
>>> Can someone, also, explain, how "fsl, cpm-command" field works,
>
>> It's the device-specific portion of the value that gets written to the CPM
>> command register (page, sub-block, and mcc channel).
>
> Is it possible to get a quick list of all values for all 8260 soc devices somewhere ? Or do I have to dig specific Freescale reference for it?
See table 13-6 (CP Command Register Field Descriptions) in the 8260 manual.
> I am particularly interested in SMC2 and FCC1,2 and 3 ?
SMC2: 0x21200000
FCC1: 0x12000000 (ATM 0x11c00280)
FCC2: 0x16200000 (ATM 0x15c00280)
FCC3: 0x1a400000
For FCCs, add 0x300 for Ethernet, 0x3c0 for transparent.
-Scott
^ permalink raw reply
* Re: powerpc port for sbc8260-based board problem
From: Scott Wood @ 2008-05-07 18:57 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev
In-Reply-To: <1210185652.3519.18.camel@p60365-ste>
Sergej Stepanov wrote:
> My story is follow: we have mpc8247 based card.
> The problem with smc happens due to the cpm reset.
> Of course, if you have not CONFIG_PPC_EARLY_DEBUG_CPM with
> CONFIG_PPC_CPM_NEW_BINDING.
> May be it is some kind of mistake, but i could fix the problem with the
> patch i told above.
> Could give me some your note, please? Thank you.
I'm not sure how it would make a difference -- the BRG should have
already been set through the set_termios callback, which is called from
uart_set_options.
-Scott
^ permalink raw reply
* Re: [ewg] [PATCH] IB/ehca: Protect QP against destroying until all async events for it are handled.
From: Roland Dreier @ 2008-05-07 19:18 UTC (permalink / raw)
To: Stefan Roscher; +Cc: LinuxPPC-Dev, fenkes, LKML, raisch, OF-EWG
In-Reply-To: <200805071800.15595.ossrosch@linux.vnet.ibm.com>
So I applied this, but thinking about it further, do you (theoretically
at least) have the same problem with CQ and SRQ async events?
- R.
^ permalink raw reply
* [PATCH] Add null pointer check to of_find_property
From: Timur Tabi @ 2008-05-07 19:19 UTC (permalink / raw)
To: linuxppc-dev, paulus
Update function of_find_property() to return NULL if the device_node passed
to it is also NULL. Otherwise, passing NULL will cause a null pointer
dereference.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch allows callers to do this:
np = of_find_compatible_node(...);
prop = of_get_property(np);
if (!prop)
goto error;
Today, we need a np==NULL check between the two of_ calls. Some callers may
not care whether the node is missing or the property is missing.
drivers/of/base.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 9bd7c4a..23ffb7c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -65,6 +65,9 @@ struct property *of_find_property(const struct device_node *np,
{
struct property *pp;
+ if (!np)
+ return NULL;
+
read_lock(&devtree_lock);
for (pp = np->properties; pp != 0; pp = pp->next) {
if (of_prop_cmp(pp->name, name) == 0) {
--
1.5.5
^ permalink raw reply related
* Re: powerpc port for sbc8260-based board problem
From: Sergej Stepanov @ 2008-05-07 19:26 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4821FBA0.9080203@freescale.com>
Am Mittwoch, den 07.05.2008, 13:57 -0500 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > My story is follow: we have mpc8247 based card.
> > The problem with smc happens due to the cpm reset.
> > Of course, if you have not CONFIG_PPC_EARLY_DEBUG_CPM with
> > CONFIG_PPC_CPM_NEW_BINDING.
> > May be it is some kind of mistake, but i could fix the problem with the
> > patch i told above.
> > Could give me some your note, please? Thank you.
>
> I'm not sure how it would make a difference -- the BRG should have
> already been set through the set_termios callback, which is called from
> uart_set_options.
>
> -Scott
Yes, i thought it also, but i traced it for us for the uart console.
The cpm_uart_set_termios(..) was not called.
At which place should it be called?
Is it uart_set_options(..)?
Sergej.
^ permalink raw reply
* Re: [PATCH] Add null pointer check to of_find_property
From: Grant Likely @ 2008-05-07 19:27 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, paulus
In-Reply-To: <1210187999-20274-1-git-send-email-timur@freescale.com>
On Wed, May 7, 2008 at 1:19 PM, Timur Tabi <timur@freescale.com> wrote:
> Update function of_find_property() to return NULL if the device_node passed
> to it is also NULL. Otherwise, passing NULL will cause a null pointer
> dereference.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> This patch allows callers to do this:
>
> np = of_find_compatible_node(...);
> prop = of_get_property(np);
> if (!prop)
> goto error;
>
> Today, we need a np==NULL check between the two of_ calls. Some callers may
> not care whether the node is missing or the property is missing.
>
> drivers/of/base.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 9bd7c4a..23ffb7c 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -65,6 +65,9 @@ struct property *of_find_property(const struct device_node *np,
> {
> struct property *pp;
>
> + if (!np)
> + return NULL;
> +
> read_lock(&devtree_lock);
> for (pp = np->properties; pp != 0; pp = pp->next) {
> if (of_prop_cmp(pp->name, name) == 0) {
> --
> 1.5.5
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: powerpc port for sbc8260-based board problem
From: Scott Wood @ 2008-05-07 19:34 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev
In-Reply-To: <1210188413.3519.36.camel@p60365-ste>
Sergej Stepanov wrote:
> Am Mittwoch, den 07.05.2008, 13:57 -0500 schrieb Scott Wood:
>> I'm not sure how it would make a difference -- the BRG should have
>> already been set through the set_termios callback, which is called from
>> uart_set_options.
>>
>> -Scott
> Yes, i thought it also, but i traced it for us for the uart console.
> The cpm_uart_set_termios(..) was not called.
> At which place should it be called?
> Is it uart_set_options(..)?
Yes, uart_set_options() calls port->ops->set_termios().
-Scott
^ permalink raw reply
* Re: [PATCH v2] powerpc: Fix a bunch of sparse warnings in the qe_lib
From: Timur Tabi @ 2008-05-07 19:37 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <1210184384-28425-1-git-send-email-afleming@freescale.com>
Andy Fleming wrote:
> Mostly having to do with not marking things __iomem. And some failure
> to use appropriate accessors to read MMIO regs.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
Acked-By: Timur Tabi <timur@freescale.com>
(Not timur.tabi@freescale.com)
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: powerpc port for sbc8260-based board problem
From: Sergej Stepanov @ 2008-05-07 19:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <48220428.6020207@freescale.com>
Am Mittwoch, den 07.05.2008, 14:34 -0500 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > Am Mittwoch, den 07.05.2008, 13:57 -0500 schrieb Scott Wood:
> >> I'm not sure how it would make a difference -- the BRG should have
> >> already been set through the set_termios callback, which is called from
> >> uart_set_options.
> >>
> >> -Scott
> > Yes, i thought it also, but i traced it for us for the uart console.
> > The cpm_uart_set_termios(..) was not called.
> > At which place should it be called?
> > Is it uart_set_options(..)?
>
> Yes, uart_set_options() calls port->ops->set_termios().
>
> -Scott
Hm... it looks like the default uart_set_termios from
static const struct tty_operations uart_ops in serial_core.c
and not cpm_uart_set_termios(..)?..
Is not it? but why?...
Ok, i have to look at my code again...
Regards.
^ 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