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