From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Zijun Hu" <zijun_hu@icloud.com>, "Thomas Weißschuh" <thomas@t-8ch.de>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Chun-Kuang Hu" <chunkuang.hu@kernel.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Jean Delvare" <jdelvare@suse.com>,
"Guenter Roeck" <linux@roeck-us.net>,
"Martin Tuma" <martin.tuma@digiteqautomotive.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Andreas Noever" <andreas.noever@gmail.com>,
"Michael Jamet" <michael.jamet@intel.com>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Yehezkel Bernat" <YehezkelShB@gmail.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Bartosz Golaszewski" <brgl@bgdev.pl>,
"Andrew Lunn" <andrew@lunn.ch>,
"Vladimir Oltean" <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Dan Williams" <dan.j.williams@intel.com>,
"Vishal Verma" <vishal.l.verma@intel.com>,
"Dave Jiang" <dave.jiang@intel.com>,
"Ira Weiny" <ira.weiny@intel.com>,
"Takashi Sakamoto" <o-takashi@sakamocchi.jp>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
"Lee Duncan" <lduncan@suse.com>,
"Chris Leech" <cleech@redhat.com>,
"Mike Christie" <michael.christie@oracle.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"Nilesh Javali" <njavali@marvell.com>,
"Manish Rangankar" <mrangankar@marvell.com>,
GR-QLogic-Storage-Upstream@marvell.com,
"Davidlohr Bueso" <dave@stgolabs.net>,
"Jonathan Cameron" <jonathan.cameron@huawei.com>,
"Alison Schofield" <alison.schofield@intel.com>,
"Andreas Larsson" <andreas@gaisler.com>,
"Stuart Yoder" <stuyoder@gmail.com>,
"Laurentiu Tudor" <laurentiu.tudor@nxp.com>,
"Jens Axboe" <axboe@kernel.dk>,
"Sudeep Holla" <sudeep.holla@arm.com>,
"Cristian Marussi" <cristian.marussi@arm.com>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Bjorn Andersson" <andersson@kernel.org>,
"Mathieu Poirier" <mathieu.poirier@linaro.org>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hwmon@vger.kernel.org, linux-media@vger.kernel.org,
linux-usb@vger.kernel.org, linux-gpio@vger.kernel.org,
netdev@vger.kernel.org, linux-pwm@vger.kernel.org,
nvdimm@lists.linux.dev, linux1394-devel@lists.sourceforge.net,
linux-serial@vger.kernel.org, linux-sound@vger.kernel.org,
open-iscsi@googlegroups.com, linux-scsi@vger.kernel.org,
linux-cxl@vger.kernel.org, sparclinux@vger.kernel.org,
linux-block@vger.kernel.org, arm-scmi@vger.kernel.org,
linux-efi@vger.kernel.org, linux-remoteproc@vger.kernel.org,
"Zijun Hu" <quic_zijuhu@quicinc.com>
Subject: Re: [PATCH v2 00/32] driver core: Constify API device_find_child() and adapt for various existing usages
Date: Tue, 03 Dec 2024 10:34:49 -0500 [thread overview]
Message-ID: <108c63c753f2f637a72c2e105ac138f80d4b0859.camel@HansenPartnership.com> (raw)
In-Reply-To: <f5ea7e17-5550-4658-8f4c-1c51827c7627@icloud.com>
On Tue, 2024-12-03 at 22:56 +0800, Zijun Hu wrote:
> On 2024/12/3 22:07, Thomas Weißschuh wrote:
> > On 2024-12-03 08:58:26-0500, James Bottomley wrote:
> > > On Tue, 2024-12-03 at 21:02 +0800, Zijun Hu wrote:
> > > > On 2024/12/3 20:41, Greg Kroah-Hartman wrote:
> > > > > On Tue, Dec 03, 2024 at 08:23:45PM +0800, Zijun Hu wrote:
> > > [...]
> > > > > > or squash such patch series into a single patch ?
> > > > > >
> > > > > > various subsystem maintainers may not like squashing way.
> > > > >
> > > > > Agreed, so look into either doing it in a bisectable way if
> > > > > at all possible. As I don't see a full series here, I can't
> > > > > suggest how it needs to happen :(
> > > > >
> > > >
> > > > let me send you a full series later and discuss how to solve
> > > > this issue.
> > >
> > > It's only slightly more complex than what we normally do: modify
> > > all instances and then change the API. In this case you have an
> > > additional problem because the prototype "const void *" will
> > > cause a mismatch if a function has "void *". The easiest way to
> > > solve this is probably to make device_find_child a macro that
> > > coerces its function argument to having a non const "void *" and
> > > then passes off to the real function. If you do that in the
> > > first patch, then you can constify all the consumers and finally
> > > remove the macro coercion in the last patch.
> >
> > Casting function pointers like that should be detected and trapped
> > by control flow integrity checking (KCFI).
> >
> > Another possibility would be to use a macro and _Generic to
> > dispatch to two different backing functions. See __BIN_ATTR() in
> > include/linux/sysfs.h for an inspiration.
That's way over complicated for this conversion: done properly there
should be no need for _Generic() compile time type matching at all.
> this way may fix building error issue but does not achieve our
> purpose. our purpose is that there are only constified
> device_find_child().
>
>
> > This also enables an incremental migration.
>
> change the API prototype from:
> device_find_child(..., void *data_0, int (*match)(struct device *dev,
> void *data));
>
> to:
> device_find_child(..., const void *data_0, int (*match)(struct device
> *dev, const void *data));
>
> For @data_0, void * -> const void * is okay.
> but for @match, the problem is function pointer type incompatibility.
>
> there are two solutions base on discussions.
>
> 1) squashing likewise Greg mentioned.
> Do all of the "prep work" first, and then
> do the const change at the very end, all at once.
>
> 2) as changing platform_driver's remove() prototype.
> Commit: e70140ba0d2b ("Get rid of 'remove_new' relic from platform
> driver struct")
>
> introduce extra device_find_child_new() which is constified -> use
> *_new() replace ALL device_find_child() instances one by one ->
> remove device_find_child() -> rename *_new() to device_find_child()
> once.
Why bother with the last step, which churns the entire code base again?
Why not call the new function device_find_child_const() and simply keep
it (it's descriptive of its function). That way you can have a patch
series without merging and at the end simply remove the old function.
Regards,
James
next prev parent reply other threads:[~2024-12-03 15:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 0:33 [PATCH v2 00/32] driver core: Constify API device_find_child() and adapt for various existing usages Zijun Hu
2024-12-03 0:33 ` [PATCH v2 01/32] driver core: Constify API device_find_child() Zijun Hu
2024-12-03 0:33 ` [PATCH v2 02/32] driver core: Introduce device_match_type() to match device with a device type Zijun Hu
2024-12-03 0:33 ` [PATCH v2 03/32] drm/mediatek: Adapt for constified device_find_child() Zijun Hu
2024-12-03 0:33 ` [PATCH v2 04/32] hwmon: " Zijun Hu
2024-12-03 0:33 ` [PATCH v2 05/32] media: pci: mgb4: " Zijun Hu
2024-12-03 0:33 ` [PATCH v2 06/32] thunderbolt: " Zijun Hu
2024-12-03 0:33 ` [PATCH v2 07/32] gpio: sim: Remove gpio_sim_dev_match_fwnode() Zijun Hu
2024-12-03 0:33 ` [PATCH v2 08/32] net: dsa: Adapt for constified device_find_child() Zijun Hu
2024-12-03 0:33 ` [PATCH v2 09/32] pwm: " Zijun Hu
2024-12-03 0:33 ` [PATCH v2 10/32] nvdimm: " Zijun Hu
2024-12-03 0:33 ` [PATCH v2 11/32] libnvdimm: Simplify nd_namespace_store() implementation Zijun Hu
2024-12-03 2:29 ` [PATCH v2 00/32] driver core: Constify API device_find_child() and adapt for various existing usages quic_zijuhu
2024-12-03 12:00 ` Uwe Kleine-König
2024-12-03 12:23 ` Zijun Hu
2024-12-03 12:41 ` Greg Kroah-Hartman
2024-12-03 13:02 ` Zijun Hu
2024-12-03 13:58 ` James Bottomley
2024-12-03 14:07 ` Thomas Weißschuh
2024-12-03 14:56 ` Zijun Hu
2024-12-03 15:34 ` James Bottomley [this message]
2024-12-04 12:26 ` Zijun Hu
2024-12-04 16:42 ` James Bottomley
2024-12-05 0:07 ` Zijun Hu
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=108c63c753f2f637a72c2e105ac138f80d4b0859.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=GR-QLogic-Storage-Upstream@marvell.com \
--cc=YehezkelShB@gmail.com \
--cc=airlied@gmail.com \
--cc=alison.schofield@intel.com \
--cc=andersson@kernel.org \
--cc=andreas.noever@gmail.com \
--cc=andreas@gaisler.com \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=ardb@kernel.org \
--cc=arm-scmi@vger.kernel.org \
--cc=axboe@kernel.dk \
--cc=brgl@bgdev.pl \
--cc=chunkuang.hu@kernel.org \
--cc=cleech@redhat.com \
--cc=cristian.marussi@arm.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=davem@davemloft.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=horms@kernel.org \
--cc=ira.weiny@intel.com \
--cc=jdelvare@suse.com \
--cc=jirislaby@kernel.org \
--cc=jonathan.cameron@huawei.com \
--cc=kuba@kernel.org \
--cc=laurentiu.tudor@nxp.com \
--cc=lduncan@suse.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=linux@roeck-us.net \
--cc=martin.petersen@oracle.com \
--cc=martin.tuma@digiteqautomotive.com \
--cc=mathieu.poirier@linaro.org \
--cc=matthias.bgg@gmail.com \
--cc=mchehab@kernel.org \
--cc=michael.christie@oracle.com \
--cc=michael.jamet@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=mrangankar@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=njavali@marvell.com \
--cc=nvdimm@lists.linux.dev \
--cc=o-takashi@sakamocchi.jp \
--cc=olteanv@gmail.com \
--cc=open-iscsi@googlegroups.com \
--cc=p.zabel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=quic_zijuhu@quicinc.com \
--cc=rafael@kernel.org \
--cc=simona@ffwll.ch \
--cc=sparclinux@vger.kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=stuyoder@gmail.com \
--cc=sudeep.holla@arm.com \
--cc=thomas@t-8ch.de \
--cc=ukleinek@kernel.org \
--cc=vishal.l.verma@intel.com \
--cc=zijun_hu@icloud.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).