lwn.git/drivers/mfd/mfd-core.c, branch v5.14-rc1

mfd: Remove software node conditionally and locate at right place

2021-06-02T09:50:00+00:00

Currently the software node is removed in error case and at ->remove() stage unconditionally, that ruins the symmetry. Besides, in some cases, when mfd_add_device() fails, the device_remove_software_node() call may lead to NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 00000000 ... EIP: strlen+0x12/0x20 ... kernfs_name_hash+0x13/0x70 kernfs_find_ns+0x32/0xc0 kernfs_remove_by_name_ns+0x2a/0x90 sysfs_remove_link+0x16/0x30 software_node_notify.cold+0x34/0x6b device_remove_software_node+0x5a/0x90 mfd_add_device.cold+0x30a/0x427 Fix all these by guarding device_remove_software_node() with a conditional and locating it at the right place. Fixes: 42e59982917a ("mfd: core: Add support for software nodes") Signed-off-by: Andy Shevchenko Signed-off-by: Lee Jones

mfd: core: Use acpi_find_child_device() for child devices lookup

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

Use acpi_find_child_device() for child devices lookup in mfd_acpi_add_device() instead of open coded approach. No functional change intended. While at it, amend a note comment, since usage of _ADR is found on other platforms and tables than Intel Galileo Gen 2, in particular USB wired devices are using it, according to Microsoft specifications for embedded platforms. Signed-off-by: Andy Shevchenko Signed-off-by: Lee Jones

mfd: core: Remove support for dangling device properties

2021-04-14T15:06:14+00:00

From now on only accepting complete software nodes. Signed-off-by: Heikki Krogerus Signed-off-by: Andy Shevchenko Signed-off-by: Lee Jones

mfd: core: Add support for software nodes

2021-04-14T15:06:07+00:00

The old device property API is going to be removed and replaced with the newer software node API. This prepares MFD subsystem for the transition. Signed-off-by: Heikki Krogerus Signed-off-by: Andy Shevchenko Signed-off-by: Lee Jones

mfd: mfd-core: Ensure disabled devices are ignored without error

2020-08-28T08:51:41+00:00

Commit e49aa9a9bd22 ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") changed the semantics for disabled devices in mfd_add_device(). Instead of silently ignoring a disabled child device, an error was returned. On receipt of the error mfd_add_devices() the precedes to remove *all* child devices and returns an all-failed error to the caller, which will inevitably fail the parent device as well. This patch reverts back to the old semantics and ignores child devices which are disabled in Device Tree. Fixes: e49aa9a9bd22 ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Reported-by: Icenowy Zheng Tested-by: Icenowy Zheng Signed-off-by: Lee Jones

mfd: core: Fix double-free in mfd_remove_devices_fn()

2020-08-24T13:23:55+00:00

The pdev.mfd_cell is released by platform_device_release(), which is invoked by platform_device_unregister(). Hence mfd_remove_devices_fn() shouldn't release the cell variable. The double-free bug is reported KASAN during of MFD driver module removal. Fixes: 466a62d7642f ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Reported-by: Marek Szyprowski Signed-off-by: Dmitry Osipenko Signed-off-by: Lee Jones

mfd: mfd-core: Add mechanism for removal of a subset of children

2020-08-13T06:50:50+00:00

Currently, the only way to remove MFD children is with a call to mfd_remove_devices, which will remove all the children. Under some circumstances it is useful to remove only a subset of the child devices. For example if some additional clean up is required between removal of certain child devices. To accomplish this a level field is added to mfd_cell, the normal mfd_remove_devices is modified to not remove devices that are set to a higher level and a corresponding mfd_remove_devices_late function is added to remove those children. See further discussion at: https://lore.kernel.org/lkml/20200616075834.GF2608702@dell/ Suggested-by: Lee Jones Signed-off-by: Charles Keepax Signed-off-by: Lee Jones

mfd: core: Make a best effort attempt to match devices with the correct of_nodes

2020-08-13T06:49:32+00:00

