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@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?
>>>
>>> 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
