summaryrefslogtreecommitdiff
path: root/drivers/i2c/i2c-smbus.c
AgeCommit message (Collapse)Author
2017-10-28i2c: i2c-smbus: add of_i2c_setup_smbus_alertPhil Reid
This commit adds of_i2c_setup_smbus_alert which allows the smbalert driver to be attached to an i2c adapter via the device tree. Signed-off-by: Phil Reid <preid@electromag.com.au> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2017-10-28i2c: i2c-smbus: Move i2c_setup_smbus_alert from i2c-smbus to i2c-core-smbusPhil Reid
In preparation to adding of_i2c_setup_smbus_alert() move i2c_setup_smbus_alert() to core module. of_i2c_setup_smbus_alert() will call i2c_setup_smbus_alert() and this avoid module dependecy issues. Signed-off-by: Phil Reid <preid@electromag.com.au> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2017-10-28i2c: i2c-smbus: Use threaded irq for smbalertPhil Reid
Prior to this commit the smbalert_irq was handling in the hard irq context. This change switch to using a thread irq which avoids the need for the work thread. Using threaded irq also removes the need for the edge_triggered flag as the enabling / disabling of the hard irq for level triggered interrupts will be handled by the irq core. Without this change have an irq connected to something like an i2c gpio resulted in a null ptr deferences. Specifically handle_nested_irq calls the threaded irq handler. There are currently 3 in tree drivers affected by this change. i2c-parport driver calls i2c_handle_smbus_alert in a hard irq context. This driver use edge trigger interrupts which skip the enable / disable calls. But it still need to handle the smbus transaction on a thread. So the work thread is kept for this driver. i2c-parport-light & i2c-thunderx-pcidrv provide the irq number in the setup which will result in the thread irq being used. i2c-parport-light is edge trigger so the enable / disable call was skipped as well. i2c-thunderx-pcidrv is getting the edge / level trigger setting from of data and was setting the flag as required. However the irq core should handle this automatically. Signed-off-by: Phil Reid <preid@electromag.com.au> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-11-24i2c: use an IRQ to report Host Notify events, not alertBenjamin Tissoires
The current SMBus Host Notify implementation relies on .alert() to relay its notifications. However, the use cases where SMBus Host Notify is needed currently is to signal data ready on touchpads. This is closer to an IRQ than a custom API through .alert(). Given that the 2 touchpad manufacturers (Synaptics and Elan) that use SMBus Host Notify don't put any data in the SMBus payload, the concept actually matches one to one. Benefits are multiple: - simpler code and API: the client will just have an IRQ, and nothing needs to be added in the adapter beside internally enabling it. - no more specific workqueue, the threading is handled by IRQ core directly (when required) - no more races when removing the device (the drivers are already required to disable irq on remove) - simpler handling for drivers: use plain regular IRQs - no more dependency on i2c-smbus for i2c-i801 (and any other adapter) - the IRQ domain is created automatically when the adapter exports the Host Notify capability - the IRQ are assign only if ACPI, OF and the caller did not assign one already - the domain is automatically destroyed on remove - fewer lines of code (minus 20, yeah!) Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-07-18i2c: i2c-smbus: fix i2c_handle_smbus_host_notify documentationJean Delvare
The parameter description is from a previous implementation, update it to describe the actual implementation. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-06-17i2c: smbus: add SMBus Host Notify supportBenjamin Tissoires
SMBus Host Notify allows a slave device to act as a master on a bus to notify the host of an interrupt. On Intel chipsets, the functionality is directly implemented in the firmware. We just need to export a function to call .alert() on the proper device driver. i2c_handle_smbus_host_notify() behaves like i2c_handle_smbus_alert(). When called, it schedules a task that will be able to sleep to go through the list of devices attached to the adapter. The current implementation allows one Host Notification to be scheduled while an other is running. Tested-by: Andrew Duggan <aduggan@synaptics.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-06-17i2c: add a protocol parameter to the alert callbackBenjamin Tissoires
.alert() is meant to be generic, but there is currently no way for the device driver to know which protocol generated the alert. Add a parameter in .alert() to help the device driver to understand what is given in data. This patch is required to have the support of SMBus Host Notify protocol through .alert(). Tested-by: Andrew Duggan <aduggan@synaptics.com> For hwmon: Acked-by: Guenter Roeck <linux@roeck-us.net> For IPMI: Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-02-20i2c: i2c-smbus: sort includesWolfram Sang
I request this for drivers, so the core should adhere to sorted includes as well. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2015-06-01i2c: smbus: fix typo in commetShailendra Verma
Signed-off-by: Shailendra Verma <shailendra.capricorn@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-11-07i2c: remove FSF addressWolfram Sang
We have a central copy of the GPL for that. Some addresses were already outdated. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2014-01-29Update Jean Delvare's e-mail addressJean Delvare
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2013-10-03i2c: Remove redundant 'driver' field from the i2c_client structLars-Peter Clausen
The 'driver' field of the i2c_client struct is redundant. The same data can be accessed through to_i2c_driver(client->dev.driver). The generated code for both approaches in more or less the same. E.g. on ARM the expression client->driver->command(...) generates ... ldr r3, [r0, #28] ldr r3, [r3, #32] blx r3 ... and the expression to_i2c_driver(client->dev.driver)->command(...) generates ... ldr r3, [r0, #160] ldr r3, [r3, #-4] blx r3 ... Other architectures will generate similar code. All users of the 'driver' field outside of the I2C core have already been converted. So this only leaves the core itself. This patch converts the remaining few users in the I2C core and then removes the 'driver' field from the i2c_client struct. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-08-19i2c: use dev_get_platdata()Jingoo Han
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2012-10-05i2c-smbus: Convert kzalloc to devm_kzallocJulia Lawall
Converting kzalloc to devm_kzalloc simplifies the code and ensures that the result, alert, is freed after the irq allocated by the subsequent devm_request_irq. This in turn ensures that when an interrupt can be triggered, the alert structure is still available. The problem of a free after a devm_request_irq was found using the following semantic match (http://coccinelle.lip6.fr/) // <smpl> @r exists@ expression e1,e2,x,a,b,c,d; identifier free; position p1,p2; @@ devm_request_irq@p1(e1,e2,...,x) ... when any when != e2 = a when != x = b if (...) { ... when != e2 = c when != x = d free@p2(...,x,...); ... return ...; } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2012-07-24i2c-smbus: Use module_i2c_driver()Fabio Estevam
Using module_i2c_driver() makes the code smaller and cleaner. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2012-03-26i2c: Update the FSF addressJean Delvare
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-06-03i2c: Remove all i2c_set_clientdata(client, NULL) in driversWolfram Sang
I2C drivers can use the clientdata-pointer to point to private data. As I2C devices are not really unregistered, but merely detached from their driver, it used to be the drivers obligation to clear this pointer during remove() or a failed probe(). As a couple of drivers forgot to do this, it was agreed that it was cleaner if the i2c-core does this clearance when appropriate, as there is no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. This feature was added to the core with commit e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. As there is no need anymore to clear the clientdata-pointer, remove all current occurrences in the drivers to simplify the code and prevent confusion. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Richard Purdie <rpurdie@linux.intel.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo
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: 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>
2010-03-13i2c-smbus: Use device_lock/device_unlockStephen Rothwell
Use the new device locking/unlocking API. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-03-02i2c: Add SMBus alert supportJean Delvare
SMBus alert support. The SMBus alert protocol allows several SMBus slave devices to share a single interrupt pin on the SMBus master, while still allowing the master to know which slave triggered the interrupt. This is based on preliminary work by David Brownell. The key difference between David's implementation and mine is that his was part of i2c-core, while mine is split into a separate, standalone module named i2c-smbus. The i2c-smbus module is meant to include support for all SMBus extensions to the I2C protocol in the future. The benefit of this approach is a zero cost for I2C bus segments which do not need SMBus alert support. Where David's implementation increased the size of struct i2c_adapter by 7% (40 bytes on i386), mine doesn't touch it. Where David's implementation added over 150 lines of code to i2c-core (+10%), mine doesn't touch it. The only change that touches all the users of the i2c subsystem is a new callback in struct i2c_driver (common to both implementations.) I seem to remember Trent was worried about the footprint of David'd implementation, hopefully mine addresses the issue. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Trent Piepho <tpiepho@freescale.com>