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 BA7F6C636BD for ; Sat, 25 Nov 2023 02:30:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231644AbjKYCaP (ORCPT ); Fri, 24 Nov 2023 21:30:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229569AbjKYCaN (ORCPT ); Fri, 24 Nov 2023 21:30:13 -0500 Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [IPv6:2001:41d0:203:375::ad]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68BFE1990 for ; Fri, 24 Nov 2023 18:30:19 -0800 (PST) Message-ID: <95052fad-b3ef-4d18-8488-74cf84c50d08@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1700879417; 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=u3cVUYf//AUjzXD/mOWnUMGkpU9IOaGIh0uDOAXNfu4=; b=dJeNBz2/AA6j5y2IYu8GgaDMNXpaQz4pNW83nqkQEM+HYMx2n3b6T1p8KN3yHUrncQk9+m cnnLcg43GTDDHsCvLFkRjsatUBaHfknXuMPYev/yzYvmwbscdBF24jVva3Ov9BeQxm93d1 2vpdKsZ9SEd1GEweHlHyjMxvWCb6YwA= Date: Sat, 25 Nov 2023 10:30:09 +0800 MIME-Version: 1.0 Subject: Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib To: Maxime Ripard Cc: Dmitry Baryshkov , Phong LE , Neil Armstrong , Sui Jingfeng , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Laurent Pinchart , Thomas Zimmermann References: <79301d04-c0cb-4740-8a6d-27a889b65daf@linux.dev> <121163c9-0d56-47ad-a12e-e67390fef2b4@linux.dev> <00ba2245-0e48-4b21-bcd4-29dfb728e408@linux.dev> <10c4ae94-525f-4ac1-9d59-80bb4f7d362e@linux.dev> Content-Language: en-US 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 On 2023/11/24 16:13, Maxime Ripard wrote: > On Fri, Nov 24, 2023 at 03:51:00PM +0800, Sui Jingfeng wrote: >> Hi, >> >> On 2023/11/24 15:38, Maxime Ripard wrote: >>> On Fri, Nov 24, 2023 at 01:52:26AM +0800, Sui Jingfeng wrote: >>>> On 2023/11/23 16:08, Dmitry Baryshkov wrote: >>>>>> I'm agree with the idea that drm bridges drivers involved toward to a direction >>>>>> that support more complex design, but I think we should also leave a way for the >>>>>> most frequent use case. Make it straight-forward as a canonical design. >>>>> Not having anything connector-related in the drm_bridge driver is a >>>>> canonical design. >>>> What you said is just for the more complex uses case. I can't agree, sorry. >>>> >>>> By choosing the word "canonical design", I means that the most frequently used >>>> cases in practice are the canonical design, 95+% motherboards I have seen has >>>> only one *onboard* display bridges chip. For my driver, I abstract the internal >>>> (inside of the chip) encoder as drm_encoder and abstract the external TX chip as >>>> drm_bridge, this design still works very well. >>>> >>>> >>>> Originally, I means that this is a concept of the hardware design. >>>> You are wrong even through in the software design context, the >>>> transparent simple drm bridge drivers(simple-bridge.c) also *allow* >>>> to create drm connector manually. I don't think I need to emulate >>>> more example, please read the code by youself. >> 'emulate' -> 'enumerate' >> >>> Ok. That's it. We've been patient long enough. You have been given a >>> review and a list of things to fix for your driver to be merged. >> This series is not relevant to my driver, can we please *limit* the >> discussion to this series? > Right, I conflated the two, I meant this series, or the general goal to > enable that bridge with your driver. The rest of the driver is of course > unaffected. > >>> Whether you follow them or not is your decision. >> I'm not saying that I will not follow, just to make sure what's >> solution is you want. I need discussion to figure out. > You had direct, repeated, feedback on that already by a maintainer and > one of the most experienced dev and reviewer on bridges. If you need > more guidance, you can definitely ask questions, but asking questions > and telling them they are wrong is very different. > >>> We won't tolerate insulting comments though. >> There is *no* insulting, please don't misunderstanding before >> *sufficient* communication, OK? Originally, I thought Dmitry may >> ignore(or overlook) what is the current status. > Saying to someone maintaining and/or reviewing that code for years now > that they are wrong and should go read the code is insulting. Back to that time, I'm focus on kindly technique debating, this is a kind of defensive reply for the patch. This is a kind of remind in case of ignores. Probably a bit of negative, but please don't misunderstanding as insult anyway. Dmitry, really thanks a lot for the instructs, I have learned a lot while talking with you. I will back to try mentioned method.