Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Fri, 24 Nov 2023 08:38:16 +0100
From:   Maxime Ripard <mripard@kernel.org>
To:     Sui Jingfeng <sui.jingfeng@linux.dev>
Cc:     Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
        Phong LE <ple@baylibre.com>,
        Neil Armstrong <neil.armstrong@linaro.org>,
        Sui Jingfeng <suijingfeng@loongson.cn>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
        Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Message-ID: <gghxzhkd3hnry6qloc3axzojps7bv7cf7lmpcweu6ucadhelh6@spjfikjfzt23>
References: <20231114150130.497915-1-sui.jingfeng@linux.dev>
 <20231114150130.497915-9-sui.jingfeng@linux.dev>
 <CAA8EJprQq3aDhzE+yKGZ2-nsuHWcptzMvApsyOi9D63PgeiZ3w@mail.gmail.com>
 <79301d04-c0cb-4740-8a6d-27a889b65daf@linux.dev>
 <CAA8EJpom5kAbDkacOdqp6BR7YPfmCSXaQfDYRVcLf9eGmi64CQ@mail.gmail.com>
 <121163c9-0d56-47ad-a12e-e67390fef2b4@linux.dev>
 <CAA8EJpowjhX=LL-9cnQL4pfCei63zNkCGW5wGOeeFxcnFpNCVA@mail.gmail.com>
 <00ba2245-0e48-4b21-bcd4-29dfb728e408@linux.dev>
 <CAA8EJpoiehS2wS3ri_DggzxeEfLY4yK7X6c+bCFKvkwSce6r+A@mail.gmail.com>
 <10c4ae94-525f-4ac1-9d59-80bb4f7d362e@linux.dev>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="2e3vfplf3w4vhnaj"
Content-Disposition: inline
In-Reply-To: <10c4ae94-525f-4ac1-9d59-80bb4f7d362e@linux.dev>
Precedence: bulk


--2e3vfplf3w4vhnaj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 desig=
n.
> > Not having anything connector-related in the drm_bridge driver is a
> > canonical design.
>=20
> What you said is just for the more complex uses case. I can't agree, sorr=
y.
>=20
> 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 in=
ternal
> (inside of the chip) encoder as drm_encoder and abstract the external TX =
chip as
> drm_bridge, this design still works very well.
>=20
>=20
> 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

--2e3vfplf3w4vhnaj
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZWBS6AAKCRDj7w1vZxhR
xV34AQCz710W6l+pqHVmnN65/ken9vPhvpEMfiUkcQIzarcRvgD+LacFo0COf1Ot
dcbPr76F+Hw8q8Q95b7aIhVgJyZydQQ=
=nZjB
-----END PGP SIGNATURE-----

--2e3vfplf3w4vhnaj--