From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Jasty, Ananth" <Ananth.Jasty@cavium.com>
Cc: "magnus.damm@gmail.com" <magnus.damm@gmail.com>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
dann frazier <dann.frazier@canonical.com>,
"laurent.pinchart+renesas@ideasonboard.com"
<laurent.pinchart+renesas@ideasonboard.com>,
"geert+renesas@glider.be" <geert+renesas@glider.be>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Subject: Re: Seeing conflict with IPMMU driver under ACPI
Date: Tue, 19 Sep 2017 10:13:36 +0300 [thread overview]
Message-ID: <3844394.PedeR4fNcQ@avalon> (raw)
In-Reply-To: <49EA67E4-A526-4F47-9D3A-18E458850E03@caviumnetworks.com>
Hi Ananth,
On Tuesday, 19 September 2017 09:54:49 EEST Jasty, Ananth wrote:
> On Sep 18, 2017, at 11:49 PM, Laurent Pinchart wrote:
> > On Tuesday, 19 September 2017 03:43:05 EEST Jasty, Ananth wrote:
> >> Hi, with your IPMMU driver enabled under 4.13 we’re seeing a crash on
> >> boot:
> >>
> >> [ 13.785164] Unable to handle kernel NULL pointer dereference at virtual
> >> address 00000018
> >> [ 13.793254] [0000000000000018] user address but active_mm is swapper
> >> [ 13.799600] Internal error: Oops: 96000004 [#1] SMP
> >> [ 13.804466] Modules linked in: aes_neon_bs aes_neon_blk crypto_simd
> >> cryptd
> >> [ 13.811334] CPU: 152 PID: 1529 Comm: kworker/152:1 Not tainted
> >> 4.13.0-9-generic #10-Ubuntu
> >> [ 13.819584] Hardware name: Default string Cavium ThunderX2/Default
> >> string, BIOS 5.13 07/20/2017
> >> [ 13.828285] Workqueue: events deferred_probe_work_func
> >> [ 13.833410] task: ffff80bee93d0000 task.stack: ffff80bee93dc000
> >> [ 13.839330] PC is at iommu_ops_from_fwnode+0x4c/0x90
> >> [ 13.844282] LR is at iommu_ops_from_fwnode+0x28/0x90
> >>
> >> The ARM SMMUv3 driver (which our platform implements) seems to be losing
> >> iommu_ops to the IPMMU driver.
> >
> > You seem not to be the first one to notice:
> >
> > https://patchwork.kernel.org/patch/9956449/\0
>
> Wow, he did not beat me by much.
>
> >> Note: our platform uses ACPI for device enumeration.
> >>
> >> I have no way to test this, but is there a reason the set_iommu isn’t in
> >> _probe?
> >
> > I can't recall what the reason was I'm afraid.
>
> arm-smmu-v3.c does do the set_iommu in probe, and thus far there have been
> no confirmed fatalities, but I can't speak authoritatively.
>
> I'll leave you all to it then.
After digging a bit I realized that calling bus_set_iommu() from the init
function is needed to support ARM32 (the same driver supports both ARM32 and
ARM64). Let's discuss the matter in a reply to https://patchwork.kernel.org/
patch/9956449/\0.
--
Regards,
Laurent Pinchart
prev parent reply other threads:[~2017-09-19 7:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-19 0:43 Seeing conflict with IPMMU driver under ACPI Jasty, Ananth
2017-09-19 6:49 ` Laurent Pinchart
2017-09-19 6:54 ` Jasty, Ananth
2017-09-19 7:13 ` Laurent Pinchart [this message]
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=3844394.PedeR4fNcQ@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=Ananth.Jasty@cavium.com \
--cc=dann.frazier@canonical.com \
--cc=geert+renesas@glider.be \
--cc=iommu@lists.linux-foundation.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=robin.murphy@arm.com \
/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;
as well as URLs for NNTP newsgroup(s).