From: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
To: Luca Ceresoli <luca.ceresoli@bootlin.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Lyude Paul <lyude@redhat.com>,
Danilo Krummrich <dakr@kernel.org>,
Marcus Folkesson <marcus.folkesson@gmail.com>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>,
Jagan Teki <jagan@amarulasolutions.com>,
Liu Ying <victor.liu@nxp.com>,
Adrien Grassein <adrien.grassein@gmail.com>,
Peter Senna Tschudin <peter.senna@gmail.com>,
Martyn Welch <martyn.welch@collabora.co.uk>,
Russell King <linux@armlinux.org.uk>,
Douglas Anderson <dianders@chromium.org>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Biju Das <biju.das.jz@bp.renesas.com>,
Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>,
Manikandan Muralidharan <manikandan.m@microchip.com>,
Andy Yan <andy.yan@rock-chips.com>,
Xin Ji <xji@analogixsemi.com>,
Loic Poulain <loic.poulain@oss.qualcomm.com>,
Fei Shao <fshao@chromium.org>, Arnd Bergmann <arnd@arndb.de>,
Kees Cook <kees@kernel.org>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
nouveau@lists.freedesktop.org
Subject: Re: [PATCH] drm: Use named initializers for arrays of i2c_device_data
Date: Mon, 22 Jun 2026 18:15:41 +0200 [thread overview]
Message-ID: <ajlfiTxD8TwCu_1l@monoceros> (raw)
In-Reply-To: <DJFNU4L6YNVS.2OXF28HEUNZO3@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]
Hello Luca,
On Mon, Jun 22, 2026 at 04:50:06PM +0200, Luca Ceresoli wrote:
> On Wed Jun 10, 2026 at 7:15 PM CEST, Uwe Kleine-König (The Capable Hub) wrote:
> > On Mon, May 18, 2026 at 12:04:01PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> >> While being less compact, using named initializers allows to more easily
> >> see which members of the structs are assigned which value without having
> >> to lookup the declaration of the struct. And it's also more robust
> >> against changes to the struct definition.
> >>
> >> The mentioned robustness is relevant for a planned change to struct
> >> i2c_device_id that replaces .driver_data by an anonymous union.
> >>
> >> While touching all these arrays, unify usage of whitespace in the list
> >> terminator and drop trailing commas there.
> >>
> >> This patch doesn't modify the compiled arrays, only their representation
> >> in source form benefits. The former was confirmed with x86 and arm64
> >> builds.
> >>
> >> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> >
> > who feels responsible to pick up this patch?
>
> The affected files are mostly in drm-misc so I could apply it, but I think
> we'd need an ack from files belonging lsewhere (should be just nouveau and
> sitronix at quick glance).
>
> >> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> >> prerequisite-patch-id: 7779c63f16ef6f7247cdb71c89e66b27e299eb74
> >> prerequisite-patch-id: 6f920b6f8c31dc0ad1689200c37680755c20ce8b
> ...
> >> prerequisite-patch-id: 915b7a2276c5a38944107c84bb282271d0bf28f4
> >> prerequisite-patch-id: 76d499a624150588f7ef07dc087e70eca6f33419
> >
> > FTR: These are bogous, there are no dependencies, I just wasn't
> > attentive enough to drop these lines.
>
> And 'b4 shazam' messes up because of these lines.
>
> Overall I think it's better if you resend after splitting by tree, and
> removing the prerequisite-patch-id lines. You can keep my R-by on all the
> patches if you just split them without further changes.
Thanks for considering to merge, will rework as suggested.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-06-22 16:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 10:04 [PATCH] drm: Use named initializers for arrays of i2c_device_data Uwe Kleine-König (The Capable Hub)
2026-05-18 10:09 ` Laurent Pinchart
2026-05-18 10:12 ` Danilo Krummrich
2026-05-18 16:57 ` Luca Ceresoli
2026-06-10 17:15 ` Uwe Kleine-König (The Capable Hub)
2026-06-22 14:50 ` Luca Ceresoli
2026-06-22 16:15 ` Uwe Kleine-König (The Capable Hub) [this message]
2026-06-11 2:15 ` Liu Ying
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ajlfiTxD8TwCu_1l@monoceros \
--to=u.kleine-koenig@baylibre.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=adrien.grassein@gmail.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=andy.yan@rock-chips.com \
--cc=arnd@arndb.de \
--cc=biju.das.jz@bp.renesas.com \
--cc=dakr@kernel.org \
--cc=dianders@chromium.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fshao@chromium.org \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@gmail.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=loic.poulain@oss.qualcomm.com \
--cc=luca.ceresoli@bootlin.com \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=manikandan.m@microchip.com \
--cc=marcus.folkesson@gmail.com \
--cc=martyn.welch@collabora.co.uk \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=nouveau@lists.freedesktop.org \
--cc=peter.senna@gmail.com \
--cc=rfoss@kernel.org \
--cc=simona@ffwll.ch \
--cc=tommaso.merciai.xr@bp.renesas.com \
--cc=tzimmermann@suse.de \
--cc=victor.liu@nxp.com \
--cc=xji@analogixsemi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox