linux-kernel - Re: [PATCH 2/5] iommu/omap: Permanently keep iommu_dev pointer in arch

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] [day] [month] [year] [list]

Date:   Fri, 7 Apr 2017 16:35:20 +0200
From:   Joerg Roedel <joro@...tes.org>
To:     Suman Anna <s-anna@...com>
Cc:     iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
        Joerg Roedel <jroedel@...e.de>
Subject: Re: [PATCH 2/5] iommu/omap: Permanently keep iommu_dev pointer in
 arch_data

Hi Suman,

On Mon, Apr 03, 2017 at 03:35:46PM -0500, Suman Anna wrote:
> > +	iommu = platform_get_drvdata(pdev);
> > +	if (!iommu) {
> > +		of_node_put(np);
> > +		return -EINVAL;
> > +	}
> 
> This change is causing the issues. OMAP IOMMU driver is not probed yet,
> but this gets called during the driver's init function in
> bus_set_iommu() and bus's iommu_ops gets set to NULL. The add_device
> today is used to add the linking to an IOMMU device (currently name
> primarily to support the legacy non-DT mode which is no longer an issue,
> but a dev pointer can be used instead here, and the real enabling is
> done during the domain's attach_dev callback.

Yeah, okay. Solving this problem requires more sophisticated handling in
the iommu core code, which is not implemented yet.

I drop this patch for now and do the device-linking and group-handling
in attach_dev. This makes iommu-groups on omap useless for now, but it
is a start.


	Joerg