21 May, 2016
1 commit
-
Pull MFD updates from Lee Jones:
"New Drivers:
- Add new driver for MAXIM MAX77620/MAX20024 PMIC
- Add new driver for Hisilicon HI665X PMICNew Device Support:
- Add support for AXP809 in axp20x-rsb
- Add support for Power Supply in axp20xNew core features:
- devm_mfd_* managed resourcesFix-ups:
- Remove unused code (da9063-irq, wm8400-core, tps6105x,
smsc-ece1099, twl4030-power)
- Improve clean-up in error path (intel_quark_i2c_gpio)
- Explicitly include headers (syscon.h)
- Allow building as modules (max77693)
- Use IS_ENABLED() instead of rolling your own (dm355evm_msp,
wm8400-core)
- DT adaptions (axp20x, hi655x, arizona, max77620)
- Remove CLK_IS_ROOT flag (intel-lpss, intel_quark)
- Move to gpiochip API (asic3, dm355evm_msp, htc-egpio, htc-i2cpld,
sm501, tc6393xb, tps65010, ucb1x00, vexpress)
- Make use of devm_mfd_* calls (act8945a, as3711, atmel-hlcdc,
bcm590xx, hi6421-pmic-core, lp3943, menf21bmc, mt6397, rdc321x,
rk808, rn5t618, rt5033, sky81452, stw481x, tps6507x, tps65217,
wm8400)Bug Fixes"
- Fix ACPI child matching (mfd-core)
- Fix start-up ordering issues (mt6397-core, arizona-core)
- Fix forgotten register state on resume (intel-lpss)
- Fix Clock related issues (twl6040)
- Fix scheduling whilst atomic (omap-usb-tll)
- Kconfig changes (vexpress)"* tag 'mfd-for-linus-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (73 commits)
mfd: hi655x: Add MFD driver for hi655x
mfd: ab8500-debugfs: Trivial fix of spelling mistake on "between"
mfd: vexpress: Add !ARCH_USES_GETTIMEOFFSET dependency
mfd: Add device-tree binding doc for PMIC MAX77620/MAX20024
mfd: max77620: Add core driver for MAX77620/MAX20024
mfd: arizona: Add defines for GPSW values that can be used from DT
mfd: omap-usb-tll: Fix scheduling while atomic BUG
mfd: wm5110: ARIZONA_CLOCK_CONTROL should be volatile
mfd: axp20x: Add a cell for the ac power_supply part of the axp20x PMICs
mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly
mfd: wl1273-core: Use devm_mfd_add_devices() for mfd_device registration
mfd: tps65910: Use devm_mfd_add_devices and devm_regmap_add_irq_chip
mfd: sec: Use devm_mfd_add_devices and devm_regmap_add_irq_chip
mfd: rc5t583: Use devm_mfd_add_devices and devm_request_threaded_irq
mfd: max77686: Use devm_mfd_add_devices and devm_regmap_add_irq_chip
mfd: as3722: Use devm_mfd_add_devices and devm_regmap_add_irq_chip
mfd: twl4030-power: Remove driver path in file comment
MAINTAINERS: Add entry for X-Powers AXP family PMIC drivers
mfd: smsc-ece1099: Remove unnecessarily remove callback
mfd: Use IS_ENABLED(CONFIG_FOO) instead of checking FOO || FOO_MODULE
...
19 Apr, 2016
1 commit
-
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
Signed-off-by: Lee Jones
11 Apr, 2016
1 commit
-
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
Acked-by: Mika Westerberg
Signed-off-by: Lee Jones
09 Apr, 2016
1 commit
-
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
Reviewed-by: Mika Westerberg
Acked-by: Thierry Reding
Acked-by: Lee Jones
Signed-off-by: Heikki Krogerus
Signed-off-by: Rafael J. Wysocki
07 Dec, 2015
1 commit
-
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
Signed-off-by: Rafael J. Wysocki
26 Oct, 2015
1 commit
-
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
Acked-by: Lee Jones
Signed-off-by: Andy Shevchenko
Signed-off-by: Wolfram Sang
28 Jul, 2015
1 commit
-
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
Signed-off-by: Lee Jones
22 Jun, 2015
1 commit
-
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
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Lee Jones
30 Mar, 2015
1 commit
-
Since commit 6e3f62f0793e ("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: 6e3f62f0793e ("mfd: core: Fix platform-device id generation")
Cc: stable # v3.19
Reported-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Johan Hovold
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Lee Jones
26 Nov, 2014
1 commit
-
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
Signed-off-by: Lee Jones
26 Sep, 2014
2 commits
-
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
Reviewed-by: Darren Hart
Signed-off-by: Lee Jones -
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
Acked-by: Arnd Bergmann
Signed-off-by: Lee Jones
03 Jun, 2014
1 commit
-
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
Reported-by: Mark Brown
Signed-off-by: Charles Keepax
Reviewed-by: Mark Brown
Signed-off-by: Lee Jones
16 Nov, 2013
1 commit
-
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
...
11 Nov, 2013
2 commits
-
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
Signed-off-by: Lee Jones -
Commit 1e29af62f2b285bd18685da93c3ce8c33ca2d1db ("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
Signed-off-by: Lee Jones
23 Oct, 2013
1 commit
-
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
Acked-by: Lee Jones
Signed-off-by: Mark Brown
15 Aug, 2013
1 commit
-
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
Signed-off-by: Holger Dengler
Signed-off-by: Lee Jones
20 Nov, 2012
1 commit
-
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
Tested-by: Peter Tyser
Reviewed-by: Mark Brown
Signed-off-by: Samuel Ortiz
16 Sep, 2012
1 commit
-
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
Signed-off-by: Samuel Ortiz
09 Jul, 2012
1 commit
-
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
Signed-off-by: Samuel Ortiz
07 Mar, 2012
2 commits
-
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
91fedede0338eb6203cdd618d8ece873fdb7c22c.Fix the check to run on each resource individually, once.
Signed-off-by: Jean Delvare
Cc: stable@vger.kernel.org
Signed-off-by: Samuel Ortiz -
The first parameter should be "number of elements" and the second parameter
should be "element size".Signed-off-by: Axel Lin
Signed-off-by: Samuel Ortiz
01 Nov, 2011
1 commit
-
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 ]
Signed-off-by: Paul Gortmaker
27 May, 2011
1 commit
-
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
12 Apr, 2011
1 commit
-
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
Acked-by: Greg KH
Signed-off-by: Samuel Ortiz
27 Mar, 2011
1 commit
-
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
Signed-off-by: Samuel Ortiz
23 Mar, 2011
5 commits
-
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
Signed-off-by: Samuel Ortiz -
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
Signed-off-by: Samuel Ortiz -
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
Signed-off-by: Samuel Ortiz -
All users of this have now been switched over to using mfd_data;
it can go away now.Signed-off-by: Andres Salomon
Signed-off-by: Samuel Ortiz -
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
Signed-off-by: Samuel Ortiz
14 Jan, 2011
1 commit
-
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
Signed-off-by: Samuel Ortiz
29 Oct, 2010
2 commits
-
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
Signed-off-by: Samuel Ortiz -
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
Signed-off-by: Samuel Ortiz
12 Aug, 2010
1 commit
-
platform_device_add_resources may fail, thus add error checking for it.
Signed-off-by: Axel Lin
Signed-off-by: Samuel Ortiz
28 May, 2010
1 commit
-
If mem_base is NULL, then we fall back to the default case, just copying the
original resource.Signed-off-by: Samuel Ortiz
30 Mar, 2010
1 commit
-
…it 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 allmodconfig8. 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: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
08 Mar, 2010
1 commit
-
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: Samuel Ortiz
17 Sep, 2009
1 commit
-
Provide basic support for MFDs having multiple cells of a given
type with different IDs by adding an id to the mfd_cell structure
and then adding that to the id passed in to mfd_add_devices().As it stands this approach requires that MFDs using this feature
deal with ensuring that there aren't any ID collisions resulting
from multiple MFDs of the same type being instantiated. This needs
to happen with the existing code too, but with this approach there
is a knock on effect on the IDs for non-duplicated devices.Signed-off-by: Mark Brown
Signed-off-by: Samuel Ortiz