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

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

Message-ID: <187b2c32-5a10-4555-8d49-cf1ee86a8eaa@rock-chips.com>
Date: Sun, 4 Jan 2026 10:51:20 +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 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.

Best regards,
Damon