Hi Arnd, On 10/16/2015 03:26 PM, Arnd Bergmann wrote: > On Friday 16 October 2015 15:06:45 Eric Auger wrote: > >> I've since forgotten his answer, but the fact that >>> __symbol_get() is only defined for modules makes it moot, we either need >>> to make symbol_get() work or define __symbol_get() for non-module >>> builds. >> I currently don't see any solution for any of those. The only solution I >> can see is someone registers the reset function pointer to vfio. >> >> I think we could keep the existing reset modules, do the request_module >> from VFIO, using their module name registered in the lookup table. But >> instead of having the reset function in the look-up table we would have >> the reset modules register their reset function pointer to VFIO. I think >> this could work around the symbol_get issue. >> >> This still leaves the layer violation argument though. >> >> Assuming this works, would that be an acceptable solution, although I >> acknowledge this does not perfectly fit into the driver model? > > I think it's possible to avoid the layering violation that way too, > by loading the module based on the compatible string, with a module_alias. > > static void vfio_platform_get_reset(struct vfio_platform_device *vdev, > struct device *dev) > { > const char *compat; > int (*reset)(struct vfio_platform_device *); > int ret, i; > char modname[256]; > > ret = device_property_read_string(dev, "compatible", &compat); > if (ret) > return; > > reset = vfio_platform_lookup_reset(compat); > if (!reset) { > snprintf(modname, "vfio-reset:%s", compat); > request_module(modname); > reset = vfio_platform_lookup_reset(compat); > } > > vdev->reset = reset; > } > > --- > > #define module_vfio_reset_handler(compat, reset) \ > MODULE_ALIAS("vfio_reset" compat); \ > static int reset ## _module_init(void) \ > { \ > return vfio_reset_register(THIS_MODULE, compat, &reset); \ > } > > I think that solution is good enough, as it avoids most of the > problems with the current implementation but is a simple enough change. That looks a good perspective. Thanks for the hint! Let's code now ;-) Best Regards Eric > > Arnd > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html