| Message ID | 1483371482-4956-1-git-send-email-javier@osg.samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote: > If the driver is built as a module, autoload won't work because the module > alias information is not filled. So user-space can't match the registered > device with the corresponding module if the device isn't registered via OF. > > Export the module alias information using the MODULE_DEVICE_TABLE() macro. I think we can just remove the table, as the platform only supports booting through DT anyway. Arnd
Hello Arnd, On 01/02/2017 01:05 PM, Arnd Bergmann wrote: > On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote: >> If the driver is built as a module, autoload won't work because the module >> alias information is not filled. So user-space can't match the registered >> device with the corresponding module if the device isn't registered via OF. >> >> Export the module alias information using the MODULE_DEVICE_TABLE() macro. > > I think we can just remove the table, as the platform only supports > booting through DT anyway. > Agreed. I should had checked if mach-picoxcell was DT-only indeed. Should I also make the driver to depend on OF and remove the #ifdefery then? > Arnd > Best regards,
On Monday, January 2, 2017 1:13:24 PM CET Javier Martinez Canillas wrote: > Hello Arnd, > > On 01/02/2017 01:05 PM, Arnd Bergmann wrote: > > On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote: > >> If the driver is built as a module, autoload won't work because the module > >> alias information is not filled. So user-space can't match the registered > >> device with the corresponding module if the device isn't registered via OF. > >> > >> Export the module alias information using the MODULE_DEVICE_TABLE() macro. > > > > I think we can just remove the table, as the platform only supports > > booting through DT anyway. > > > > Agreed. I should had checked if mach-picoxcell was DT-only indeed. > > Should I also make the driver to depend on OF and remove the #ifdefery then? I don't think we need a dependency, the #ifdef checks in there were needed only to make the driver smaller if OF is disabled and it should still build fine if someone tries to compile it for CONFIG_COMPILE_TEST without CONFIG_OF. If we remove the platform ID, we can however also remove the spacc_is_compatible() function and just call of_device_is_compatible() in its place. Arnd
On 01/02/2017 01:24 PM, Arnd Bergmann wrote: > On Monday, January 2, 2017 1:13:24 PM CET Javier Martinez Canillas wrote: >> Hello Arnd, >> >> On 01/02/2017 01:05 PM, Arnd Bergmann wrote: >>> On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote: >>>> If the driver is built as a module, autoload won't work because the module >>>> alias information is not filled. So user-space can't match the registered >>>> device with the corresponding module if the device isn't registered via OF. >>>> >>>> Export the module alias information using the MODULE_DEVICE_TABLE() macro. >>> >>> I think we can just remove the table, as the platform only supports >>> booting through DT anyway. >>> >> >> Agreed. I should had checked if mach-picoxcell was DT-only indeed. >> >> Should I also make the driver to depend on OF and remove the #ifdefery then? > > I don't think we need a dependency, the #ifdef checks in there were needed > only to make the driver smaller if OF is disabled and it should still build > fine if someone tries to compile it for CONFIG_COMPILE_TEST without > CONFIG_OF. > OK, the driver doesn't depend on COMPILE_TEST though but I agree with you since it seems the driver only has runtime but no build time dependencies with ARCH_PICOXCELL. > If we remove the platform ID, we can however also remove the > spacc_is_compatible() function and just call of_device_is_compatible() > in its place. > Yes. > Arnd > Best regards,
diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c index 47576098831f..64449b7c00af 100644 --- a/drivers/crypto/picoxcell_crypto.c +++ b/drivers/crypto/picoxcell_crypto.c @@ -1808,6 +1808,7 @@ static const struct platform_device_id spacc_id_table[] = { { "picochip,spacc-l2", }, { } }; +MODULE_DEVICE_TABLE(platform, spacc_id_table); static struct platform_driver spacc_driver = { .probe = spacc_probe,
If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module if the device isn't registered via OF. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/crypto/picoxcell_crypto.ko | grep alias alias: of:N*T*Cpicochip,spacc-l2C* alias: of:N*T*Cpicochip,spacc-l2 alias: of:N*T*Cpicochip,spacc-ipsecC* alias: of:N*T*Cpicochip,spacc-ipsec After this patch: $ modinfo drivers/crypto/picoxcell_crypto.ko | grep alias alias: of:N*T*Cpicochip,spacc-l2C* alias: of:N*T*Cpicochip,spacc-l2 alias: of:N*T*Cpicochip,spacc-ipsecC* alias: of:N*T*Cpicochip,spacc-ipsec alias: platform:picochip,spacc-l2 alias: platform:picochip,spacc-ipsec Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> --- drivers/crypto/picoxcell_crypto.c | 1 + 1 file changed, 1 insertion(+)