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: NIrina Tirdea <irina.tirdea@intel.com>
Acked-by: NMika Westerberg <mika.westeberg@linux.intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael 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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLee 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: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Since commit 6e3f62f0 ("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: 6e3f62f0 ("mfd: core: Fix platform-device id generation")
Cc: stable <stable@vger.kernel.org>	# v3.19
Reported-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NLee 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: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLee 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: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NLee 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: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLee 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: NCarlo Caione <carlo@caione.org>
Reported-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This reverts commit 68044bee13770918e0b28dd44aa98c889ec7558f.

We've had confirmed reports of this patch causing unforeseen issues
with existing MFD users. It has been agreed by the original author
and myself that reversion is the best solution.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

mfd_add_device() assigns .of_node in the device objects it creates only
if the mfd_cell for the device has the .of_compatible field set and the
DT node for the top-level MFD device contains a child whose compatible
property matches the cell's .of_compatible field.

This leaves .of_node unset in many cases. When this happens, entries in
the DT /aliases property which refer to the top-level MFD DT node will
never match the MFD child devices, hence causing the requested alias not
to be honored.

Solve this by setting each MFD child device's .of_node equal to the top-
level MFD device's .of_node field in the cases where it would otherwise
remain unset.

The first use-case for this will be aliases for the TPS6586x's RTC
device.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

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: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Commit 1e29af62 ("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: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLee 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: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark 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: NBenedikt Spranger <b.spranger@linutronix.de>
Signed-off-by: NHolger Dengler <dengler@linutronix.de>
Signed-off-by: NLee 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: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Tested-by: NPeter Tyser <ptyser@xes-inc.com>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel 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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel 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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel 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: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NSamuel 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
91fedede.

Fix the check to run on each resource individually, once.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@vger.kernel.org
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The first parameter should be "number of elements" and the second parameter
should be "element size".
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NSamuel 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
91fedede.

Fix the check to run on each resource individually, once.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@vger.kernel.org
Signed-off-by: NSamuel 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: NPaul 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: NSamuel 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: NGreg KH <gregkh@suse.de>
Signed-off-by: NSamuel 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: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel 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: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel 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: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel 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: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel 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: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel 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: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel 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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel 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: NBrian Harring <ferringb@gmail.com>
Signed-off-by: NSamuel 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: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

platform_device_add_resources may fail, thus add error checking for it.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

If mem_base is NULL, then we fall back to the default case, just copying the
original resource.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

For ACPI based systems, we should check for ACPI conflicts when adding the
platform devices. The test will always succeed for non ACPI platforms.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>