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 787EAC54FB9 for ; Fri, 17 Nov 2023 17:36:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346156AbjKQRgO (ORCPT ); Fri, 17 Nov 2023 12:36:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231430AbjKQRgN (ORCPT ); Fri, 17 Nov 2023 12:36:13 -0500 Received: from out-176.mta0.migadu.com (out-176.mta0.migadu.com [IPv6:2001:41d0:1004:224b::b0]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07FCC90 for ; Fri, 17 Nov 2023 09:36:07 -0800 (PST) Message-ID: <954e2f85-7ed8-4768-97c4-970315afeec1@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1700242565; 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=9vWjfYPNGTMvPQmWqPhQYpJv3Ri6BeWVhxBfWZZgUXg=; b=baZIDETogy3HPFLmzPPEvP+7Z7rf3XKfKcDs8ueMQdbzIbxthuwI2sJATP245CyZiV9grr 3NuEfR/r0nJvTnzPQkPme2O5OUYg/it4JBQlUs/64v8uXtGk5dHZqYyD1pMJ3F/5WCdOC5 tCnAItfZhFH62ftjaGzE8P9WpdfO+4E= Date: Sat, 18 Nov 2023 01:35:56 +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> <1b59d647-c345-4260-b07b-22abb70ae17a@linux.dev> <7b85d057-3d66-435a-a657-dd69067b6bef@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/17 17:03, Dmitry Baryshkov wrote: > On Fri, 17 Nov 2023 at 06:24, Sui Jingfeng wrote: >> Hi, >> >> On 2023/11/16 23:23, Dmitry Baryshkov wrote: >>>>>> Then you will need some way (fwnode?) to >>>>>> discover the bridge chain. And at the last point you will get into the >>>>>> device data and/or properties business. >>>>>> >>>>> No, leave that chance to a more better programmer and forgive me please, >>>>> too difficult, I'm afraid of not able to solve. Thanks a lot for the >>>>> trust! >>> From my point of view: no. >> >> I respect the fact that the community prefer generic mechanisms. >> If our approach is not what the community want, can I switch back >> to my previous solution? I can reduce the duplication of our >> localized it66121 driver to a minimal, rewrite it until it meets >> the community's requirement. I know our device looks weird and >> our approach is not elegant. But at the very least, we could not >> mess the community's design up by localize. Otherwise, I don't know >> what is the better approach to solve such a problem. >> >> Can I switch back or any other ideas? > I keep on repeating: create the i2c device from your root device > driver, which parses BIOS data. You didn't focus on solve the problem, You are focus on solving me. How does the method that parsing BIOS data can be generic and applied universally?