From: Sui Jingfeng <sui.jingfeng@linux.dev>
To: Krzysztof Kozlowski <krzk@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>
Cc: Robert Foss <rfoss@kernel.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Phong LE <ple@baylibre.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 9/9] drm/bridge: tfp410: Add platform module alias
Date: Tue, 23 Apr 2024 18:44:40 +0800 [thread overview]
Message-ID: <648e60f1-780a-428c-93b3-89d9804d6686@linux.dev> (raw)
In-Reply-To: <e41e7916-14aa-4128-9ef1-42736ad9a581@kernel.org>
On 2024/4/23 18:20, Krzysztof Kozlowski wrote:
> 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.
Not exactly, creating devices manually can be modern and fancy approach.
Complex driver need to create devices manually to paper over the issue(-EPROBE_DEFER)
raised with cross drivers subsystem design. Or for the purpose of better modularization.
See etnaviv, vkms, efifb, aux-bridge, aux-bus, ect.
OK, I know what you means here.
>> 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.
Use MODULE_DEVICE_TABLE() instead? OK, I understand then. Thanks a lot
for the education.
> Best regards,
> Krzysztof
>
--
Best regards,
Sui
next prev parent reply other threads:[~2024-04-23 10:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 19:18 [PATCH v4 0/9] drm/bridge: Allow using fwnode API to get the next bridge Sui Jingfeng
2024-04-22 19:18 ` [PATCH v4 1/9] " Sui Jingfeng
2024-04-22 19:51 ` Dmitry Baryshkov
2024-04-23 6:21 ` Sui Jingfeng
2024-04-22 19:18 ` [PATCH v4 2/9] drm/bridge: simple-bridge: Use fwnode API to acquire device properties Sui Jingfeng
2024-04-22 19:56 ` Dmitry Baryshkov
2024-04-22 19:18 ` [PATCH v4 3/9] drm/bridge: simple-bridge: Add platform module alias Sui Jingfeng
2024-04-22 19:58 ` Dmitry Baryshkov
2024-04-22 19:18 ` [PATCH v4 4/9] drm-bridge: display-connector: Use fwnode API to acquire device properties Sui Jingfeng
2024-04-22 20:00 ` Dmitry Baryshkov
2024-04-22 19:18 ` [PATCH v4 5/9] drm/bridge: display-connector: Add platform module alias Sui Jingfeng
2024-04-22 20:01 ` Dmitry Baryshkov
2024-04-22 19:19 ` [PATCH v4 6/9] drm-bridge: sii902x: Use fwnode API to acquire device properties Sui Jingfeng
2024-04-22 20:02 ` Dmitry Baryshkov
2024-04-22 19:19 ` [PATCH v4 7/9] drm-bridge: it66121: " Sui Jingfeng
2024-04-22 20:06 ` Dmitry Baryshkov
2024-04-27 13:11 ` Sui Jingfeng
2024-04-22 19:19 ` [PATCH v4 8/9] drm/bridge: tfp410: " Sui Jingfeng
2024-04-22 20:08 ` Dmitry Baryshkov
2024-04-27 18:43 ` Sui Jingfeng
2024-04-27 19:17 ` Dmitry Baryshkov
2024-04-27 20:10 ` Sui Jingfeng
2024-04-22 19:19 ` [PATCH v4 9/9] drm/bridge: tfp410: Add platform module alias Sui Jingfeng
2024-04-23 8:05 ` Krzysztof Kozlowski
2024-04-23 10:12 ` Sui Jingfeng
2024-04-23 10:20 ` Krzysztof Kozlowski
2024-04-23 10:44 ` Sui Jingfeng [this message]
2024-04-23 10:49 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=648e60f1-780a-428c-93b3-89d9804d6686@linux.dev \
--to=sui.jingfeng@linux.dev \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=ple@baylibre.com \
--cc=rfoss@kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).