Received-SPF: pass (google.com: domain of linux-kernel+bounces-164744-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240321222258.1440130-1-sui.jingfeng@linux.dev>
 <caa6fb05-8080-444a-93c3-2d9283ccb74d@bosc.ac.cn> <20240429-enchanted-cooperative-jacamar-cf2902@houat>
 <6db82a3f.c7.18f2c927d9f.Coremail.suijingfeng@bosc.ac.cn>
In-Reply-To: <6db82a3f.c7.18f2c927d9f.Coremail.suijingfeng@bosc.ac.cn>
From: Doug Anderson <dianders@chromium.org>
Date: Tue, 30 Apr 2024 14:33:17 -0700
Message-ID: <CAD=FV=W2ksFLtv3o5tqrpXY4aHD_wUq7R7rT9hOHCQa8FLmeoQ@mail.gmail.com>
Subject: Re: Re: drm/debugfs: Drop conditionals around of_node pointers
To: =?UTF-8?B?6ZqL5pmv5bOw?= <suijingfeng@bosc.ac.cn>
Cc: Maxime Ripard <mripard@kernel.org>, Sui Jingfeng <sui.jingfeng@linux.dev>, 
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Thomas Zimmermann <tzimmermann@suse.de>, 
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, 
	Biju Das <biju.das.jz@bp.renesas.com>, dri-devel@lists.freedesktop.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Apr 29, 2024 at 6:16=E2=80=AFPM =E9=9A=8B=E6=99=AF=E5=B3=B0 <suijin=
gfeng@bosc.ac.cn> wrote:
>
> Hi,
>
>
> > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----
> > =E5=8F=91=E4=BB=B6=E4=BA=BA: "Maxime Ripard" <mripard@kernel.org>
> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2024-04-29 19:30:24 (=E6=98=9F=E6=
=9C=9F=E4=B8=80)
> > =E6=94=B6=E4=BB=B6=E4=BA=BA: "Sui Jingfeng" <suijingfeng@bosc.ac.cn>
> > =E6=8A=84=E9=80=81: "Sui Jingfeng" <sui.jingfeng@linux.dev>, "Maarten L=
ankhorst" <maarten.lankhorst@linux.intel.com>, "Thomas Zimmermann" <tzimmer=
mann@suse.de>, "David Airlie" <airlied@gmail.com>, "Daniel Vetter" <daniel@=
ffwll.ch>, "Douglas Anderson" <dianders@chromium.org>, "Laurent Pinchart" <=
laurent.pinchart+renesas@ideasonboard.com>, "Biju Das" <biju.das.jz@bp.rene=
sas.com>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
> > =E4=B8=BB=E9=A2=98: Re: drm/debugfs: Drop conditionals around of_node p=
ointers
> >
> > On Sun, Apr 28, 2024 at 04:52:13PM +0800, Sui Jingfeng wrote:
> > > ping
> > >
> > > =E5=9C=A8 2024/3/22 06:22, Sui Jingfeng =E5=86=99=E9=81=93:
> > > > Having conditional around the of_node pointer of the drm_bridge str=
ucture
> > > > turns out to make driver code use ugly #ifdef blocks.
> >
> > The code being ugly is an opinion, what problem is it causing exactly?
> >
> > > Drop the conditionals to simplify debugfs.
> >
> > What does it simplifies?
> >
> > > >
> > > > Fixes: d8dfccde2709 ("drm/bridge: Drop conditionals around of_node =
pointers")
> > > > Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev>
> >
> > Why do we want to backport that patch to stable?

Technically it's not CCing stable and so it's not really incorrect.
..but I agree that this is a bit of a stretch to call it a "Fix".
Maybe drop the "Fixes" line?


> My commit message is written based on commit of d8dfccde2709
>
> $ git show c9e358dfc4a8
>
>     This patch is based on commit c9e358dfc4a8 ("driver-core: remove
>     conditionals around devicetree pointers").
>
>     Having conditional around the of_node pointer of the drm_bridge
>     structure turns out to make driver code use ugly #ifdef blocks. Drop =
the
>     conditionals to simplify drivers. While this slightly increases the s=
ize
>     of struct drm_bridge on non-OF system, the number of bridges used tod=
ay
>     and foreseen tomorrow on those systems is very low, so this shouldn't=
 be
>     an issue.
>
>     So drop #if conditionals by adding struct device_node forward declara=
tion.
>
> > Maxime
>
> I'm just start to contribute by mimic other people's tone, there seems no=
 need
> to over read.

I think the fact that you skipped the reference to commit c9e358dfc4a8
("driver-core: remove conditionals around devicetree pointers") was
relevant here. Referencing that commit makes it easy for the reader to
see that you are following convention used throughout the kernel and
not just asserting your own opinion about style.

If you add that reference into your commit message and send a v2, I'm
happy to apply it.

-Doug