linux-kernel - Re: [PATCH v8 04/18] drm/bridge: analogix_dp: Add &analogix_dp_plat_data.next

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] [day] [month] [year] [list]

Message-ID: <f644a5ab-5dd1-4f4e-b2e9-3585dec81a96@rock-chips.com>
Date: Wed, 7 Jan 2026 10:36:57 +0800
From: Damon Ding <damon.ding@...k-chips.com>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>, andrzej.hajda@...el.com,
 neil.armstrong@...aro.org, rfoss@...nel.org
Cc: Laurent.pinchart@...asonboard.com, jonas@...boo.se,
 jernej.skrabec@...il.com, maarten.lankhorst@...ux.intel.com,
 mripard@...nel.org, tzimmermann@...e.de, airlied@...il.com, simona@...ll.ch,
 shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de,
 festevam@...il.com, inki.dae@...sung.com, sw0312.kim@...sung.com,
 kyungmin.park@...sung.com, krzk@...nel.org, alim.akhtar@...sung.com,
 jingoohan1@...il.com, p.zabel@...gutronix.de, hjc@...k-chips.com,
 heiko@...ech.de, andy.yan@...k-chips.com, dmitry.baryshkov@....qualcomm.com,
 dianders@...omium.org, m.szyprowski@...sung.com, jani.nikula@...el.com,
 linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
 linux-samsung-soc@...r.kernel.org, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v8 04/18] drm/bridge: analogix_dp: Add
 &analogix_dp_plat_data.next_bridge

Hi Luca,

On 1/4/2026 10:51 AM, Damon Ding wrote:
> Hi Luca,
> 
> On 12/31/2025 7:11 PM, Luca Ceresoli wrote:
>> Hello Damon,
>>
>> On Wed Dec 17, 2025 at 10:33 AM CET, Damon Ding wrote:
>>> In order to move the panel/bridge parsing and attachmenet to the
>>> Analogix side, add component struct drm_bridge *next_bridge to
>>> platform data struct analogix_dp_plat_data.
>>>
>>> The movement makes sense because the panel/bridge should logically
>>> be positioned behind the Analogix bridge in the display pipeline.
>>>
>>> Signed-off-by: Damon Ding <damon.ding@...k-chips.com>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
>>> Tested-by: Marek Szyprowski <m.szyprowski@...sung.com>
>>>
>>> ---
>>>
>>> Changes in v4:
>>> - Rename the &analogix_dp_plat_data.bridge to
>>>    &analogix_dp_plat_data.next_bridge
>>> ---
>>>   include/drm/bridge/analogix_dp.h | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/ 
>>> analogix_dp.h
>>> index cf17646c1310..582357c20640 100644
>>> --- a/include/drm/bridge/analogix_dp.h
>>> +++ b/include/drm/bridge/analogix_dp.h
>>> @@ -27,6 +27,7 @@ static inline bool is_rockchip(enum 
>>> analogix_dp_devtype type)
>>>   struct analogix_dp_plat_data {
>>>       enum analogix_dp_devtype dev_type;
>>>       struct drm_panel *panel;
>>> +    struct drm_bridge *next_bridge;
>>>       struct drm_encoder *encoder;
>>>       struct drm_connector *connector;
>>>       bool skip_connector;
>>
>> It took a while to understand why you are adding the next_bridge 
>> pointer in
>> struct analogix_dp_plat_data instead of struct analogix_dp_device, 
>> where it
>> would be more natural. I found an answer in patch 16: with current 
>> code you
>> need to place next_bridge in struct analogix_dp_plat_data because it is
>> used by user drivers to attach, and those drivers have no access to 
>> struct
>> analogix_dp_device. However patch 16 (which looks a very good cleanup 
>> BTW)
>> next_bridge can be moved to struct analogix_dp_device.
>>
>> So I'd suggest to move patch 16 before this one if it easily doable, so
>> that you can introduce next_bridge in struct analogix_dp_device from the
>> beginning. Should that be impossible, you can send a separate patch to 
>> move
>> next_bridge, after patch 16.
>>
>>
> 
> Thanks for your nice suggestion! After patch 16, bridge attachment is 
> unified to the Analogix side, which acts as a common bridge driver for 
> both the Rockchip and Exynos sides, so moving next_bridge there makes 
> perfect sense. I will add a separate patch to move next_bridge in v9.
> 
> 

My apologies for reversing the plan to move next_bridge to the Analogix 
side in v9 -- I only considered the Rockchip side before.

When I tried modifying the code based on your suggestion, I found it 
better to keep &analogix_plat_data.next_bridge as is. This is because 
the Exynos side needs to maintain compatibility with the legacy method 
of parsing panels and bridges, so the next bridge isn't always parsed by 
the common Analogix side driver.

This patch series has been pending for ages, and I'm even a bit fuzzy on 
the details myself. ;-)

Best regards,
Damon