This is the convention used in most parts of the kernel including DT
counterpart of I2C slave enumeration. To make things consistent do the same
for ACPI I2C slave enumeration path as well.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit 523c5b89 ("i2c: Remove support for legacy PM") removed the PM
ops from the bus type, which causes the pm operations on the s3c2410
adapter device to fail (-ENOSUPP in rpm_callback). The adapter device
doesn't get bound to a driver and as such can't have its own pm_runtime
callbacks. Previously this was fine as the bus callbacks would have been
used, but now this can cause devices which use PM runtime and are
attached over I2C to fail to resume.

This commit fixes this issue by marking all adapter devices with
pm_runtime_no_callbacks, since they can't have any.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: NBeata Michalska <b.michalska@samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Fixes: 523c5b89
Cc: stable@kernel.org

Current -next fails to link an ARM allmodconfig because drivers that use
the core recovery functions can be built as modules but those functions
are not exported:

ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined!

Add exports to fix this.

Fixes: 5f9296ba (i2c: Add bus recovery infrastructure)
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch changes type of input parameter for
prepare/unprepare_recovery() callbacks from struct i2c_bus_recovery_info
* to struct i2c_adapter *. This allows to simplify implementation of
these callbacks and avoid type conversations from i2c_bus_recovery_info
to i2c_adapter. The i2c_bus_recovery_info can be simply retrieved from
struct i2c_adapter which contains pointer on it. There are no users
currently, so this is safe to do.
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Make sure dynamic ids do not interfere with fixed ones and let them
start after the highest fixed id. This patch might cause different
bus-numbers than before for dynamic ids, however it fixes a bug. Assume:

- fixed id0 defers probe
- fixed id1 succeeds and registers a muxed bus with dynamic id
- muxed bus gets id0
- fixed id0 wants to probe again, but its fixed id is gone now
- fixed id0 probe fails

With this patch, the fixed ids are always reserved in the DT case.
For legacy board init, we already have a mechanism like this in
i2c_register_board_info().
Reported-by: NBob Feretich <bob.feretich@rafresearch.com>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Now that we have struct fwnode_handle, we can use that to point to
ACPI companions from struct device objects instead of pointing to
struct acpi_device directly.

There are two benefits from that.  First, the somewhat ugly and
hackish struct acpi_dev_node can be dropped and, second, the same
struct fwnode_handle pointer can be used in the future to point
to other (non-ACPI) firmware device node types.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NGrant Likely <grant.likely@linaro.org>

Let the core do the checks if HW quirks prevent a transfer. Saves code
from drivers and adds consistency.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Tested-by: NRay Jui <rjui@broadcom.com>
Tested-by: NIvan T. Ivanov <iivanov@mm-sol.com>
Tested-by: NNeelesh Gupta <neelegup@linux.vnet.ibm.com>
Tested-By: NLudovic Desroches <ludovic.desroches@atmel.com>

This reverts commit e4df3a0b
("i2c: core: Dispose OF IRQ mapping at client removal time")

Calling irq_dispose_mapping() will destroy the mapping and disassociate
the IRQ from the IRQ chip to which it belongs. Keeping it is OK, because
existent mappings are reused properly.

Also, this commit breaks drivers using devm* for IRQ management on
OF-based systems because devm* cleanup happens in device code, after
bus's remove() method returns.
Signed-off-by: NJakub Kicinski <kubakici@wp.pl>
Reported-by: NSébastien Szymanski <sebastien.szymanski@armadeus.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
[wsa: updated the commit message with findings fromt the other bug report]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
Fixes: e4df3a0b

There was quite some confusion why this completion is there and if it is
still necessary. Sadly, it is. However, let's improve the comments and
share what we rediscovered.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
included unconditionally, even when it is not needed.

I2C bus drivers which implement slave support must select
I2C_SLAVE.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Trying to register an I2C device asynchronously (via async_schedule() call)
results in an ugly warning from request_module() warning about potential
deadlock (because request_module tries to wait for async works to
complete). While we could try to switch to request_module_nowait(), other
buses, as well as I2C itself when not using device tree, do not try to load
modules, but rather rely on the standard infrastructure (udev) to execute
module loading, and we should be doing the same.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Declaring attribute groups can be done with macros these days, let's use
them for consistency and readability reasons. Also, put the ATTR macros
directly below the referenced functions while we are here.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

ACPI specification allows I2C devices with multiple addresses. The current
implementation goes over all addresses and assigns the last one to the
device. This is typically not the primary address of the device.

Instead of doing that we assign the first address to the device and then
let the driver handle rest of the addresses as it wishes.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

There haven't been any I2C driver that use the legacy suspend/resume
callbacks for a while now and new drivers are supposed to use PM ops. So
remove support for legacy suspend/resume for I2C drivers.

