On 17/09/2021 16:44, Horia Geantă wrote: > On 9/17/2021 1:33 PM, Krzysztof Kozlowski wrote: >> On 17/09/2021 11:51, Horia Geantă wrote: >>> On 9/16/2021 5:06 PM, Marek Vasut wrote: >>>> On 9/16/21 3:59 PM, Krzysztof Kozlowski wrote: >>>>> On 16/09/2021 15:41, Marek Vasut wrote: >>>>>> Add MODULE_ALIAS for caam and caam_jr modules, so they can be auto-loaded. >>>>>> >>>>>> Signed-off-by: Marek Vasut <marex@xxxxxxx> >>>>>> Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> >>>>>> Cc: Horia Geantă <horia.geanta@xxxxxxx> >>>>>> Cc: Iuliana Prodan <iuliana.prodan@xxxxxxx> >>>>>> Cc: Krzysztof Kozlowski <krzk@xxxxxxxxxx> >>>>>> --- >>>>>> drivers/crypto/caam/ctrl.c | 1 + >>>>>> drivers/crypto/caam/jr.c | 1 + >>>>>> 2 files changed, 2 insertions(+) >>>>>> >>>>> >>>>> Since you marked it as RFC, let me share a comment - would be nice to >>>>> see here explanation why do you need module alias. >>>>> >>>>> Drivers usually do not need module alias to be auto-loaded, unless the >>>>> subsystem/bus reports different alias than one used for binding. Since >>>>> the CAAM can bind only via OF, I wonder what is really missing here. Is >>>>> it a MFD child (it's one of cases this can happen)? >>>> >>>> I noticed the CAAM is not being auto-loaded on boot, and then I noticed >>>> the MODULE_ALIAS fixes cropping up in the kernel log, but I couldn't >>>> find a good documentation for that MODULE_ALIAS. So I was hoping to get >>>> a feedback on it. >>>> >>> What platform are you using? >>> >>> "make modules_install" should take care of adding the proper aliases, >>> relying on the MODULE_DEVICE_TABLE() macro in the caam, caam_jr drivers. >>> >>> modules.alias file should contain: >>> alias of:N*T*Cfsl,sec4.0C* caam >>> alias of:N*T*Cfsl,sec4.0 caam >>> alias of:N*T*Cfsl,sec-v4.0C* caam >>> alias of:N*T*Cfsl,sec-v4.0 caam >>> alias of:N*T*Cfsl,sec4.0-job-ringC* caam_jr >>> alias of:N*T*Cfsl,sec4.0-job-ring caam_jr >>> alias of:N*T*Cfsl,sec-v4.0-job-ringC* caam_jr >>> alias of:N*T*Cfsl,sec-v4.0-job-ring caam_jr >> >> Marek added a platform alias which is not present here on the list >> (because there are no platform device IDs). The proper question is who >> requests this device via a platform match? Who sends such event? >> > AFAICS the platform bus adds the "platform:" alias to uevent env. > in its .uevent callback - platform_uevent(). > > When caam (platform) device is added, the uevent is generated with this env., > which contains both OF-style and "platform:" modaliases. I am not saying about theoretical case, I know that platform bus will send platform uevent. How did this device end up in platform bus so this uevent is being sent? It should be instantiated from OF on for example amba bus or directly from OF FDT scanning. Therefore I have the same question - who requests device via a platform match? Is it used out-of-tree in different configuration? Best regards, Krzysztof
