[PATCH 6/9] i2c: Export i2c_match_id() for direct use by device drivers

When there was no other way to match a I2C device to driver i2c_match_id() was exclusively used. However, now there are other types of tables which are commonly supplied, matching on an i2c_device_id table is used less frequently. Instead of _always_ calling i2c_match_id() from within the

[PATCH 4/9] i2c: Match using traditional OF methods, then by vendor-less compatible strings

This function provides a single call for all I2C devices which need to match firstly using traditional OF means i.e by of_node, then if that fails we attempt to match using the supplied I2C client name with a list of supplied compatible strings with the 'vendor,' string removed. The latter is

[PATCH 9/9] mfd: as3722: Rid driver of superfluous I2C device ID structure

Also remove unused second probe() parameter 'i2c_device_id'. Acked-by: Grant Likely grant.lik...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org --- drivers/mfd/as3722.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/drivers/mfd/as3722.c

[PATCH 8/9] mfd: 88pm860x: Move over to new I2C device .probe() call

As part of an effort to rid the mostly unused second parameter for I2C related .probe() functions and to conform to other existing frameworks we're moving over to a temporary replacement .probe() call-back. Acked-by: Grant Likely grant.lik...@linaro.org Signed-off-by: Lee Jones

[PATCH 7/9] i2c: Provide a temporary .probe2() call-back type

This will aid the seamless removal of the current probe()'s, more commonly unused than used second parameter. Most I2C drivers can simply switch over to the new interface, others which have DT support can use its own matching instead and others can call i2c_match_id() themselves. This brings

[PATCH 5/9] i2c: Make I2C ID tables non-mandatory for DT'ed devices

Currently the I2C framework insists on devices supplying an I2C ID table. Many of the devices which do so unnecessarily adding quite a few wasted lines to kernel code. This patch allows drivers a means to 'not' supply the aforementioned table and match on DT match tables instead. Acked-by:

[PATCH 2/9] i2c: Add pointer dereference protection to i2c_match_id()

Here we're providing dereference protection for i2c_match_id(), which saves us having to do it each time it's called. We're also stripping out the (now) needless checks in i2c_device_match(). This patch paves the way for other, similar code trimming. Acked-by: Grant Likely

[PATCH v3 0/7] i2c: Relax mandatory I2C ID table passing

Hi Wolfram, As previously discussed I believe it should be okay for an I2C device driver _not_ supply an I2C ID table to match to. The I2C subsystem should be able to match via other means, such as via OF tables. The blocking factor during our previous conversation was to keep registering via

[PATCH 1/9] ARM: multi_v7_defconfig: Enable ST's I2C driver

Signed-off-by: Lee Jones lee.jo...@linaro.org --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 91af0a9..57335e1 100644 --- a/arch/arm/configs/multi_v7_defconfig +++

[PATCH] gpio: crystalcove: Fix implicit declaration of function 'seq_printf' error

drivers/gpio/gpio-crystalcove.c: In function 'crystalcove_gpio_dbg_show': drivers/gpio/gpio-crystalcove.c:286:3: error: implicit declaration of function 'seq_printf' seq_printf(s, gpio-%-2d %s %s %s %s ctlo=%2x,%s %s %s\n, Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by:

[PATCH 3/9] i2c: Add the ability to match device to compatible string without an of_node

A great deal of I2C devices are currently matched via DT node name, and as such the compatible naming convention of 'vendor,device' has gone somewhat awry - some nodes don't supply one, some supply an arbitrary string and others the correct device name with an arbitrary vendor prefix. In an

Driver-Support of I2C_M_RECV_LEN

Hello, in the documentation i found at http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/DocBook/kernel-api/re1222.html the following sentence: Note that using this function requires that the client's adapter support the I2C_FUNC_SMBUS_READ_BLOCK_DATA functionality. Not all adapter drivers

Re: [PATCH] i2c: exynos5: Properly use the noirq variants of suspend/resume

Hi Doug, Doug Anderson diand...@chromium.org writes: On Thu, Jun 19, 2014 at 11:43 AM, Kevin Hilman khil...@linaro.org wrote: Doug Anderson diand...@chromium.org writes: The original code for the exynos i2c controller registered for the noirq variants. However during review feedback it was

Re: [PATCH] i2c: exynos5: Properly use the noirq variants of suspend/resume

Kevin, On Fri, Jun 20, 2014 at 2:48 PM, Kevin Hilman khil...@linaro.org wrote: Hi Doug, Doug Anderson diand...@chromium.org writes: On Thu, Jun 19, 2014 at 11:43 AM, Kevin Hilman khil...@linaro.org wrote: Doug Anderson diand...@chromium.org writes: The original code for the exynos i2c

Re: [PATCH] i2c: exynos5: Properly use the noirq variants of suspend/resume

Doug Anderson diand...@chromium.org writes: Kevin, On Fri, Jun 20, 2014 at 2:48 PM, Kevin Hilman khil...@linaro.org wrote: Hi Doug, Doug Anderson diand...@chromium.org writes: On Thu, Jun 19, 2014 at 11:43 AM, Kevin Hilman khil...@linaro.org wrote: Doug Anderson diand...@chromium.org

Re: [PATCH] i2c: exynos5: Properly use the noirq variants of suspend/resume

Kevin, On Fri, Jun 20, 2014 at 4:13 PM, Kevin Hilman khil...@linaro.org wrote: Doug Anderson diand...@chromium.org writes: Kevin, On Fri, Jun 20, 2014 at 2:48 PM, Kevin Hilman khil...@linaro.org wrote: Hi Doug, Doug Anderson diand...@chromium.org writes: On Thu, Jun 19, 2014 at 11:43

Re: [PATCH] i2c: exynos5: Properly use the noirq variants of suspend/resume

On 21.06.2014 01:53, Doug Anderson wrote: Kevin, On Fri, Jun 20, 2014 at 4:13 PM, Kevin Hilman khil...@linaro.org wrote: Doug Anderson diand...@chromium.org writes: Kevin, On Fri, Jun 20, 2014 at 2:48 PM, Kevin Hilman khil...@linaro.org wrote: Hi Doug, Doug Anderson