Re: [PATCH] VFIO: platform: AMD xgbe reset module
From: Arnd Bergmann
Date: Fri Oct 16 2015 - 09:27:24 EST
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.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/