Re: [PATCH v4 9/9] drm/bridge: tfp410: Add platform module alias

[Krzysztof Kozlowski <krzk@kernel.org>]

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