From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B0E1C61D97 for ; Thu, 23 Nov 2023 17:04:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345188AbjKWREs (ORCPT ); Thu, 23 Nov 2023 12:04:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229970AbjKWREp (ORCPT ); Thu, 23 Nov 2023 12:04:45 -0500 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [IPv6:2001:41d0:203:375::bb]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B437C1 for ; Thu, 23 Nov 2023 09:04:50 -0800 (PST) Message-ID: <77c3ad35-24e4-4bf4-87a1-f48e13a6b838@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1700759088; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=t+oX6Z1R5D902d7QsFYgso+yPiFC9aIghMuoj3BGEfk=; b=jQfW6O848KtMwh90BwxowE88Yb2tw+fOohmBQXIG8fxTKGnbKn2PtIDmXCf4nr6b33NCYX 0e5e8sXTeNgxpDwySP5U7QKWB/PF2eUQjAWP0ZZ3z3DycIHjYqF/wHRzBzo66GoB5Ot3S2 TFre8bWupfsIEedGtc55MJAzC401+bU= Date: Fri, 24 Nov 2023 01:04:43 +0800 MIME-Version: 1.0 Subject: Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib Content-Language: en-US To: Dmitry Baryshkov Cc: Phong LE , Neil Armstrong , Maxime Ripard , Sui Jingfeng , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Laurent Pinchart , Thomas Zimmermann References: <20231114150130.497915-1-sui.jingfeng@linux.dev> <20231114150130.497915-9-sui.jingfeng@linux.dev> <79301d04-c0cb-4740-8a6d-27a889b65daf@linux.dev> <121163c9-0d56-47ad-a12e-e67390fef2b4@linux.dev> <00ba2245-0e48-4b21-bcd4-29dfb728e408@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sui Jingfeng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?