On 23/04/2024 12:12, Sui Jingfeng wrote: > Hi, > > On 2024/4/23 16:05, Krzysztof Kozlowski wrote: >> On 22/04/2024 21:19, Sui Jingfeng wrote: >>> Otherwise when compiled as module, this driver will not be probed on >>> non-DT environment. This is a fundamential step to make this driver >>> truely OF-independent. >> NAK. > > > :( ... > > >> >> You should not need MODULE_ALIAS() in normal cases. If you need it, >> usually it means your device ID table is wrong (e.g. misses either >> entries or MODULE_DEVICE_TABLE()). MODULE_ALIAS() is not a substitute >> for incomplete ID table. > > > I think I could give you a reason. > > 1) When compile this driver into linux kernel > > This driver will be probed if we create a platform device manually with the name "tfp410". Then do not create devices manually. This is not y2000 to use board files. > This is also true for the display-connector driver(drivers/gpu/drm/bridge/display-connector.c), > see patch 0005 of this series and the simple-bridge driver(drivers/gpu/drm/bridge/simple-bridge.c) > see patch 0003 of this series. They have the same problem. > > 2) But when compile this driver as module, creating a platform device manually with the same name > *won't* make those platform driver probed. I think, this is *inconsistent behavior*. Therefore, I > add MODULE_ALIAS() to keep the behavior consistent. That is, a driver, should be able to be probed > regardless it is compile as a kernel module or it is built into the kernel. > That's obvious. Please focus on the actual issue here. > >> Just check your aliases and look what is there. You already have >> i2c:tfp410 alias. > > Right, but the i2c:tfp410 alias only guarantee the driver can be probed successfully > when tfp410 working as I2C slave. tfp410 can also works as a transparent bridge. So which bus or driver instantiates the device? What use case is this? > > >> If you need platform one, for some reason, explain >> what is your matching path and add appropriate ID table. With that >> explanation, of course. > > When tfp410 works as a transparent bridge. The device itself is just a platform device. > similar with the display-connector.c and simple-bridge.c. > > It is not discoverable by the system on non-DT environment, this is the root problem. > I said the various display bridges drivers are fully DT dependent, Dimtry didn't agree! > > He said "I can not agree here. It doesn't depend on DT." and then asks me to developing > some other solution witch could preserve code sharing. So here it is. You wrote long message without actually reading my answer early. I already gave you the solution. Address that one. Best regards, Krzysztof