Currently, when a child platform device (sometimes referred to as a sub-device) is registered via the Multi-Functional Device (MFD) API, the framework attempts to match the newly registered platform device with its associated Device Tree (OF) node. Until now, the device has been allocated the first node found with an identical OF compatible string. Unfortunately, if there are, say for example '3' devices which are to be handled by the same driver and therefore have the same compatible string, each of them will be allocated a pointer to the *first* node. An example Device Tree entry might look like this: mfd_of_test { compatible = "mfd,of-test-parent"; #address-cells = <0x02>; #size-cells = <0x02>; child@aaaaaaaaaaaaaaaa { compatible = "mfd,of-test-child"; reg = <0xaaaaaaaa 0xaaaaaaaa 0 0x11>, <0xbbbbbbbb 0xbbbbbbbb 0 0x22>; }; child@cccccccc { compatible = "mfd,of-test-child"; reg = <0x00000000 0xcccccccc 0 0x33>; }; child@dddddddd00000000 { compatible = "mfd,of-test-child"; reg = <0xdddddddd 0x00000000 0 0x44>; }; }; When used with example sub-device registration like this: static const struct mfd_cell mfd_of_test_cell[] = { OF_MFD_CELL("mfd-of-test-child", NULL, NULL, 0, 0, "mfd,of-test-child"), OF_MFD_CELL("mfd-of-test-child", NULL, NULL, 0, 1, "mfd,of-test-child"), OF_MFD_CELL("mfd-of-test-child", NULL, NULL, 0, 2, "mfd,of-test-child") }; ... the current implementation will result in all devices being allocated the first OF node found containing a matching compatible string: [0.712511] mfd-of-test-child mfd-of-test-child.0: Probing platform device: 0 [0.712710] mfd-of-test-child mfd-of-test-child.0: Using OF node: child@aaaaaaaaaaaaaaaa [0.713033] mfd-of-test-child mfd-of-test-child.1: Probing platform device: 1 [0.713381] mfd-of-test-child mfd-of-test-child.1: Using OF node: child@aaaaaaaaaaaaaaaa [0.713691] mfd-of-test-child mfd-of-test-child.2: Probing platform device: 2 [0.713889] mfd-of-test-child mfd-of-test-child.2: Using OF node: child@aaaaaaaaaaaaaaaa After this patch each device will be allocated a unique OF node: [0.712511] mfd-of-test-child mfd-of-test-child.0: Probing platform device: 0 [0.712710] mfd-of-test-child mfd-of-test-child.0: Using OF node: child@aaaaaaaaaaaaaaaa [0.713033] mfd-of-test-child mfd-of-test-child.1: Probing platform device: 1 [0.713381] mfd-of-test-child mfd-of-test-child.1: Using OF node: child@cccccccc [0.713691] mfd-of-test-child mfd-of-test-child.2: Probing platform device: 2 [0.713889] mfd-of-test-child mfd-of-test-child.2: Using OF node: child@dddddddd00000000 Which is fine if all OF nodes are identical. However if we wish to apply an attribute to particular device, we really need to ensure the correct OF node will be associated with the device containing the correct address. We accomplish this by matching the device's address expressed in DT with one provided during sub-device registration. Like this: static const struct mfd_cell mfd_of_test_cell[] = { OF_MFD_CELL_REG("mfd-of-test-child", NULL, NULL, 0, 1, "mfd,of-test-child", 0xdddddddd00000000), OF_MFD_CELL_REG("mfd-of-test-child", NULL, NULL, 0, 2, "mfd,of-test-child", 0xaaaaaaaaaaaaaaaa), OF_MFD_CELL_REG("mfd-of-test-child", NULL, NULL, 0, 3, "mfd,of-test-child", 0x00000000cccccccc) }; This will ensure a specific device (designated here using the platform_ids; 1, 2 and 3) is matched with a particular OF node: [0.712511] mfd-of-test-child mfd-of-test-child.0: Probing platform device: 0 [0.712710] mfd-of-test-child mfd-of-test-child.0: Using OF node: child@dddddddd00000000 [0.713033] mfd-of-test-child mfd-of-test-child.1: Probing platform device: 1 [0.713381] mfd-of-test-child mfd-of-test-child.1: Using OF node: child@aaaaaaaaaaaaaaaa [0.713691] mfd-of-test-child mfd-of-test-child.2: Probing platform device: 2 [0.713889] mfd-of-test-child mfd-of-test-child.2: Using OF node: child@cccccccc This implementation is still not infallible, hence the mention of "best effort" in the commit subject. Since we have not *insisted* on the existence of 'reg' properties (in some scenarios they just do not make sense) and no device currently uses the new 'of_reg' attribute, we have to make an on-the-fly judgement call whether to associate the OF node anyway. Which we do in cases where parent drivers haven't specified a particular OF node to match to. So there is a *slight* possibility of the following result (note: the implementation here is convoluted, but it shows you one means by which this process can still break): /* * First entry will match to the first OF node with matching compatible * Second will fail, since the first took its OF node and is no longer available * Third will succeed */ static const struct mfd_cell mfd_of_test_cell[] = { OF_MFD_CELL("mfd-of-test-child", NULL, NULL, 0, 1, "mfd,of-test-child"), OF_MFD_CELL_REG("mfd-of-test-child", NULL, NULL, 0, 2, "mfd,of-test-child", 0xaaaaaaaaaaaaaaaa), OF_MFD_CELL_REG("mfd-of-test-child", NULL, NULL, 0, 3, "mfd,of-test-child", 0x00000000cccccccc) }; The result: [0.753869] mfd-of-test-parent mfd_of_test: Registering 3 devices [0.756597] mfd-of-test-child: Failed to locate of_node [id: 2] [0.759999] mfd-of-test-child mfd-of-test-child.1: Probing platform device: 1 [0.760314] mfd-of-test-child mfd-of-test-child.1: Using OF node: child@aaaaaaaaaaaaaaaa [0.760908] mfd-of-test-child mfd-of-test-child.2: Probing platform device: 2 [0.761183] mfd-of-test-child mfd-of-test-child.2: No OF node associated with this device [0.761621] mfd-of-test-child mfd-of-test-child.3: Probing platform device: 3 [0.761899] mfd-of-test-child mfd-of-test-child.3: Using OF node: child@cccccccc We could code around this with some pre-parsing semantics, but the added complexity required to cover each and every corner-case is not justified. Merely patching the current failing (via this patch) is already working with some pretty small corner-cases. Other issues should be patched in the parent drivers which can be achieved simply by implementing OF_MFD_CELL_REG(). Signed-off-by: Lee Jones

mfd: mfd-core: Complete kerneldoc header for devm_mfd_add_devices()

2020-07-06T07:31:57+00:00

Each function parameter should be documented in kerneldoc format. Squashes the following W=1 warnings: drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'dev' not described in 'devm_mfd_add_devices' drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'id' not described in 'devm_mfd_add_devices' drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'cells' not described in 'devm_mfd_add_devices' drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'n_devs' not described in 'devm_mfd_add_devices' drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'mem_base' not described in 'devm_mfd_add_devices' drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'irq_base' not described in 'devm_mfd_add_devices' drivers/mfd/mfd-core.c:326: warning: Function parameter or member 'domain' not described in 'devm_mfd_add_devices' Signed-off-by: Lee Jones

mfd: mfd-core: Honour Device Tree's request to disable a child-device

2019-11-11T11:23:57+00:00

Until now, MFD has assumed all child devices passed to it (via mfd_cells) are to be registered. It does not take into account requests from Device Tree and the like to disable child devices on a per-platform basis. Well now it does. Link: https://www.spinics.net/lists/arm-kernel/msg366309.html Link: https://lkml.org/lkml/2019/8/22/1350 Reported-by: Barry Song Reported-by: Stephan Gerhold Reviewed-by: Daniel Thompson Reviewed-by: Mark Brown Tested-by: Stephan Gerhold Signed-off-by: Lee Jones