| Message ID | 20210916134154.8764-1-marex@denx.de (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | [RFC] crypto: caam - Add missing MODULE_ALIAS | expand |
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@denx.de> > Cc: Herbert Xu <herbert@gondor.apana.org.au> > Cc: Horia Geantă <horia.geanta@nxp.com> > Cc: Iuliana Prodan <iuliana.prodan@nxp.com> > Cc: Krzysztof Kozlowski <krzk@kernel.org> > --- > 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)? Best regards, Krzysztof
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@denx.de> >> Cc: Herbert Xu <herbert@gondor.apana.org.au> >> Cc: Horia Geantă <horia.geanta@nxp.com> >> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> >> Cc: Krzysztof Kozlowski <krzk@kernel.org> >> --- >> 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.
On 16/09/2021 16:06, 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@denx.de> >>> Cc: Herbert Xu <herbert@gondor.apana.org.au> >>> Cc: Horia Geantă <horia.geanta@nxp.com> >>> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> >>> Cc: Krzysztof Kozlowski <krzk@kernel.org> >>> --- >>> 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. Some busses, e.g. SPI or I2C, always reports matching name of "i2c:<foo>" even if actual matching of device was done via OF. The uevent will be i2c:<foo>. If the I2C/SPI table does not have above <foo> entry, but it has <foo> in OF table, you will have a case: 1. built-in works, because device matching happens via OF table, 2. module autoloading does not work, because module matching happens via I2C ID table. MFD children, which are usually platform devices, is another example. However your case looks different. What uevent do you get for this device? What does modinfo print? Best regards, Krzysztof
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@denx.de> >>> Cc: Herbert Xu <herbert@gondor.apana.org.au> >>> Cc: Horia Geantă <horia.geanta@nxp.com> >>> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> >>> Cc: Krzysztof Kozlowski <krzk@kernel.org> >>> --- >>> 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 Regards, Horia
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@denx.de> >>>> Cc: Herbert Xu <herbert@gondor.apana.org.au> >>>> Cc: Horia Geantă <horia.geanta@nxp.com> >>>> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> >>>> Cc: Krzysztof Kozlowski <krzk@kernel.org> >>>> --- >>>> 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? Best regards, Krzysztof
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@denx.de> >>>>> Cc: Herbert Xu <herbert@gondor.apana.org.au> >>>>> Cc: Horia Geantă <horia.geanta@nxp.com> >>>>> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> >>>>> Cc: Krzysztof Kozlowski <krzk@kernel.org> >>>>> --- >>>>> 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. Regards, Horia
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@denx.de> >>>>>> Cc: Herbert Xu <herbert@gondor.apana.org.au> >>>>>> Cc: Horia Geantă <horia.geanta@nxp.com> >>>>>> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> >>>>>> Cc: Krzysztof Kozlowski <krzk@kernel.org> >>>>>> --- >>>>>> 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
On 17/09/2021 18:21, Krzysztof Kozlowski wrote: > 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@denx.de> >>>>>>> Cc: Herbert Xu <herbert@gondor.apana.org.au> >>>>>>> Cc: Horia Geantă <horia.geanta@nxp.com> >>>>>>> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> >>>>>>> Cc: Krzysztof Kozlowski <krzk@kernel.org> >>>>>>> --- >>>>>>> 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? I tried to reproduce such situation in case of a board I have with me (Exynos5422). I have a platform_driver only with of_device_id table. The driver is built as module. In my DTS the device node is like (exynos5.dtsi and device is modified exynos-chipid to be a module): soc: soc { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges; chipid: chipid@10000000 { compatible = "samsung,exynos4210-chipid"; reg = <0x10000000 0x100>; }; ... }; The module was properly autoloaded (via OF aliases/events) and device was matched. Best regards, Krzysztof
On 9/17/21 7:30 PM, Krzysztof Kozlowski wrote: > On 17/09/2021 18:21, Krzysztof Kozlowski wrote: >> 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@denx.de> >>>>>>>> Cc: Herbert Xu <herbert@gondor.apana.org.au> >>>>>>>> Cc: Horia Geantă <horia.geanta@nxp.com> >>>>>>>> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> >>>>>>>> Cc: Krzysztof Kozlowski <krzk@kernel.org> >>>>>>>> --- >>>>>>>> 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? > > I tried to reproduce such situation in case of a board I have with me > (Exynos5422). I have a platform_driver only with of_device_id table. The > driver is built as module. In my DTS the device node is like > (exynos5.dtsi and device is modified exynos-chipid to be a module): > > soc: soc { > compatible = "simple-bus"; > #address-cells = <1>; > #size-cells = <1>; > ranges; > > chipid: chipid@10000000 { > compatible = "samsung,exynos4210-chipid"; > reg = <0x10000000 0x100>; > }; > > ... > }; > > The module was properly autoloaded (via OF aliases/events) and device > was matched. Please put this on hold for a bit, I need a colleague to check the udev event on this platform before we can move on any further.
Hi, On 2021-09-20 15:43, Marek Vasut wrote: > On 9/17/21 7:30 PM, Krzysztof Kozlowski wrote: >> On 17/09/2021 18:21, Krzysztof Kozlowski wrote: >>> 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@denx.de> >>>>>>>>> Cc: Herbert Xu <herbert@gondor.apana.org.au> >>>>>>>>> Cc: Horia Geantă <horia.geanta@nxp.com> >>>>>>>>> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> >>>>>>>>> Cc: Krzysztof Kozlowski <krzk@kernel.org> >>>>>>>>> --- >>>>>>>>> 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? >> >> I tried to reproduce such situation in case of a board I have with me >> (Exynos5422). I have a platform_driver only with of_device_id table. The >> driver is built as module. In my DTS the device node is like >> (exynos5.dtsi and device is modified exynos-chipid to be a module): >> >> soc: soc { >> compatible = "simple-bus"; >> #address-cells = <1>; >> #size-cells = <1>; >> ranges; >> >> chipid: chipid@10000000 { >> compatible = "samsung,exynos4210-chipid"; >> reg = <0x10000000 0x100>; >> }; >> >> ... >> }; >> >> The module was properly autoloaded (via OF aliases/events) and device >> was matched. > > Please put this on hold for a bit, I need a colleague to check the udev > event on this platform before we can move on any further. Here are the uevent entries without this RFC patch applied: ``` # udevadm info -q all -p devices/platform/soc@0/30800000.bus/30900000.crypto P: /devices/platform/soc@0/30800000.bus/30900000.crypto L: 0 E: DEVPATH=/devices/platform/soc@0/30800000.bus/30900000.crypto E: DRIVER=caam E: OF_NAME=crypto E: OF_FULLNAME=/soc@0/bus@30800000/crypto@30900000 E: OF_COMPATIBLE_0=fsl,sec-v4.0 E: OF_COMPATIBLE_N=1 E: MODALIAS=of:NcryptoT(null)Cfsl,sec-v4.0 E: SUBSYSTEM=platform E: USEC_INITIALIZED=4468986 E: ID_PATH=platform-30900000.crypto E: ID_PATH_TAG=platform-30900000_crypto ``` regards, Claudius
On 20/09/2021 18:09, Claudius Heine wrote: > Hi, > > On 2021-09-20 15:43, Marek Vasut wrote: >> On 9/17/21 7:30 PM, Krzysztof Kozlowski wrote: >>> On 17/09/2021 18:21, Krzysztof Kozlowski wrote: >>>> 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@denx.de> >>>>>>>>>> Cc: Herbert Xu <herbert@gondor.apana.org.au> >>>>>>>>>> Cc: Horia Geantă <horia.geanta@nxp.com> >>>>>>>>>> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> >>>>>>>>>> Cc: Krzysztof Kozlowski <krzk@kernel.org> >>>>>>>>>> --- >>>>>>>>>> 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? >>> >>> I tried to reproduce such situation in case of a board I have with me >>> (Exynos5422). I have a platform_driver only with of_device_id table. The >>> driver is built as module. In my DTS the device node is like >>> (exynos5.dtsi and device is modified exynos-chipid to be a module): >>> >>> soc: soc { >>> compatible = "simple-bus"; >>> #address-cells = <1>; >>> #size-cells = <1>; >>> ranges; >>> >>> chipid: chipid@10000000 { >>> compatible = "samsung,exynos4210-chipid"; >>> reg = <0x10000000 0x100>; >>> }; >>> >>> ... >>> }; >>> >>> The module was properly autoloaded (via OF aliases/events) and device >>> was matched. >> >> Please put this on hold for a bit, I need a colleague to check the udev >> event on this platform before we can move on any further. > > Here are the uevent entries without this RFC patch applied: > > ``` > # udevadm info -q all -p devices/platform/soc@0/30800000.bus/30900000.crypto > P: /devices/platform/soc@0/30800000.bus/30900000.crypto > L: 0 > E: DEVPATH=/devices/platform/soc@0/30800000.bus/30900000.crypto > E: DRIVER=caam > E: OF_NAME=crypto > E: OF_FULLNAME=/soc@0/bus@30800000/crypto@30900000 > E: OF_COMPATIBLE_0=fsl,sec-v4.0 > E: OF_COMPATIBLE_N=1 > E: MODALIAS=of:NcryptoT(null)Cfsl,sec-v4.0 > E: SUBSYSTEM=platform > E: USEC_INITIALIZED=4468986 > E: ID_PATH=platform-30900000.crypto > E: ID_PATH_TAG=platform-30900000_crypto > ``` Thanks. There is no platform alias in MODALIAS (as expected). It's exactly the same uevent I found in my case of exynos-chipid driver. No need for platform module alias. :) Best regards, Krzysztof
Hi Claudius, On Mon, Sep 20, 2021 at 1:54 PM Claudius Heine <ch@denx.de> wrote: > Here are the uevent entries without this RFC patch applied: > > ``` > # udevadm info -q all -p devices/platform/soc@0/30800000.bus/30900000.crypto > P: /devices/platform/soc@0/30800000.bus/30900000.crypto > L: 0 > E: DEVPATH=/devices/platform/soc@0/30800000.bus/30900000.crypto > E: DRIVER=caam > E: OF_NAME=crypto > E: OF_FULLNAME=/soc@0/bus@30800000/crypto@30900000 > E: OF_COMPATIBLE_0=fsl,sec-v4.0 > E: OF_COMPATIBLE_N=1 > E: MODALIAS=of:NcryptoT(null)Cfsl,sec-v4.0 > E: SUBSYSTEM=platform > E: USEC_INITIALIZED=4468986 > E: ID_PATH=platform-30900000.crypto > E: ID_PATH_TAG=platform-30900000_crypto Looking at the addresses above, it looks like you have a device from the i.MX8M family. caam module is being correctly autoloaded on imx8mn-evk, for example on kernel 5.14.6: https://storage.kernelci.org/stable/linux-5.14.y/v5.14.6/arm64/defconfig/gcc-8/lab-baylibre/baseline-imx8mn-ddr4-evk.html It works on 5.10.67 too: https://storage.kernelci.org/stable/linux-5.10.y/v5.10.67/arm64/defconfig/gcc-8/lab-baylibre/baseline-imx8mn-ddr4-evk.html Which kernel version do you use? Regards, Fabio Estevam
Hi Fabio, On 2021-09-21 13:08, Fabio Estevam wrote: > Hi Claudius, > > On Mon, Sep 20, 2021 at 1:54 PM Claudius Heine <ch@denx.de> wrote: > >> Here are the uevent entries without this RFC patch applied: >> >> ``` >> # udevadm info -q all -p devices/platform/soc@0/30800000.bus/30900000.crypto >> P: /devices/platform/soc@0/30800000.bus/30900000.crypto >> L: 0 >> E: DEVPATH=/devices/platform/soc@0/30800000.bus/30900000.crypto >> E: DRIVER=caam >> E: OF_NAME=crypto >> E: OF_FULLNAME=/soc@0/bus@30800000/crypto@30900000 >> E: OF_COMPATIBLE_0=fsl,sec-v4.0 >> E: OF_COMPATIBLE_N=1 >> E: MODALIAS=of:NcryptoT(null)Cfsl,sec-v4.0 >> E: SUBSYSTEM=platform >> E: USEC_INITIALIZED=4468986 >> E: ID_PATH=platform-30900000.crypto >> E: ID_PATH_TAG=platform-30900000_crypto > > Looking at the addresses above, it looks like you have a device from > the i.MX8M family. > > caam module is being correctly autoloaded on imx8mn-evk, for example > on kernel 5.14.6: > https://storage.kernelci.org/stable/linux-5.14.y/v5.14.6/arm64/defconfig/gcc-8/lab-baylibre/baseline-imx8mn-ddr4-evk.html > > It works on 5.10.67 too: > https://storage.kernelci.org/stable/linux-5.10.y/v5.10.67/arm64/defconfig/gcc-8/lab-baylibre/baseline-imx8mn-ddr4-evk.html > > Which kernel version do you use? I never have any issues with auto loading of the module. I just had an issue where the rngd daemon didn't wait until the module was loaded and failed to start. I found out that there was just some `Wants=systemd-udev-settle.service` missing in the service file and then everything worked. [1] Marek just suspected at first that a `MODULE_ALIAS` might be necessary in the driver and submitted this RFC patch for it. So all is well from my end :) And thanks for everyone looking into this! regards, Claudius [1] https://lists.openembedded.org/g/openembedded-core/message/156129
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c index ca0361b2dbb07..f4a1babb418dc 100644 --- a/drivers/crypto/caam/ctrl.c +++ b/drivers/crypto/caam/ctrl.c @@ -923,3 +923,4 @@ module_platform_driver(caam_driver); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("FSL CAAM request backend"); MODULE_AUTHOR("Freescale Semiconductor - NMG/STC"); +MODULE_ALIAS("platform:caam"); diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c index 6f669966ba2c1..3b7ea315226aa 100644 --- a/drivers/crypto/caam/jr.c +++ b/drivers/crypto/caam/jr.c @@ -635,3 +635,4 @@ module_exit(jr_driver_exit); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("FSL CAAM JR request backend"); MODULE_AUTHOR("Freescale Semiconductor - NMG/STC"); +MODULE_ALIAS("platform:caam_jr");
Add MODULE_ALIAS for caam and caam_jr modules, so they can be auto-loaded. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> --- drivers/crypto/caam/ctrl.c | 1 + drivers/crypto/caam/jr.c | 1 + 2 files changed, 2 insertions(+)