Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: Panic in quirk_usb_early_handoff
Date: Mon, 6 Mar 2017 14:49:47 +0100	[thread overview]
Message-ID: <76dea81d-c524-ad40-06bf-e549bb457f59@free.fr> (raw)
In-Reply-To: <491b40db-dc07-2a8e-9bc4-07b86f990600@free.fr>

On 06/03/2017 13:42, Mason wrote:

> So the kernel panics in xhci_find_next_ext_cap()
> ( drivers/usb/host/xhci-ext-caps.h:122 )
> http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122
> 
> Any idea how this can happen?
> 
> 	base = ioremap_nocache(pci_resource_start(pdev, 0), len);
> 
> Could I be passing garbage to ioremap_nocache?

Oh...

I have just now understood what Ard wrote a few days ago.

The issue was that, on this platform, the PCI configuration space
and memory space are multiplexed; in other words they reside at
the same physical address, with a bit in MMIO to choose one or
the other.

I was specifying an arbitrary address for the memory space,
which doesn't make any sense, as Ard pointed out.

So quirk_usb_handoff_xhci would ioremap(0x91000000, 8192)
which is the size of the USB device's memory region, but
0x91000000 is an address in system RAM. Thus, the readl
was actually picking up random garbage in RAM, which
makes xhci_find_next_ext_cap blow up pretty fast.

[    1.265224] xhci_find_next_ext_cap: offset=0xec44

I'm off to fix my blunder.

Regards.

  reply	other threads:[~2017-03-06 13:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-03 16:18 Panic in quirk_usb_early_handoff Mason
2017-03-03 17:10 ` Mason
2017-03-03 17:15   ` Mason
2017-03-03 19:02     ` Robin Murphy
2017-03-03 22:09       ` Mason
2017-03-04  0:24       ` Mason
2017-03-04  8:07         ` Ard Biesheuvel
2017-03-04 15:51           ` Alan Stern
2017-03-04 16:57           ` Mason
2017-03-04 17:16             ` Ard Biesheuvel
2017-03-04 17:29               ` Mason
2017-03-04 18:27                 ` Ard Biesheuvel
2017-03-06 12:42       ` Mason
2017-03-06 13:49         ` Mason [this message]
2017-03-06 15:27           ` David Laight
2017-03-06 15:45             ` Mason
2017-03-06 15:58               ` David Laight
2017-03-06 14:30         ` Robin Murphy
2017-03-06 14:56           ` Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=76dea81d-c524-ad40-06bf-e549bb457f59@free.fr \
    --to=slash.tmp@free.fr \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox