* RE: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches
From: Bounine, Alexandre @ 2010-10-25 17:13 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linux-kernel, Thomas Moll, akpm, linuxppc-dev
In-Reply-To: <4CC5ACAB.7070309@neli.hopto.org>
Micha Nelissen <micha@neli.hopto.org> wrote:
>=20
> Bounine, Alexandre wrote:
> > 1. The destid for the switch needs an additional mechanism to share
it
> > among processors in the RIO network,
>=20
> ? See comment for 2)
>=20
> > 2. It takes ID value away from the pool of available IDs, what will
>=20
> It does not take an ID away, it shares it with a connected endpoint to
> that switch. The tag uses one extra bit to identify the device as a
> switch instead of an endpoint. This provides the information to
> unambiguously identify a switch from an endpoint.
OK taking away #2. But do not see how it justifies storing two values of
destid.
And you have just confirmed using CT for unique identification. We
simply have differences in interpretation of CT: you are using component
tag to pass unique identification and I am using CT as a unique
identification. I prefer not to assume any relationship between routing
information and the component tag.
Alex.
^ permalink raw reply
* Re: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches
From: Micha Nelissen @ 2010-10-25 16:13 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linux-kernel, Thomas Moll, akpm, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55201445BA4@CORPEXCH1.na.ads.idt.com>
Bounine, Alexandre wrote:
> Micha Nelissen <micha@neli.hopto.org> wrote:
>>> rid of rswitch->switchid and use component_tag directly for
> switches).
>> I still prefer the destid as the single identification id.
>
> In your patch you allocate individual destid for switches. This method
> has two problems:
> 1. The destid for the switch needs an additional mechanism to share it
> among processors in the RIO network,
? See comment for 2)
> 2. It takes ID value away from the pool of available IDs, what will
It does not take an ID away, it shares it with a connected endpoint to
that switch. The tag uses one extra bit to identify the device as a
switch instead of an endpoint. This provides the information to
unambiguously identify a switch from an endpoint.
Micha
^ permalink raw reply
* Re: [PATCH 1/2] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: David Woodhouse @ 2010-10-25 14:15 UTC (permalink / raw)
To: tiejun.chen
Cc: Wood Scott-B07421, dedekind1, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, Gala Kumar-B11780
In-Reply-To: <4CBC1775.6000706@windriver.com>
On Mon, 2010-10-18 at 17:46 +0800, tiejun.chen wrote:
>
> >>> Looks you always iounmap(fsl_lbc_ctrl_dev->regs) on position 'err' but here
> >>> of_iomap() is already failed you should skip iounmap() fsl_lbc_ctrl_dev->regs
> >>> again. So you should improve that as the following on 'err', or layout 'err'
> >>> in
> >>> gain.
> >>> ------
> >>> if(fsl_lbc_ctrl_dev->regs)
> >>> iounmap(fsl_lbc_ctrl_dev->regs);
> >>>
> >>> Tiejun
> >> You are right!
> >> How about
> >>
> >> if (!fsl_lbc_ctrl_dev->regs) {
> >> dev_err(&dev->dev, "failed to get memory region\n");
> >> kfree(fsl_lbc_ctrl_dev);
> >> return -ENOMEM;
> >> }
> >
> > Although this is a big problem, I prefer to return 'ENXIO' :)
> ^
> Typo: is not a ......
My God! Why did you *both* repeat over 400 lines of patch, over and over
again, just for this?
Please, make sure you quote *only* what you actually need to quote for
context. Don't make me implement a filter for the list which rejects
messages that are more than 90% quotation.
--
dwmw2
^ permalink raw reply
* Re: BUG with the kernel version 2.6.36-rc1 on power machine
From: Yong Zhang @ 2010-10-25 14:15 UTC (permalink / raw)
To: divya
Cc: Dmitry Torokhov, linux-kernel, Linuxppc-dev, Paul Mackerras,
Anton Blanchard, Subrata Modak
In-Reply-To: <20101025135710.GA5461@zhy>
On Mon, Oct 25, 2010 at 09:57:10PM +0800, Yong Zhang wrote:
> On Mon, Oct 25, 2010 at 04:32:01PM +0530, divya wrote:
> > http://lkml.org/lkml/2010/10/13/67 resolves the issue.
> >
> > But this is not a part of 2.6.36-git6 , when will it be pulled into the upstream?
>
> That patch is splited into two parts.
> The lockdep one is 4ba053c04aece1f4734056f21b751eee47ea3fb1 upstream.
> The mousedev one is taken by Dmitry Torokhov(Cc'ing)
Just notice Dmitry has sent pull request to Linus.
You can also get the mousedev one here:
http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=commit;h=f74eef95e33a07379aa2b950c7f313cbfd55ebbe
Thanks,
Yong
^ permalink raw reply
* Re: BUG with the kernel version 2.6.36-rc1 on power machine
From: Yong Zhang @ 2010-10-25 13:57 UTC (permalink / raw)
To: divya
Cc: Dmitry Torokhov, linux-kernel, Linuxppc-dev, Paul Mackerras,
Anton Blanchard, Subrata Modak
In-Reply-To: <4CC563A9.3020308@linux.vnet.ibm.com>
On Mon, Oct 25, 2010 at 04:32:01PM +0530, divya wrote:
> http://lkml.org/lkml/2010/10/13/67 resolves the issue.
>
> But this is not a part of 2.6.36-git6 , when will it be pulled into the upstream?
That patch is splited into two parts.
The lockdep one is 4ba053c04aece1f4734056f21b751eee47ea3fb1 upstream.
The mousedev one is taken by Dmitry Torokhov(Cc'ing)
Thanks,
Yong
^ permalink raw reply
* RE: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches
From: Bounine, Alexandre @ 2010-10-25 13:22 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linux-kernel, Thomas Moll, akpm, linuxppc-dev
In-Reply-To: <4CC20923.8050400@neli.hopto.org>
Micha Nelissen <micha@neli.hopto.org> wrote:
> Bounine, Alexandre wrote:
> > If we will need to identify the same physical switch by different
> > processors we may use the component tag which now is unique for
every
> > device.
>=20
> Yes, identification is the point. I think it might be confusing to
have
> a destid *and* a component tag id which are slightly different. The
> destid is unambiguous (if you know whether the device is a switch or
> endpoint) so I think it makes sense to use that if possible.
The component tag is the way to identify a RIO device (switch or
endpoint).
1. it is defined by RIO spec as a register existing in both types of
devices (this provides a universal access to the identification
information by any processor).
2. the Error Management specification already uses the CT as a device
identifier.
3. the CT value is large enough to be unique for max number of endpoints
in the large system and any reasonable number of switches. BTW, I am
planning to provide a patch that defines CT fields to ensure future
compatibility.
The destid does not exists as a HW element of switches and therefore
cannot be used as a universal identification token.
> > This actually gives me another idea: instead of using global
> > next_switchid counter make rswitch->switchid =3D component_tag and
> > switches in sysfs will look identical for every processor (or just
get
> > rid of rswitch->switchid and use component_tag directly for
switches).
>=20
> I still prefer the destid as the single identification id.
As I answered above, destid cannot be used as a universal identification
token - it is a routing element. The destID has register in endpoints
only to provide a packet filtering.
In your patch you allocate individual destid for switches. This method
has two problems:
1. The destid for the switch needs an additional mechanism to share it
among processors in the RIO network,
2. It takes ID value away from the pool of available IDs, what will
reduce number of IDs that can be assigned to endpoints. (NOTE: I am
actually working on destID assignment scheme that will recycle destID in
case of hot-swap events, i.e. if device is extracted its destID will be
returned to the pool of available IDs and may be reused later for device
insertion).
The only case when assigning individual destid to the switch is
justified is an "empty" switch - one without any endpoints attached to
it. But that destid should be assigned to an endpoint as soon as it is
attached to that switch. =20
Alex.
^ permalink raw reply
* MPC5200B MWDMA2 with recent 2.6.36 kernels
From: Roman Fietze @ 2010-10-25 11:17 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I recently tried to switch to 2.6.36 (torvalds/master) using a
Lite5200B compatible board.
Using 2.6.34 we were running ATA in MWDMA 2 to avoid MPC5200B HW
problems with UDMA.
But with 2.6.36 I get only ATA errors (PIO4 is working fine):
...
ata: MPC52xx IDE/ATA libata driver
scsi0 : mpc52xx_ata
ata1: PATA max MWDMA2 ata_regs 0xf0003a00 irq 135
...
ata1.00: ATA-6: Hitachi HEJ421010G9AT00, F5DJA40B, max UDMA/100
ata1.00: 195371568 sectors, multi 0: LBA48
ata1.00: configured for MWDMA2
scsi 0:0:0:0: Direct-Access ATA Hitachi HEJ42101 F5DJ PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 195371568 512-byte logical blocks: (100 GB/93.1 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO749060] ------------[ cut here ]------------
WARNING: at /home/fietze/src/linux-2.6-telemotive/drivers/ata/libata-sff.c:1468
Modules linked in:
NIP: c01b1680 LR: c01b1654 CTR: c01b06d0
REGS: c7843ad0 TRAP: 0700 Not tainted (2.6.36.00.02-obelix)
MSR: 00021032 <ME,CE,IR,DR> CR: 24008084 XER: 00000000
TASK = c7829b20[8] 'kworker/u:1' THREAD: c7842000
GPR00: 00000001 c7843b80 c7829b20 00000050 c9088a78 00000001 00000000 00000000
GPR08: 00000000 c03432d8 00000003 00000000 44008082 1001a7f0 c02adb28 c0269df8
GPR16: c02adb20 c02adbc4 c02adbec c6f2bc60 c6f48000 c02647a0 c74081a0 c000f060
GPR24: c780baa0 00000002 c6f21430 c6f21430 00000003 00000000 c6f20000 c6f200a4
NIP [c01b1680] ata_sff_qc_issue+0x78/0x24c
LR [c01b1654] ata_sff_qc_issue+0x4c/0x24c
Call Trace:
[c7843b80] [c01b1654] ata_sff_qc_issue+0x4c/0x24c (unreliable)
[c7843ba0] [c01a087c] ata_qc_issue+0x208/0x330
[c7843bd0] [c01a5ca4] ata_scsi_translate+0x104/0x1b0
[c7843bf0] [c018d208] scsi_dispatch_cmd+0xf4/0x208
[c7843c10] [c0193b64] scsi_request_fn+0x270/0x404
[c7843c40] [c01405b0] __generic_unplug_device+0x48/0x5c
[c7843c50] [c0140ee4] generic_unplug_device+0x28/0x44
[c7843c60] [c013e480] blk_unplug+0x20/0x30
[c7843c70] [c00b14b4] block_sync_page+0x54/0x70
[c7843c80] [c005b37c] sync_page+0x50/0x74
[c7843c90] [c0259b50] __wait_on_bit_lock+0x94/0x124
[c7843cb0] [c005b2f8] __lock_page+0x50/0x60
[c7843ce0] [c005baac] do_read_cache_page+0x18c/0x190
[c7843d10] [c005bb08] read_cache_page+0x14/0x28
[c7843d20] [c00d7ca8] read_dev_sector+0x40/0xb0
[c7843d40] [c00d8c24] msdos_partition+0xb4/0x98c
[c7843e20] [c00d885c] rescan_partitions+0x1c0/0x4bc
[c7843e80] [c00b960c] __blkdev_get+0x1a0/0x368
[c7843ec0] [c00d85ec] register_disk+0x17c/0x194
[c7843ef0] [c0147e04] add_disk+0xf4/0x144
[c7843f20] [c019b658] sd_probe_async+0xf4/0x1bc
[c7843f40] [c004339c] async_run_entry_fn+0x84/0x1cc
[c7843f60] [c0035c1c] process_one_work+0x10c/0x330
[c7843f90] [c003730c] worker_thread+0x1ec/0x32c
[c7843fb0] [c003ba60] kthread+0x7c/0x80
[c7843ff0] [c000f5c4] kernel_thread+0x4c/0x68
Instruction dump:
4bfff65d 8b9f0014 2f9c0002 419e00e8 2b9c0002 419d0040 2f9c0001 419e0158
3d20c034 392932d8 89690005 69600001 <0f000000> 2f8b0000 38600040 419e01bc
---[ end trace 69c43b02b90e3750 ]---
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: failed command: READ DMA
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
res 50/00:00:2f:22:a5/00:00:00:00:00/a0 Emask 0x40 (internal error)
ata1.00: status: { DRDY }
ata1.00: configured for MWDMA2
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: failed command: READ DMA
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
res 50/00:00:2f:22:a5/00:00:00:00:00/a0 Emask 0x40 (internal error)
ata1.00: status: { DRDY }
ata1.00: configured for MWDMA2
...
... and so on
Any ideas? Same behavious on some of your boxes? Too bad my current
know how when it comes to ATA is not too much above zero.
Roman
--
Roman Fietze Telemotive AG Buero Muehlhausen
Breitwiesen 73347 Muehlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* Re: BUG with the kernel version 2.6.36-rc1 on power machine
From: divya @ 2010-10-25 11:02 UTC (permalink / raw)
To: Yong Zhang
Cc: linux-kernel, Linuxppc-dev, Paul Mackerras, Anton Blanchard,
Subrata Modak
In-Reply-To: <20101023093630.GA3036@zhy>
On Saturday 23 October 2010 03:06 PM, Yong Zhang wrote:
> On Sat, Oct 23, 2010 at 12:43:21AM +0530, Subrata Modak wrote:
>
>> This is equally seen for both Power6 and Power7 machines.
>>
> Seems resolved by part of http://lkml.org/lkml/2010/10/13/67
>
> Thanks,
> Yong
>
>
>> Regards--
>> Subrata
>>
>> On Sat, 2010-10-23 at 00:37 +0530, Subrata Modak wrote:
>>
>>>
>>> ---------- Forwarded message ----------
>>> From: divya<dipraksh@linux.vnet.ibm.com>
>>> Date: Fri, Oct 22, 2010 at 1:10 PM
>>> Subject: Re: BUG with the kernel version 2.6.36-rc1 on power machine
>>> To: LKML<linux-kernel@vger.kernel.org>, benh@kernel.crashing.org,
>>> linuxppc-dev@ozlabs.org
>>>
>>>
>>>
>>> On Friday 22 October 2010 12:50 PM, divya wrote:
>>> Hi ,
>>>
>>> With the latest version of kernel 2.6.36-rc1 running on the
>>> power machine, came across the following call trace
>>>
>>> BUG: looking up invalid subclass: 31
>>> turning off the locking correctness validator.
>>> Call Trace:
>>> [c00000000e0bfb60] [c0000000000119a0] .show_stack+0x6c/0x16c
>>> (unreliable)
>>> [c00000000e0bfc10] [c0000000000c39b8] .lockdep_init_map
>>> +0x194/0x630
>>> [c00000000e0bfcf0] [c0000000005524f8] .mousedev_create
>>> +0xcc/0x234
>>> [c00000000e0bfda0] [c00000000093fb58] .mousedev_init+0x38/0xa0
>>> [c00000000e0bfe30] [c0000000000097e4] .do_one_initcall
>>> +0xd8/0x1c8
>>> [c00000000e0bfee0] [c0000000009004ac] .kernel_init+0x23c/0x2f8
>>> [c00000000e0bff90] [c00000000002ad30] .kernel_thread+0x54/0x70
>>>
>>> The config file used for make oldconfig is being attached
>>>
>>> Thanks
>>> Divya
>>>
>>>
>>>
>>>
>>> I meant 2.6.36-git1(b5153163ed580e) , and not 2.6.36-rc1.
>>> Sorry for the confusion.
>>>
>>> Thanks
>>> Divya
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>>
>>>
>>>
>>> --
>>> Regards& Thanks--
>>> Subrata
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
The patch at
http://lkml.org/lkml/2010/10/13/67 resolves the issue.
But this is not a part of 2.6.36-git6 , when will it be pulled into the upstream?
Thanks
Divya
^ permalink raw reply
* Re: Oops while running systemtap on the p6 machine against the kernel version 2.6.36-rc7-git3
From: divya @ 2010-10-25 10:19 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: linuxppc-dev, systemtap
In-Reply-To: <y0mmxqgec4e.fsf@fche.csb>
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
On Friday 15 October 2010 02:16 AM, Frank Ch. Eigler wrote:
> divya<dipraksh@linux.vnet.ibm.com> writes:
>
>
>> While running systemtap tests on the p6 machine , against the kernel
>> version 2.6.36-rc7-git3 Oops occured , here are the call trace
>>
> Did the oops happen during a systemtap module startup vs. operation
> vs. shutdown? stap -V version string?
>
>
>> BUG: spinlock bad magic on CPU#6, stapio/20398
>> -- 0:conmux-control -- time-stamp -- Oct/13/10 2:49:18 --res
>> lock: c000000000fcfa18, .magic: 00000000, .owner:<none>/-1, .owner_cpu: 0
>> Call Trace:
>> [c0000001effbfab0] [c000000000011934] .show_stack+0x6c/0x16c (unreliable)
>> [c0000001effbfb60] [c0000000002c9274] .spin_bug+0xb0/0xd4
>> [c0000001effbfbf0] [c0000000002c953c] .do_raw_spin_lock+0x48/0x184
>> [c0000001effbfc90] [c00000000054af78] ._raw_spin_lock+0x10/0x24
>> [c0000001effbfd00] [d000000003015908] .__stp_time_timer_callback+0x94/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
>> [...]
>> kernel BUG at kernel/timer.c:681!
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> SMP NR_CPUS=1024 NUMA pSeries
>> [...]
>> [c0000001effbfc50] [c0000001effbfd00] 0xc0000001effbfd00 (unreliable)
>> [c0000001effbfd00] [d00000000301597c] .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
>> [c0000001effbfdc0] [c00000000009c2f8] .run_timer_softirq+0x1d8/0x2a8
>>
>
> We have had occasional problems in the past with something like this:
> http://sourceware.org/PR10651, but it never was tracked down to a
> systemtap bug per se, as opposed to suspicions that the kernel was not
> satisfying one of its guarantees w.r.t. del_timer_sync().
>
> - FChE
>
Sorry Frank for the late reply
The Oops occured during the execution of systemtap tests.
stap version being :
Snapshot: 89e2abb
Attached are the systemtap test execution logs
Thanks
Divya
[-- Attachment #2: systemtap.DEBUG --]
[-- Type: text/plain, Size: 18391 bytes --]
10/13 15:06:44 DEBUG| utils:0053| Running 'which gcc'
10/13 15:06:44 DEBUG| utils:0085| /usr/bin/gcc
10/13 15:06:44 INFO | test:0256| Test started. Number of iterations: 1
10/13 15:06:44 INFO | test:0259| Executing iteration 1 of 1
10/13 15:06:44 DEBUG| utils:0053| Running 'PATH=/usr/local/autobench/autotest/deps/systemtap/systemtap/bin:/usr/local/autobench/autotest/deps/dejagnu/dejagnu/bin:$PATH make installcheck'
10/13 15:06:44 DEBUG| utils:0085| make check-DEJAGNU RUNTESTFLAGS=" --tool_opts \'install \'"
10/13 15:06:44 DEBUG| utils:0085| make[1]: Entering directory `/usr/local/autobench/autotest/tests/systemtap/test'
10/13 15:06:44 DEBUG| utils:0085| srcdir=`CDPATH="${ZSH_VERSION+.}:" && cd /usr/local/autobench/autotest/tests/systemtap/src/testsuite && pwd`; export srcdir; \
10/13 15:06:44 DEBUG| utils:0085| EXPECT=expect; export EXPECT; \
10/13 15:06:44 DEBUG| utils:0085| runtest="env SYSTEMTAP_TESTAPPS= SYSTEMTAP_RUNTIME=/usr/local/autobench/autotest/deps/systemtap/systemtap/share/systemtap/runtime SYSTEMTAP_TAPSET=/usr/local/autobench/autotest/deps/systemtap/systemtap/share/systemtap/tapset LD_LIBRARY_PATH=/usr/local/autobench/autotest/deps/systemtap/systemtap/lib/systemtap CRASH_LIBDIR=/usr/local/autobench/autotest/deps/systemtap/systemtap/lib/systemtap PATH=/usr/local/autobench/autotest/deps/systemtap/systemtap/bin:$PATH SYSTEMTAP_PATH=/usr/local/autobench/autotest/deps/systemtap/systemtap/bin SYSTEMTAP_INCLUDES=/usr/local/autobench/autotest/deps/systemtap/systemtap/include PKGLIBDIR=/usr/local/autobench/autotest/deps/systemtap/systemtap/libexec/systemtap /usr/local/autobench/autotest/tests/systemtap/src/testsuite/execrc runtest"; \
10/13 15:06:44 DEBUG| utils:0085| if /bin/sh -c "$runtest --version" > /dev/null 2>&1; then \
10/13 15:06:44 DEBUG| utils:0085| exit_status=0; l='systemtap'; for tool in $l; do \
10/13 15:06:44 DEBUG| utils:0085| if $runtest --tool $tool --tool_opts \'\' --srcdir $srcdir --tool_opts \'install \'; \
10/13 15:06:44 DEBUG| utils:0085| then :; else exit_status=1; fi; \
10/13 15:06:44 DEBUG| utils:0085| done; \
10/13 15:06:44 DEBUG| utils:0085| else echo "WARNING: could not find \`runtest'" 1>&2; :;\
10/13 15:06:44 DEBUG| utils:0085| fi; \
10/13 15:06:44 DEBUG| utils:0085| exit $exit_status
10/13 15:06:45 ERROR| utils:0085| WARNING: Couldn't find the global config file.
10/13 15:06:45 DEBUG| utils:0085| kernel location:
10/13 15:06:45 DEBUG| utils:0085| kernel version: 2.6.36-rc7-git3-autotest
10/13 15:06:45 DEBUG| utils:0085| systemtap location: /usr/local/autobench/autotest/deps/systemtap/systemtap/bin/stap
10/13 15:06:45 DEBUG| utils:0085| systemtap version: version 1.4/0.148 non-git sources
10/13 15:06:45 DEBUG| utils:0085| gcc location: /usr/bin/gcc
10/13 15:06:45 DEBUG| utils:0085| gcc version: gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
10/13 15:06:46 DEBUG| utils:0085| Test Run By root on Wed Oct 13 15:06:46 2010
10/13 15:06:46 DEBUG| utils:0085| Native configuration is powerpc64-unknown-linux-gnu
10/13 15:06:46 DEBUG| utils:0085|
10/13 15:06:46 DEBUG| utils:0085| === systemtap tests ===
10/13 15:06:46 DEBUG| utils:0085|
10/13 15:06:46 DEBUG| utils:0085| Schedule of variations:
10/13 15:06:46 DEBUG| utils:0085| unix
10/13 15:06:46 DEBUG| utils:0085|
10/13 15:06:46 DEBUG| utils:0085| Running target unix
10/13 15:06:46 DEBUG| utils:0085| Using /usr/local/autobench/autotest/deps/dejagnu/dejagnu/share/dejagnu/baseboards/unix.exp as board description file for target.
10/13 15:06:46 DEBUG| utils:0085| Using /usr/local/autobench/autotest/deps/dejagnu/dejagnu/share/dejagnu/config/unix.exp as generic interface file for target.
10/13 15:06:46 DEBUG| utils:0085| Using /usr/local/autobench/autotest/tests/systemtap/src/testsuite/config/unix.exp as tool-and-target-specific interface file.
10/13 15:06:46 DEBUG| utils:0085|
10/13 15:06:46 DEBUG| utils:0085| Host: Linux p55alp2 2.6.36-rc7-git3-autotest #1 SMP Wed Oct 13 14:46:58 IST 2010 ppc64 ppc64 ppc64 GNU/Linux
10/13 15:06:46 DEBUG| utils:0085| Snapshot: 89e2abb
10/13 15:06:46 DEBUG| utils:0085| GCC: 4.3.2 [gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]]
10/13 15:06:46 DEBUG| utils:0085| Distro: SUSE Linux Enterprise Server 11 (ppc64)
10/13 15:06:46 DEBUG| utils:0085|
10/13 15:06:46 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap/notest.exp ...
10/13 15:06:46 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.apps/mysql.exp ...
10/13 15:06:46 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.apps/postgres.exp ...
10/13 15:06:46 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.apps/tcl.exp ...
10/13 15:06:46 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.apps/xulrunner.exp ...
10/13 15:06:46 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/add.exp ...
10/13 15:06:58 DEBUG| utils:0085| FAIL: systemtap.base/add.stp startup (eof)
10/13 15:06:58 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/alias-condition.exp ...
10/13 15:07:06 DEBUG| utils:0085| FAIL: systemtap.base/alias-condition.stp startup (eof)
10/13 15:07:06 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/alias_tapset.exp ...
10/13 15:07:10 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/alternatives.exp ...
10/13 15:07:13 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/arith.exp ...
10/13 15:07:21 DEBUG| utils:0085| FAIL: arith
10/13 15:07:21 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/arith_limits.exp ...
10/13 15:07:30 DEBUG| utils:0085| FAIL: arith_limits
10/13 15:07:30 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/array_size.exp ...
10/13 15:07:43 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/array_string.exp ...
10/13 15:07:49 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/atomic.exp ...
10/13 15:08:32 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/backtrace.exp ...
10/13 15:09:03 DEBUG| utils:0085| FAIL: backtrace (0 0)
10/13 15:09:27 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/badkprobe.exp ...
10/13 15:10:23 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/be_order.exp ...
10/13 15:10:29 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/beginenderror.exp ...
10/13 15:10:36 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/bench.exp ...
10/13 15:10:38 DEBUG| utils:0085| FAIL: bench (0)
10/13 15:10:38 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/bitfield.exp ...
10/13 15:10:47 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/bz10078.exp ...
10/13 15:10:48 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/bz5274.exp ...
10/13 15:10:48 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/bz6850.exp ...
10/13 15:10:49 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/cache.exp ...
10/13 15:12:14 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/cast.exp ...
10/13 15:12:23 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/cmd_parse.exp ...
10/13 15:12:40 DEBUG| utils:0085| FAIL: cmd_parse9 eof
10/13 15:12:42 DEBUG| utils:0085| FAIL: cmd_parse10 eof
10/13 15:12:44 DEBUG| utils:0085| FAIL: cmd_parse11 eof
10/13 15:12:46 DEBUG| utils:0085| FAIL: cmd_parse12 eof
10/13 15:13:05 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/const_value.exp ...
10/13 15:13:06 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/control_limits.exp ...
10/13 15:13:30 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/crash.exp ...
10/13 15:13:30 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/ctime.exp ...
10/13 15:13:36 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/cu-decl.exp ...
10/13 15:13:36 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/cxxclass.exp ...
10/13 15:13:37 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/debugpath.exp ...
10/13 15:13:40 DEBUG| utils:0085| FAIL: debugpath-good (eof)
10/13 15:13:40 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/deref.exp ...
10/13 15:13:47 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/deref2.exp ...
10/13 15:13:47 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/div0.exp ...
10/13 15:13:49 DEBUG| utils:0085| FAIL: systemtap.base/div0.stp startup (eof)
10/13 15:13:49 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/dtrace.exp ...
10/13 15:13:51 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/equal.exp ...
10/13 15:13:56 DEBUG| utils:0085| FAIL: systemtap.base/equal.stp startup (eof)
10/13 15:13:56 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/error_fn.exp ...
10/13 15:14:02 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/externalvar.exp ...
10/13 15:14:02 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/finloop2.exp ...
10/13 15:14:08 DEBUG| utils:0085| FAIL: systemtap.base/finloop2.stp startup (eof)
10/13 15:14:08 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/flightrec1.exp ...
10/13 15:14:13 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/flightrec2.exp ...
10/13 15:14:26 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/flightrec3.exp ...
10/13 15:14:45 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/flightrec4.exp ...
10/13 15:14:54 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/flightrec5.exp ...
10/13 15:15:09 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/foreach_value.exp ...
10/13 15:15:16 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/func_alias.exp ...
10/13 15:15:18 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/global_end.exp ...
10/13 15:15:34 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/global_init.exp ...
10/13 15:15:36 DEBUG| utils:0085| FAIL: systemtap.base/global_init.stp startup (eof)
10/13 15:15:36 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/global_opt.exp ...
10/13 15:15:38 DEBUG| utils:0085| FAIL: global_opt: unexpected EOF
10/13 15:15:38 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/global_stat.exp ...
10/13 15:15:44 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/global_vars.exp ...
10/13 15:15:46 DEBUG| utils:0085| FAIL: systemtap.base/global_vars.stp startup (eof)
10/13 15:15:46 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/gtod.exp ...
10/13 15:16:06 DEBUG| utils:0085| FAIL: gtod (0)
10/13 15:16:06 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/if.exp ...
10/13 15:16:11 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/inc.exp ...
10/13 15:16:13 DEBUG| utils:0085| FAIL: systemtap.base/inc.stp startup (eof)
10/13 15:16:13 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/inlinedvars.exp ...
10/13 15:16:15 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/itrace.exp ...
10/13 15:16:16 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/kfunct.exp ...
10/13 15:16:21 DEBUG| utils:0085| FAIL: systemtap.base/kfunct.stp startup (eof)
10/13 15:16:21 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/kmodule.exp ...
10/13 15:16:25 DEBUG| utils:0085| FAIL: systemtap.base/kmodule.stp startup (eof)
10/13 15:16:25 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/kprobes.exp ...
10/13 15:16:31 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/kretprobe-vars.exp ...
10/13 15:16:37 DEBUG| utils:0085| FAIL: systemtap.base/kretprobe-vars.stp startup (eof)
10/13 15:16:37 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/labels.exp ...
10/13 15:16:37 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/limits.exp ...
10/13 15:16:43 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/logical_and.exp ...
10/13 15:16:44 DEBUG| utils:0085| FAIL: systemtap.base/logical_and.stp startup (eof)
10/13 15:16:44 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/marker.exp ...
10/13 15:16:45 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/maxactive.exp ...
10/13 15:16:50 DEBUG| utils:0085| FAIL: MAXACTIVE01 startup (eof)
10/13 15:16:55 DEBUG| utils:0085| FAIL: MAXACTIVE02 startup (eof)
10/13 15:16:55 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/maxmemory.exp ...
10/13 15:17:14 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/modargs.exp ...
10/13 15:17:16 DEBUG| utils:0085| FAIL: modargs compilation: /tmp/stapbqFK0D/stap_b3c6d56a1ee2d88b4eee11c3a17a03c8_1022.c:594: error: 'param_ops_int64_t' undeclared here (not in a function)
10/13 15:17:16 DEBUG| utils:0085| make[3]: *** [/tmp/stapbqFK0D/stap_b3c6d56a1ee2d88b4eee11c3a17a03c8_1022.o] Error 1
10/13 15:17:16 DEBUG| utils:0085| make[2]: *** [_module_/tmp/stapbqFK0D] Error 2
10/13 15:17:16 DEBUG| utils:0085| Pass 4: compilation failed. Try again with another '--vp 0001' option.
10/13 15:17:16 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/not.exp ...
10/13 15:17:18 DEBUG| utils:0085| FAIL: systemtap.base/not.stp startup (eof)
10/13 15:17:18 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/onoffprobe.exp ...
10/13 15:17:24 DEBUG| utils:0085| FAIL: conditional probes (0)
10/13 15:17:24 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/optim.exp ...
10/13 15:17:30 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/optim_arridx.exp ...
10/13 15:17:30 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/optim_voidstmt.exp ...
10/13 15:17:36 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/optionalprobe.exp ...
10/13 15:17:40 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/overcatcher.exp ...
10/13 15:17:46 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/overflow_error.exp ...
10/13 15:17:48 DEBUG| utils:0085| FAIL: overflow_error (0)
10/13 15:17:48 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/overload.exp ...
10/13 15:18:09 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/pointer_array.exp ...
10/13 15:18:20 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/poll_map.exp ...
10/13 15:18:28 DEBUG| utils:0085| FAIL: poll_map (0)
10/13 15:18:28 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/pp.exp ...
10/13 15:18:50 DEBUG| utils:0085| Running /usr/local/autobench/autotest/tests/systemtap/src/testsuite/systemtap.base/pr10854.exp ...
^ permalink raw reply
* Re: CONFIG_FEC is not good for mpc8xx ethernet?
From: tiejun.chen @ 2010-10-25 8:21 UTC (permalink / raw)
To: Shawn Jin; +Cc: Scott Wood, ppcdev
In-Reply-To: <AANLkTimW1_Hc3kQ2Wbn6zDMUSJvRCxn0XdGw4wB-mm0D@mail.gmail.com>
Shawn Jin wrote:
>> The problem for me is that the PHY failed to be probed. The related
>> error messages are shown below. I even tried the patch Tiejun pointed
>> out. But that doesn't help. The phy ID read from the bus was all Fs.
>>
>> FEC MII Bus: probed
>> mdio_bus fa200e00: error probing PHY at address 0
>
> I think I figured out the probing failure. My board uses PortD bit8 as
> an input pin from phy's MDC. I didn't set up this pin assignment.
>
> When probing the PHY the fs_enet_fec_mii_read() is called to get phy
> id. The correct phy id was returned. However when I tried to set up
> the ip address using the command "ifconfig eth0 192.168.0.4". The same
> function was called again. But this time the fecp->fec_r_cntrl
> mysteriously became 0 so the kernel reported bug for that.
Sorry for this delay response since I'm a bit busying recently:)
If you're sure that work well at the first time it may be issued from PIN. Are
the PINs used to MDIO bus multiplexed? Maybe you miss something to re-configure
PIN with the appropriate mode, OUT direction and some GPIO REGs to bind your PHY
PINs. I means maybe other drivers also use same PINs and re-configure them, so
they don't work properly as the first time. So you can try adding some codes to
re-initial PINs as PHY expect on here to check this again.
Tiejun
>
> # ifconfig eth0 192.168.0.4
> ------------[ cut here ]------------
> kernel BUG at drivers/net/fs_enet/mii-fec.c:58!
> Oops: Exception in kernel mode, sig: 5 [#1]
> MyMPC870
> NIP: c012b79c LR: c012963c CTR: c012b77c
> REGS: c7457c60 TRAP: 0700 Not tainted (2.6.33.5)
> MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24020042 XER: 20000000
> TASK = c7840000[236] 'ifconfig' THREAD: c7456000
> GPR00: 00000001 c7457d10 c7840000 c7845400 00000000 00000001 ffffffff 00000000
> GPR08: c77c44fc c906ce00 c784806c 00000b9f 84020042 100b986c 10096042 1009604f
> GPR16: 1009603b 10096030 10096001 100b188e c7457e18 ffff8914 c742430c c740b000
> GPR24: c7424300 c78443c0 00000001 00000000 c7845428 c7845400 c7845600 c7845600
> NIP [c012b79c] fs_enet_fec_mii_read+0x20/0x90
> LR [c012963c] mdiobus_read+0x50/0x74
> Call Trace:
> [c7457d10] [c0115744] driver_bound+0x60/0xa0 (unreliable)
> [c7457d30] [c0129094] genphy_config_init+0x24/0xd4
> [c7457d40] [c0128920] phy_init_hw+0x4c/0x78
> [c7457d50] [c0128a40] phy_connect_direct+0x24/0x88
> [c7457d70] [c0133e50] of_phy_connect+0x48/0x6c
> [c7457d90] [c012ae10] fs_enet_open+0xf0/0x2cc
> [c7457db0] [c0148a54] dev_open+0x100/0x138
> [c7457dd0] [c0146ca0] dev_change_flags+0x80/0x1a8
> [c7457df0] [c018e104] devinet_ioctl+0x630/0x750
> [c7457e60] [c018eb5c] inet_ioctl+0xcc/0xf8
> [c7457e70] [c01370d8] sock_ioctl+0x60/0x28c
> [c7457e90] [c007dbcc] vfs_ioctl+0x38/0x9c
> [c7457ea0] [c007ddf0] do_vfs_ioctl+0x84/0x708
> [c7457f10] [c007e4b4] sys_ioctl+0x40/0x74
> [c7457f40] [c000de60] ret_from_syscall+0x0/0x38
> Instruction dump:
> 80010014 7c0803a6 38210010 4e800020 81230018 81290000 7c0004ac 80090144
> 0c000000 4c00012c 68000004 5400f7fe <0f000000> 5484b810 64846002 54a5925a
> ---[ end trace 41bf95259a68372e ]---
> Trace/breakpoint trap
>
> I cannot find where the fec_r_cntrl would be reset to 0 after
> fs_enet_mdio_probe() sets it to FEC_RCNTRL_MII_MODE. Odd?
>
> Thanks,
> -Shawn.
>
^ permalink raw reply
* [PATCH][v0] RTC driver(Linux) for PT7C4338 chip.
From: Priyanka Jain @ 2010-10-25 8:08 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: Priyanka Jain
PT7C4338 chip is manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile RAM.
Freescale P1010RDB uses PT7C4338 as RTC.
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
Based of unified git(next branch) for P1010 RDB.
drivers/rtc/Kconfig | 9 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-pt7c4338.c | 215 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 225 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-pt7c4338.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 10ba12c..6ff0901 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -324,6 +324,15 @@ config RTC_DRV_RX8025
This driver can also be built as a module. If so, the module
will be called rtc-rx8025.
+config RTC_DRV_PT7C4338
+ tristate "Pericom Technology Inc. PT7C4338 RTC"
+ help
+ If you say yes here you get support for the Pericom Technology
+ Inc. PT7C4338 RTC chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-pt7c4338.
+
endif # I2C
comment "SPI RTC drivers"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 5adbba7..4014607 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_RTC_DRV_PCF50633) += rtc-pcf50633.o
obj-$(CONFIG_RTC_DRV_PL030) += rtc-pl030.o
obj-$(CONFIG_RTC_DRV_PL031) += rtc-pl031.o
obj-$(CONFIG_RTC_DRV_PS3) += rtc-ps3.o
+obj-$(CONFIG_RTC_DRV_PT7C4338) += rtc-pt7c4338.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701) += rtc-r9701.o
obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
diff --git a/drivers/rtc/rtc-pt7c4338.c b/drivers/rtc/rtc-pt7c4338.c
new file mode 100644
index 0000000..fca52cd
--- /dev/null
+++ b/drivers/rtc/rtc-pt7c4338.c
@@ -0,0 +1,215 @@
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ *
+ * Author: Priyanka Jain <Priyanka.Jain@freescale.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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
+ */
+
+/*
+ * This file provides Date & Time support (no alarms) for PT7C4338 chip.
+ *
+ * This file is based on drivers/rtc/rtc-ds1307.c
+ *
+ * PT7C4338 chip is manufactured by Pericom Technology Inc.
+ * It is a serial real-time clock which provides
+ * 1)Low-power clock/calendar.
+ * 2)Programmable square-wave output.
+ * It has 56 bytes of nonvolatile RAM.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/rtc.h>
+#include <linux/bcd.h>
+
+/* RTC register addresses */
+#define PT7C4338_REG_SECONDS 0x00
+#define PT7C4338_REG_MINUTES 0x01
+#define PT7C4338_REG_HOURS 0x02
+#define PT7C4338_REG_AMPM 0x02
+#define PT7C4338_REG_DAY 0x03
+#define PT7C4338_REG_DATE 0x04
+#define PT7C4338_REG_MONTH 0x05
+#define PT7C4338_REG_YEAR 0x06
+#define PT7C4338_REG_CTRL_STAT 0x07
+
+/* RTC second register address bit */
+#define PT7C4338_SEC_BIT_CH 0x80 /*Clock Halt (in Register 0)*/
+
+/* RTC control and status register bits */
+#define PT7C4338_CTRL_STAT_BIT_RS0 0x1 /*Rate select 0*/
+#define PT7C4338_CTRL_STAT_BIT_RS1 0x2 /*Rate select 1*/
+#define PT7C4338_CTRL_STAT_BIT_SQWE 0x10 /*Square Wave Enable*/
+#define PT7C4338_CTRL_STAT_BIT_OSF 0x20 /*Oscillator Stop Flag*/
+#define PT7C4338_CTRL_STAT_BIT_OUT 0x80 /*Output Level Control*/
+
+static const struct i2c_device_id pt7c4338_id[] = {
+ { "pt7c4338", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, pt7c4338_id);
+
+struct pt7c4338{
+ struct i2c_client *client;
+ struct rtc_device *rtc;
+};
+
+static int pt7c4338_read_time(struct device *dev, struct rtc_time *time)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ int ret;
+ u8 buf[7];
+ u8 year, month, day, hour, minute, second;
+ u8 week, twelve_hr, am_pm;
+
+ ret = i2c_smbus_read_i2c_block_data(client,
+ PT7C4338_REG_SECONDS, 7, buf);
+ if (ret < 0)
+ return ret;
+ if (ret < 7)
+ return -EIO;
+
+ second = buf[0];
+ minute = buf[1];
+ hour = buf[2];
+ week = buf[3];
+ day = buf[4];
+ month = buf[5];
+ year = buf[6];
+
+ /* Extract additional information for AM/PM */
+ twelve_hr = hour & 0x40;
+ am_pm = hour & 0x20;
+
+ /* Write to rtc_time structure */
+ time->tm_sec = bcd2bin(second & 0x7f);
+ time->tm_min = bcd2bin(minute & 0x7f);
+ if (twelve_hr) {
+ /* Convert to 24 hr */
+ if (am_pm)
+ time->tm_hour = bcd2bin(hour & 0x10) + 12;
+ else
+ time->tm_hour = bcd2bin(hour & 0xBF);
+ } else {
+ time->tm_hour = bcd2bin(hour);
+ }
+
+ time->tm_wday = bcd2bin(week & 0x07) - 1;
+ time->tm_mday = bcd2bin(day & 0x3f);
+ time->tm_mon = bcd2bin(month & 0x1F) - 1;
+ /* assume 20YY not 19YY */
+ time->tm_year = bcd2bin(year) + 100;
+
+ return 0;
+}
+
+static int pt7c4338_set_time(struct device *dev, struct rtc_time *time)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ u8 buf[7];
+
+ /* Extract time from rtc_time and load into pt7c4338*/
+ buf[0] = bin2bcd(time->tm_sec);
+ buf[1] = bin2bcd(time->tm_min);
+ buf[2] = bin2bcd(time->tm_hour);
+ buf[3] = bin2bcd(time->tm_wday + 1); /* Day of the week */
+ buf[4] = bin2bcd(time->tm_mday); /* Date */
+ buf[5] = bin2bcd(time->tm_mon + 1);
+
+ /* assume 20YY not 19YY */
+ if (time->tm_year >= 100)
+ buf[6] = bin2bcd(time->tm_year - 100);
+ else
+ buf[6] = bin2bcd(time->tm_year);
+
+ return i2c_smbus_write_i2c_block_data(client,
+ PT7C4338_REG_SECONDS, 7, buf);
+}
+
+static const struct rtc_class_ops pt7c4338_rtc_ops = {
+ .read_time = pt7c4338_read_time,
+ .set_time = pt7c4338_set_time,
+};
+
+static int pt7c4338_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct pt7c4338 *pt7c4338;
+ struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
+ int ret;
+
+ pt7c4338 = kzalloc(sizeof(struct pt7c4338), GFP_KERNEL);
+ if (!pt7c4338)
+ return -ENOMEM;
+
+ pt7c4338->client = client;
+ i2c_set_clientdata(client, pt7c4338);
+ pt7c4338->rtc = rtc_device_register(client->name, &client->dev,
+ &pt7c4338_rtc_ops, THIS_MODULE);
+ if (IS_ERR(pt7c4338->rtc)) {
+ ret = PTR_ERR(pt7c4338->rtc);
+ dev_err(&client->dev, "unable to register the class device\n");
+ goto out_free;
+ }
+
+ return 0;
+out_free:
+ i2c_set_clientdata(client, NULL);
+ kfree(pt7c4338);
+ return ret;
+}
+
+static int __devexit pt7c4338_remove(struct i2c_client *client)
+{
+ struct pt7c4338 *pt7c4338 = i2c_get_clientdata(client);
+
+ rtc_device_unregister(pt7c4338->rtc);
+ i2c_set_clientdata(client, NULL);
+ kfree(pt7c4338);
+ return 0;
+}
+
+static struct i2c_driver pt7c4338_driver = {
+ .driver = {
+ .name = "rtc-pt7c4338",
+ .owner = THIS_MODULE,
+ },
+ .probe = pt7c4338_probe,
+ .remove = __devexit_p(pt7c4338_remove),
+ .id_table = pt7c4338_id,
+};
+
+static int __init pt7c4338_init(void)
+{
+ return i2c_add_driver(&pt7c4338_driver);
+}
+
+static void __exit pt7c4338_exit(void)
+{
+ i2c_del_driver(&pt7c4338_driver);
+}
+
+module_init(pt7c4338_init);
+module_exit(pt7c4338_exit);
+
+MODULE_AUTHOR("Priyanka Jain <Priyanka.Jain@freescale.com>");
+MODULE_DESCRIPTION("pericom Technology Inc. PT7C4338 RTC Driver");
+MODULE_LICENSE("GPL");
--
1.6.5.6
^ permalink raw reply related
* [PATCH] powerpc/mpc5200: MPC5200 ATA driver requires BMDMA to be configured
From: Roman Fietze @ 2010-10-25 7:21 UTC (permalink / raw)
To: linuxppc-dev
Hello List Members,
I updated to v2.6.34 from torvalds/master.
While playing around with ATA settings (I have problems with MWDMA2 on
a Lite5200B compatible board, the problems are not related to this
patch here), I also turned off BMDMA, which caused compile errors on
pata_mpc52xx. So my question is, is the patch below correct? Should we
only offer the pata_mpc52xx if BMDMA is configured?
Subject: [PATCH] powerpc/mpc5200: MPC5200 ATA driver requires BMDMA to be
configured
The driver uses e.g. bmdma_setup which is only available with
ATA_BMDMA beeing configured.
Move the configuration of the driver pata_mpc52xx down in Kconfig to
the section "PATA SFF controllers with BMDMA".
Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
---
drivers/ata/Kconfig | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 11ec911..85756b8 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -128,16 +128,6 @@ config PDC_ADMA
If unsure, say N.
-config PATA_MPC52xx
- tristate "Freescale MPC52xx SoC internal IDE"
- depends on PPC_MPC52xx && PPC_BESTCOMM
- select PPC_BESTCOMM_ATA
- help
- This option enables support for integrated IDE controller
- of the Freescale MPC52xx SoC.
-
- If unsure, say N.
-
config PATA_OCTEON_CF
tristate "OCTEON Boot Bus Compact Flash support"
depends on CPU_CAVIUM_OCTEON
@@ -491,6 +481,16 @@ config PATA_MARVELL
If unsure, say N.
+config PATA_MPC52xx
+ tristate "Freescale MPC52xx SoC internal IDE"
+ depends on PPC_MPC52xx && PPC_BESTCOMM
+ select PPC_BESTCOMM_ATA
+ help
+ This option enables support for integrated IDE controller
+ of the Freescale MPC52xx SoC.
+
+ If unsure, say N.
+
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
depends on PCI
--
1.7.3.1
Roman
--
Roman Fietze Telemotive AG Buero Muehlhausen
Breitwiesen 73347 Muehlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply related
* Re: linux-next: build warning in Linus' tree
From: Stephen Rothwell @ 2010-10-25 6:03 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: linuxppc-dev, H. Peter Anvin, Linus Torvalds, Jan Beulich
In-Reply-To: <1287978429-18542-1-git-send-email-lacombar@gmail.com>
Hi Arnaud,
On Sun, 24 Oct 2010 23:47:09 -0400 Arnaud Lacombe <lacombar@gmail.com> wrote:
>
> The following patch should fix this warning.
I think the following is preferable. Not tested yet, I will test
tomorrow and submit properly then.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 25 Oct 2010 16:57:47 +1100
Subject: [PATCH] powerpc: remove second definition of STACK_FRAME_OVERHEAD
Since STACK_FRAME_OVERHEAD is defined in asm/ptrace.h and that
is ASSEMBER safe, we can just include that instead of going via
asm-offsets.h.
Eliminated build warnings about a duplicate definition now that
the asm-offsets.h version has parentheses around the values.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/asm-offsets.c | 1 -
arch/powerpc/kernel/entry_32.S | 1 +
arch/powerpc/kernel/exceptions-64s.S | 1 +
arch/powerpc/kernel/fpu.S | 1 +
arch/powerpc/kernel/head_40x.S | 1 +
arch/powerpc/kernel/head_44x.S | 1 +
arch/powerpc/kernel/head_64.S | 1 +
arch/powerpc/kernel/head_8xx.S | 1 +
arch/powerpc/kernel/head_fsl_booke.S | 1 +
arch/powerpc/kernel/misc_32.S | 1 +
arch/powerpc/kernel/misc_64.S | 1 +
arch/powerpc/kernel/ppc_save_regs.S | 1 +
arch/powerpc/kernel/vector.S | 1 +
arch/powerpc/platforms/pseries/hvCall.S | 1 +
14 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index bd0df2e..23e6a93 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -209,7 +209,6 @@ int main(void)
DEFINE(RTASENTRY, offsetof(struct rtas_t, entry));
/* Interrupt register frame */
- DEFINE(STACK_FRAME_OVERHEAD, STACK_FRAME_OVERHEAD);
DEFINE(INT_FRAME_SIZE, STACK_INT_FRAME_SIZE);
DEFINE(SWITCH_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs));
#ifdef CONFIG_PPC64
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index ed4aeb9..c22dc1e 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -31,6 +31,7 @@
#include <asm/asm-offsets.h>
#include <asm/unistd.h>
#include <asm/ftrace.h>
+#include <asm/ptrace.h>
#undef SHOW_SYSCALLS
#undef SHOW_SYSCALLS_TASK
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 9f8b01d..8a81799 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -13,6 +13,7 @@
*/
#include <asm/exception-64s.h>
+#include <asm/ptrace.h>
/*
* We layout physical memory as follows:
diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
index e86c040..de36955 100644
--- a/arch/powerpc/kernel/fpu.S
+++ b/arch/powerpc/kernel/fpu.S
@@ -23,6 +23,7 @@
#include <asm/thread_info.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
#ifdef CONFIG_VSX
#define REST_32FPVSRS(n,c,base) \
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 8278e8b..9dd21a8 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -40,6 +40,7 @@
#include <asm/thread_info.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
/* As with the other PowerPC ports, it is expected that when code
* execution begins here, the following registers contain valid, yet
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 562305b..cbb3436 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -37,6 +37,7 @@
#include <asm/thread_info.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
#include <asm/synch.h>
#include "head_booke.h"
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index f0dd577..ce41b97 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -38,6 +38,7 @@
#include <asm/page_64.h>
#include <asm/irqflags.h>
#include <asm/kvm_book3s_asm.h>
+#include <asm/ptrace.h>
/* The physical memory is layed out such that the secondary processor
* spin code sits at 0x0000...0x00ff. On server, the vectors follow
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 1f1a04b..1cbf64e 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -29,6 +29,7 @@
#include <asm/thread_info.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
/* Macro to make the code more readable. */
#ifdef CONFIG_8xx_CPU6
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 529b817..3e02710 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -41,6 +41,7 @@
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
#include <asm/cache.h>
+#include <asm/ptrace.h>
#include "head_booke.h"
/* As with the other PowerPC ports, it is expected that when code
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index a7a570d..094bd98 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -30,6 +30,7 @@
#include <asm/processor.h>
#include <asm/kexec.h>
#include <asm/bug.h>
+#include <asm/ptrace.h>
.text
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index e514490..206a321 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -25,6 +25,7 @@
#include <asm/cputable.h>
#include <asm/thread_info.h>
#include <asm/kexec.h>
+#include <asm/ptrace.h>
.text
diff --git a/arch/powerpc/kernel/ppc_save_regs.S b/arch/powerpc/kernel/ppc_save_regs.S
index 5113bd2..e83ba3f 100644
--- a/arch/powerpc/kernel/ppc_save_regs.S
+++ b/arch/powerpc/kernel/ppc_save_regs.S
@@ -11,6 +11,7 @@
#include <asm/processor.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
/*
* Grab the register values as they are now.
diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
index fe46048..9de6f39 100644
--- a/arch/powerpc/kernel/vector.S
+++ b/arch/powerpc/kernel/vector.S
@@ -5,6 +5,7 @@
#include <asm/cputable.h>
#include <asm/thread_info.h>
#include <asm/page.h>
+#include <asm/ptrace.h>
/*
* load_up_altivec(unused, unused, tsk)
diff --git a/arch/powerpc/platforms/pseries/hvCall.S b/arch/powerpc/platforms/pseries/hvCall.S
index 48d2057..fd05fde 100644
--- a/arch/powerpc/platforms/pseries/hvCall.S
+++ b/arch/powerpc/platforms/pseries/hvCall.S
@@ -11,6 +11,7 @@
#include <asm/processor.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
#define STK_PARM(i) (48 + ((i)-3)*8)
--
1.7.2.3
^ permalink raw reply related
* Re: linux-next: build warning in Linus' tree
From: Arnaud Lacombe @ 2010-10-25 3:47 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linuxppc-dev, H. Peter Anvin, Linus Torvalds, Arnaud Lacombe,
Jan Beulich
In-Reply-To: <20101025135237.337b8321.sfr@canb.auug.org.au>
Hi,
[adding linuxppc-dev@lists.ozlabs.org to the CC's list]
On Sun, Oct 24, 2010 at 10:52 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> In building Linus' tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> In file included from arch/powerpc/platforms/iseries/exception.S:32:
> arch/powerpc/include/asm/ptrace.h:60:1: warning: "STACK_FRAME_OVERHEAD" redefined
> In file included from arch/powerpc/include/asm/asm-offsets.h:1,
> from arch/powerpc/platforms/iseries/exception.S:30:
> include/generated/asm-offsets.h:87:1: warning: this is the location of the previous definition
>
> Caused by commit 3234282f33b29d349bcada40204fc7c8fda7fe72 ("x86, asm: Fix
> CFI macro invocations to deal with shortcomings in gas").
The following patch should fix this warning.
- Arnaud
From: Arnaud Lacombe <lacombar@gmail.com>
Date: Sun, 24 Oct 2010 20:39:53 -0400
Subject: [PATCH] powerpc: wrap STACK_FRAME_OVERHEAD definition around parenthesis
Although the value does not need protection, wrapping it around parenthesis make
it match the definition from `include/generated/asm-offsets.h' and silent the
following gcc's warning:
In file included from arch/powerpc/kernel/head_32.S:34:0:
arch/powerpc/include/asm/ptrace.h:73:0: warning: "STACK_FRAME_OVERHEAD" redefined
include/generated/asm-offsets.h:28:0: note: this is the location of the previous definition
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
---
arch/powerpc/include/asm/ptrace.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 0175a67..3e18533 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -57,7 +57,7 @@ struct pt_regs {
#ifdef __powerpc64__
-#define STACK_FRAME_OVERHEAD 112 /* size of minimum stack frame */
+#define STACK_FRAME_OVERHEAD (112) /* size of minimum stack frame */
#define STACK_FRAME_LR_SAVE 2 /* Location of LR in stack frame */
#define STACK_FRAME_REGS_MARKER ASM_CONST(0x7265677368657265)
#define STACK_INT_FRAME_SIZE (sizeof(struct pt_regs) + \
@@ -70,7 +70,7 @@ struct pt_regs {
#else /* __powerpc64__ */
-#define STACK_FRAME_OVERHEAD 16 /* size of minimum stack frame */
+#define STACK_FRAME_OVERHEAD (16) /* size of minimum stack frame */
#define STACK_FRAME_LR_SAVE 1 /* Location of LR in stack frame */
#define STACK_FRAME_REGS_MARKER ASM_CONST(0x72656773)
#define STACK_INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD)
--
1.7.3.12.gf5e62.dirty
^ permalink raw reply related
* Re: BUG with the kernel version 2.6.36-rc1 on power machine
From: Yong Zhang @ 2010-10-23 9:36 UTC (permalink / raw)
To: Subrata Modak
Cc: linux-kernel, Linuxppc-dev, Paul Mackerras, Anton Blanchard,
divya
In-Reply-To: <1287774802.19497.1.camel@subratamodak.linux.ibm.com>
On Sat, Oct 23, 2010 at 12:43:21AM +0530, Subrata Modak wrote:
> This is equally seen for both Power6 and Power7 machines.
Seems resolved by part of http://lkml.org/lkml/2010/10/13/67
Thanks,
Yong
>
> Regards--
> Subrata
>
> On Sat, 2010-10-23 at 00:37 +0530, Subrata Modak wrote:
> >
> >
> > ---------- Forwarded message ----------
> > From: divya <dipraksh@linux.vnet.ibm.com>
> > Date: Fri, Oct 22, 2010 at 1:10 PM
> > Subject: Re: BUG with the kernel version 2.6.36-rc1 on power machine
> > To: LKML <linux-kernel@vger.kernel.org>, benh@kernel.crashing.org,
> > linuxppc-dev@ozlabs.org
> >
> >
> >
> > On Friday 22 October 2010 12:50 PM, divya wrote:
> > Hi ,
> >
> > With the latest version of kernel 2.6.36-rc1 running on the
> > power machine, came across the following call trace
> >
> > BUG: looking up invalid subclass: 31
> > turning off the locking correctness validator.
> > Call Trace:
> > [c00000000e0bfb60] [c0000000000119a0] .show_stack+0x6c/0x16c
> > (unreliable)
> > [c00000000e0bfc10] [c0000000000c39b8] .lockdep_init_map
> > +0x194/0x630
> > [c00000000e0bfcf0] [c0000000005524f8] .mousedev_create
> > +0xcc/0x234
> > [c00000000e0bfda0] [c00000000093fb58] .mousedev_init+0x38/0xa0
> > [c00000000e0bfe30] [c0000000000097e4] .do_one_initcall
> > +0xd8/0x1c8
> > [c00000000e0bfee0] [c0000000009004ac] .kernel_init+0x23c/0x2f8
> > [c00000000e0bff90] [c00000000002ad30] .kernel_thread+0x54/0x70
> >
> > The config file used for make oldconfig is being attached
> >
> > Thanks
> > Divya
> >
> >
> >
> >
> > I meant 2.6.36-git1(b5153163ed580e) , and not 2.6.36-rc1.
> > Sorry for the confusion.
> >
> > Thanks
> > Divya
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> >
> >
> >
> > --
> > Regards & Thanks--
> > Subrata
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches
From: Micha Nelissen @ 2010-10-22 21:58 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linux-kernel, Thomas Moll, akpm, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55201445A6B@CORPEXCH1.na.ads.idt.com>
Bounine, Alexandre wrote:
> Micha Nelissen <micha@neli.hopto.org> wrote:
>> rswitch->rdev->destid should be the id associated with a given switch,
>> so that every (processor) device can agree what id some switch has.
>
> If we will need to identify the same physical switch by different
> processors we may use the component tag which now is unique for every
> device.
Yes, identification is the point. I think it might be confusing to have
a destid *and* a component tag id which are slightly different. The
destid is unambiguous (if you know whether the device is a switch or
endpoint) so I think it makes sense to use that if possible.
> This actually gives me another idea: instead of using global
> next_switchid counter make rswitch->switchid = component_tag and
> switches in sysfs will look identical for every processor (or just get
> rid of rswitch->switchid and use component_tag directly for switches).
I still prefer the destid as the single identification id.
Micha
^ permalink raw reply
* RE: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches
From: Bounine, Alexandre @ 2010-10-22 21:04 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linux-kernel, Thomas Moll, akpm, linuxppc-dev
In-Reply-To: <4CC1D7DE.7060405@neli.hopto.org>
Micha Nelissen <micha@neli.hopto.org> wrote:
>=20
> Bounine, Alexandre wrote:
> > Looks like I formulated it bad - better would be: they have
different
> > interpretation by hardware but logically in RapidIO they have single
> > role - destid/hopcount are a device coordinates in the RIO network
used
> > to access that device.
>=20
> They are logically different as well (for a non-host).
>=20
> rswitch->destid with hopcount is the way to reach that switch.
>=20
OK. This is moved to rdev->destid now to make access unified with
endpoints.=20
> rswitch->rdev->destid should be the id associated with a given switch,
> so that every (processor) device can agree what id some switch has.
For
> a non-host, the path to reach a switch may use a different id than the
> switch itself has; it's just the id by which it was discovered.
> However, it's possible to fix that by fixing the id+hopcount once the
> switch is found using the path with its own id: then you know the
right
> hopcount.
I have got an impression that we are discussing slightly different
implementations
here. The suggested role of rswitch->rdev->destid is not clear to me.
I agree that destid and hopcount for switch will be different for every
processor.
There is nothing wrong with it because a switch physically does not have
its own ID.
If we will need to identify the same physical switch by different
processors we may use the component tag which now is unique for every
device.
This actually gives me another idea: instead of using global
next_switchid counter make rswitch->switchid =3D component_tag and
switches in sysfs will look identical for every processor (or just get
rid of rswitch->switchid and use component_tag directly for switches).
> >> can be defined to point to the switch that a given rio_dev is
> > connected
> >> to. This is useful for quick lookups. How else can to know to which
> >> switch a given device is connected?
> >
> > rdev->rswitch is not a pointer to the entire switch device object -
it
> > is a pointer to the switch specific extension associated with given
> > rio_dev (if applicable). There is no other role for rdev->rswitch.
>=20
> I know this, it doesn't answer my question.
>=20
> > Why would you keep a pointer to device data extension instead of the
> > pointer to attached device object itself?
>=20
> There is no particular reason, but this is a useful way to define the
> fields that are there.
>=20
> My point is, now that you remove the pointer field, that information
(to
> which switch is a particular device connected) cannot be stored in
this
> way, so do you have an alternative proposal for that? Maybe add a new
field.
>
See my comment below ;).
> > BTW, I have back and forward links added in previous patches and
only
> > one link that may be added later is a forward link from mport to the
> > attached rio_dev (ptr to rio_switch will not work here because it
can be
> > switchless connection). But this reference has to be added into
> > rio_mport.
>=20
> Possible, but I suggest to put it in the rio_net: fields rdev_host,
and
> rdev_self. You can see it in the patch I sent you.
Yes, we may rework rio_net that way and use some good things from there.
Alex.
^ permalink raw reply
* Re: [PATCH 0/9] Typo fixes of faild to failed
From: Mike Frysinger @ 2010-10-22 20:15 UTC (permalink / raw)
To: Joe Perches
Cc: cbe-oss-dev, jfs-discussion, Jiri Kosina, rtc-linux, netdev,
linux-kernel, dri-devel, linux-ide, osd-dev, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <cover.1287724261.git.joe@perches.com>
On Fri, Oct 22, 2010 at 01:17, Joe Perches wrote:
> =C2=A0drivers/ata/pata_bf54x.c =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=
=A0 =C2=A02 +-
> =C2=A0drivers/video/bf54x-lq043fb.c =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A06 =
+++---
> =C2=A0drivers/video/bfin-t350mcqb-fb.c =C2=A0 | =C2=A0 =C2=A02 +-
Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
^ permalink raw reply
* Re: BUG with the kernel version 2.6.36-rc1 on power machine
From: Subrata Modak @ 2010-10-22 19:13 UTC (permalink / raw)
To: linux-kernel, Linuxppc-dev; +Cc: Paul Mackerras, Anton Blanchard, divya
In-Reply-To: <AANLkTikmpohofzO_dV_Dv8EfcEMsyy4cdhGMUD-PAFO3@mail.gmail.com>
This is equally seen for both Power6 and Power7 machines.
Regards--
Subrata
On Sat, 2010-10-23 at 00:37 +0530, Subrata Modak wrote:
>
>
> ---------- Forwarded message ----------
> From: divya <dipraksh@linux.vnet.ibm.com>
> Date: Fri, Oct 22, 2010 at 1:10 PM
> Subject: Re: BUG with the kernel version 2.6.36-rc1 on power machine
> To: LKML <linux-kernel@vger.kernel.org>, benh@kernel.crashing.org,
> linuxppc-dev@ozlabs.org
>
>
>
> On Friday 22 October 2010 12:50 PM, divya wrote:
> Hi ,
>
> With the latest version of kernel 2.6.36-rc1 running on the
> power machine, came across the following call trace
>
> BUG: looking up invalid subclass: 31
> turning off the locking correctness validator.
> Call Trace:
> [c00000000e0bfb60] [c0000000000119a0] .show_stack+0x6c/0x16c
> (unreliable)
> [c00000000e0bfc10] [c0000000000c39b8] .lockdep_init_map
> +0x194/0x630
> [c00000000e0bfcf0] [c0000000005524f8] .mousedev_create
> +0xcc/0x234
> [c00000000e0bfda0] [c00000000093fb58] .mousedev_init+0x38/0xa0
> [c00000000e0bfe30] [c0000000000097e4] .do_one_initcall
> +0xd8/0x1c8
> [c00000000e0bfee0] [c0000000009004ac] .kernel_init+0x23c/0x2f8
> [c00000000e0bff90] [c00000000002ad30] .kernel_thread+0x54/0x70
>
> The config file used for make oldconfig is being attached
>
> Thanks
> Divya
>
>
>
>
> I meant 2.6.36-git1(b5153163ed580e) , and not 2.6.36-rc1.
> Sorry for the confusion.
>
> Thanks
> Divya
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
> --
> Regards & Thanks--
> Subrata
^ permalink raw reply
* Re: BUG with the kernel version 2.6.36-rc1 on power machine
From: Subrata Modak @ 2010-10-22 19:04 UTC (permalink / raw)
To: LKML, linuxppc-dev; +Cc: Paul Mackerras, Anton Blanchard, divya
In-Reply-To: <4CC13FFF.7040200@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
This is seen equally on Power6 & Power7 systems.
Regards--
Subrata
On Fri, Oct 22, 2010 at 1:10 PM, divya <dipraksh@linux.vnet.ibm.com> wrote:
> On Friday 22 October 2010 12:50 PM, divya wrote:
>
>> Hi ,
>>
>> With the latest version of kernel 2.6.36-rc1 running on the power machine,
>> came across the following call trace
>>
>> BUG: looking up invalid subclass: 31
>> turning off the locking correctness validator.
>> Call Trace:
>> [c00000000e0bfb60] [c0000000000119a0] .show_stack+0x6c/0x16c (unreliable)
>> [c00000000e0bfc10] [c0000000000c39b8] .lockdep_init_map+0x194/0x630
>> [c00000000e0bfcf0] [c0000000005524f8] .mousedev_create+0xcc/0x234
>> [c00000000e0bfda0] [c00000000093fb58] .mousedev_init+0x38/0xa0
>> [c00000000e0bfe30] [c0000000000097e4] .do_one_initcall+0xd8/0x1c8
>> [c00000000e0bfee0] [c0000000009004ac] .kernel_init+0x23c/0x2f8
>> [c00000000e0bff90] [c00000000002ad30] .kernel_thread+0x54/0x70
>>
>> The config file used for make oldconfig is being attached
>>
>> Thanks
>> Divya
>>
>>
>>
>>
>> I meant 2.6.36-git1(b5153163ed580e) , and not 2.6.36-rc1.
> Sorry for the confusion.
>
> Thanks
> Divya
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Regards & Thanks--
Subrata
[-- Attachment #2: Type: text/html, Size: 2234 bytes --]
^ permalink raw reply
* Re: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches
From: Micha Nelissen @ 2010-10-22 18:28 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linux-kernel, Thomas Moll, akpm, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55201445906@CORPEXCH1.na.ads.idt.com>
Bounine, Alexandre wrote:
> Micha Nelissen <micha@neli.hopto.org> wrote:
>> Alexandre Bounine wrote:
>> How can you say this? The two variables have different meanings, this
>> logically implies you can't merge them. So how do you say 'this does
> not
>> prevent us from ...' without providing a reason?
>
> Looks like I formulated it bad - better would be: they have different
> interpretation by hardware but logically in RapidIO they have single
> role - destid/hopcount are a device coordinates in the RIO network used
> to access that device.
They are logically different as well (for a non-host).
rswitch->destid with hopcount is the way to reach that switch.
rswitch->rdev->destid should be the id associated with a given switch,
so that every (processor) device can agree what id some switch has. For
a non-host, the path to reach a switch may use a different id than the
switch itself has; it's just the id by which it was discovered.
However, it's possible to fix that by fixing the id+hopcount once the
switch is found using the path with its own id: then you know the right
hopcount.
>> can be defined to point to the switch that a given rio_dev is
> connected
>> to. This is useful for quick lookups. How else can to know to which
>> switch a given device is connected?
>
> rdev->rswitch is not a pointer to the entire switch device object - it
> is a pointer to the switch specific extension associated with given
> rio_dev (if applicable). There is no other role for rdev->rswitch.
I know this, it doesn't answer my question.
> Why would you keep a pointer to device data extension instead of the
> pointer to attached device object itself?
There is no particular reason, but this is a useful way to define the
fields that are there.
My point is, now that you remove the pointer field, that information (to
which switch is a particular device connected) cannot be stored in this
way, so do you have an alternative proposal for that? Maybe add a new field.
> BTW, I have back and forward links added in previous patches and only
> one link that may be added later is a forward link from mport to the
> attached rio_dev (ptr to rio_switch will not work here because it can be
> switchless connection). But this reference has to be added into
> rio_mport.
Possible, but I suggest to put it in the rio_net: fields rdev_host, and
rdev_self. You can see it in the patch I sent you.
Micha
^ permalink raw reply
* [RFC][PATCH 7/8] Removal of dead code from arch/powerpc/mm/tlb_low_64e.S and arch/powerpc/include/asm/exception-64e.h
From: N.P.S. @ 2010-10-22 18:25 UTC (permalink / raw)
To: linux-kernel, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev
In-Reply-To: <4CC1D2D5.9050009@gmail.com>
commit bca5655fdfd3ad0a4891914bd88b28f78e5cec16
Author: N.P.S <napohybelskurwysynom2010@gmail.com>
Date: Thu Oct 21 23:26:48 2010 +0200
Removal of dead code from
arch/powerpc/mm/tlb_low_64e.S
arch/powerpc/include/asm/exception-64e.h
Signed-off-by: Zimny Lech <napohybelskurwysynom2010@gmail.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: <linuxppc-dev@lists.ozlabs.org>
CC: <linux-kernel@vger.kernel.org>
diff --git a/arch/powerpc/include/asm/exception-64e.h b/arch/powerpc/include/asm/exception-64e.h
index 6d53f31..db74814 100644
--- a/arch/powerpc/include/asm/exception-64e.h
+++ b/arch/powerpc/include/asm/exception-64e.h
@@ -65,14 +65,7 @@
#define EX_TLB_MMUCR0 (12 * 8) /* Level 0 */
#define EX_TLB_MAS1 (12 * 8) /* Level 0 */
#define EX_TLB_MAS2 (13 * 8) /* Level 0 */
-#ifdef CONFIG_BOOK3E_MMU_TLB_STATS
-#define EX_TLB_R8 (14 * 8)
-#define EX_TLB_R9 (15 * 8)
-#define EX_TLB_LR (16 * 8)
-#define EX_TLB_SIZE (17 * 8)
-#else
#define EX_TLB_SIZE (14 * 8)
-#endif
#define START_EXCEPTION(label) \
.globl exc_##label##_book3e; \
@@ -157,36 +150,6 @@ exc_##label##_book3e:
addi r11,r13,PACA_EXTLB; \
TLB_MISS_RESTORE(r11)
-#ifdef CONFIG_BOOK3E_MMU_TLB_STATS
-#define TLB_MISS_PROLOG_STATS \
- mflr r10; \
- std r8,EX_TLB_R8(r12); \
- std r9,EX_TLB_R9(r12); \
- std r10,EX_TLB_LR(r12);
-#define TLB_MISS_RESTORE_STATS \
- ld r16,EX_TLB_LR(r12); \
- ld r9,EX_TLB_R9(r12); \
- ld r8,EX_TLB_R8(r12); \
- mtlr r16;
-#define TLB_MISS_STATS_D(name) \
- addi r9,r13,MMSTAT_DSTATS+name; \
- bl .tlb_stat_inc;
-#define TLB_MISS_STATS_I(name) \
- addi r9,r13,MMSTAT_ISTATS+name; \
- bl .tlb_stat_inc;
-#define TLB_MISS_STATS_X(name) \
- ld r8,PACA_EXTLB+EX_TLB_ESR(r13); \
- cmpdi cr2,r8,-1; \
- beq cr2,61f; \
- addi r9,r13,MMSTAT_DSTATS+name; \
- b 62f; \
-61: addi r9,r13,MMSTAT_ISTATS+name; \
-62: bl .tlb_stat_inc;
-#define TLB_MISS_STATS_SAVE_INFO \
- std r14,EX_TLB_ESR(r12); /* save ESR */ \
-
-
-#else
#define TLB_MISS_PROLOG_STATS
#define TLB_MISS_RESTORE_STATS
#define TLB_MISS_STATS_D(name)
@@ -194,7 +157,6 @@ exc_##label##_book3e:
#define TLB_MISS_STATS_X(name)
#define TLB_MISS_STATS_Y(name)
#define TLB_MISS_STATS_SAVE_INFO
-#endif
#define SET_IVOR(vector_number, vector_offset) \
li r3,vector_offset@l; \
diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S
index 8b04c54..fc87217 100644
--- a/arch/powerpc/mm/tlb_low_64e.S
+++ b/arch/powerpc/mm/tlb_low_64e.S
@@ -757,13 +757,3 @@ tlb_load_linear_fault:
b exc_data_storage_book3e
1: TLB_MISS_EPILOG_ERROR_SPECIAL
b exc_instruction_storage_book3e
-
-
-#ifdef CONFIG_BOOK3E_MMU_TLB_STATS
-.tlb_stat_inc:
-1: ldarx r8,0,r9
- addi r8,r8,1
- stdcx. r8,0,r9
- bne- 1b
- blr
-#endif
^ permalink raw reply related
* [RFC][PATCH 6/8] Removal of dead code from arch/powerpc/kernel/process.c
From: N.P.S. @ 2010-10-22 18:24 UTC (permalink / raw)
To: linux-kernel, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev
In-Reply-To: <4CC1D2D5.9050009@gmail.com>
commit 12747993cb2b4a07df7a62f247f20aa4a6263cd9
Author: N.P.S <napohybelskurwysynom2010@gmail.com>
Date: Thu Oct 21 23:36:00 2010 +0200
Removal of dead code from
arch/powerpc/kernel/process.c
Signed-off-by: Zimny Lech <napohybelskurwysynom2010@gmail.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: <linuxppc-dev@lists.ozlabs.org>
CC: <linux-kernel@vger.kernel.org>
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index b1c648a..e622887 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -670,12 +670,7 @@ void exit_thread(void)
void flush_thread(void)
{
discard_lazy_cpu_state();
-
-#ifdef CONFIG_HAVE_HW_BREAKPOINTS
- flush_ptrace_hw_breakpoint(current);
-#else /* CONFIG_HAVE_HW_BREAKPOINTS */
set_debug_reg_defaults(¤t->thread);
-#endif /* CONFIG_HAVE_HW_BREAKPOINTS */
}
void
^ permalink raw reply related
* RE: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches
From: Bounine, Alexandre @ 2010-10-22 16:47 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linux-kernel, Thomas Moll, akpm, linuxppc-dev
In-Reply-To: <4CC0AD74.8070800@neli.hopto.org>
Micha Nelissen <micha@neli.hopto.org> wrote:
>=20
> Alexandre Bounine wrote:
> > 1. Using one storage location common for switches and endpoints
eliminates
> > unnecessary device type checks during maintenance access operations.
> > While destination IDs and hop counts have different meaning for
endpoints and
> > switches, this does not prevent us from storing them in the primary
RIO device
> > structure (rio_dev) for both types.
>=20
> How can you say this? The two variables have different meanings, this
> logically implies you can't merge them. So how do you say 'this does
not
> prevent us from ...' without providing a reason?
Looks like I formulated it bad - better would be: they have different
interpretation by hardware but logically in RapidIO they have single
role - destid/hopcount are a device coordinates in the RIO network used
to access that device.
> > 2. Convert RIO switch device structures (rio_dev + rio_switch) into
single
> > allocation unit. This change is based on the fact that RIO switches
are using
> > common RIO device objects anyway. Allocating RIO switch objects as
RIO devices
> > with added space for switch information simplifies handling of RIO
switch device
> > objects.
>=20
> I still don't think that's a good idea because the rdev->rswitch
pointer
> can be defined to point to the switch that a given rio_dev is
connected
> to. This is useful for quick lookups. How else can to know to which
> switch a given device is connected?
rdev->rswitch is not a pointer to the entire switch device object - it
is a pointer to the switch specific extension associated with given
rio_dev (if applicable). There is no other role for rdev->rswitch.
Why would you keep a pointer to device data extension instead of the
pointer to attached device object itself?
BTW, I have back and forward links added in previous patches and only
one link that may be added later is a forward link from mport to the
attached rio_dev (ptr to rio_switch will not work here because it can be
switchless connection). But this reference has to be added into
rio_mport.
=20
Alex.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix hcall tracepoint recursion
From: Steven Rostedt @ 2010-10-22 14:14 UTC (permalink / raw)
To: Anton Blanchard
Cc: ltp-list, Peter Zijlstra, linuxppc-dev, Li Zefan, LKML,
Paul Mackerras, Ingo Molnar, subrata
In-Reply-To: <20101021215212.4a982c85@kryten>
On Thu, 2010-10-21 at 21:52 +1100, Anton Blanchard wrote:
> Anton
> --
>
> Subject: [PATCH] powerpc: Fix hcall tracepoint recursion
>
> Spinlocks on shared processor partitions use H_YIELD to notify the
> hypervisor we are waiting on another virtual CPU. Unfortunately this means
> the hcall tracepoints can recurse.
>
> The patch below adds a percpu depth and checks it on both the entry and
> exit hcall tracepoints.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: powerpc.git/arch/powerpc/platforms/pseries/lpar.c
> ===================================================================
> --- powerpc.git.orig/arch/powerpc/platforms/pseries/lpar.c 2010-10-21 17:32:00.980003644 +1100
> +++ powerpc.git/arch/powerpc/platforms/pseries/lpar.c 2010-10-21 17:34:54.942681273 +1100
> @@ -701,6 +701,13 @@ EXPORT_SYMBOL(arch_free_page);
> /* NB: reg/unreg are called while guarded with the tracepoints_mutex */
> extern long hcall_tracepoint_refcount;
>
> +/*
> + * Since the tracing code might execute hcalls we need to guard against
> + * recursion. One example of this are spinlocks calling H_YIELD on
> + * shared processor partitions.
> + */
> +static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);
> +
> void hcall_tracepoint_regfunc(void)
> {
> hcall_tracepoint_refcount++;
> @@ -713,12 +720,42 @@ void hcall_tracepoint_unregfunc(void)
>
> void __trace_hcall_entry(unsigned long opcode, unsigned long *args)
> {
> + unsigned long flags;
> + unsigned int *depth;
> +
> + local_irq_save(flags);
> +
> + depth = &__get_cpu_var(hcall_trace_depth);
> +
> + if (*depth)
> + goto out;
> +
> + (*depth)++;
> trace_hcall_entry(opcode, args);
> + (*depth)--;
> +
> +out:
> + local_irq_restore(flags);
> }
>
> void __trace_hcall_exit(long opcode, unsigned long retval,
> unsigned long *retbuf)
> {
> + unsigned long flags;
> + unsigned int *depth;
> +
> + local_irq_save(flags);
> +
> + depth = &__get_cpu_var(hcall_trace_depth);
> +
> + if (*depth)
> + goto out;
> +
> + (*depth)++;
> trace_hcall_exit(opcode, retval, retbuf);
> + (*depth)--;
> +
> +out:
> + local_irq_restore(flags);
> }
> #endif
That's similar to the example that I wrote, but without the encapsulated
code and with disabling interrupts for the reasons you gave.
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
^ 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