linux-kernel - Re: [PATCH 08/10] iommu/omap: Use bus_set_iommu instead of register

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:	Sun, 2 Oct 2011 19:24:49 +0200
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Greg KH <greg@...ah.com>
Cc:	Joerg Roedel <joerg.roedel@....com>,
	iommu@...ts.linux-foundation.org,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Alex Williamson <alex.williamson@...hat.com>,
	David Woodhouse <dwmw2@...radead.org>,
	David Brown <davidb@...eaurora.org>, joro@...tes.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/10] iommu/omap: Use bus_set_iommu instead of register_iommu

(sorry for the late response; we had a big holiday here and I was
forced away from my keyboard :)

On Thu, Sep 29, 2011 at 11:04 PM, Greg KH <greg@...ah.com> wrote:
> On Fri, Sep 23, 2011 at 05:45:54PM +0200, Joerg Roedel wrote:
>> -     register_iommu(&omap_iommu_ops);
>> +     bus_set_iommu(&platform_bus_type, &omap_iommu_ops);
>
> I too worry about this.
>
> It kind of looks like the omap code should not be using the platform bus
> code for this, but instead, use their own bus code, as I'm sure that not
> all platform devices really work properly with this iommu controller,
> right?

You're right that not all omap platform devices will work with this
iommu device.

But maybe it's worth explaining the bigger difference here: there is
no omap bus really that makes sense here as much as pci does with x86.

On OMAP each iommu device services a single, and specific, on-chip
device (and not a group of devices that resides on a specific hardware
bus). E.g. on OMAP4 we have an iommu for the DSP, and another one for
the dual Cortex M3.

Those remote processors devices happen to be platform devices (because
there isn't really any relevant hardware bus here), and board code (or
DT) will set their iommu archdata to point at the relevant iommu
devices they're physically attached to. This way their drivers will be
able to configure the appropriate iommu devices as needed.

Binding the iommu ops to the platform bus will not enable other
platform drivers to configure the iommu: no other device will have the
relevant iommu archdata set, and any attempt to erroneously configure
the iommu by an unrelated driver will immediately fail (i.e.
iommu_attach_device() will fail).

In that sense, binding the iommu ops to the platform bus does not
increase the chance of error. I guess it even reduces it, because
today the iommu ops are globally accessible.

I was worried that with this change, sub-devices of the original
platform device, that belong to a different bus (e.g. virtio or
rpmsg), might not be able to access those iommu ops anymore. But I
guess that as long as we set the parent-child device hierarchy
appropriately, that would be a non issue.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/