Messages in this thread | | | Date | Wed, 5 Sep 2018 12:46:02 +0300 | From | Mika Westerberg <> | Subject | Re: [PATCH 2/2] thunderbolt: Initialize after IOMMUs |
| |
On Wed, Sep 05, 2018 at 10:47:46AM +0200, Lukas Wunner wrote: > On Mon, Sep 03, 2018 at 04:20:12PM +0300, Mika Westerberg wrote: > > If IOMMU is enabled and Thunderbolt driver is built into the kernel > > image, it will be probed before IOMMUs are attached to the PCI bus. > > Because of this DMA mappings the driver does will not go through IOMMU > > and start failing right after IOMMUs are enabled. > > > > For this reason move the Thunderbolt driver initialization happen at > > rootfs level. > > > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > --- > > drivers/thunderbolt/nhi.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c > > index 88cff05a1808..5cd6bdfa068f 100644 > > --- a/drivers/thunderbolt/nhi.c > > +++ b/drivers/thunderbolt/nhi.c > > @@ -1191,5 +1191,5 @@ static void __exit nhi_unload(void) > > tb_domain_exit(); > > } > > > > -fs_initcall(nhi_init); > > +rootfs_initcall(nhi_init); > > module_exit(nhi_unload); > > What if the rootfs is located on a Thunderbolt-attached drive and > the thunderbolt driver needs to establish tunnels to that drive > before rootfs can be accessed? Doesn't the above break such a setup?
No, then you put the driver as part of your initrd.
> I think the dependency on the IOMMU should be open coded by returning > -EPROBE_DEFER from the ->probe hook if it's not yet attached. > Shuffling around initcall order is just applying duct tape.
It is not a dependency. The same thing can happen with any other driver if they happen to initialize any DMA with the device before IOMMUs are initialized.
> Commit acb40d841257 already changed module_init() to fs_initcall() > and now it has to be changed again. Shows how fragile this is.
It is a bit fragile but I don't see any other way to handle this than trusting on the link ordering. Both -EPROBE_DEFER and device_links are out of the question AFAICT.
| |