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: <tkaucp235w3nlydj7ae66g5r75w2rtjhum65cjrahmgeae7zgz@zb77pw2ih6vs>
Date:   Fri, 24 Nov 2023 09:13:35 +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 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.

Maxime

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