From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B0F820B7F2; Tue, 3 Dec 2024 15:34:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.44.175.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733240099; cv=none; b=LtsNsGvhJHeu81DybNV1Tnad3qIu185S17gjtYYMfeIrQgzLqokNR79DHho68oaMlUZb+lWlwVDODEDmeZQaPwV2CYF2wnfaUadLjEyHfsKQ5H3Jvd5/2zqZXM/yjgQL6zuVBNE6C5qTr8tmjuqNDsY/jYvS3CR50e9S54tAQJ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733240099; c=relaxed/simple; bh=L/QXZvHG42gthQ6VgZcE1FVgbBCT68wm3yek2sYu4mw=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=cmgqloiInue402+/BJHVxQP5t0EI7sL5NRa4fqage/DVyh26AaN6TKl97ZPjT0dlmrn+HEGkp2zFri/+e8Yo5AWz3H/ZvbDnt//uVq19D38t8ZdlC28HxIWRWzuVt2dtSjEABCNQBZOftMpJ3zXsa2H+pxD8rxU6B+G6ok+KLwY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=HansenPartnership.com; spf=pass smtp.mailfrom=HansenPartnership.com; dkim=pass (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b=eZ4U4tRU; dkim=pass (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b=eZ4U4tRU; arc=none smtp.client-ip=96.44.175.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=HansenPartnership.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=HansenPartnership.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="eZ4U4tRU"; dkim=pass (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="eZ4U4tRU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1733240096; bh=L/QXZvHG42gthQ6VgZcE1FVgbBCT68wm3yek2sYu4mw=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=eZ4U4tRU1qIWP3lhCG1NFGqdlkJwbCoeHoXmlbwbm0xojoL7yxF2OmBDrwRg5sJZD yUR1Ufh9cMTmWMSk/QfvKgX3lU1FOQtEkMYCzG5HJRGBhs9c6tkPAgFURJTLia4EJE fFgUsJsyCn7Ieybkh2Zt2C6KjPseMR4k9lZkDFPA= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id A95511286A94; Tue, 03 Dec 2024 10:34:56 -0500 (EST) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavis, port 10024) with ESMTP id Nouo1dbPKzw4; Tue, 3 Dec 2024 10:34:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1733240096; bh=L/QXZvHG42gthQ6VgZcE1FVgbBCT68wm3yek2sYu4mw=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=eZ4U4tRU1qIWP3lhCG1NFGqdlkJwbCoeHoXmlbwbm0xojoL7yxF2OmBDrwRg5sJZD yUR1Ufh9cMTmWMSk/QfvKgX3lU1FOQtEkMYCzG5HJRGBhs9c6tkPAgFURJTLia4EJE fFgUsJsyCn7Ieybkh2Zt2C6KjPseMR4k9lZkDFPA= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4302:c21::a774]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id F32C01286A7D; Tue, 03 Dec 2024 10:34:50 -0500 (EST) Message-ID: <108c63c753f2f637a72c2e105ac138f80d4b0859.camel@HansenPartnership.com> Subject: Re: [PATCH v2 00/32] driver core: Constify API device_find_child() and adapt for various existing usages From: James Bottomley To: Zijun Hu , Thomas =?ISO-8859-1?Q?Wei=DFschuh?= Cc: Greg Kroah-Hartman , Uwe =?ISO-8859-1?Q?Kleine-K=F6nig?= , "Rafael J. Wysocki" , Chun-Kuang Hu , Philipp Zabel , David Airlie , Simona Vetter , Matthias Brugger , AngeloGioacchino Del Regno , Jean Delvare , Guenter Roeck , Martin Tuma , Mauro Carvalho Chehab , Andreas Noever , Michael Jamet , Mika Westerberg , Yehezkel Bernat , Linus Walleij , Bartosz Golaszewski , Andrew Lunn , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Dan Williams , Vishal Verma , Dave Jiang , Ira Weiny , Takashi Sakamoto , Jiri Slaby , Heikki Krogerus , Srinivas Kandagatla , Lee Duncan , Chris Leech , Mike Christie , "Martin K. Petersen" , Nilesh Javali , Manish Rangankar , GR-QLogic-Storage-Upstream@marvell.com, Davidlohr Bueso , Jonathan Cameron , Alison Schofield , Andreas Larsson , Stuart Yoder , Laurentiu Tudor , Jens Axboe , Sudeep Holla , Cristian Marussi , Ard Biesheuvel , Bjorn Andersson , Mathieu Poirier , 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 Date: Tue, 03 Dec 2024 10:34:49 -0500 In-Reply-To: References: <20241203-const_dfc_done-v2-0-7436a98c497f@quicinc.com> <9d34bd6f-b120-428a-837b-5a5813e14618@icloud.com> <2024120320-manual-jockey-dfd1@gregkh> <8eb7c0c54b280b8eb72f82032ede802c001ab087.camel@HansenPartnership.com> <8fb887a0-3634-4e07-9f0d-d8d7c72ca802@t-8ch.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 Precedence: bulk X-Mailing-List: linux-pwm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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