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 <lee.jones@linaro.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <lee.jones@linaro.org>
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 <Baohua.Song@csr.com>
Reported-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Most of the complexity of mfd_platform_add_cell() has been removed. The
only functionality left duplicates cell memory into the child's platform
device. Since it's only a few lines, moving it to the main thread and
removing the superfluous function makes sense.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
The MFD implementation for reference counting was complex and unnecessary.
There was only one bona fide user which has now been converted to handle
the process in a different way. Any future resource protection, shared
enablement functions should be handed by the parent device, rather than
through the MFD subsystem API.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Providing a subsystem-level API helper seems over-kill just to save a
few lines of C-code. Previous commits saw us convert mfd_clone_cell()'s
only user over to use a more traditional style of MFD child-device
registration. Now we can remove the superfluous helper from the MFD API.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
If a child device calls mfd_cell_{en,dis}able() without an appropriate
call-back being set, we are likely to encounter a panic. Avoid this
by adding suitable checking.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
- Set 'struct device' fwnode when registering a new device
- New Drivers
- Add support for ROHM BD70528 PMIC
- New Device Support
- Add support for LP87561 4-Phase Regulator to TI LP87565 PMIC
- Add support for RK809 and RK817 to Rockchip RK808
- Add support for Lid Angle to ChromeOS core
- Add support for CS47L15 CODEC to Madera core
- Add support for CS47L92 CODEC to Madera core
- Add support for ChromeOS (legacy) Accelerometers in ChromeOS core
- Add support for Add Intel Elkhart Lake PCH to Intel LPSS
- New Functionality
- Provide regulator supply information when registering; madera-core
- Additional Device Tree support; lp87565, madera, cros-ec, rohm,bd71837-pmic
- Allow over-riding power button press via Device Tree; rohm-bd718x7
- Differentiate between running processors; cros_ec_dev
- Fix-ups
- Big header file update; cros_ec_commands.h
- Split header per-subsystem; rohm-bd718x7
- Remove superfluous code; menelaus, cs5535-mfd, cs47lXX-tables
- Trivial; sorting, coding style; intel-lpss-pci
- Only remove Power Off functionality if set locally; rk808
- Make use for Power Off Prepare(); rk808
- Fix spelling mistake in header guards; stmfx
- Properly free IDA resources
- SPDX fixups; cs47lXX-tables, madera
- Error path fixups; hi655x-pmic
- Bug Fixes
- Add missing break in case() statement
- Repair undefined behaviour when not initialising variables; arizona-core, madera-core
- Fix reference to Device Tree documentation; madera
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAl0sLxgACgkQUa+KL4f8
d2E25Q/9HmDJIdfyDQg0xv5IM5HS1WsP9BcJCEgoRIsad4mMDRYt+ZeLbslwMhue
E9tsFH359gGvyqR+7d6hPpEUET1UEcJy4eRD1zAc0+epllQTDHSy8oHt1dtH+8xB
2AU5rvAKOqBk83D+V2Hkx2KcroWEQQNYIoR9/12Pi3xmEB1uaCO0/Ajd3B28bIBM
Tzi3cVQ3U7jY9EIM44GVTsjDAbMSkQR0iab6cQF0vJAWaUmGKlsO7iRrU1XkN69V
qXyBauI8WGiGssihrE8r+jYvHvmg7hA9OKZIckUaMXD/k7kpHbwIaFRh7gukq4Re
Q6Cy30NfVJ1tY66/5oqN6gj5znfeuEudMCCzYAkzlROSp5eApe2Ke5ajYn3kOCZd
ZKcsrw9Fiox1lKmuWXDbyf0nqf4zwdDPAnShRWaaF5aipwgywyGcwSigVtK4F0P5
Hjc5RLv7GjTAJq+ZzwgKyAdtx8L0mhdLd1ZTQpEXk/g/E9dW4GF72hWj9TQ/9BnA
ZflKv8aP3lDGRHgO3Huwi4lMzskB8BVCQMCFwLwGs5cY1oZQhAjTdJzBZjTGexhC
evuuA8OUsCrOWMvnZf3saSdHJ1iMHtfPnqEGHRJQtNj4fFaXv80LasIomvvfJc1/
9JlRyAgm2pF7YDrgTh65ZzBb324eKSZZoAj9XZbnTyzxUAcF69A=
=A3jw
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"Core Frameworks:
- Set 'struct device' fwnode when registering a new device
New Drivers:
- Add support for ROHM BD70528 PMIC
New Device Support:
- Add support for LP87561 4-Phase Regulator to TI LP87565 PMIC
- Add support for RK809 and RK817 to Rockchip RK808
- Add support for Lid Angle to ChromeOS core
- Add support for CS47L15 CODEC to Madera core
- Add support for CS47L92 CODEC to Madera core
- Add support for ChromeOS (legacy) Accelerometers in ChromeOS core
- Add support for Add Intel Elkhart Lake PCH to Intel LPSS
New Functionality:
- Provide regulator supply information when registering; madera-core
- Additional Device Tree support; lp87565, madera, cros-ec, rohm,bd71837-pmic
- Allow over-riding power button press via Device Tree; rohm-bd718x7
- Differentiate between running processors; cros_ec_dev
Fix-ups:
- Big header file update; cros_ec_commands.h
- Split header per-subsystem; rohm-bd718x7
- Remove superfluous code; menelaus, cs5535-mfd, cs47lXX-tables
- Trivial; sorting, coding style; intel-lpss-pci
- Only remove Power Off functionality if set locally; rk808
- Make use for Power Off Prepare(); rk808
- Fix spelling mistake in header guards; stmfx
- Properly free IDA resources
- SPDX fixups; cs47lXX-tables, madera
- Error path fixups; hi655x-pmic
Bug Fixes:
- Add missing break in case() statement
- Repair undefined behaviour when not initialising variables; arizona-core, madera-core
- Fix reference to Device Tree documentation; madera"
* tag 'mfd-next-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (45 commits)
mfd: hi655x-pmic: Fix missing return value check for devm_regmap_init_mmio_clk
mfd: madera: Fixup SPDX headers
mfd: madera: Remove some unused registers and fix some defaults
mfd: intel-lpss: Release IDA resources
mfd: intel-lpss: Add Intel Elkhart Lake PCH PCI IDs
mfd: cs5535-mfd: Remove ifdef OLPC noise
mfd: stmfx: Fix macro definition spelling
dt-bindings: mfd: Add link to ROHM BD71847 Datasheet
MAINAINERS: Swap words in INTEL PMIC MULTIFUNCTION DEVICE DRIVERS
mfd: cros_ec_dev: Register cros_ec_accel_legacy driver as a subdevice
mfd: rk808: Prepare rk805 for poweroff
mfd: rk808: Check pm_power_off pointer
mfd: cros_ec: differentiate SCP from EC by feature bit
dt-bindings: Add binding for cros-ec-rpmsg
mfd: madera: Add Madera core support for CS47L92
mfd: madera: Add Madera core support for CS47L15
mfd: madera: Update DT bindings to add additional CODECs
mfd: madera: Add supply mapping for MICVDD
mfd: madera: Fix potential uninitialised use of variable
mfd: madera: Fix bad reference to pinctrl.txt file
...
The logic for setting the of_node on devices created by mfd did not set
the fwnode pointer to match, which caused fwnode-based APIs to
malfunction on these devices since the fwnode pointer was null. Fix
this.
Signed-off-by: Robert Hancock <hancock@sedsystems.ca>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a kernel doc for mfd_add_devices().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Make sure to drop the reference taken by bus_find_device_by_name()
before returning from mfd_clone_cell().
Fixes: a9bbba9963 ("mfd: add platform_device sharing support for mfd")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Add resource managed API devm_mfd_add_devices() for the mfd_add_devices().
This helps in reducing code in error path as it is not required
to call mfd_remove_devices() explicitly to remove all child-devices.
In some cases, it also helps not to implement .remove() callback
which get called during driver unbind.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
If MDF child devices have separate ACPI nodes identified
by _HID/_CID, they will not be assigned the intended
ACPI companion.
acpi_match_device_ids will return 0 if a the child device
matches the _HID/_CID, so this patch changes the matching
condition to check for 0 on success.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Acked-by: Mika Westerberg <mika.westeberg@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Since device_add_property_set() now always takes a copy of
the property_set, and also since the fwnode type is always
hard coded to be FWNODE_PDATA, there is no need for the
drivers to deliver the entire struct property_set. The
function can just create the instance of it on its own and
bind the properties from the drivers to it on the spot.
This renames device_add_property_set() to
device_add_properties(). The function now takes struct
property_entry as its parameter instead of struct
property_set.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In the similar way like we do for the platform data we propagate the device
properties. For example, in case of Intel LPSS drivers we may provide a
specific property to tell the actual device driver an additional information
such as platform name.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses
_ADR to distinguish the devices under one actual device. Due to this we have to
improve the quirk in the MFD core to handle that board.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The newly introduced device_for_each_child_reverse() would be used when MFD
core removes the device.
After this patch applied the devices will be removed in a reversed order. This
behaviour is useful when devices have implicit dependency on order, i.e.
consider MFD device with serial bus controller, such as SPI, and DMA IP that is
attached to serial bus controller: before remove the DMA driver we have to be
ensured that no DMA transfers is ongoing and the requested channel are unused.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Current code in mfd-core calls into ACPI to check resources even
on a system that booted with a DT (on kernels with both DT and ACPI
support compiled in). This triggers ACPI exceptions since we may
end up calling the ACPI interpreter when it has not been initialized:
"ACPI Exception: AE_BAD_PARAMETER, Thread 2064154624 could not acquire
Mutex [0x1] (20150410/utmutex-285)"
This patch fixes the issues by adding a check for an ACPI companion
device before carrying out ACPI resources checks to avoid calling
the ACPI interpreter if the fwnode representing the device is an OF one.
Cc: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Since commit 6e3f62f079 ("mfd: core: Fix platform-device id
generation") we honour PLATFORM_DEVID_AUTO and PLATFORM_DEVID_NONE when
registering mfd-devices.
Unfortunately, some mfd-drivers rely on the old behaviour of generating
platform-device ids by adding the cell id also to the special value of
PLATFORM_DEVID_NONE. The resulting platform ids are not only used to
generate device-unique names, but are also used instead of the cell id
to identify cells when probing subdevices.
These drivers should be updated to use PLATFORM_DEVID_AUTO, which would
also allow more than one device to be registered without resorting to
hacks (see for example wm831x), but lets fix the regression first by
partially reverting the above mentioned commit with respect to
PLATFORM_DEVID_NONE.
Fixes: 6e3f62f079 ("mfd: core: Fix platform-device id generation")
Cc: stable <stable@vger.kernel.org> # v3.19
Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Make sure to always honour multi-function devices registered with
PLATFORM_DEVID_NONE (-1) or PLATFORM_DEVID_AUTO (-2) as id base. In this
case it does not make sense to append the cell id to the mfd-id base and
potentially change the requested behaviour.
Specifically this will allow multi-function devices to be registered
with PLATFORM_DEVID_AUTO while still having non-zero cell ids.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
If an MFD device is backed by ACPI namespace, we should allow subdevice
drivers to access their corresponding ACPI companion devices through normal
means (e.g using ACPI_COMPANION()).
This patch adds such support to the MFD core. If the MFD parent device
does not specify any ACPI _HID/_CID for the child device, the child
device will share the parent ACPI companion device. Otherwise the child
device will be assigned with the corresponding ACPI companion, if found
in the namespace below the parent.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
dma_mask and dma_parms are already inherited from the parent device but
dma_coherent_mask was left uninitialized (set to zero thanks to kzalloc).
Set sub-device coherent_dma_mask to its parent value to simplify
sub-drivers making use of dma coherent helper functions (those drivers
currently have to explicitly set the dma coherent mask using
dma_set_coherent_mask function).
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The supply aliases for the MFD devices were being added using devres but
the device hasn't been added at this point and as such we can't use
devres.
The MFD already has a function that removes devices this patch uses the
non-devres versions of the supply alias functions and adds an unregister
in mfd_remove_devices_fn.
Reported-by: Carlo Caione <carlo@caione.org>
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
AS3722 PMIC and for STMicroelectronics STw481x PMIC.
Although this is a smaller update than usual, we also have:
- Device tree support for the max77693 driver.
- linux/of.h inclusion for all DT compatible MFD drivers, to avoid build
breakage in the future.
- Support for Intel Wildcat Point-LP PCH through the lpc_ich driver.
- A small arizona update for new wm5110 DSP registers and a few fixes.
- A small palmas update as well, including an of_device table addition
and a few minor fixes.
- Two small mfd-core changes, one including a memory leak fix for when
mfd_add_device() fails.
- Our usual round of minor cleanups and janitorial fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAABAgAGBQJShjufAAoJEIqAPN1PVmxKRoEP/jKe0UgrNA6G4xHSPX1Xcktc
/kaQdcwJcTTHMpkIyQPFayItCcBPyb8bN1SdrQs4sds4ut7xyjve2uHz0KpZI6JO
F+Rh6UVNkUIbcEx3jfh0DDv3pHv0vryFPnerkOIr0TFmSF1Tj29dRORQzpEqZ2fZ
rstxmxNTG0ggP0Ug4ivv/YWjhGmO9CvKePJzQyImrC8QWCRDiARu072bG8xhVyHZ
PkJTzJr2kjkI3whIY7Z04Nx90AtpikM4G27JiCwsHyv4vCCOtTtC9lRYb/IBUHWJ
UhJiPvTygsU63opGOyAodR9LJxta0UCWm2Qn71ZuBAJmQ4oFxdZ7iVkWePjeSF5U
2Jx9dUi1UWJQNCSB8HEpaUExybXdsNTwnSw8NIb6Gg2kygClj5KvzPMwz3ZHRKU/
Ef1TGpWTeuok0zOijhBDUqAhq4KQv/H9Xjbm8FIMSBVGQgRBT3dkYTRZv30deeg/
SIzoJGg7QiMDwlu/33k7aX7aIwJA2r6st/Q3OUKp/aBVqd6i24rL5+ZMykqcx5HJ
x9GnvjrHgz+nAgF2yU6KQT1FrX1IQEM4F1tgMtroXQcCAGgoWoJRjW82gQqp6NE+
eVbvsE56z2MiSNbiYUL4hdC03b/z8LbzP1zEt95Xc+sOf7NewMHYln7XkByBxrPH
tlR20ZV44W25s7DYg7xh
=nQ/p
-----END PGP SIGNATURE-----
Merge tag 'mfd-3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next
Pull MFD updates from Samuel Ortiz:
"For the 3.13 merge window we have a couple of new drivers for the AMS
AS3722 PMIC and for STMicroelectronics STw481x PMIC.
Although this is a smaller update than usual, we also have:
- Device tree support for the max77693 driver
- linux/of.h inclusion for all DT compatible MFD drivers, to avoid
build breakage in the future
- Support for Intel Wildcat Point-LP PCH through the lpc_ich driver
- A small arizona update for new wm5110 DSP registers and a few fixes
- A small palmas update as well, including an of_device table
addition and a few minor fixes
- Two small mfd-core changes, one including a memory leak fix for
when mfd_add_device() fails
- Our usual round of minor cleanups and janitorial fixes"
* tag 'mfd-3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next: (63 commits)
Documentation: mfd: Update s2mps11.txt
mfd: pm8921: Potential NULL dereference in pm8921_remove()
mfd: Fix memory leak in mfd_add_devices()
mfd: Stop setting refcounting pointers in original mfd_cell arrays
mfd: wm5110: Enable micd clamp functionality
mfd: lpc_ich: Add Device IDs for Intel Wildcat Point-LP PCH
mfd: max77693: Fix up bug of wrong interrupt number
mfd: as3722: Don't export the regmap config
mfd: twl6040: Remove obsolete cleanup for i2c clientdata
mfd: tps65910: Remove warning during dt node parsing
mfd: lpc_sch: Ignore resource conflicts when adding mfd cells
mfd: ti_am335x_tscadc: Avoid possible deadlock of reg_lock
mfd: syscon: Return -ENOSYS if CONFIG_MFD_SYSCON is not enabled
mfd: Add support for ams AS3722 PMIC
mfd: max77693: Include linux/of.h header
mfd: tc3589x: Detect the precise version
mfd: omap-usb: prepare/unprepare clock while enable/disable
mfd: max77686: Include linux/of.h header
mfd: max8907: Include linux/of.h header
mfd: max8997: Include linux/of.h header
...
If the first call to mfd_add_device() fails, no child devices have been
registered to the parent yet, and thus mfd_remove_devices() won't find
anything to remove nor free.
Hence the previously allocated array of atomic_t objects will leak.
Free the array instead of calling mfd_remove_devices() on failure during
the first loop iteration to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Commit 1e29af62f2 ("mfd: Add refcounting
support to mfd_cells") had to drop the "const" keyword on the "cell"
parameter of mfd_add_devices(), as it added the refcounting pointers
to the objects of the passed mfd_cell array itself.
However, the mfd core code operates on copies of the mfd_cell objects,
so there's no need to modify the originally passed objects.
Hence, move the setting of the refcounting pointers from mfd_add_devices()
to mfd_platform_add_cell(), where the copy of the mfd_cell objects is made.
mfd_clone_cell() can just pass (a copy of) the original usage_count
pointer.
This allows to make the "cell" parameter of mfd_add_devices() "const"
again, and avoids future race conditions when registering multiple
instances of the same device in parallel.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Occasionally, it is useful to map supplies from a child device onto the
MFD device. A typical usecase for this would be if the MFD device is
represented as a single node in device tree. All supplies will be
defined in device tree as existing on the MFD device. When a child
depends on frameworks which might have no knowledge of MFD to lookup
supplies on its behalf the supply will not be found.
This patch adds a list of supplies that should be looked up on the
parent rather than the child as part of the mfd_cell structure.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
The child device intends to perform DMA operations then it needs a dma
mask and params set. This patches copies them from the parent device.
Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
Signed-off-by: Holger Dengler <dengler@linutronix.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd_remove_devices would iterate over all devices sharing a parent with
an mfd device regardless of whether they were allocated by the mfd core
or not. This especially caused problems when the device structure was
not contained within a platform_device, because to_platform_device is
used on each device pointer.
This patch defines a device_type for mfd devices and checks this is
present from mfd_remove_devices_fn before processing the device.
Cc: stable@vger.kernel.org
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Tested-by: Peter Tyser <ptyser@xes-inc.com>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Currently the MFD core supports remapping MFD cell interrupts using an
irqdomain but only if the MFD is being instantiated using device tree
and only if the device tree bindings use the pattern of registering IPs
in the device tree with compatible properties. This will be actively
harmful for drivers which support non-DT platforms and use this pattern
for their DT bindings as it will mean that the core will silently change
remapping behaviour and it is also limiting for drivers which don't do
DT with this particular pattern. There is also a potential fragility if
there are interrupts not associated with MFD cells and all the cells are
omitted from the device tree for some reason.
Instead change the code to take an IRQ domain as an optional argument,
allowing drivers to take the decision about the parent domain for their
interrupts. The one current user of this feature is ab8500-core, it has
the domain lookup pushed out into the driver.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
During Device Tree enablement of the ab8500 and db8500-prcmu drivers,
a decision was made to omit registration through the MFD API and use
Device Tree directly. However, because MFD devices have a different
address space and the ab8500 and db8500 both use I2C to communicate,
this causes issues with address translation during execution of
of_platform_populate(). So the solution is to make the MFD core aware
of Device Tree and have it assign the correct node pointers instead.
To make this work the MFD core also needs to be awere of IRQ domains,
as Device Tree insists on IRQ domain compatibility. So, instead of
providing an irq-base via platform code, in the DT case we simply
look up the IRQ domain and map to the correct virtual IRQ.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The code is currently always checking the first resource of every
device only (several times.) This has been broken since the ACPI check
was added in February 2010 in commit
91fedede03.
Fix the check to run on each resource individually, once.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@vger.kernel.org
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The first parameter should be "number of elements" and the second parameter
should be "element size".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
With the pending module.h cleanup, these files will fail to compile,
unless they explicitly call out the include of this file.
[omap-usb-host addition courtesy of Anand Gadiyar <gadiyar@ti.com>]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Now that we have a way to pass MFD cells down to the sub drivers,
we can gradually get rid of mfd_data by putting the platform pointer
back in place.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In order for MFD drivers to fetch their cell pointer but also their
platform data one, an mfd cell pointer is added to the platform_device
structure.
That allows all MFD sub devices drivers to be MFD agnostic, unless
they really need to access their MFD cell data. Most of them don't,
especially the ones for IPs used by both MFD and non MFD SoCs.
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg KH <gregkh@suse.de>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Replace mfd_shared_platform_driver_register with mfd_clone_cell. The
former was called by an mfd client, and registered both a platform driver
and device. The latter is called by an mfd driver, and registers only a
platform device.
The downside of this is that mfd drivers need to be modified whenever
new clients are added that share a cell; the upside is that it fits
Linux's driver model better. It's also simpler.
This also converts cs5535-mfd/olpc-xo1 from the old API. cs5535-mfd
now creates the olpc-xo1-{acpi,pms} devices, while olpc-xo1 binds to
them via platform drivers.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
As requested by Samuel, there's not really any reason to have "shared"
in the name.
This also modifies the only user of the function, as well.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This adds functions to enable platform_device sharing for mfd clients.
Each platform driver (mfd client) that wants to share an mfd_cell's
platform_device uses the mfd_shared_platform_driver_{un,}register()
functions instead of platform_driver_{un,}register(). Along with
registering the platform driver, these also register a new platform
device with the same characteristics as the original cell, but a different
name. Given an mfd_cell with the name "foo", drivers that want to
share access to its resources can call mfd_shared_platform_driver_register
with platform drivers named (for example) "bar" and "baz". This
will register two platform devices and drivers named "bar" and "baz"
that share the same cell as the platform device "foo". The drivers
can then call "foo" cell's enable hooks (or mfd_shared_cell_enable)
to enable resources, and obtain platform resources as they normally
would.
This deals with platform handling only; mfd driver-specific details,
hardware handling, refcounting, etc are all dealt with separately.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This provides convenience functions for sharing of cells across
multiple mfd clients. Mfd drivers can provide enable/disable hooks
to actually tweak the hardware, and clients can call
mfd_shared_cell_{en,dis}able without having to worry about whether
or not another client happens to have enabled or disabled the
cell/hardware.
Note that this is purely optional; drivers can continue to use
the mfd_cell's enable/disable hooks for their own purposes, if
desired.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
All users of this have now been switched over to using mfd_data;
it can go away now.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Previously, one would set the mfd_cell's platform_data/data_size to point
to the current mfd_cell in order to pass that information along to drivers.
This causes the current mfd_cell to always be available to drivers. It
also adds a wrapper function for fetching the mfd cell from a platform
device, similar to what originally existed for mfd devices.
Drivers who previously used platform_data for other purposes can still
use it; the difference is that mfd_get_data() must be used to
access it (and the pdata structure is no longer allocated in
mfd_add_devices).
Note that mfd_get_data is intentionally vague (in name) about where
the data is stored; variable name changes can come later without having
to touch brazillions of drivers.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Allow MFD cells to have pm_runtime_no_callbacks() called on them during
registration. This causes the runtime PM framework to ignore them,
allowing use of runtime PM to suspend the device as a whole even if
not all drivers for the MFD can usefully implement runtime PM. For
example, RTCs are likely to run continuously regardless of the power
state of the system.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When the cell data_size is 0, the resulting platform_data pointer will be
set to ZERO_SIZE_PTR. That could be misleading for device drivers running
a NULL check on thei platform_data pointer before dereferencing it.
Signed-off-by: Brian Harring <ferringb@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The upcoming VIA VX855 MFD driver needs to communicate resources
to subdevices where the resources may be claimed by ACPI.
Add a flag to mfd_cell to request that resources are not policed.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
platform_device_add_resources may fail, thus add error checking for it.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
