Messages in this thread | | | Date | Wed, 5 Sep 2018 10:47:46 +0200 | From | Lukas Wunner <> | Subject | Re: [PATCH 2/2] thunderbolt: Initialize after IOMMUs |
| |
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?
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.
Commit acb40d841257 already changed module_init() to fs_initcall() and now it has to be changed again. Shows how fragile this is.
Thanks,
Lukas
| |