Re: [PATCH] [RFC] i2c: Don't wait for device release in i2c_del_adapter

On Wed, Jan 14, 2015 at 07:24:22PM +0200, Pantelis Antoniou wrote: I’ll try to dig around tomorrow and see what the real device reference counts are, but my hunch goes like this: MUX +—- ADAPTER +— DEV. Mux remove method is called, i2c_del_mux_adapter is called on all the channels

Re: [PATCH v3 2/3] i2c: iproc: Add Broadcom iProc I2C Driver

On 1/13/2015 11:51 PM, Uwe Kleine-König wrote: Hello, On Tue, Jan 13, 2015 at 06:14:17PM -0800, Ray Jui wrote: + irq = platform_get_irq(pdev, 0); + if (irq 0) { irq == 0 should be handled as error, too. Ah. I thought zero is a valid global interrupt number, and I see other drivers

[PATCH v4 1/3] i2c: iProc: define Broadcom iProc I2C binding

Document the I2C device tree binding for Broadcom iProc family of SoCs Signed-off-by: Ray Jui r...@broadcom.com Reviewed-by: Scott Branden sbran...@broadcom.com --- .../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 37 1 file changed, 37 insertions(+) create mode

[PATCH v4 3/3] ARM: dts: add I2C device nodes for Broadcom Cygnus

Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep them disabled there. Individual I2C devices can be enabled in board specific dts file when I2C slave devices are enabled in the future Signed-off-by: Ray Jui r...@broadcom.com Reviewed-by: Scott Branden sbran...@broadcom.com ---

[PATCH v4 2/3] i2c: iproc: Add Broadcom iProc I2C Driver

Add initial support to the Broadcom iProc I2C controller found in the iProc family of SoCs. The iProc I2C controller has separate internal TX and RX FIFOs, each has a size of 64 bytes. The iProc I2C controller supports two bus speeds including standard mode (100kHz) and fast mode (400kHz)

[PATCH v4 0/3] Add I2C support to Broadcom iProc

This patchset contains the initial I2C support for Broadcom iProc family of SoCs. The iProc I2C controller has separate internal TX and RX FIFOs, each has a size of 64 bytes. The iProc I2C controller supports two bus speeds including standard mode (100 kHz) and fast mode (400 kHz) Changes from

Re: [PATCH 3/3] i2c: imx: whitespace and checkpatch cleanup

Am Mittwoch, den 14.01.2015, 15:25 +0100 schrieb Wolfram Sang: On Tue, Jan 06, 2015 at 03:48:21PM +0100, Philipp Zabel wrote: This patch fixes up some whitespace issues and addresses a few checkpatch warnings. Well, since you asked for it... I am not so strict with the 80 char limit:

Re: [PATCH 2/3] i2c: imx: remove unused return value assignments

On Tue, Jan 06, 2015 at 03:48:20PM +0100, Philipp Zabel wrote: The ret variable is set and never used in the error path of i2c_imx_dma_request. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Applied to for-next, thanks! signature.asc Description: Digital signature

Re: [PATCH] [RFC] i2c: Don't wait for device release in i2c_del_adapter

On Wed, 14 Jan 2015 15:54:52 +0200, Pantelis Antoniou wrote: On Jan 14, 2015, at 15:49 , Jean Delvare jdelv...@suse.de wrote: That being said, nobody complained about this in 11 years, so I would be surprised if it was plain wrong. I'd rather question the test code. Where is it? No-one

Re: [PATCH 3/3] i2c: imx: whitespace and checkpatch cleanup

On Tue, Jan 06, 2015 at 03:48:21PM +0100, Philipp Zabel wrote: This patch fixes up some whitespace issues and addresses a few checkpatch warnings. Well, since you asked for it... I am not so strict with the 80 char limit: @@ -527,8 +528,10 @@ static int i2c_imx_start(struct imx_i2c_struct

Re: [PATCH] [RFC] i2c: Don't wait for device release in i2c_del_adapter

On Wed, Jan 14, 2015 at 04:18:56PM +0200, Pantelis Antoniou wrote: Hi Guenter, On Jan 14, 2015, at 16:14 , Guenter Roeck li...@roeck-us.net wrote: On 01/14/2015 05:54 AM, Pantelis Antoniou wrote: That being said, nobody complained about this in 11 years, so I would be surprised if

Re: [PATCH] [RFC] i2c: Don't wait for device release in i2c_del_adapter

Hi Jean, On Jan 14, 2015, at 19:14 , Jean Delvare jdelv...@suse.de wrote: Hi Guenter, On Wed, 14 Jan 2015 08:24:43 -0800, Guenter Roeck wrote: On Wed, Jan 14, 2015 at 04:15:25PM +0100, Jean Delvare wrote: I did that. On my system the i2c-i801 driver instantiates an i2c-mux-gpio device.

Re: [PATCH] [RFC] i2c: Don't wait for device release in i2c_del_adapter

Hi Guenter, On Wed, 14 Jan 2015 08:24:43 -0800, Guenter Roeck wrote: On Wed, Jan 14, 2015 at 04:15:25PM +0100, Jean Delvare wrote: I did that. On my system the i2c-i801 driver instantiates an i2c-mux-gpio device. Unloading the i2c-i801 driver removes that device and it works fine. Note

Re: [PATCH V3 1/2] i2c-designware: Add i2c bus locking support

Hi, Expect something tonight should the latest tests run okay. I needed to include an EPROBE_DEFER to address the unavailibity of the pci driver needed in order to request the lock during probe of the i2c device. This due to the lock now being requested during probe because of the hang. Dave On

Re: [PATCH v6] i2c: cadence: Check for errata condition involving master receive

On Wed, Jan 14, 2015 at 12:04:59AM +0530, Harini Katakam wrote: Cadence I2C controller has the following bugs: - completion indication is not given to the driver at the end of a read/receive transfer with HOLD bit set. - Invalid read transaction are generated on the bus when HW timeout

Re: [PATCH] i2c / ACPI: Pick the first address if device has multiple

On Mon, Dec 29, 2014 at 03:48:48PM +0200, Mika Westerberg wrote: 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

[PATCH] i2c-ocores: add common clock support

Allow bus clock specification as a common clock handle. This makes this controller easier to use in a setup based on common clock framework. Signed-off-by: Max Filippov jcmvb...@gmail.com --- .../devicetree/bindings/i2c/i2c-ocores.txt | 4 ++- drivers/i2c/busses/i2c-ocores.c

Re: [PATCH] [RFC] i2c: Don't wait for device release in i2c_del_adapter

Hi Wolfram, Pantelis, On Tue, 13 Jan 2015 16:29:57 +0100, Wolfram Sang wrote: On Mon, Jan 12, 2015 at 07:00:50PM +0200, Pantelis Antoniou wrote: Waiting for the device release method to be called when going through i2c_del_adapter is wrong and leads to deadlock when removing an i2c mux

Re: [PATCH] [RFC] i2c: Don't wait for device release in i2c_del_adapter

Am 14.01.2015 um 14:54 schrieb Pantelis Antoniou: Hi Jean, On Jan 14, 2015, at 15:49 , Jean Delvare jdelv...@suse.de wrote: ... That being said, nobody complained about this in 11 years, so I would be surprised if it was plain wrong. I'd rather question the test code. Where is it? No-one

Re: [PATCH] [RFC] i2c: Don't wait for device release in i2c_del_adapter

Hi Michael, On Jan 14, 2015, at 16:06 , Michael Lawnick ml.lawn...@gmx.de wrote: Am 14.01.2015 um 14:54 schrieb Pantelis Antoniou: Hi Jean, On Jan 14, 2015, at 15:49 , Jean Delvare jdelv...@suse.de wrote: ... That being said, nobody complained about this in 11 years, so I would be

Re: [PATCH 1/3] i2c: imx: silence dma_request_slave_channel errors if dma not set up in device tree

On Tue, Jan 06, 2015 at 03:48:19PM +0100, Philipp Zabel wrote: If the i2c device tree nodes don't contain the dmas and dma-names property, an error is displayed for each i2c device: of_dma_request_slave_channel: dma-names property of node '/soc/aips-bus@0210/i2c@021a' missing or

Re: [PATCH] [RFC] i2c: Don't wait for device release in i2c_del_adapter

On 01/14/2015 05:54 AM, Pantelis Antoniou wrote: That being said, nobody complained about this in 11 years, so I would be surprised if it was plain wrong. I'd rather question the test code. Where is it? No-one has apparently tested removing an i2c mux device on a running system before. Hi

Re: [PATCH] [RFC] i2c: Don't wait for device release in i2c_del_adapter

Hi Guenter, On Jan 14, 2015, at 16:14 , Guenter Roeck li...@roeck-us.net wrote: On 01/14/2015 05:54 AM, Pantelis Antoniou wrote: That being said, nobody complained about this in 11 years, so I would be surprised if it was plain wrong. I'd rather question the test code. Where is it?