linux-stable.git/drivers/base/swnode.c, branch linux-5.6.y

Revert "software node: Simplify software_node_release() function"

2020-03-04T21:31:44+00:00

This reverts commit 3df85a1ae51f6b256982fe9d17c2dc5bfb4cc402.

The reverted commit says "It's possible to release the node ID
immediately when fwnode_remove_software_node() is called, no need to
wait for software_node_release() with that." However, releasing the node
ID before waiting for software_node_release() to be called causes the
node ID to be released before the kobject and the underlying sysfs
entry; this means there is a period of time where a sysfs entry exists
that is associated with an unallocated node ID.

Once consequence of this is that there is a race condition where it is
possible to call fwnode_create_software_node() with no parent node
specified (NULL) and have it fail with -EEXIST because the node ID that
was assigned is still associated with a stale sysfs entry that hasn't
been cleaned up yet.

Although it is difficult to reproduce this race condition under normal
conditions, it can be deterministically reproduced with the following
minconfig on UML:

CONFIG_KUNIT_DRIVER_PE_TEST=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_TIMERS=y
CONFIG_DEBUG_KOBJECT_RELEASE=y
CONFIG_KUNIT=y

Running the tests with this configuration causes the following failure:


kobject: 'node0' ((____ptrval____)): kobject_release, parent (____ptrval____) (delayed 400)
	ok 1 - pe_test_uints
sysfs: cannot create duplicate filename '/kernel/software_nodes/node0'
CPU: 0 PID: 28 Comm: kunit_try_catch Not tainted 5.6.0-rc3-next-20200227 #14

kobject_add_internal failed for node0 with -EEXIST, don't try to register things with the same name in the same directory.
kobject: 'node0' ((____ptrval____)): kobject_release, parent (____ptrval____) (delayed 100)
	# pe_test_uint_arrays: ASSERTION FAILED at drivers/base/test/property-entry-test.c:123
	Expected node is not error, but is: -17
	not ok 2 - pe_test_uint_arrays


Reported-by: Heidi Fahim 
Signed-off-by: Brendan Higgins 
Reviewed-by: Heikki Krogerus 
Cc: 5.3+  # 5.3+
Signed-off-by: Rafael J. Wysocki

software node: remove separate handling of references

2019-12-03T10:46:20+00:00

Now that all users of references have moved to reference properties,
we can remove separate handling of references.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Rafael J. Wysocki

software node: implement reference properties

2019-12-03T10:46:20+00:00

It is possible to store references to software nodes in the same fashion as
other static properties, so that users do not need to define separate
structures:

static const struct software_node gpio_bank_b_node = {
	.name = "B",
};

static const struct property_entry simone_key_enter_props[] = {
	PROPERTY_ENTRY_U32("linux,code", KEY_ENTER),
	PROPERTY_ENTRY_STRING("label", "enter"),
	PROPERTY_ENTRY_REF("gpios", &gpio_bank_b_node, 123, GPIO_ACTIVE_LOW),
	{ }
};

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Rafael J. Wysocki

software node: allow embedding of small arrays into property_entry

2019-12-03T10:46:19+00:00

We should not conflate whether a property data is an array or a single
value with where it is stored (embedded into property_entry structure or
out-of-line). All single-value properties are in effect 1-element
arrays, and we can figure the amount of data stored in a property by
examining its length and the data type. And arrays can be as easily
stored in property entry instances as single values are, provided that
we have enough space (we have up to 8 bytes). We can embed:

 - up to 8 bytes from U8 arrays
 - up to 4 words
 - up to 2 double words
 - one U64 value
 - one (on 64 bit architectures) or 2 (on 32 bit) strings.

This change also has an effect of switching properties with small amount
of data to embed it instead of keeping it separate when copying such
properties.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Rafael J. Wysocki

software node: replace is_array with is_inline

2019-12-03T10:46:19+00:00

We do not need a special flag to know if we are dealing with an
array, as we can get that data from ratio between element length and
the data size, but we do need a flag to know whether or not the data
is stored directly inside property_entry.

Signed-off-by: Dmitry Torokhov 
[ rjw: Subject & changelog, struct property_entry kerneldoc ]
Signed-off-by: Rafael J. Wysocki

software node: simplify property_entry_read_string_array()

2019-11-05T22:18:10+00:00

There is no need to treat string arrays and single strings separately, we can go
exclusively by the element length in relation to data type size.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Rafael J. Wysocki

software node: remove property_entry_read_uNN_array functions

2019-11-05T22:18:10+00:00

There is absolutely no reason to have them as we can handle it all nicely in
property_entry_read_int_array().

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Rafael J. Wysocki

software node: get rid of property_set_pointer()

2019-11-05T22:18:10+00:00

Instead of explicitly setting values of integer types when copying
property entries lets just copy entire value union when processing
non-array values.

For value arrays we no longer use union of pointers, but rather a single
void pointer, which allows us to remove property_set_pointer().

In property_get_pointer() we do not need to handle each data type
separately, we can simply return either the pointer or pointer to values
union.

We are not losing anything from removing typed pointer union because the
upper layers do their accesses through void pointers anyway, and we
trust the "type" of the property when interpret the data. We rely on
users of property entries on using PROPERTY_ENTRY_XXX() macros to
properly initialize entries instead of poking in the instances directly.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Rafael J. Wysocki

software node: clean up property_copy_string_array()

2019-11-05T22:18:10+00:00

Because property_copy_string_array() stores the newly allocated pointer in the
destination property, we have an awkward code in property_entry_copy_data()
where we fetch the new pointer from dst.

Let's change property_copy_string_array() to return pointer and rely on the
common path in property_entry_copy_data() to store it in destination structure.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Rafael J. Wysocki

device property: Add a function to obtain a node's prefix

2019-10-11T09:26:55+00:00

The prefix is used for printing purpose before a node, and it also works
as a separator between two nodes.

Signed-off-by: Sakari Ailus 
Acked-by: Rob Herring  (for OF)
Reviewed-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki