- 14 7月, 2016 2 次提交
-
-
由 Wolfram Sang 提交于
Move recovery init to a seperate function to let have i2c_register_adapter() less lines and to avoid goto and a label. Refactor string handling there for consistency and to save some bytes. Signed-off-by: NWolfram Sang <wsa-dev@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
On error, we should give idr back to the pool in any case. Signed-off-by: NWolfram Sang <wsa-dev@sang-engineering.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 14 6月, 2016 1 次提交
-
-
由 Jean-Michel Hautbois 提交于
Some I2C devices have multiple addresses assigned, for example each address corresponding to a different internal register map page of the device. So far drivers which need support for this have handled this with a driver specific and non-generic implementation, e.g. passing the additional address via platform data. This patch provides a new helper function called i2c_new_secondary_device() which is intended to provide a generic way to get the secondary address as well as instantiate a struct i2c_client for the secondary address. The function expects a pointer to the primary i2c_client, a name for the secondary address and an optional default address. The name is used as a handle to specify which secondary address to get. The default address is used as a fallback in case no secondary address was explicitly specified. In case no secondary address and no default address were specified the function returns NULL. For now the function only supports look-up of the secondary address from devicetree, but it can be extended in the future to for example support board files and/or ACPI. Signed-off-by: NJean-Michel Hautbois <jean-michel.hautbois@veo-labs.com> Acked-by: NRob Herring <robh@kernel.org> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 13 5月, 2016 1 次提交
-
-
由 Wolfram Sang 提交于
A custom recovery function doesn't need these pointers to be populated because it may work differently internally. Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Tested-by: NPeter Griffin <peter.griffin@linaro.org>
-
- 05 5月, 2016 3 次提交
-
-
由 Peter Rosin 提交于
With a i2c topology like the following GPIO ---| ------ BAT1 | v / I2C -----+----------+---- MUX | \ EEPROM ------ BAT2 there is a locking problem with the GPIO controller since it is a client on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1) will lock the whole i2c bus prior to attempting to switch the mux to the correct i2c segment. In the above case, the GPIO device is an I/O expander with an i2c interface, and since the GPIO subsystem knows nothing (and rightfully so) about the lockless needs of the i2c mux code, this results in a deadlock when the GPIO driver issues i2c transfers to modify the mux. So, observing that while it is needed to have the i2c bus locked during the actual MUX update in order to avoid random garbage on the slave side, it is not strictly a must to have it locked over the whole sequence of a full select-transfer-deselect mux client operation. The mux itself needs to be locked, so transfers to clients behind the mux are serialized, and the mux needs to be stable during all i2c traffic (otherwise individual mux slave segments might see garbage, or worse). Introduce this new locking concept as "mux-locked" muxes, and call the pre-existing mux locking scheme "parent-locked". Modify the i2c mux locking so that muxes that are "mux-locked" locks only the muxes on the parent adapter instead of the whole i2c bus when there is a transfer to the slave side of the mux. This lock serializes transfers to the slave side of the muxes on the parent adapter. Add code to i2c-mux-gpio and i2c-mux-pinctrl that checks if all involved gpio/pinctrl devices have a parent that is an i2c adapter in the same adapter tree that is muxed, and request a "mux-locked mux" if that is the case. Modify the select-transfer-deselect code for "mux-locked" muxes so that each of the select-transfer-deselect ops locks the mux parent adapter individually. Signed-off-by: NPeter Rosin <peda@axentia.se> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Peter Rosin 提交于
Instead of checking for i2c parent adapters for every lock/unlock, simply override the locking for muxes to always lock/unlock the parent adapter directly. Signed-off-by: NPeter Rosin <peda@axentia.se> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Peter Rosin 提交于
Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and unlock_bus ops in the adapter. These funcs/ops take an additional flags argument that indicates for what purpose the adapter is locked. There are two flags, I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_SEGMENT, but they are both implemented the same. For now. Locking the root adapter means that the whole bus is locked, locking the segment means that only the current bus segment is locked (i.e. i2c traffic on the parent side of a mux is still allowed even if the child side of the mux is locked). Also support a trylock_bus op (but no function to call it, as it is not expected to be needed outside of the i2c core). Implement i2c_lock_adapter/i2c_unlock_adapter in terms of the new locking scheme (i.e. lock with the I2C_LOCK_ROOT_ADAPTER flag). Locking the root adapter and locking the segment is the same thing for all root adapters (e.g. in the normal case of a simple topology with no i2c muxes). The two locking variants are also the same for traditional muxes (aka parent-locked muxes). These muxes traverse the tree, locking each level as they go until they reach the root. This patch is preparatory for a later patch in the series introducing mux-locked muxes, which behave differently depending on the requested locking. Since all current users are using i2c_lock_adapter, which is a wrapper for I2C_LOCK_ROOT_ADAPTER, we only need to annotate the calls that will not need to lock the root adapter for mux-locked muxes. I.e. the instances that needs to use I2C_LOCK_SEGMENT instead of i2c_lock_adapter/I2C_LOCK_ROOT_ADAPTER. Those instances are in the i2c_transfer and i2c_smbus_xfer functions, so that mux-locked muxes can single out normal i2c accesses to its slave side and adjust the locking for those accesses. Signed-off-by: NPeter Rosin <peda@axentia.se> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 13 4月, 2016 1 次提交
-
-
由 Linus Walleij 提交于
When using a certain I2C device with runtime PM enabled on a certain I2C bus adaper the following happens: struct amba_device *foo \ struct i2c_adapter *bar \ struct i2c_client *baz The AMBA device foo has its device PM struct set to ignore children with pm_suspend_ignore_children(&foo->dev, true). This makes runtime PM work just fine locally in the driver: the fact that devices on the bus are suspended or resumed individually does not affect its operation, and the hardware does not power up unless transferring messages. However this child ignorance property is not inherited into the struct i2c_adapter *bar. On system suspend things will work fine. On system resume the following annoying phenomenon occurs: - In the pm_runtime_force_resume() path of struct i2c_client *baz, pm_runtime_set_active(&baz->dev); is eventually called. - This becomes __pm_runtime_set_status(&baz->dev, RPM_ACTIVE); - __pm_runtime_set_status() detects that RPM state is changed, and checks whether the parent is: not active (RPM_ACTIVE) and not ignoring its children If this happens it concludes something is wrong, because a parent that is not ignoring its children must be active before any children activate. - Since the struct i2c_adapter *bar does not ignore its children, the PM core thinks that it must indeed go online before its children, the check bails out with -EBUSY, i.e. the i2c_client *baz thinks it can't work because it's parent is not online, and it respects its parent. - In the driver the .resume() callback returns -EBUSY from the runtime_force_resume() call as per above. This leaves the device in a suspended state, leading to bad behaviour later when the device is used. The following debug print is made with an extra printg patch but illustrates the problem: [ 17.040832] bh1780 2-0029: parent (i2c-2) is not active parent->power.ignore_children = 0 [ 17.040832] bh1780 2-0029: pm_runtime_force_resume: pm_runtime_set_active() failed (-16) [ 17.040863] dpm_run_callback(): pm_runtime_force_resume+0x0/0x88 returns -16 [ 17.040863] PM: Device 2-0029 failed to resume: error -16 Fix this by letting all struct i2c_adapter:s ignore their children: i2c children have no business doing keeping their parents awake: they are completely autonomous devices that just use their parent to talk, a usecase which must be power managed in the host on a per-message basis. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 12 4月, 2016 1 次提交
-
-
由 Wolfram Sang 提交于
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 30 3月, 2016 1 次提交
-
-
由 Wolfram Sang 提交于
Jan reported this: === After enabling CONFIG_I2C_DEBUG_CORE my system was broken (no network, console login not possible). System log was flooded with the this message: ... [ 608.052077] rtc-ds1307 0-0068: uevent [ 608.052500] rtc-ds1307 0-0068: uevent [ 608.052925] rtc-ds1307 0-0068: uevent ... The culprit is the dev_dbg printk in the i2c uevent handler. If this is activated (for instance by CONFIG_I2C_DEBUG_CORE) it results in an endless loop with systemd-journald. This happens if user-space scans the system log and reads the uevent file to get information about a newly created device, which seems fair use to me. Unfortunately reading the "uevent" file uses the same function that runs for creating the uevent for a new device, generating the next syslog entry. Ideally user-space would implement a recursion detection and after reading the same device file for the 1000th time call it a day, but nevertheless I think we should avoid this problem by removing the debug print completely or using another print variant. The same problem seems to be reported here: https://bugs.freedesktop.org/show_bug.cgi?id=76886 === His patch converted the message to pr_debug, but I think the debug can simply go. We have other means to see code paths these days. This enables us to clean up the function some more while we are here. Reported-by: NJan Glauber <jglauber@cavium.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Acked-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com> Tested-by: NJan Glauber <jglauber@cavium.com>
-
- 15 3月, 2016 1 次提交
-
-
由 Wolfram Sang 提交于
Mark the i2c bus as registered right after the the bus_register call, not at the end of init. Otherwise, we can't register our own dummy driver. Reported-by: NThierry Reding <thierry.reding@gmail.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Fixes: 95026658 ("i2c: do not use internal data from driver core")
-
- 12 3月, 2016 1 次提交
-
-
由 Sudip Mukherjee 提交于
The variable p is a data structure which is used by the driver core internally and it is not expected that busses will be directly accessing these driver core internal only data. Signed-off-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> [wsa: removed the unlikely()] Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 21 2月, 2016 1 次提交
-
-
由 Wolfram Sang 提交于
I request this for drivers, so the core should adhere to sorted includes as well. Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 10 1月, 2016 1 次提交
-
-
由 Wolfram Sang 提交于
The adapter device is a logical device. Because of that, it already uses pm_runtime_no_callbacks() in the core. To ensure proper propagation from the children (i2c devices) to the parent of the adapter (the HW device), make sure RuntimePM is enabled in any case. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 18 12月, 2015 1 次提交
-
-
由 Wolfram Sang 提交于
This function used to be DT only, so it lived inside a CONFIG_OF block. Now it uses device attributes and must be moved outside of it. No further code changes, only one whitespace improvement. Reported-by: NJim Davis <jim.epost@gmail.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 14 12月, 2015 1 次提交
-
-
由 Wolfram Sang 提交于
Inspired from the i2c-rk3x driver (thanks guys!) but refactored and extended. See built-in docs for further information. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 20 11月, 2015 1 次提交
-
-
由 Grygorii Strashko 提交于
This patch fixes obvious copy-past error in wake up irq parsing code which leads to the fact that dev_pm_set_wake_irq() will be called with wrong IRQ number when "wakeup" IRQ is not defined in DT. Fixes: 3fffd128 ("i2c: allow specifying separate wakeup interrupt in device tree") Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com> Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: <stable@vger.kernel.org> # v4.3
-
- 25 10月, 2015 1 次提交
-
-
由 Dustin Byford 提交于
Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or device property compatible string match), enumerating I2C client devices connected through an I2C mux needs a little extra work. This change implements a method for describing an I2C device hierarchy that includes mux devices by using an ACPI Device() for each mux channel along with an _ADR to set the channel number for the device. See Documentation/acpi/i2c-muxes.txt for a simple example. To make this work the ismt, i801, and designware pci/platform devs now share an ACPI companion with their I2C adapter dev similar to how it's done in OF. This is done on the assumption that power management functions will not be called directly on the I2C dev that is sharing the ACPI node. Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NDustin Byford <dustin@cumulusnetworks.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 20 10月, 2015 1 次提交
-
-
由 Mika Westerberg 提交于
The way we currently scan I2C devices behind an I2C host controller does not work in cases where the I2C device in question is not declared directly below the host controller ACPI node. This is perfectly legal according the ACPI 6.0 specification and some existing systems are doing this. To be able to enumerate all devices which are connected to a certain I2C host controller we need to rework the current I2C scanning routine a bit. Instead of scanning directly below the host controller we scan the whole ACPI namespace for present devices with valid I2cSerialBus() connection pointing to the host controller in question. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: NDustin Byford <dustin@cumulusnetworks.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 15 10月, 2015 1 次提交
-
-
由 Kieran Bingham 提交于
A change of return status was introduced in commit 3fffd128 ("i2c: allow specifying separate wakeup interrupt in device tree") The commit prevents the defer status being passed up the call stack appropriately when dev_pm_domain_attach returns -EPROBE_DEFER. Catch the PROBE_DEFER and clear up the IRQ wakeup status Signed-off-by: NKieran Bingham <kieranbingham@gmail.com> Fixes: 3fffd128 ("i2c: allow specifying separate wakeup interrupt in device tree") Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 27 8月, 2015 1 次提交
-
-
由 Dmitry Torokhov 提交于
Instead of having each i2c driver individually parse device tree data in case it or platform supports separate wakeup interrupt, and handle enabling and disabling wakeup interrupts in their power management routines, let's have i2c core do that for us. Platforms wishing to specify separate wakeup interrupt for the device should use named interrupt syntax in their DTSes: interrupt-parent = <&intc1>; interrupts = <5 0>, <6 0>; interrupt-names = "irq", "wakeup"; This patch is inspired by work done by Vignesh R <vigneshr@ti.com> for pixcir_i2c_ts driver. Note that the original code tried to preserve any existing wakeup settings from userspace but was not quite right in that regard: it would preserve wakeup flag set by userspace upon driver rebinding; but it would re-arm the wakeup flag if it was disabled by userspace. We think that resetting the flag upon re-binding the driver is proper behavior as the driver is responsible for setting up and handling wakeups. Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: NVignesh R <vigneshr@ti.com> [wsa: updated the commit message] Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 24 8月, 2015 8 次提交
-
-
由 Irina Tirdea 提交于
There are devices that need to handle block transactions regardless of the capabilities exported by the adapter. For performance reasons, they need to use i2c read blocks if available, otherwise emulate the block transaction with word or byte transactions. Add support for a helper function that would read a data block using the best transfer available: I2C_FUNC_SMBUS_READ_I2C_BLOCK, I2C_FUNC_SMBUS_READ_WORD_DATA or I2C_FUNC_SMBUS_READ_BYTE_DATA. Signed-off-by: NIrina Tirdea <irina.tirdea@intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
Address collisions will be rare, but we should let the user know that slaves have their own address space nonetheless. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
We now have seperate address spaces for 10 bit and we-are-slave clients. Update the sysfs device instantiation method to support these types by accepting the address offsets that are assigned to the extra address spaces. Update the documentation, too. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
It is not enough to compare the plain address value, we also need to check the flags enabling a different address space. E.g. it is valid to have address 0x50 as a 7-bit address and 0x050 as 10-bit address on the same bus. Same for addresses when we are the slave. Tested-by: NAndrey Danin <danindrey@mail.ru> Acked-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
Check for slave and 10-bit flags when probing and mark the client when found. Improve the address validity check, too Tested-by: NAndrey Danin <danindrey@mail.ru> Acked-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
We want to use this function with struct boardinfo soon, so let's just pass the parameters really needed. We also extend the type of addr, so more types can be input. Remove a superfluous dangling comment while here. Tested-by: NAndrey Danin <danindrey@mail.ru> Acked-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
The current naming is based on the arguments of the functions and not on what they do. Even I as the maintainer find this confusing, so let's rename them to something more descriptive. Tested-by: NAndrey Danin <danindrey@mail.ru> Acked-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
We want a separate address range for being an I2C slave. Add an offset of 0x1000, so it can be combined with ten bit addresses as well. Add a separate function to create the address value, we will need it later in other places. Tested-by: NAndrey Danin <danindrey@mail.ru> Acked-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 10 8月, 2015 2 次提交
-
-
由 Vladimir Zapolskiy 提交于
of_find_i2c_adapter_by_node() call requires quite often missing put_device(), and i2c_put_adapter() releases a device locked by i2c_get_adapter() only. In general module_put(adapter->owner) and put_device(dev) are not interchangeable. This is a common error reproduction scenario as a result of the misusage described above (for clearness this is run on iMX6 platform with HDMI and I2C bus drivers compiled as kernel modules): root@mx6q:~# lsmod | grep i2c i2c_imx 10213 0 root@mx6q:~# lsmod | grep dw_hdmi_imx dw_hdmi_imx 3631 0 dw_hdmi 11846 1 dw_hdmi_imx imxdrm 8674 3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb drm_kms_helper 113765 5 dw_hdmi,imxdrm,imx_ipuv3_crtc,imx_ldb root@mx6q:~# rmmod dw_hdmi_imx root@mx6q:~# lsmod | grep i2c i2c_imx 10213 -1 ^^^^^ root@mx6q:~# rmmod i2c_imx rmmod: ERROR: Module i2c_imx is in use To fix existing users of these interfaces and to avoid any further confusion and misusage in future, add one more interface of_get_i2c_adapter_by_node(), it is similar to i2c_get_adapter() in sense that an I2C bus device driver found and locked by user can be correctly unlocked by i2c_put_adapter(). Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Vladimir Zapolskiy 提交于
In addition to module_get()/module_put() add get_device()/put_device() calls into i2c_get_adapter()/i2c_put_adapter() exported interfaces. This is done to lock I2C bus device, if it is in use by a client. Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 01 8月, 2015 1 次提交
-
-
由 Vladimir Zapolskiy 提交于
If of_find_i2c_device_by_node() or of_find_i2c_adapter_by_node() find a device by node, but its type does not match, a reference to that device is still held. This change fixes the problem. Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 31 7月, 2015 1 次提交
-
-
由 Jan Luebbe 提交于
Using set_scl may be ineffective before calling the driver specific prepare_recovery callback, which might change into a test mode. So instead of setting SCL in i2c_generic_scl_recovery, move it to i2c_generic_recovery (after the optional prepare_recovery). Signed-off-by: NJan Luebbe <jlu@pengutronix.de> Acked-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com> Tested-by: NAlexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 10 7月, 2015 1 次提交
-
-
由 Pantelis Antoniou 提交于
Mark (and unmark) device nodes with the POPULATE flag as appropriate. This is required to avoid multi probing when using I2C and device overlays containing a mux. This patch is also more careful with the release of the adapter device which caused a deadlock with muxes, and does not break the build on !OF since the node flag accessors are not defined then. Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 02 6月, 2015 1 次提交
-
-
由 Jarkko Nikula 提交于
sizeof(struct i2c_client) is 1088 bytes on a CONFIG_X86_64=y build and produces following warning when CONFIG_FRAME_WARN is set to 1024: drivers/i2c/i2c-core.c: In function ‘acpi_i2c_space_handler’: drivers/i2c/i2c-core.c:367:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=] This is not critical given that kernel stack is 16 kB on x86_64 but lets reduce the stack usage by allocating the struct i2c_client from the heap. Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 01 6月, 2015 3 次提交
-
-
由 Shailendra Verma 提交于
Signed-off-by: NShailendra Verma <shailendra.capricorn@gmail.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
int is vague, let's simply use the type of the variable in question. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
Inform users what went wrong from the core, so drivers don't have to do it. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 13 5月, 2015 2 次提交
-
-
由 Mika Westerberg 提交于
Following what DT already does. If the device does not have ACPI Interrupt resource but instead it has one or more GpioInt resources listed below it, we take the first GpioInt resource, convert it to suitable Linux IRQ number and pass it to the driver instead. This makes drivers simpler because the don't need to care about GPIOs at all if only thing they need is interrupt. 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>
-
由 Mika Westerberg 提交于
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>
-