linux.git/drivers/base/devres.c, branch v6.1.168

drivers: base: devres: Allow to release group on device release

2025-04-25T08:43:32+00:00

[ Upstream commit 8e1ddfada4530939a8cb64ee9251aef780474274 ]

When releasing a device, if the release action causes a group to be
released, a warning is emitted because it can't find the group. This
happens because devres_release_all() moves the entire list to a todo
list and also move the group markers. Considering r* normal resource
nodes and g1 a group resource node:

		    g1 -----------.
		    v		  v
	r1 -> r2 -> g1[0] -> r3-> g[1] -> r4

After devres_release_all(), dev->devres_head becomes empty and the todo
list it iterates on becomes:

			       g1
			       v
	r1 -> r2 -> r3-> r4 -> g1[0]

When a call to component_del() is made and takes down the aggregate
device, a warning like this happen:

	RIP: 0010:devres_release_group+0x362/0x530
	...
	Call Trace:
	 
	 component_unbind+0x156/0x380
	 component_unbind_all+0x1d0/0x270
	 mei_component_master_unbind+0x28/0x80 [mei_hdcp]
	 take_down_aggregate_device+0xc1/0x160
	 component_del+0x1c6/0x3e0
	 intel_hdcp_component_fini+0xf1/0x170 [xe]
	 xe_display_fini+0x1e/0x40 [xe]

Because the devres group corresponding to the hdcp component cannot be
found. Just ignore this corner case: if the dev->devres_head is empty
and the caller is trying to remove a group, it's likely in the process
of device cleanup so just ignore it instead of warning.

Acked-by: Greg Kroah-Hartman 
Reviewed-by: Rodrigo Vivi 
Link: https://patchwork.freedesktop.org/patch/msgid/20250222001051.3012936-2-lucas.demarchi@intel.com
Signed-off-by: Lucas De Marchi 
Signed-off-by: Sasha Levin

devres: Initialize an uninitialized struct member

2024-09-12T09:10:23+00:00

[ Upstream commit 56a20ad349b5c51909cf8810f7c79b288864ad33 ]

Initialize an uninitialized struct member for driver API
devres_open_group().

Signed-off-by: Zijun Hu 
Link: https://lore.kernel.org/r/1719931914-19035-4-git-send-email-quic_zijuhu@quicinc.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

devres: Fix memory leakage caused by driver API devm_free_percpu()

2024-08-03T06:49:39+00:00

commit bd50a974097bb82d52a458bd3ee39fb723129a0c upstream.

It will cause memory leakage when use driver API devm_free_percpu()
to free memory allocated by devm_alloc_percpu(), fixed by using
devres_release() instead of devres_destroy() within devm_free_percpu().

Fixes: ff86aae3b411 ("devres: add devm_alloc_percpu()")
Cc: stable@vger.kernel.org
Signed-off-by: Zijun Hu 
Link: https://lore.kernel.org/r/1719931914-19035-3-git-send-email-quic_zijuhu@quicinc.com
Signed-off-by: Greg Kroah-Hartman

devres: Fix devm_krealloc() wasting memory

2024-08-03T06:49:39+00:00

commit c884e3249f753dcef7a2b2023541ac1dc46b318e upstream.

Driver API devm_krealloc() calls alloc_dr() with wrong argument
@total_new_size, so causes more memory to be allocated than required
fix this memory waste by using @new_size as the argument for alloc_dr().

Fixes: f82485722e5d ("devres: provide devm_krealloc()")
Cc: stable@vger.kernel.org
Signed-off-by: Zijun Hu 
Link: https://lore.kernel.org/r/1719931914-19035-2-git-send-email-quic_zijuhu@quicinc.com
Signed-off-by: Greg Kroah-Hartman

devres: Slightly optimize alloc_dr()

2022-09-01T16:17:14+00:00

If the gfp flag used for the memory allocation already has __GFP_ZERO,
then there is no need to explicitly clear the "struct devres_node". It is
already zeroed.

This saves a few cycles when using devm_zalloc() and co.

In the case of devres_alloc() (which calls __devres_alloc_node()), the
compiler could remove the test and the memset() because it should be able
to see that the __GFP_ZERO flag is set.
So this would make the code both faster and smaller.

Signed-off-by: Christophe JAILLET 
Link: https://lore.kernel.org/r/d255bd871484e63cdd628e819f929e2df59afb02.1658352383.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman

devres: fix typos in comments

2022-03-18T13:30:12+00:00

Various spelling mistakes in comments.
Detected with the help of Coccinelle.

Signed-off-by: Julia Lawall 

Link: https://lore.kernel.org/r/20220314115354.144023-19-Julia.Lawall@inria.fr
Signed-off-by: Greg Kroah-Hartman

devres: Enable trace events

2021-06-15T15:14:36+00:00

In some cases the printf() mechanism is too heavy and can't be used.
For example, when debugging a race condition involving devres API.
When CONFIG_DEBUG_DEVRES is enabled I can't reproduce an issue, and
otherwise it's quite visible with a useful information being collected.

Enable trace events for devres part of the driver core.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210517122946.53161-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

devres: No need to call remove_nodes() when there none present

2021-06-15T15:14:36+00:00

If a list of devres nodes is empty, no need to call remove_nodes().

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210517122946.53161-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

devres: Use list_for_each_safe_from() in remove_nodes()

2021-06-15T15:14:36+00:00

The remove_nodes() open codes the list_for_each_safe_from().
Replace it by a generic macro.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210517122946.53161-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

devres: Make locking straight forward in release_nodes()

2021-06-15T15:14:36+00:00

It seems for the sake of saving stack memory of couple of pointers,
the locking in release_nodes() callers becomes interesting.

Replace this logic with a straight forward locking and unlocking scheme.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210517122946.53161-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman