diff mbox series

[RFC] crypto: caam - Add missing MODULE_ALIAS

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

Commit Message

Marek Vasut Sept. 16, 2021, 1:41 p.m. UTC
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(+)

Comments

Krzysztof Kozlowski Sept. 16, 2021, 1:59 p.m. UTC | #1
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
Marek Vasut Sept. 16, 2021, 2:06 p.m. UTC | #2
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.
Krzysztof Kozlowski Sept. 16, 2021, 2:22 p.m. UTC | #3
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
Horia Geanta Sept. 17, 2021, 9:51 a.m. UTC | #4
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
Krzysztof Kozlowski Sept. 17, 2021, 10:33 a.m. UTC | #5
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
Horia Geanta Sept. 17, 2021, 2:44 p.m. UTC | #6
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
Krzysztof Kozlowski Sept. 17, 2021, 4:21 p.m. UTC | #7
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
Krzysztof Kozlowski Sept. 17, 2021, 5:30 p.m. UTC | #8
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
Marek Vasut Sept. 20, 2021, 1:43 p.m. UTC | #9
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.
Claudius Heine Sept. 20, 2021, 4:09 p.m. UTC | #10
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
Krzysztof Kozlowski Sept. 20, 2021, 4:16 p.m. UTC | #11
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
Fabio Estevam Sept. 21, 2021, 11:08 a.m. UTC | #12
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
Claudius Heine Sept. 21, 2021, 11:19 a.m. UTC | #13
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 mbox series

Patch

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");