Since there aren't any special bus specific things to do during
suspend/resume and since the PM core will automatically fallback directly to
using the device's PM ops if no bus PM ops are specified there is no need to
have any I2C bus PM ops.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Finally(!), make Linux support being an I2C slave. Most of the existing
infrastructure is reused. We mainly add i2c_slave_register/unregister()
calls which tells i2c bus drivers to activate the slave mode. Then, they
also get a callback to report slave events to.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

CONFIG_OF_DYNAMIC enables runtime changes to the device tree which in
turn may trigger addition or removal of devices from Linux. Add an
OF_RECONFIG notifier handler to receive tree change events and to
creating or destroy i2c devices as required.
Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
[grant.likely: clean up #ifdefs and drop unneeded error handling]
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Reviewed-by: NWolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-i2c@vger.kernel.org

Dynamically inserting i2c client device nodes requires the use
of a single device registration method. Factor out the loop body of
of_i2c_register_devices() so that it can be called for individual
device_nodes instead of for all the children of a node.

Note: The diff of this commit looks far more complicated than it
actually is due the indentation being changed for a large block of code.
When viewed using the diff -w flag to ignore whitespace changes it can
be seen that the change is actually quite simple.
Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
[grant.likely: Made new function static and removed changes to header]
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Reviewed-by: NWolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-i2c@vger.kernel.org

ACPI 5.0 introduces _DEP (Operation Region Dependencies) to designate
device objects that OSPM should assign a higher priority in start
ordering due to future operation region accesses.

On Asus T100TA, ACPI battery info are read from a I2C slave device via
I2C operation region. Before I2C operation region handler is installed,
battery _STA always returns 0. There is a _DEP method of designating
start order under battery device node.

This patch is to implement _DEP feature to fix battery issue on the
Asus T100TA.  Introducing acpi_dep_list and adding dep_unmet count
in struct acpi_device. During ACPI namespace scan, create struct
acpi_dep_data for a valid pair of master (device pointed to by _DEP)/
slave(device with _DEP), record master's and slave's ACPI handle in
it and put it into acpi_dep_list. The dep_unmet count will increase
by one if there is a device under its _DEP. Driver's probe() should
return EPROBE_DEFER when find dep_unmet is larger than 0. When I2C
operation region handler is installed, remove all struct acpi_dep_data
on the acpi_dep_list whose master is pointed to I2C host controller
and decrease slave's dep_unmet. When dep_unmet decreases to 0, all
_DEP conditions are met and then do acpi_bus_attach() for the device
in order to resolve battery _STA issue on the Asus T100TA.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=69011Tested-by: NJan-Michael Brummer <jan.brummer@tabos.org>
Tested-by: NAdam Williamson <adamw@happyassassin.net>
Tested-by: NMichael Shigorin <shigorin@gmail.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

No need to initialize 'ret' if it gets assigned directly after that.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Since commit 2fd36c55 ("i2c: core: Map OF IRQ at probe time"),
i2c slaves without interrupts (e.g. da9210 and at24 on r8a7791/koelsch)
fail to probe:

    at24: probe of 2-0050 failed with error -22

    da9210: probe of 6-0068 failed with error -22

This happens because the call to of_irq_get() in i2c_device_probe()
returns -EINVAL.

If a device node does not have an "interrupts" property,
of_irq_parse_one() fails. Unlike irq_of_parse_and_map(), of_irq_get()
does not ignore errors from of_irq_parse_one(), but forwards them.

Make i2c_device_probe() ignore all errors but -EPROBE_DEFER to fix this,
just like platform_get_irq() and platform_get_irq_byname() already do.

Fixes: 2fd36c55 ("i2c: core: Map OF IRQ at probe time")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

I2C clients instantiated from OF get their IRQ mapped at device
registration time. This leads to the IRQ being silently ignored if the
related irqchip hasn't been proved yet.

Fix this by moving IRQ mapping at probe time using of_get_irq(). The
function operates as irq_of_parse_and_map() but additionally returns
-EPROBE_DEFER if the irqchip isn't available, allowing us to defer I2C
client probing.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Clients instantiated from OF get an IRQ mapping created at device
registration time. Dispose the mapping when the client is removed.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

We have a central copy of the GPL for that. Some addresses were already
outdated.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>

The commit 46420dd7 (PM / Domains: Add APIs to attach/detach a PM
domain for a device) started using errno values in pm.h header file.
It also failed to include the header for these, thus it caused
compiler errors.

Instead of including the errno header to pm.h, let's move the functions
to pm_domain.h, since it's a better match.

Fixes: 46420dd7 (PM / Domains: Add APIs to attach/detach a PM domain for a device)
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If adapter->dev.parent == NULL there is a NULL pointer dereference in
acpi_i2c_install_space_handler and acpi_i2c_remove_space_handler.

This is present since introduction of this code:
36604751 "i2c: rework kernel config I2C_ACPI" or even
da3c6647 "I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI"

The adapter->dev.parent == NULL case is valid for the i2c_stub,
so loading i2c_stub with ACPI_I2C_OPREGION enabled results in an oops.
This is also valid at least for i2c_tiny_usb and i2c_robotfuzz_osif.

Fix by checking whether it is null before calling ACPI_HANDLE.
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Commit 5d98e61d ("I2C/ACPI: Add i2c ACPI operation region support")
renamed the i2c-core module. This may cause regressions for
distributions, so put the ACPI code back into the core.
Reported-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Tested-by: NLan Tianyu <tianyu.lan@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Previously only the ACPI PM domain was supported by the i2c bus.

Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch adds helper functions to configure clock parents and rates
as specified through 'assigned-clock-parents', 'assigned-clock-rates'
DT properties for a clock provider or clock consumer device.
The helpers are now being called by the bus code for the platform, I2C
and SPI busses, before the driver probing and also in the clock core
after registration of a clock provider.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

We have a warning already when support for old-fashioned class based
instantiation is about to be dropped somewhen soon from a driver. Let's
have another one when it was actually dropped. This allows to remove the
cruft a little earlier and still let users know what happened in the
rare case they are missing devices after the change. However, there is
enough interest to get rid of class based instantiation rather sooner
than later because it improves boot up time.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Clean up ACPI related code in the i2c core and add CONFIG_I2C_ACPI
to enable I2C ACPI code.

Current there is a race between removing I2C ACPI operation region
and ACPI AML code accessing. So make i2c core built-in if CONFIG_I2C_ACPI
is set.
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation region.
It allows ACPI aml code able to access such kind of devices to implement
some ACPI standard method.

ACPI Spec defines some access attribute to associate with i2c protocol.
AttribQuick 	       	       		Read/Write Quick Protocol
AttribSendReceive			Send/Receive Byte Protocol
AttribByte 			 	Read/Write Byte Protocol
AttribWord				Read/Write Word Protocol
AttribBlock				Read/Write Block Protocol
AttribBytes				Read/Write N-Bytes Protocol
AttribProcessCall			Process Call Protocol
AttribBlockProcessCall			Write Block-Read Block Process Call Protocol
AttribRawBytes 				Raw Read/Write N-BytesProtocol
AttribRawProcessBytes			Raw Process Call Protocol

On the Asus T100TA, Bios use GenericSerialBus operation region to access
i2c device to get battery info.

Sample code From Asus T100TA

    Scope (_SB.I2C1)
    {
        Name (UMPC, ResourceTemplate ()
        {
            I2cSerialBus (0x0066, ControllerInitiated, 0x00061A80,
                AddressingMode7Bit, "\\_SB.I2C1",
                0x00, ResourceConsumer, ,
                )
        })

	...

        OperationRegion (DVUM, GenericSerialBus, Zero, 0x0100)
        Field (DVUM, BufferAcc, NoLock, Preserve)
        {
            Connection (UMPC),
            Offset (0x81),
            AccessAs (BufferAcc, AttribBytes (0x3E)),
            FGC0,   8
        }
	...
     }

     Device (BATC)
     {
         Name (_HID, EisaId ("PNP0C0A"))  // _HID: Hardware ID
         Name (_UID, One)  // _UID: Unique ID
	 ...

            Method (_BST, 0, NotSerialized)  // _BST: Battery Status
            {
                If (LEqual (AVBL, One))
                {
                    Store (FGC0, BFFG)
                    If (LNotEqual (STAT, One))
                    {
                        ShiftRight (CHST, 0x04, Local0)
                        And (Local0, 0x03, Local0)
                        If (LOr (LEqual (Local0, One), LEqual (Local0, 0x02)))
                        {
                            Store (0x02, Local1)
                        }
	...

    }

The i2c operation region is defined under I2C1 scope. _BST method under
battery device BATC read battery status from the field "FCG0". The request
would be sent to i2c operation region handler.

This patch is to add i2c ACPI operation region support. Due to there are
only "Byte" and "Bytes" protocol access on the Asus T100TA, other protocols
have not been tested.

About RawBytes and RawProcessBytes protocol, they needs specific drivers to interpret
reference data from AML code according ACPI 5.0 SPEC(5.5.2.4.5.3.9 and 5.5.2.4.5.3.10).
So far, not found such case and will add when find real case.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The SMBUS tracepoints can be enabled thusly:

	echo 1 >/sys/kernel/debug/tracing/events/i2c/enable

and will dump messages that can be viewed in /sys/kernel/debug/tracing/trace
that look like:

         ... smbus_read: i2c-0 a=051 f=0000 c=fa BYTE_DATA
         ... smbus_reply: i2c-0 a=051 f=0000 c=fa BYTE_DATA l=1 [39]
         ... smbus_result: i2c-0 a=051 f=0000 c=fa BYTE_DATA rd res=0

formatted as:

	i2c-<adapter-nr>
	a=<addr>
	f=<flags>
	c=<command>
	<protocol-name>
	<rd|wr>
	res=<result>
	l=<data-len>
	[<data-block>]

The adapters to be traced can be selected by something like:

	echo adapter_nr==1 >/sys/kernel/debug/tracing/events/i2c/filter

Note that this shares the same filter and enablement as i2c.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add tracepoints into the I2C message transfer function to retrieve the message
sent or received.  The following config options must be turned on to make use
of the facility:

	CONFIG_FTRACE
	CONFIG_ENABLE_DEFAULT_TRACERS

The I2C tracepoint can be enabled thusly:

	echo 1 >/sys/kernel/debug/tracing/events/i2c/enable

and will dump messages that can be viewed in /sys/kernel/debug/tracing/trace
that look like:

	... i2c_write: i2c-5 #0 a=044 f=0000 l=2 [02-14]
	... i2c_read: i2c-5 #1 a=044 f=0001 l=4
	... i2c_reply: i2c-5 #1 a=044 f=0001 l=4 [33-00-00-00]
	... i2c_result: i2c-5 n=2 ret=2

formatted as:

	i2c-<adapter-nr>
	#<message-array-index>
	a=<addr>
	f=<flags>
	l=<datalen>
	n=<message-array-size>
	ret=<result>
	[<data>]

The operation is done between the i2c_write/i2c_read lines and the i2c_reply
and i2c_result lines so that if the hardware hangs, the trace buffer can be
consulted to determine the problematic operation.

The adapters to be traced can be selected by something like:

	echo adapter_nr==1 >/sys/kernel/debug/tracing/events/i2c/filter

These changes are based on code from Steven Rostedt.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
[wsa: adapted path for 'enable' in the commit msg]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Class based instantiation can cause noticeable delays when booting. This
mechanism is used when it is not possible to describe slaves on I2C
busses. As we do have other mechanisms, most embedded I2C will not need
classes and for embedded it is explicitly not recommended to use them. Add
a deprecation warning for drivers which want to disable class based
instantiation in the near future to gain boot-up time, so users relying
on this technique can switch to something better. They really should.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Signed-off-by: NJean Delvare <khali@linux-fr.org>

Commit 0998d063 (device-core: Ensure drvdata = NULL when no driver
is bound) modified the driver core to always clear .driver and .drvdata
on remove or probe error. No need for the I2C core to do it.
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

ACPI enumerated devices has ACPI style _HID and _CID strings,
all of these strings can be used for both driver loading and matching.

Currently, in Platform, I2C and SPI bus, the ACPI style driver matching
is supported by invoking acpi_driver_match_device() in bus .match() callback.
But, the module autoloading is still broken.

For example, there is any ACPI device with _HID "INTABCD" that is
enumerated to platform bus, and we have a driver that can probe it.

The driver exports its module_alias as "acpi:INTABCD" use the following code
static const struct acpi_device_id xxx_acpi_match[] = {
        { "INTABCD", 0 },
        { }
};
MODULE_DEVICE_TABLE(acpi, xxx_acpi_match);

But, unfortunately, the device' modalias is shown as "platform:INTABCD:00",
please refer to modalias_show() and platform_uevent() in
drivers/base/platform.c.
This results in that the driver will not be loaded automatically when the
device node is created, because their modalias do not match.

This also applies to I2C and SPI bus.

With this patch, the device' modalias will be shown as "acpi:INTABCD" as well.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NMark Brown <broonie@linaro.org>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Current I2C adapter id - client address "x-00yy" based device naming scheme
is not always stable enough to be used in name based matching, for instance
within ALSA SoC subsystem.

This is problematic in PC kind of platforms where I2C adapter numbers can
change due variable amount of bus controllers, probe order, add-on cards or
just because of BIOS settings.

This patch addresses the problem by using the ACPI device name with
"i2c-" prefix for ACPI enumerated I2C slaves. For them device name
"x-00yz" becomes "i2c-INTABCD:ij" after this patch.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it.  Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead.  For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.

The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles).  However, there are more reasons
why it may be useful.

First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros.  Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part

If the I2C client device is enumerated from ACPI namespace it might have
ACPI methods that needs to be called in order to transition the device to
different power states (such as _PSx).

Implement this for I2C client devices by checking if the device has an ACPI
handle and if that's the case, attach it to the ACPI power domain. In
addition we make sure that the device is fully powered when its ->probe()
function gets called.

For non-ACPI devices this patch is a no-op.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>