* Re: [PATCH 5/5] hvc_console: Fix race between hvc_close and hvc_remove
From: John Kacur @ 2010-06-11 13:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Rusty Russell, Clark Williams, Greg Kroah-Hartman,
Arnaldo Carvalho de Melo, linuxppc-dev, Amit Shah,
Thomas Gleixner, Luis Claudio R. Goncalves, Alan Cox
In-Reply-To: <1683892268.3009511276260172853.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
----- "Stephen Rothwell" <sfr@canb.auug.org.au> wrote:
> Hi John,
>
> On Thu, 10 Jun 2010 13:03:00 +0200 John Kacur <jkacur@redhat.com>
> wrote:
> >
> > From: Amit Shah <amit.shah@redhat.com>
> >
> > Alan pointed out a race in the code where hvc_remove is invoked.
> The
> > recent virtio_console work is the first user of hvc_remove().
>
> I am not sure where this comes from (linuxppc-dev only got 5/5) but
> this
> patch was applied to Linus' tree quite some time age (and fixed since
> then).
>
Thanks for responding Stephen.
I was just listing patches that Thomas could potentially include
in the real-time kernel which is currently based on 2.6.33.5
I hadn't intended for git-send-email to cc everyone, but it
automatically included authors. sigh. I'll make sure to suppress that
next time.
John
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/fsl_soc.c: prepare for addition of mpc5121 USB code
From: Grant Likely @ 2010-06-11 15:47 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: Greg Kroah-Hartman, Wolfgang Denk, Detlev Zundel, linux-usb,
linuxppc-dev, David Brownell
In-Reply-To: <20100611132443.567daf79@wker>
On Fri, Jun 11, 2010 at 5:24 AM, Anatolij Gustschin <agust@denx.de> wrote:
> On Wed, 19 May 2010 14:47:47 -0600
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> On Thu, May 6, 2010 at 1:18 PM, Anatolij Gustschin <agust@denx.de> wrote=
:
>> > Hi Grant,
>> >
>> > On Tue, 27 Apr 2010 10:51:21 -0600
>> > Grant Likely <grant.likely@secretlab.ca> wrote:
>> >
>> >> On Tue, Apr 27, 2010 at 10:11 AM, Anatolij Gustschin <agust@denx.de> =
wrote:
>> >> > Factor out common code for registering a FSL EHCI platform
>> >> > device into new fsl_usb2_register_device() function. This
>> >> > is done to avoid code duplication while adding code for
>> >> > instantiating of MPC5121 dual role USB platform devices.
>> >> > Then, the subsequent patch can use
>> >> > for_each_compatible_node(np, NULL, "fsl,mpc5121-usb2-dr") {
>> >> > =A0 =A0 =A0 =A0...
>> >> > =A0 =A0 =A0 =A0fsl_usb2_register_device();
>> >> > }
>> >> >
>> >> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
>> >> > Cc: Kumar Gala <galak@kernel.crashing.org>
>> >> > Cc: Grant Likely <grant.likely@secretlab.ca>
>> >> > ---
>> >> > =A0arch/powerpc/sysdev/fsl_soc.c | =A0231 +++++++++++++++++++------=
---------------
>> >>
>> >> Hi Anatolij,
>> >>
>> >> Thanks for this work. =A0However, I've got concerns.
>> >>
>> >> Forgive me for ragging on code that you didn't write, but this
>> >> fsl_soc.c code for registering the USB device really doesn't belong
>> >> here anymore. =A0It should be part of the drivers/usb/host/ehci-fsl.c
>> >> and the driver should do of-style binding (Which should be a lot
>> >> easier if I manage to get the merge of platform bus and of_platform
>> >> bus into 2.6.35).
>> >
>> > Now I moved the USB devices registration code to
>> > drivers/usb/host/ehci-fsl.c and added of-style binding there. It
>> > works for one platform driver based on your test-devicetree branch.
>> > It seems I can't bind more than one driver to the device described
>> > in the tree. But I need to bind at least 2 drivers, ehci-hcd and
>> > fsl-usb2-udc. For USB OTG support I need additional one to be bound
>> > to the same USB dual role device (also tree different drivers
>> > simultaneously).
>> > I also can't register UDC device in the ehci-fsl.c since registering
>> > of the UDC device should also be possible independent of the EHCI-HDC
>> > driver (for USB device support we do not need host controller driver).
>> > Is it possible to bind more than one driver to the same device
>> > simultaneously? If so, how can I implement this?
>>
>> No, the linux driver model can bind exactly one driver to a struct
>> device. =A0However, that doesn't mean you can't have multiple struct
>> devices (in whatever form they come) to tell the Linux kernel about
>> all the details of a single hardware device.
>>
>> >> This patch series makes the fsl_soc.c code even more complicated, and
>> >> scatters what is essentially driver code over even more places in the
>> >> arch/powerpc tree. =A0I'm really not keen on it being merged in this
>> >> form.
>> >
>> > Now I see one reason why it has been originally implemented
>> > this way.
>>
>> Should be a solvable problem. =A0The fsl_soc.c stuff was originally
>> written simply because the infrastructure wasn't there for doing it
>> any other way. =A0We're long past that point now. =A0I don't have time t=
o
>> dig into the details now (merge window and all), but ping me in a few
>> weeks and I'll take another look to see if I can help you.
>
> Hi Grant,
>
> Ping. Do you have any suggestions how to realize this using current
> infrastructure? Thanks!
It sounds like the USB OTG controller is effectively a compound device
with one host controller and one device controller plus some logic to
switch between the two. I'm not a USB expert, so correct me if I'm
wrong here.
You've got 2 choices for implementing this:
A) create a 'master' of_driver which registers 2 platform devices it
it's probe routine.
B) Rework the drivers so that both fsl-ehci and fsl-usb2-udc bits are
called directly (essentially one driver handles both modes)
Option A probably makes the most sense as it has the least amount of
impact on current code. Essentially, you create an of_driver and put
into it's probe hook the code that is currently in fsl_soc.c. Then it
will bind in the normal of_platform_bus_type manner and can register
the appropriate platform devices for each platform.
Some important points though; when you create the platform devices,
make sure you set the parent pointer correctly so the new devices are
registered as children of the of_device.
Second, you can eliminate the call to platform_device_add_data() by
setting the of_node pointer in the platform device (the of_node is now
part of struct device). Make the driver look up its own data from the
device tree instead of passing it in an anonymous data structure.
On that note, the current code looks racy anyway because it registers
the device before attaching the platform_data. It's probably okay
because of how early it is run and no drivers are registered yet, but
it is still wrong. It should be: allocate; add data; then register.
But I digress. Eliminating the platform data makes this problem go
away.
I hope this helps.
g.
^ permalink raw reply
* [PATCH] gianfar: Fix oversized packets handling
From: Anton Vorontsov @ 2010-06-11 20:51 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, Andy Fleming, Sandeep Gopalpet, netdev
Issuing the following command on host:
$ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1
Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0)
oops like this:
skb_over_panic: text:c0195914 len:1537 put:1537 head:c79e4800 data:c79e4880 tail:0xc79e4e81 end:0xc79e4e80 dev:eth1
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:127!
Oops: Exception in kernel mode, sig: 5 [#1]
MPC831x RDB
last sysfs file: /sys/kernel/uevent_seqnum
Modules linked in:
NIP: c01c1840 LR: c01c1840 CTR: c016d918
[...]
NIP [c01c1840] skb_over_panic+0x48/0x5c
LR [c01c1840] skb_over_panic+0x48/0x5c
Call Trace:
[c0339d50] [c01c1840] skb_over_panic+0x48/0x5c (unreliable)
[c0339d60] [c01c3020] skb_put+0x5c/0x60
[c0339d70] [c0195914] gfar_clean_rx_ring+0x25c/0x3d0
[c0339dc0] [c01976e8] gfar_poll+0x170/0x1bc
Dumped buffer descriptors showed that eTSEC's length/truncation
logic sometimes passes oversized packets, i.e. for the above ICMP
packet the following two buffer descriptors may become ready:
status=1400 length=1536
status=1800 length=1541
So, it seems that gianfar actually receives the whole big frame,
and it tries to place the packet into two BDs. This situation
confuses the driver, and so the skb_put() sanity check fails.
This patch fixes the issue by adding an appropriate check, i.e.
the driver should not try to process frames with buffer
descriptor's length over rx_buffer_size (i.e. maxfrm and mrblr).
Note that sometimes eTSEC works correctly, i.e. in the second
(last) buffer descriptor bits 'truncated' and 'crcerr' are set,
and so there's no oops. Though I couldn't find any logic when
it works correctly and when not.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/gianfar.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 46c69cd..7c31f0f 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2642,6 +2642,10 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
dma_unmap_single(&priv->ofdev->dev, bdp->bufPtr,
priv->rx_buffer_size, DMA_FROM_DEVICE);
+ if (unlikely(!(bdp->status & RXBD_ERR) &&
+ bdp->length > priv->rx_buffer_size))
+ bdp->status = RXBD_LARGE;
+
/* We drop the frame if we failed to allocate a new buffer */
if (unlikely(!newskb || !(bdp->status & RXBD_LAST) ||
bdp->status & RXBD_ERR)) {
--
1.7.0.5
^ permalink raw reply related
* [PATCH 2.6.35 & stable (v2)] powerpc: fix logic error in fixup_irqs
From: Johannes Berg @ 2010-06-11 20:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, alastair.bridgewater
In-Reply-To: <1276289669.3918.3.camel@jlt3.sipsolutions.net>
When SPARSE_IRQ is set, irq_to_desc() can
return NULL. While the code here has a
check for NULL, it's not really correct.
Fix it by separating the check for it.
This fixes CPU hot unplug for me.
Reported-by: Alastair Bridgewater <alastair.bridgewater@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
v2: cc Alastair, sorry
arch/powerpc/kernel/irq.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- wireless-testing.orig/arch/powerpc/kernel/irq.c 2010-06-11 22:51:08.000000000 +0200
+++ wireless-testing/arch/powerpc/kernel/irq.c 2010-06-11 22:54:11.000000000 +0200
@@ -295,7 +295,10 @@ void fixup_irqs(const struct cpumask *ma
for_each_irq(irq) {
desc = irq_to_desc(irq);
- if (desc && desc->status & IRQ_PER_CPU)
+ if (!desc)
+ continue;
+
+ if (desc->status & IRQ_PER_CPU)
continue;
cpumask_and(mask, desc->affinity, map);
^ permalink raw reply
* Re: [git pull] PCI fixes
From: Jesse Barnes @ 2010-06-11 21:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michal Simek, linux-am33-list, linux-pci, linux-kernel,
linuxppc-dev, microblaze-uclinux, Koichi Yasutake
In-Reply-To: <alpine.LFD.2.00.1006091611040.4506@i5.linux-foundation.org>
On Wed, 9 Jun 2010 16:14:10 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, 9 Jun 2010, Jesse Barnes wrote:
> >
> > Nothing too big here; I do have a couple of fixes in the queue that
> > aren't included here though. I'll be pulling them together over the
> > next couple of days.
>
> Hmm. None of these seem to really be relevant. The fact that one is from
> me doesn't make me any more eager to pull. Are any of these real
> regressions (the missing parenthesis one seems to be the only one that
> could be serious, but I didn't grep for actual use).
Ok I've updated the tree to cover the regressions reported so far,
including the printk change so we get fewer spurious reports. Note it
hasn't gone through linux-next yet, but the patches are all small and
have each been tested individually.
There's one change in particular I'd like you (along with the cc'd
arch maintainers) to review:
commit 837c4ef13c44296bb763a0ca0e84a076592474cf
Author: Yinghai Lu <yinghai.lu@oracle.com>
Date: Thu Jun 3 13:43:03 2010 -0700
PCI: clear bridge resource range if BIOS assigned bad one
This fixes a regression rather minimally, but may have side effects I'm
not seeing. An alternative to that fix would be to revert
commit d65245c3297ac63abc51a976d92f45f2195d2854
Author: Yinghai Lu <yinghai@kernel.org>
Date: Fri Jan 22 01:02:23 2010 -0800
PCI: don't shrink bridge resources
but it seems that's a bit more risky at this point, since it could
affect hotplug and rescan cases. Really this code needs to be
reworked, especially in light of the revert of
977d17bb1749517b353874ccdc9b85abc7a58c2a which tried (and failed)
to perform aggressive reallocation when devices weren't configured.
I'll try to find some time next week to work on that.
The following changes since commit 9dda696f0de87a2e5cfabb147e28c76b7d3c6846:
Linus Torvalds (1):
Merge branch 'release' of git://git.kernel.org/.../aegl/linux-2.6
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 for-linus
Bjorn Helgaas (1):
PCI: change resource collision messages from KERN_ERR to KERN_INFO
Jesse Barnes (1):
Revert "PCI: create function symlinks in /sys/bus/pci/slots/N/"
Jiri Slaby (1):
PCI: hotplug/cpqphp, fix NULL dereference
Yinghai Lu (1):
PCI: clear bridge resource range if BIOS assigned bad one
Documentation/ABI/testing/sysfs-bus-pci | 40 -------------------------
arch/microblaze/pci/pci-common.c | 1 +
arch/mn10300/unit-asb2305/pci-asb2305.c | 1 +
arch/powerpc/kernel/pci-common.c | 1 +
arch/x86/pci/i386.c | 2 +
drivers/pci/hotplug/cpqphp_core.c | 7 ++++
drivers/pci/pci-sysfs.c | 37 -----------------------
drivers/pci/setup-res.c | 10 +++---
drivers/pci/slot.c | 48 -------------------------------
9 files changed, 17 insertions(+), 130 deletions(-)
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 2.6.35 & stable (v2)] powerpc: fix logic error in fixup_irqs
From: Johannes Berg @ 2010-06-11 21:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, alastair.bridgewater
In-Reply-To: <1276289756.3918.4.camel@jlt3.sipsolutions.net>
On Fri, 2010-06-11 at 22:55 +0200, Johannes Berg wrote:
> When SPARSE_IRQ is set, irq_to_desc() can
> return NULL. While the code here has a
> check for NULL, it's not really correct.
> Fix it by separating the check for it.
Incidentally, there's another quirk in fixup_irqs():
...
alloc_cpumask_var(&mask, GFP_KERNEL);
...
local_irq_enable();
mdelay(1);
local_irq_disable();
Either it's called with IRQs disabled, in which case it shouldn't do
GFP_KERNEL, or it's called with IRQs enabled, in which case it doesn't
need the local_irq_enable(), no?
johannes
^ permalink raw reply
* Request review of device tree documentation
From: Grant Likely @ 2010-06-11 22:59 UTC (permalink / raw)
To: devicetree-discuss, Jeremy Kerr, John Rigby, linuxppc-dev,
microblaze-uclinux, Olof Johansson
I've been doing a bit of work on some introductory level documentation
of the flattened device tree. I've got a rough copy up on the
devicetree.org wiki, and I could use some feedback. If anyone has
some time to look at it, you can find it here:
http://devicetree.org/Device_Tree_Usage
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Dan Malek @ 2010-06-11 23:47 UTC (permalink / raw)
To: Grant Likely
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Jeremy Kerr
In-Reply-To: <AANLkTilK4YkRMJqlcRDOAlGBzpdlZuSo9NF5NrRNocHT@mail.gmail.com>
Hi Grant.
On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
> I've been doing a bit of work on some introductory level documentation
> of the flattened device tree.
Wow, I feel empowered to create device trees now :-)
Seriously, I never understood this well and this is a
great document.
I have one source of confusion. Your first Initial structure
example uses 'compatible' to describe the machine, the
paragraph below then mentions the 'model' property,
and all subsequent examples use model.
Does this mean if I use just the single line in the dts,
using 'compatible' implies the ARM machine ID? If I
have more description I use 'model'?
Thanks.
-- Dan
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 2:58 UTC (permalink / raw)
To: Dan Malek
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Jeremy Kerr
In-Reply-To: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com>
On Fri, 2010-06-11 at 16:47 -0700, Dan Malek wrote:
> Hi Grant.
>
> On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
>
> > I've been doing a bit of work on some introductory level documentation
> > of the flattened device tree.
>
> Wow, I feel empowered to create device trees now :-)
> Seriously, I never understood this well and this is a
> great document.
>
> I have one source of confusion. Your first Initial structure
> example uses 'compatible' to describe the machine, the
> paragraph below then mentions the 'model' property,
> and all subsequent examples use model.
>
> Does this mean if I use just the single line in the dts,
> using 'compatible' implies the ARM machine ID? If I
> have more description I use 'model'?
Normally, "compatible" is what is used for code to match,
and model is more like a user-visible thingy.
It's possible to peek at 'model' tho, in some cases, I've seen the case
for example where things are -supposed- to be identical from an arch
point of view, have the same compatible, but later on, a quirk is found
and a test against model is used to differentiate. But that's something
to avoid in general. Better off having multiple strings in "compatible"
then, one more "generic" to have the BSP match against, and one more
"specific" that can be used if a quirk is needed.
Of course, it doesn't help that all pseries have "chrp" and nothing else
as compatible :-) But then, both IBM and Apple have been quite lax with
their (ab)use of the DT.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 3:00 UTC (permalink / raw)
To: Grant Likely
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Jeremy Kerr
In-Reply-To: <AANLkTilK4YkRMJqlcRDOAlGBzpdlZuSo9NF5NrRNocHT@mail.gmail.com>
On Fri, 2010-06-11 at 16:59 -0600, Grant Likely wrote:
> I've been doing a bit of work on some introductory level documentation
> of the flattened device tree. I've got a rough copy up on the
> devicetree.org wiki, and I could use some feedback. If anyone has
> some time to look at it, you can find it here:
>
> http://devicetree.org/Device_Tree_Usage
Quite nice. Maybe the introduction could use a very quick blurb on the
various data types that dtc supports for properties, and something on
labels & phandles (references to nodes).
I just flew over it. I'll try to give you a more in depth review later.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 3:07 UTC (permalink / raw)
To: Grant Likely
Cc: Olof Johansson, microblaze-uclinux, devicetree-discuss,
Jeremy Kerr, linuxppc-dev
In-Reply-To: <1276311610.1962.173.camel@pasglop>
On Sat, 2010-06-12 at 13:00 +1000, Benjamin Herrenschmidt wrote:
>
> Quite nice. Maybe the introduction could use a very quick blurb on
> the
> various data types that dtc supports for properties, and something on
> labels & phandles (references to nodes).
>
> I just flew over it. I'll try to give you a more in depth review
> later.
Oh, yes, btw, Dan is right, you do seem to mixup "model" and
"compatible" all over the place :-)
Maybe a paragraph on the new proposed clock binding that Jeremy is
working would be of use btw.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-12 4:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: microblaze-uclinux, Dan Malek, devicetree-discuss, Jeremy Kerr,
linuxppc-dev
In-Reply-To: <1276311487.1962.172.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Fri, 2010-06-11 at 16:47 -0700, Dan Malek wrote:
>
>> Hi Grant.
>>
>> On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
>>
>>
>>> I've been doing a bit of work on some introductory level documentation
>>> of the flattened device tree.
>>>
>> Wow, I feel empowered to create device trees now :-)
>> Seriously, I never understood this well and this is a
>> great document.
>>
>> I have one source of confusion. Your first Initial structure
>> example uses 'compatible' to describe the machine, the
>> paragraph below then mentions the 'model' property,
>> and all subsequent examples use model.
>>
>> Does this mean if I use just the single line in the dts,
>> using 'compatible' implies the ARM machine ID? If I
>> have more description I use 'model'?
>>
>
> Normally, "compatible" is what is used for code to match,
> and model is more like a user-visible thingy.
>
Indeed, one common use of "model" - at least in the systems I work on -
is to display the name of the machine in a system identification banner
that the user sees.
> It's possible to peek at 'model' tho, in some cases, I've seen the case
> for example where things are -supposed- to be identical from an arch
> point of view, have the same compatible, but later on, a quirk is found
> and a test against model is used to differentiate. But that's something
> to avoid in general. Better off having multiple strings in "compatible"
> then, one more "generic" to have the BSP match against, and one more
> "specific" that can be used if a quirk is needed.
>
> Of course, it doesn't help that all pseries have "chrp" and nothing else
> as compatible :-) But then, both IBM and Apple have been quite lax with
> their (ab)use of the DT.
>
> Cheers,
> Ben.
>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
>
^ permalink raw reply
* random exception on ppc based board
From: Thirumalai @ 2010-06-12 5:10 UTC (permalink / raw)
To: u-boot, linuxppc-dev
Hi,
I am having a ppc based target on which linux-2.4.20 kernel is running
with u-boot 1.3.4 as boot loader. The target is having MPC7410 as processor
and MPC107 as system controller. Regarding memory it is having 128 MB of ram
and 16 MB of Flash memory. Also the kernel is patched with RTLinux-3.2 for
realtime performance. I am getting a random Program and DSI exception on the
target. Normally the exeption occurs during loading of rtl_time.o. The panic
message is given below.
==================
Using /usr/rtlinux/modules/rtl_time.okernel BUG at page_alloc.c:221!
Oops: Exception in kernel mode, sig: 4
NIP: C0032980 XER: 00000000 LR: C0032980 SP: C7CEDBA0 REGS: c7cedaf0 TRAP:
0700 Not tainted
MSR: 00089032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c7cec000[366] 'exe' Last syscall: 3
last math c7cec000 last altivec 00000000
GPR00: C0032980 C7CEDBA0 C7CEC000 00000020 00000001 00000001 00001137
00000000
GPR08: 00000002 00000000 CD879EC0 C7CEDAB0 CD876108 C0011934 00000000
00000000
GPR16: 00000004 00000001 C002A0E8 C789E840 00009032 07CEDD90 C01A2C70
C01A2C70
GPR24: 00000001 00000000 C016E080 00000000 C79966E0 00000000 C016E0B8
C016E0C4
Call backtrace:
C0032980 C0033020 C0032C4C C0025A18 C0025B58 C0025D8C C000EF88
C0005D48 C03A8B28 C0029B28 C002A258 C003A99C C0005AFC 00000000
0FF15DBC 0FF175DC 0FF09894 10012190 100127D0 100356AC 100352A4
0FEBCF6C 00000000
Oops: kernel access of bad area, sig: 11
NIP: C00326DC XER: 00000000 LR: C0032588 SP: C7CED880 REGS: c7ced7d0 TRAP:
0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000000, DSISR: 42000000
TASK = c7cec000[366] 'exe' Last syscall: 3
last math c7cec000 last altivec 00000000
GPR00: 00000000 C7CED880 C7CEC000 C7CED888 FFFFFFFF 30026000 C0388250
00000000
GPR08: 00008000 00000000 00155210 00000000 CD876CD4 C0032588 00000000
00000000
GPR16: 00000004 00000001 C002A0E8 C789E840 00009032 C01A2C70 C01A2C70
C016E130
GPR24: C0233024 C0388234 00003E06 00007C0C C016E080 FFFFFFFE C016E0B8
C0388260
Call backtrace:
C003249C C0033398 C0033B18 C00243D8 C0026234 C00246D0 C0027A70
C001326C C00187D4 C0005ED4 C0005F44 C00062B0 C0005D48 C0032980
C0033020 C0032C4C C0025A18 C0025B58 C0025D8C C000EF88 C0005D48
C03A8B28 C0029B28 C002A258 C003A99C C0005AFC 00000000 0FF15DBC
0FF175DC 0FF09894 10012190 100127D0 100356AC
Illegal instruction
========
Sometimes i am getting the following panic message.
===========
Oops: kernel access of bad area, sig: 11
NIP: C0033360 XER: 20000000 LR: C00DE9A8 SP: C016C0D0 REGS: c016c020 TRAP:
0300 Tainted: P
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 03910018, DSISR: 40000000
TASK = c016a480[0] 'swapper' Last syscall: 120
last math c505c000 last altivec 00000000
GPR00: C00DE9A8 C016C0D0 C016A480 03910000 00000000 00000000 C5A469DC
FFFFFFFF
GPR08: 00000001 03910014 00000043 C5A2FE20 2490C022 C0030A04 07FF0D00
00000000
GPR16: 00044008 00000000 00000000 00000000 00001032 00000003 FFFFFFFF
0A050393
GPR24: C5A46980 C5A2F842 00000040 00000000 C5A2F842 C01C0000 C5A46980
00000001
Call backtrace:
00000040 C00DE9A8 C00DE9DC C00DEB28 C01163D4 C01166EC C00F4898
C00F44E4 C00F4AC8 C00F468C C00E3664 C00E3810 C00E397C C001A200
C0007620 CD876CAC C0005D40 C000744C C0007460 C0003918 C01815E0
000035F0
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
<0>Rebooting in 180 seconds..
================
How to debug this???
-Thirumalai
^ permalink raw reply
* Re: [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
From: Barry Song @ 2010-06-12 6:27 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, Andrew Morton, David Woodhouse
In-Reply-To: <20090818214622.GA22651@oksana.dev.rtsoft.ru>
T24gV2VkLCBBdWcgMTksIDIwMDkgYXQgNTo0NiBBTSwgQW50b24gVm9yb250c292Cjxhdm9yb250
c292QHJ1Lm12aXN0YS5jb20+IHdyb3RlOgo+Cj4gUHJldmlvc2x5IHRoZSBkcml2ZXIgYWx3YXlz
IHRyaWVkIEpFREVDIHByb2JpbmcsIGFzc3VtaW5nIHRoYXQgbm9uLUpFREVDCj4gY2hpcHMgd2ls
bCByZXR1cm4gJzAnLiBCdXQgdHJ1bHkgbm9uLUpFREVDIGNoaXBzIChsaWtlIENBVDI1KSB3b24n
dCBkbwo+IHRoYXQsIHRoZWlyIGJlaGF2aW91ciBvbiBSRElEIGNvbW1hbmQgaXMgdW5kZWZpbmVk
LCBzbyB0aGUgZHJpdmVyIHNob3VsZAo+IG5vdCBjYWxsIGplZGVjX3Byb2JlKCkgZm9yIHRoZXNl
IGNoaXBzLgo+Cj4gQWxzbywgYmUgbGVzcyBzdHJpY3Qgb24gZXJyb3IgY29uZGl0aW9ucywgZG9u
J3QgZmFpbCB0byBwcm9iZSBpZiBKRURFQwo+IGZvdW5kIGEgY2hpcCB0aGF0IGlzIGRpZmZlcmVu
dCBmcm9tIHdoYXQgcGxhdGZvcm0gY29kZSB0b2xkLCBpbnN0ZWFkCj4ganVzdCBwcmludCBzb21l
IHdhcm5pbmdzIGFuZCB1c2UgYW4gaW5mb3JtYXRpb24gb2J0YWluZWQgdmlhIEpFREVDLiBJbgpU
aGlzIHBhdGNoIGNhdXNlZCBhIHByb2JsZW06CmV2ZW4gdGhvdWdoIHRoZSBleHRlcm5hbCBmbGFz
aCBkb2Vzbid0IGV4aXN0LCBpdCB3aWxsIHN0aWxsIHBhc3MgdGhlCnByb2JlKCkgYW5kIGJlIHJl
Z2lzdGVycmVkIGludG8ga2VybmVsIGFuZCBnaXZlbiB0aGUgcGFydGl0aW9uIHRhYmxlLgpZb3Ug
bWF5IHJlZmVyIHRvIHRoaXMgYnVnIHJlcG9ydDoKaHR0cDovL2JsYWNrZmluLnVjbGludXgub3Jn
L2dmL3Byb2plY3QvdWNsaW51eC1kaXN0L3RyYWNrZXIvP2FjdGlvbj1UcmFja2VySXRlbUVkaXQm
dHJhY2tlcl9pdGVtX2lkPTU5NzUmc3RhcnQ9MAoKPiB0aGF0IGNhc2Ugd2Ugc2hvdWxkIG5vdCB0
cnVzdCBwYXJ0aXRpb25zIGFueSBsb25nZXIsIGJ1dCB0aGV5IG1pZ2h0IGJlCj4gc3RpbGwgdXNl
ZnVsIChpLmUuIHRoZXkgY291bGQgcHJvdGVjdCBzb21lIHBhcnRzIG9mIHRoZSBjaGlwKS4KPgo+
IFNpZ25lZC1vZmYtYnk6IEFudG9uIFZvcm9udHNvdiA8YXZvcm9udHNvdkBydS5tdmlzdGEuY29t
Pgo+IC0tLQo+IMKgZHJpdmVycy9tdGQvZGV2aWNlcy9tMjVwODAuYyB8IMKgIDY5ICsrKysrKysr
KysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tCj4gwqAxIGZpbGVzIGNoYW5nZWQsIDQw
IGluc2VydGlvbnMoKyksIDI5IGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMv
bXRkL2RldmljZXMvbTI1cDgwLmMgYi9kcml2ZXJzL210ZC9kZXZpY2VzL20yNXA4MC5jCj4gaW5k
ZXggMGQ3NGIzOC4uYjc1ZTMxOSAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL210ZC9kZXZpY2VzL20y
NXA4MC5jCj4gKysrIGIvZHJpdmVycy9tdGQvZGV2aWNlcy9tMjVwODAuYwo+IEBAIC01ODEsNiAr
NTgxLDE0IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3Qgc3BpX2RldmljZV9pZCAqX19kZXZpbml0IGpl
ZGVjX3Byb2JlKHN0cnVjdCBzcGlfZGV2aWNlICpzcGkpCj4gwqAgwqAgwqAgwqBqZWRlYyA9IGpl
ZGVjIDw8IDg7Cj4gwqAgwqAgwqAgwqBqZWRlYyB8PSBpZFsyXTsKPgo+ICsgwqAgwqAgwqAgLyoK
PiArIMKgIMKgIMKgIMKgKiBTb21lIGNoaXBzIChsaWtlIE51bW9ueXggTTI1UDgwKSBoYXZlIEpF
REVDIGFuZCBub24tSkVERUMgdmFyaWFudHMsCj4gKyDCoCDCoCDCoCDCoCogd2hpY2ggZGVwZW5k
IG9uIHRlY2hub2xvZ3kgcHJvY2Vzcy4gT2ZmaWNpYWxseSBSRElEIGNvbW1hbmQgZG9lc24ndAo+
ICsgwqAgwqAgwqAgwqAqIGV4aXN0IGZvciBub24tSkVERUMgY2hpcHMsIGJ1dCBmb3IgY29tcGF0
aWJpbGl0eSB0aGV5IHJldHVybiBJRCAwLgo+ICsgwqAgwqAgwqAgwqAqLwo+ICsgwqAgwqAgwqAg
aWYgKGplZGVjID09IDApCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXR1cm4gTlVMTDsKPiAr
Cj4gwqAgwqAgwqAgwqBleHRfamVkZWMgPSBpZFszXSA8PCA4IHwgaWRbNF07Cj4KPiDCoCDCoCDC
oCDCoGZvciAodG1wID0gMDsgdG1wIDwgQVJSQVlfU0laRShtMjVwX2lkcykgLSAxOyB0bXArKykg
ewo+IEBAIC02MDIsNyArNjEwLDcgQEAgc3RhdGljIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lk
ICpfX2RldmluaXQgamVkZWNfcHJvYmUoc3RydWN0IHNwaV9kZXZpY2UgKnNwaSkKPiDCoCovCj4g
wqBzdGF0aWMgaW50IF9fZGV2aW5pdCBtMjVwX3Byb2JlKHN0cnVjdCBzcGlfZGV2aWNlICpzcGkp
Cj4gwqB7Cj4gLSDCoCDCoCDCoCBjb25zdCBzdHJ1Y3Qgc3BpX2RldmljZV9pZCDCoCDCoCDCoCpp
ZDsKPiArIMKgIMKgIMKgIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lkIMKgIMKgIMKgKmlkID0g
c3BpX2dldF9kZXZpY2VfaWQoc3BpKTsKPiDCoCDCoCDCoCDCoHN0cnVjdCBmbGFzaF9wbGF0Zm9y
bV9kYXRhIMKgIMKgIMKgKmRhdGE7Cj4gwqAgwqAgwqAgwqBzdHJ1Y3QgbTI1cCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCAqZmxhc2g7Cj4gwqAgwqAgwqAgwqBzdHJ1Y3QgZmxhc2hfaW5m
byDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqaW5mbzsKPiBAQCAtNjE1LDQxICs2MjMsNDQgQEAgc3Rh
dGljIGludCBfX2RldmluaXQgbTI1cF9wcm9iZShzdHJ1Y3Qgc3BpX2RldmljZSAqc3BpKQo+IMKg
IMKgIMKgIMKgICovCj4gwqAgwqAgwqAgwqBkYXRhID0gc3BpLT5kZXYucGxhdGZvcm1fZGF0YTsK
PiDCoCDCoCDCoCDCoGlmIChkYXRhICYmIGRhdGEtPnR5cGUpIHsKPiArIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lkICpwbGF0X2lkOwo+ICsKPiDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoGZvciAoaSA9IDA7IGkgPCBBUlJBWV9TSVpFKG0yNXBfaWRzKSAtIDE7
IGkrKykgewo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWQgPSAmbTI1cF9p
ZHNbaV07Cj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbmZvID0gKHZvaWQg
KiltMjVwX2lkc1tpXS5kcml2ZXJfZGF0YTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIGlmIChzdHJjbXAoZGF0YS0+dHlwZSwgaWQtPm5hbWUpKQo+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgcGxhdF9pZCA9ICZtMjVwX2lkc1tpXTsKPiArIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChzdHJjbXAoZGF0YS0+dHlwZSwgcGxhdF9pZC0+
bmFtZSkpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBj
b250aW51ZTsKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJyZWFrOwo+IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgfQo+Cj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAvKiB1bnJl
Y29nbml6ZWQgY2hpcD8gKi8KPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChpID09IEFSUkFZ
X1NJWkUobTI1cF9pZHMpIC0gMSkgewo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgREVCVUcoTVREX0RFQlVHX0xFVkVMMCwgIiVzOiB1bnJlY29nbml6ZWQgaWQgJXNcbiIsCj4g
LSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCBkZXZfbmFtZSgmc3BpLT5kZXYpLCBkYXRhLT50eXBlKTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIGluZm8gPSBOVUxMOwo+IC0KPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IC8qIHJlY29nbml6ZWQ7IGlzIHRoYXQgY2hpcCByZWFsbHkgd2hhdCdzIHRoZXJlPyAqLwo+IC0g
wqAgwqAgwqAgwqAgwqAgwqAgwqAgfSBlbHNlIGlmIChpbmZvLT5qZWRlY19pZCkgewo+IC0gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWQgPSBqZWRlY19wcm9iZShzcGkpOwo+IC0K
PiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChpZCAhPSAmbTI1cF9pZHNb
aV0pIHsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRl
dl93YXJuKCZzcGktPmRldiwgImZvdW5kICVzLCBleHBlY3RlZCAlc1xuIiwKPiAtIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGlkID8gaWQtPm5hbWUgOiAiVU5LTk9XTiIsCj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtMjVwX2lkc1tp
XS5uYW1lKTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IGluZm8gPSBOVUxMOwo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfQo+IC0g
wqAgwqAgwqAgwqAgwqAgwqAgwqAgfQo+IC0gwqAgwqAgwqAgfSBlbHNlIHsKPiAtIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIGlkID0gamVkZWNfcHJvYmUoc3BpKTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGlmICghaWQpCj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZCA9IHNw
aV9nZXRfZGV2aWNlX2lkKHNwaSk7Cj4gLQo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5mbyA9
ICh2b2lkICopaWQtPmRyaXZlcl9kYXRhOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWYgKHBs
YXRfaWQpCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZCA9IHBsYXRfaWQ7
Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlbHNlCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCBkZXZfd2Fybigmc3BpLT5kZXYsICJ1bnJlY29nbml6ZWQgaWQgJXNcbiIsIGRh
dGEtPnR5cGUpOwo+IMKgIMKgIMKgIMKgfQo+Cj4gLSDCoCDCoCDCoCBpZiAoIWluZm8pCj4gLSDC
oCDCoCDCoCDCoCDCoCDCoCDCoCByZXR1cm4gLUVOT0RFVjsKPiArIMKgIMKgIMKgIGluZm8gPSAo
dm9pZCAqKWlkLT5kcml2ZXJfZGF0YTsKPiArCj4gKyDCoCDCoCDCoCBpZiAoaW5mby0+amVkZWNf
aWQpIHsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lk
ICpqaWQ7Cj4gKwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgamlkID0gamVkZWNfcHJvYmUoc3Bp
KTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmICghamlkKSB7Cj4gKyDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCBkZXZfaW5mbygmc3BpLT5kZXYsICJub24tSkVERUMgdmFyaWFu
dCBvZiAlc1xuIiwKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgaWQtPm5hbWUpOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfSBlbHNlIGlmIChqaWQg
IT0gaWQpIHsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC8qCj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogSkVERUMga25vd3MgYmV0dGVyLCBzbyBv
dmVyd3JpdGUgcGxhdGZvcm0gSUQuIFdlCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCogY2FuJ3QgdHJ1c3QgcGFydGl0aW9ucyBhbnkgbG9uZ2VyLCBidXQgd2UnbGwgbGV0
Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogbXRkIGFwcGx5IHRoZW0g
YW55d2F5LCBzaW5jZSBzb21lIHBhcnRpdGlvbnMgbWF5IGJlCj4gKyDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCogbWFya2VkIHJlYWQtb25seSwgYW5kIHdlIGRvbid0IHdhbnQg
dG8gbG9zZSB0aGF0Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogaW5m
b3JtYXRpb24sIGV2ZW4gaWYgaXQncyBub3QgMTAwJSBhY2N1cmF0ZS4KPiArIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKi8KPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIGRldl93YXJuKCZzcGktPmRldiwgImZvdW5kICVzLCBleHBlY3RlZCAlc1xuIiwKPiAr
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgamlkLT5uYW1l
LCBpZC0+bmFtZSk7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZCA9IGpp
ZDsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluZm8gPSAodm9pZCAqKWpp
ZC0+ZHJpdmVyX2RhdGE7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCB9Cj4gKyDCoCDCoCDCoCB9
Cj4KPiDCoCDCoCDCoCDCoGZsYXNoID0ga3phbGxvYyhzaXplb2YgKmZsYXNoLCBHRlBfS0VSTkVM
KTsKPiDCoCDCoCDCoCDCoGlmICghZmxhc2gpCj4gLS0KPiAxLjYuMy4zCj4KPiAtLQo+IFRvIHVu
c3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51
eC1rZXJuZWwiIGluCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtl
cm5lbC5vcmcKPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0IMKgaHR0cDovL3ZnZXIua2VybmVsLm9y
Zy9tYWpvcmRvbW8taW5mby5odG1sCj4gUGxlYXNlIHJlYWQgdGhlIEZBUSBhdCDCoGh0dHA6Ly93
d3cudHV4Lm9yZy9sa21sLwo=
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-12 6:53 UTC (permalink / raw)
To: Dan Malek, Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Jeremy Kerr
In-Reply-To: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com>
On Fri, Jun 11, 2010 at 5:47 PM, Dan Malek <ppc6dev@digitaldans.com> wrote:
>
> Hi Grant.
>
> On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
>
>> I've been doing a bit of work on some introductory level documentation
>> of the flattened device tree.
>
> Wow, I feel empowered to create device trees now :-)
> Seriously, I never understood this well and this is a
> great document.
Hey, thanks! That's a fantastic compliment!
> I have one source of confusion. =A0Your first Initial structure
> example uses 'compatible' to describe the machine, the
> paragraph below then mentions the 'model' property,
> and all subsequent examples use model.
>
> Does this mean if I use just the single line in the dts,
> using 'compatible' implies the ARM machine ID? =A0If I
> have more description I use 'model'?
No, that is just a reflection of a late change I made to the document.
It should be compatible all the way down. I was trying to keep
things simple because on a lot of boards both compatible and model
properties will exist in the root node. I started writing with model,
and then changed it last minute without fixing everything up which is
why the document was confusing.
I've fixed it now if you want to take a look.
I also changed the property in the cpu nodes from model to compatible
so that the exact CPU version can be specified. This isn't actually
in any spec anywhere, but I need something to properly identify the
different ARM cores.
Mitch, I know you were working on a draft ARM binding a while ago,
have you resurrected it at all? How do you think the core should be
identified?
Cheers,
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-12 8:19 UTC (permalink / raw)
To: Grant Likely
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <AANLkTilv6TtPZs0DAwd8JlSV_J3VvMsvtVVOOeQauOIn@mail.gmail.com>
Grant Likely wrote:
>
> I also changed the property in the cpu nodes from model to compatible
> so that the exact CPU version can be specified. This isn't actually
> in any spec anywhere, but I need something to properly identify the
> different ARM cores.
>
> Mitch, I know you were working on a draft ARM binding a while ago,
> have you resurrected it at all?
As it turns out, today I re-began ARM OFW work in earnest, after a
hiatus of something like 10 years.
I haven't thought much about a binding yet. I'm still getting my head
around the current state of the ARM art.
> How do you think the core should be identified?
>
When I was last working on ARM, few ARM devices had enough resources to
run a general purpose OS. To first approximation, StrongARM was the
only game in town - so there wasn't much need to address the
identification question.
It seems that many of the differences at the CPU level can be determined
by looking at "coprocessor" registers. For what purpose(s) do we need
to identify the core? That will inform our choice of a core ID schema.
> Cheers,
> g.
>
>
>
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 10:45 UTC (permalink / raw)
To: Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <4C13430B.5000907@firmworks.com>
On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote:
> It seems that many of the differences at the CPU level can be determined
> by looking at "coprocessor" registers. For what purpose(s) do we need
> to identify the core? That will inform our choice of a core ID schema.
The primary thing I see would be architecture version compliance,
though this is better carried additionally via a binary field in
the header or a GPR at the entry point, to help the initial asm
code to setup the MMU etc... before getting into C code.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 10:48 UTC (permalink / raw)
To: Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <1276339529.1962.184.camel@pasglop>
On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote:
> > It seems that many of the differences at the CPU level can be determined
> > by looking at "coprocessor" registers. For what purpose(s) do we need
> > to identify the core? That will inform our choice of a core ID schema.
>
> The primary thing I see would be architecture version compliance,
> though this is better carried additionally via a binary field in
> the header or a GPR at the entry point, to help the initial asm
> code to setup the MMU etc... before getting into C code.
Also, if you're going to revive a "real" OF port to ARM (with client
interface etc...), should we start considering moving some of powerpc's
prom_init.c to a generic place ?
IE. prom_init is a trampoline that uses the client interface to
essentially create a flatten device-tree and enter the kernel via the
common "epapr" style entry point.
The main drawback is that it doesn't allow to keep OF alive along with
the OS, but then, only sparc does that successfully and I'm not sure
it's something that would be practical to do on ARM either.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: fix obsolete device tree code for the UPM NAND driver.
From: Richard Cochran @ 2010-06-12 12:39 UTC (permalink / raw)
To: linuxppc-dev
Commit 58f9b0b02414062eaff46716bc04b47d7e79add5 removed of_device->node.
This driver was apparently overlooked in the processes.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/mtd/nand/fsl_upm.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 00aea6f..81ec87a 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -232,7 +232,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
if (!fun)
return -ENOMEM;
- ret = of_address_to_resource(ofdev->node, 0, &io_res);
+ ret = of_address_to_resource(ofdev->dev.of_node, 0, &io_res);
if (ret) {
dev_err(&ofdev->dev, "can't get IO base\n");
goto err1;
@@ -244,7 +244,8 @@ static int __devinit fun_probe(struct of_device *ofdev,
goto err1;
}
- prop = of_get_property(ofdev->node, "fsl,upm-addr-offset", &size);
+ prop = of_get_property(ofdev->dev.of_node,
+ "fsl,upm-addr-offset", &size);
if (!prop || size != sizeof(uint32_t)) {
dev_err(&ofdev->dev, "can't get UPM address offset\n");
ret = -EINVAL;
@@ -252,7 +253,8 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
fun->upm_addr_offset = *prop;
- prop = of_get_property(ofdev->node, "fsl,upm-cmd-offset", &size);
+ prop = of_get_property(ofdev->dev.of_node,
+ "fsl,upm-cmd-offset", &size);
if (!prop || size != sizeof(uint32_t)) {
dev_err(&ofdev->dev, "can't get UPM command offset\n");
ret = -EINVAL;
@@ -260,7 +262,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
fun->upm_cmd_offset = *prop;
- prop = of_get_property(ofdev->node,
+ prop = of_get_property(ofdev->dev.of_node,
"fsl,upm-addr-line-cs-offsets", &size);
if (prop && (size / sizeof(uint32_t)) > 0) {
fun->mchip_count = size / sizeof(uint32_t);
@@ -276,7 +278,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
for (i = 0; i < fun->mchip_count; i++) {
fun->rnb_gpio[i] = -1;
- rnb_gpio = of_get_gpio(ofdev->node, i);
+ rnb_gpio = of_get_gpio(ofdev->dev.of_node, i);
if (rnb_gpio >= 0) {
ret = gpio_request(rnb_gpio, dev_name(&ofdev->dev));
if (ret) {
@@ -292,13 +294,13 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
}
- prop = of_get_property(ofdev->node, "chip-delay", NULL);
+ prop = of_get_property(ofdev->dev.of_node, "chip-delay", NULL);
if (prop)
fun->chip_delay = *prop;
else
fun->chip_delay = 50;
- prop = of_get_property(ofdev->node, "fsl,upm-wait-flags", &size);
+ prop = of_get_property(ofdev->dev.of_node, "fsl,upm-wait-flags", &size);
if (prop && size == sizeof(uint32_t))
fun->wait_flags = *prop;
else
@@ -315,7 +317,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
fun->dev = &ofdev->dev;
fun->last_ctrl = NAND_CLE;
- ret = fun_chip_init(fun, ofdev->node, &io_res);
+ ret = fun_chip_init(fun, ofdev->dev.of_node, &io_res);
if (ret)
goto err2;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] powerpc: fix obsolete device tree code for the UPM NAND driver.
From: Anatolij Gustschin @ 2010-06-12 12:56 UTC (permalink / raw)
To: Richard Cochran; +Cc: linuxppc-dev
In-Reply-To: <20100612123943.GA1982@riccoc20.at.omicron.at>
On Sat, 12 Jun 2010 14:39:43 +0200
Richard Cochran <richardcochran@gmail.com> wrote:
> Commit 58f9b0b02414062eaff46716bc04b47d7e79add5 removed of_device->node.
> This driver was apparently overlooked in the processes.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> ---
> drivers/mtd/nand/fsl_upm.c | 18 ++++++++++--------
> 1 files changed, 10 insertions(+), 8 deletions(-)
This is already fixed in 2.6.35-rc2, please update your tree.
^ permalink raw reply
* Re: [PATCH] powerpc: rtas_flash cannot be a module
From: Anton Blanchard @ 2010-06-12 13:46 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <20100610-reply@mdm.bga.com>
Hi,
> So we should use that rtas_data_buf with its lock ...
>
> Oh look, the driver already uses that buffer for the call to verify_flash
>
> untested patch to follow
Thanks, it built and tested OK with the following patch. Will send a
complete patch with these changes in a minute.
Anton
--- build/arch/powerpc/kernel/rtas_flash.c~ 2010-06-12 09:06:43.000000000 -0400
+++ build/arch/powerpc/kernel/rtas_flash.c 2010-06-12 09:08:30.000000000 -0400
@@ -613,9 +613,9 @@
* the kernel data segment.
*/
spin_lock(&rtas_data_buf_lock);
- flist = (struct rtas_flash_list *)&rtas_data_buf[0];
- flist.num_blocks = 0;
- flist.next = rtas_firmware_flash_list;
+ flist = (struct flash_block_list *)&rtas_data_buf[0];
+ flist->num_blocks = 0;
+ flist->next = rtas_firmware_flash_list;
rtas_block_list = virt_to_abs(flist);
if (rtas_block_list >= 4UL*1024*1024*1024) {
printk(KERN_ALERT "FLASH: kernel bug...flash list header addr above 4GB\n");
^ permalink raw reply
* Re: [PATCH] powerpc: rtas_flash needs to use rtas_data_buf
From: Anton Blanchard @ 2010-06-12 13:48 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <20100610-rtas-flash@mdm.bga.com>
From: Milton Miller <miltonm@us.ibm.com>
When trying to flash a machine via the update_flash command, Anton received the
following error:
Restarting system.
FLASH: kernel bug...flash list header addr above 4GB
The code in question has a comment that the flash list should be in
the kernel data and therefore under 4GB:
/* NOTE: the "first" block list is a global var with no data
* blocks in the kernel data segment. We do this because
* we want to ensure this block_list addr is under 4GB.
*/
Unfortunately the Kconfig option is marked tristate which means the variable
may not be in the kernel data and could be above 4GB.
Instead of relying on the data segment being below 4GB, use the static
data buffer allocated by the kernel for use by rtas. Since we don't
use the header struct directly anymore, convert it to a simple pointer.
Reported-By: Anton Blanchard <anton@samba.org>
Signed-Off-By: Milton Miller <miltonm@bga.com
Tested-By: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/rtas_flash.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/rtas_flash.c 2010-05-05 16:17:00.883456148 +1000
+++ powerpc.git/arch/powerpc/kernel/rtas_flash.c 2010-06-12 23:44:25.973458269 +1000
@@ -94,12 +94,8 @@ struct flash_block_list {
struct flash_block_list *next;
struct flash_block blocks[FLASH_BLOCKS_PER_NODE];
};
-struct flash_block_list_header { /* just the header of flash_block_list */
- unsigned long num_blocks;
- struct flash_block_list *next;
-};
-static struct flash_block_list_header rtas_firmware_flash_list = {0, NULL};
+static struct flash_block_list *rtas_firmware_flash_list;
/* Use slab cache to guarantee 4k alignment */
static struct kmem_cache *flash_block_cache = NULL;
@@ -108,13 +104,14 @@ static struct kmem_cache *flash_block_ca
/* Local copy of the flash block list.
* We only allow one open of the flash proc file and create this
- * list as we go. This list will be put in the
- * rtas_firmware_flash_list var once it is fully read.
+ * list as we go. The rtas_firmware_flash_list varable will be
+ * set once the data is fully read.
*
* For convenience as we build the list we use virtual addrs,
* we do not fill in the version number, and the length field
* is treated as the number of entries currently in the block
- * (i.e. not a byte count). This is all fixed on release.
+ * (i.e. not a byte count). This is all fixed when calling
+ * the flash routine.
*/
/* Status int must be first member of struct */
@@ -201,16 +198,16 @@ static int rtas_flash_release(struct ino
if (uf->flist) {
/* File was opened in write mode for a new flash attempt */
/* Clear saved list */
- if (rtas_firmware_flash_list.next) {
- free_flash_list(rtas_firmware_flash_list.next);
- rtas_firmware_flash_list.next = NULL;
+ if (rtas_firmware_flash_list) {
+ free_flash_list(rtas_firmware_flash_list);
+ rtas_firmware_flash_list = NULL;
}
if (uf->status != FLASH_AUTH)
uf->status = flash_list_valid(uf->flist);
if (uf->status == FLASH_IMG_READY)
- rtas_firmware_flash_list.next = uf->flist;
+ rtas_firmware_flash_list = uf->flist;
else
free_flash_list(uf->flist);
@@ -593,7 +590,7 @@ static void rtas_flash_firmware(int rebo
unsigned long rtas_block_list;
int i, status, update_token;
- if (rtas_firmware_flash_list.next == NULL)
+ if (rtas_firmware_flash_list == NULL)
return; /* nothing to do */
if (reboot_type != SYS_RESTART) {
@@ -610,20 +607,25 @@ static void rtas_flash_firmware(int rebo
return;
}
- /* NOTE: the "first" block list is a global var with no data
- * blocks in the kernel data segment. We do this because
- * we want to ensure this block_list addr is under 4GB.
+ /*
+ * NOTE: the "first" block must be under 4GB, so we create
+ * an entry with no data blocks in the reserved buffer in
+ * the kernel data segment.
*/
- rtas_firmware_flash_list.num_blocks = 0;
- flist = (struct flash_block_list *)&rtas_firmware_flash_list;
+ spin_lock(&rtas_data_buf_lock);
+ flist = (struct flash_block_list *)&rtas_data_buf[0];
+ flist->num_blocks = 0;
+ flist->next = rtas_firmware_flash_list;
rtas_block_list = virt_to_abs(flist);
if (rtas_block_list >= 4UL*1024*1024*1024) {
printk(KERN_ALERT "FLASH: kernel bug...flash list header addr above 4GB\n");
+ spin_unlock(&rtas_data_buf_lock);
return;
}
printk(KERN_ALERT "FLASH: preparing saved firmware image for flash\n");
/* Update the block_list in place. */
+ rtas_firmware_flash_list = NULL; /* too hard to backout on error */
image_size = 0;
for (f = flist; f; f = next) {
/* Translate data addrs to absolute */
@@ -664,6 +666,7 @@ static void rtas_flash_firmware(int rebo
printk(KERN_ALERT "FLASH: unknown flash return code %d\n", status);
break;
}
+ spin_unlock(&rtas_data_buf_lock);
}
static void remove_flash_pde(struct proc_dir_entry *dp)
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-12 16:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <1276339684.1962.186.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote:
>
>> On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote:
>>
>>> It seems that many of the differences at the CPU level can be determined
>>> by looking at "coprocessor" registers. For what purpose(s) do we need
>>> to identify the core? That will inform our choice of a core ID schema.
>>>
>> The primary thing I see would be architecture version compliance,
>> though this is better carried additionally via a binary field in
>> the header or a GPR at the entry point, to help the initial asm
>> code to setup the MMU etc... before getting into C code.
>>
>
> Also, if you're going to revive a "real" OF port to ARM (with client
> interface etc...), should we start considering moving some of powerpc's
> prom_init.c to a generic place ?
>
> IE. prom_init is a trampoline that uses the client interface to
> essentially create a flatten device-tree and enter the kernel via the
> common "epapr" style entry point.
>
> The main drawback is that it doesn't allow to keep OF alive along with
> the OS, but then, only sparc does that successfully and I'm not sure
> it's something that would be practical to do on ARM either.
>
I'm certainly going to try keeping OFW alive. On the x86 OLPC machines,
the ability to
dive into OFW via a SysRq key combo was very helpful for debugging some
difficult
problems. The team has asked me to support the feature on ARM.
> Cheers,
> Ben.
>
>
>
^ permalink raw reply
* Re: Request review of device tree documentation
From: Stephan Gatzka @ 2010-06-12 17:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTilK4YkRMJqlcRDOAlGBzpdlZuSo9NF5NrRNocHT@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
Hi Grant,
> I've been doing a bit of work on some introductory level documentation
> of the flattened device tree. I've got a rough copy up on the
> devicetree.org wiki, and I could use some feedback. If anyone has
> some time to look at it, you can find it here:
>
> http://devicetree.org/Device_Tree_Usage
>
> Thanks,
> g.
>
this looks good. Maybe an example of a complete host/PCI bridge might be
helpful. Probably I can write something during the next week.
Regards,
Stephan
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3332 bytes --]
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-12 18:19 UTC (permalink / raw)
To: stephan; +Cc: linuxppc-dev
In-Reply-To: <4C13C4D9.2030108@gatzka.org>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
That would be great. Thank you.
On 12 Jun 2010 11:44, "Stephan Gatzka" <stephan@gatzka.org> wrote:
Hi Grant,
> I've been doing a bit of work on some introductory level documentation
> of the flattened device...
this looks good. Maybe an example of a complete host/PCI bridge might be
helpful. Probably I can write something during the next week.
Regards,
Stephan
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 915 bytes --]
^ 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