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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 23 Apr 2024 12:20:10 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Sui Jingfeng <sui.jingfeng@...ux.dev>,
 Neil Armstrong <neil.armstrong@...aro.org>
Cc: Robert Foss <rfoss@...nel.org>,
 Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
 Andrzej Hajda <andrzej.hajda@...el.com>, Jonas Karlman <jonas@...boo.se>,
 Jernej Skrabec <jernej.skrabec@...il.com>, Maxime Ripard
 <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
 Phong LE <ple@...libre.com>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 9/9] drm/bridge: tfp410: Add platform module alias

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