linux-kernel - Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on tegra124

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1499666739.1313.1.camel@paulk.fr>
Date:   Mon, 10 Jul 2017 09:05:39 +0300
From:   Paul Kocialkowski <contact@...lk.fr>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Jonathan Hunter <jonathanh@...dia.com>,
        Stephen Warren <swarren@...dotorg.org>,
        Mikko Perttunen <mperttunen@...dia.com>
Subject: Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on
 tegra124

Le lundi 10 juillet 2017 à 07:21 +0200, Thierry Reding a écrit :
> On Sun, Jul 09, 2017 at 07:36:14PM +0300, Paul Kocialkowski wrote:
> > This registers the host1x node with the SMMU (as HC swgroup) to
> > allow
> > the host1x code to attach to it. It avoid failing the probe
> > sequence,
> > which resulted in the tegra drm driver not probing and thus nothing
> > being displayed on-screen.
> > 
> > Signed-off-by: Paul Kocialkowski <contact@...lk.fr>
> > ---
> >  arch/arm/boot/dts/tegra124.dtsi | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Thanks for tracking this down. However, I don't think this is an
> appropriate fix for v4.12 because it requires an update to the DTB in
> order to preserve functionality, which means we've broken DT ABI. The
> proper fix I think needs to be to make usage of the IOMMU completely
> optional in the host1x driver.

I see, that makes sense.

> So I think what happens without this DT change is that the call to
> iommu_attach_device() fails and we have no way to recover from that.

That is exactly what is happening, indeed.

> I think what we need to do is to free the domain in that case and make
> sure we can continue without one. It's probably best to add an error
> message, or maybe a warning to make sure people are aware.

By freeing the domain, do you mean continuing without IOMMU support?
If so, then we should make sure to only behave that way for -ENODEV and
generally still fail for other errors.

> Do you have the time to address this? If not, perhaps Mikko can take a
> look?

I can craft a patch this evening, but if someone else wants to work on
it earlier, they are totally welcome to do it!

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)