* [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS @ 2021-09-16 13:41 Marek Vasut 2021-09-16 13:59 ` Krzysztof Kozlowski 0 siblings, 1 reply; 14+ messages in thread From: Marek Vasut @ 2021-09-16 13:41 UTC (permalink / raw) To: linux-crypto Cc: ch, Marek Vasut, Herbert Xu, Horia Geantă, Iuliana Prodan, Krzysztof Kozlowski 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(+) 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"); -- 2.33.0 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-16 13:41 [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS Marek Vasut @ 2021-09-16 13:59 ` Krzysztof Kozlowski 2021-09-16 14:06 ` Marek Vasut 0 siblings, 1 reply; 14+ messages in thread From: Krzysztof Kozlowski @ 2021-09-16 13:59 UTC (permalink / raw) To: Marek Vasut, linux-crypto Cc: ch, Herbert Xu, Horia Geantă, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-16 13:59 ` Krzysztof Kozlowski @ 2021-09-16 14:06 ` Marek Vasut 2021-09-16 14:22 ` Krzysztof Kozlowski 2021-09-17 9:51 ` Horia Geantă 0 siblings, 2 replies; 14+ messages in thread From: Marek Vasut @ 2021-09-16 14:06 UTC (permalink / raw) To: Krzysztof Kozlowski, linux-crypto Cc: ch, Herbert Xu, Horia Geantă, Iuliana Prodan 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-16 14:06 ` Marek Vasut @ 2021-09-16 14:22 ` Krzysztof Kozlowski 2021-09-17 9:51 ` Horia Geantă 1 sibling, 0 replies; 14+ messages in thread From: Krzysztof Kozlowski @ 2021-09-16 14:22 UTC (permalink / raw) To: Marek Vasut, linux-crypto Cc: ch, Herbert Xu, Horia Geantă, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-16 14:06 ` Marek Vasut 2021-09-16 14:22 ` Krzysztof Kozlowski @ 2021-09-17 9:51 ` Horia Geantă 2021-09-17 10:33 ` Krzysztof Kozlowski 1 sibling, 1 reply; 14+ messages in thread From: Horia Geantă @ 2021-09-17 9:51 UTC (permalink / raw) To: Marek Vasut, Krzysztof Kozlowski, linux-crypto Cc: ch, Herbert Xu, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-17 9:51 ` Horia Geantă @ 2021-09-17 10:33 ` Krzysztof Kozlowski 2021-09-17 14:44 ` Horia Geantă 0 siblings, 1 reply; 14+ messages in thread From: Krzysztof Kozlowski @ 2021-09-17 10:33 UTC (permalink / raw) To: Horia Geantă, Marek Vasut, linux-crypto Cc: ch, Herbert Xu, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-17 10:33 ` Krzysztof Kozlowski @ 2021-09-17 14:44 ` Horia Geantă 2021-09-17 16:21 ` Krzysztof Kozlowski 0 siblings, 1 reply; 14+ messages in thread From: Horia Geantă @ 2021-09-17 14:44 UTC (permalink / raw) To: Krzysztof Kozlowski, Marek Vasut, linux-crypto Cc: ch, Herbert Xu, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-17 14:44 ` Horia Geantă @ 2021-09-17 16:21 ` Krzysztof Kozlowski 2021-09-17 17:30 ` Krzysztof Kozlowski 0 siblings, 1 reply; 14+ messages in thread From: Krzysztof Kozlowski @ 2021-09-17 16:21 UTC (permalink / raw) To: Horia Geantă, Marek Vasut, linux-crypto Cc: ch, Herbert Xu, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-17 16:21 ` Krzysztof Kozlowski @ 2021-09-17 17:30 ` Krzysztof Kozlowski 2021-09-20 13:43 ` Marek Vasut 0 siblings, 1 reply; 14+ messages in thread From: Krzysztof Kozlowski @ 2021-09-17 17:30 UTC (permalink / raw) To: Horia Geantă, Marek Vasut, linux-crypto Cc: ch, Herbert Xu, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-17 17:30 ` Krzysztof Kozlowski @ 2021-09-20 13:43 ` Marek Vasut 2021-09-20 16:09 ` Claudius Heine 0 siblings, 1 reply; 14+ messages in thread From: Marek Vasut @ 2021-09-20 13:43 UTC (permalink / raw) To: Krzysztof Kozlowski, Horia Geantă, linux-crypto Cc: ch, Herbert Xu, Iuliana Prodan 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-20 13:43 ` Marek Vasut @ 2021-09-20 16:09 ` Claudius Heine 2021-09-20 16:16 ` Krzysztof Kozlowski 2021-09-21 11:08 ` Fabio Estevam 0 siblings, 2 replies; 14+ messages in thread From: Claudius Heine @ 2021-09-20 16:09 UTC (permalink / raw) To: Marek Vasut, Krzysztof Kozlowski, Horia Geantă, linux-crypto Cc: Herbert Xu, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-20 16:09 ` Claudius Heine @ 2021-09-20 16:16 ` Krzysztof Kozlowski 2021-09-21 11:08 ` Fabio Estevam 1 sibling, 0 replies; 14+ messages in thread From: Krzysztof Kozlowski @ 2021-09-20 16:16 UTC (permalink / raw) To: Claudius Heine, Marek Vasut, Horia Geantă, linux-crypto Cc: Herbert Xu, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-20 16:09 ` Claudius Heine 2021-09-20 16:16 ` Krzysztof Kozlowski @ 2021-09-21 11:08 ` Fabio Estevam 2021-09-21 11:19 ` Claudius Heine 1 sibling, 1 reply; 14+ messages in thread From: Fabio Estevam @ 2021-09-21 11:08 UTC (permalink / raw) To: Claudius Heine Cc: Marek Vasut, Krzysztof Kozlowski, Horia Geantă, linux-crypto, Herbert Xu, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS 2021-09-21 11:08 ` Fabio Estevam @ 2021-09-21 11:19 ` Claudius Heine 0 siblings, 0 replies; 14+ messages in thread From: Claudius Heine @ 2021-09-21 11:19 UTC (permalink / raw) To: Fabio Estevam Cc: Marek Vasut, Krzysztof Kozlowski, Horia Geantă, linux-crypto, Herbert Xu, Iuliana Prodan 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-09-21 11:19 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-16 13:41 [RFC][PATCH] crypto: caam - Add missing MODULE_ALIAS Marek Vasut 2021-09-16 13:59 ` Krzysztof Kozlowski 2021-09-16 14:06 ` Marek Vasut 2021-09-16 14:22 ` Krzysztof Kozlowski 2021-09-17 9:51 ` Horia Geantă 2021-09-17 10:33 ` Krzysztof Kozlowski 2021-09-17 14:44 ` Horia Geantă 2021-09-17 16:21 ` Krzysztof Kozlowski 2021-09-17 17:30 ` Krzysztof Kozlowski 2021-09-20 13:43 ` Marek Vasut 2021-09-20 16:09 ` Claudius Heine 2021-09-20 16:16 ` Krzysztof Kozlowski 2021-09-21 11:08 ` Fabio Estevam 2021-09-21 11:19 ` Claudius Heine
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.