Thread (24 messages) 24 messages, 6 authors, 2024-12-05

Re: [PATCH v2 00/32] driver core: Constify API device_find_child() and adapt for various existing usages

From: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: 2024-12-03 13:58:42
Also in: arm-scmi, dri-devel, linux-block, linux-cxl, linux-efi, linux-gpio, linux-hwmon, linux-media, linux-mediatek, linux-pwm, linux-remoteproc, linux-scsi, linux-serial, linux-sound, linux-usb, lkml, nvdimm, sparclinux

On Tue, 2024-12-03 at 21:02 +0800, Zijun Hu wrote:
On 2024/12/3 20:41, Greg Kroah-Hartman wrote:
quoted
On Tue, Dec 03, 2024 at 08:23:45PM +0800, Zijun Hu wrote:
[...]
quoted
quoted
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.

James
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help