linux-kernel - Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

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

Message-ID: <gghxzhkd3hnry6qloc3axzojps7bv7cf7lmpcweu6ucadhelh6@spjfikjfzt23>
Date:   Fri, 24 Nov 2023 08:38:16 +0100
From:   Maxime Ripard <mripard@...nel.org>
To:     Sui Jingfeng <sui.jingfeng@...ux.dev>
Cc:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Phong LE <ple@...libre.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Sui Jingfeng <suijingfeng@...ngson.cn>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Thomas Zimmermann <tzimmermann@...e.de>
Subject: Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

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.

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. Whether
you follow them or not is your decision.

We won't tolerate insulting comments though.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)