linux-kernel - Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

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 for Android: free password hash cracker in your pocket

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

Message-ID: <77c3ad35-24e4-4bf4-87a1-f48e13a6b838@linux.dev>
Date:   Fri, 24 Nov 2023 01:04:43 +0800
From:   Sui Jingfeng <sui.jingfeng@...ux.dev>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     Phong LE <ple@...libre.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Maxime Ripard <mripard@...nel.org>,
        Sui Jingfeng <suijingfeng@...ngson.cn>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Thomas Zimmermann <tzimmermann@...e.de>
Subject: Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

Hi,

On 2023/11/23 16:08, Dmitry Baryshkov wrote:
>>> The host can not specify the
>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, it will cause a warning here. And
>>> it can not omit the flag (as otherwise the first bridge will create a
>>> connector, without consulting the second bridge).
>> The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flagare implement-defined,
> No, they are not. Semantics are pretty simple: do not create the
> drm_connector instance. Pass the flag to the next bridge in the chain.
>
>> for our case, I could just ignore it if their
>> don't have a signal(DT or ACPI) tell me that there are multiple bridges
>> in the chain. This depend on community's attitude.
> Ignoring a flag is a bad idea.

Can you also read the code in the bridge/lontium-lt8912.c please?
when flags == 0 is true, the lt8912 driver will just create
a drm_connector instance in the drm bridge drivers. The behavior
is similar with this patch in the perspective of spirit.

And the most important thing is that no matter what the flag the upstream
port is passed, lt8912 just always pass the DRM_BRIDGE_ATTACH_NO_CONNECTOR
flags to the next bridge. Does this count as a kind of ignore? or

This is to say that both the lt8912 and the tfp410 drm bridge drivers are
allowing create a drm_connector manually in drm bridge drivers. They didn't
being asked to move the drm_connector related code to display controller
driver. I don't know why I can't follow this way?

Do you really read the code before do comments or I failed to understand something?