Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

On 01/05/2016 07:57 AM, Peter Rosin wrote: From: Peter Rosin The initial core mux structure starts off small with only the parent adapter pointer, which all muxes have, and a priv pointer for mux driver private data. Add i2c_mux_alloc function to unify the creation of a mux.

Re: [PATCH 01/10] i2c-mux: add common core data for every mux instance

On 01/04/2016 07:10 AM, Peter Rosin wrote: From: Peter Rosin The initial core mux structure starts off small with only the parent adapter pointer, which all muxes have, and a priv pointer for mux driver private data. Add i2c_mux_alloc function to unify the creation of a mux.

Re: [PATCH V4 2/6] watchdog: Add support for Freescale Layerscape platforms

Hou Zhiqiang <b48...@freescale.com> --- This patch has been acked in V3 by Guenter Roeck [li...@roeck-us.net]. Here it is again, but if there is no change, please just add the Ack to subsequent versions of the patch. Acked-by: Guenter Roeck <li...@roeck-us.net> V4: V3 V2 -

Re: [PATCH V3 2/6] watchdog: Add support for Freescale Layerscape platforms

Hou Zhiqiang <b48...@freescale.com> Acked-by: Guenter Roeck <li...@roeck-us.net> --- V3: - No change. drivers/watchdog/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 79e1aa1..448dbaf 100644

Re: [PATCH] watchdog: iTCO_wdt: Fix unmet dependency in select

On 09/25/2015 07:02 AM, Jean Delvare wrote: Hi Guenter, Le Friday 25 September 2015 à 06:29 -0700, Guenter Roeck a écrit : On 09/25/2015 01:10 AM, Jean Delvare wrote: ITCO_WDT selects I2C_I801 but does not select its dependencies (I2C.) This can result in link-time failures: drivers/built

Re: [PATCH 2/6] watchdog: Add support for Freescale Layerscape platforms

On 09/21/2015 05:22 AM, Zhiqiang Hou wrote: From: Shaohui Xie <shaohui@freescale.com> Modify watchdog/Kconfig file to support Layerscape platforms. "Enable IMX2+ watchdog for Layerscape platforms" would be a better description. Nitpick, so Acked-by: Guenter Roeck <

Re: [RFC] i2c: Revert back to old device naming for ACPI enumerated I2C slaves

On 08/25/2015 09:18 AM, Wolfram Sang wrote: On Tue, Aug 25, 2015 at 08:18:30AM -0700, Guenter Roeck wrote: On 08/25/2015 07:57 AM, Wolfram Sang wrote: On Tue, Aug 25, 2015 at 06:25:13AM +0100, Mark Brown wrote: On Mon, Aug 24, 2015 at 01:52:02PM +0300, Jarkko Nikula wrote: Commit

Re: [RFC] i2c: Revert back to old device naming for ACPI enumerated I2C slaves

On 08/25/2015 07:57 AM, Wolfram Sang wrote: On Tue, Aug 25, 2015 at 06:25:13AM +0100, Mark Brown wrote: On Mon, Aug 24, 2015 at 01:52:02PM +0300, Jarkko Nikula wrote: Commit 70762abb9f89 (i2c: Use stable dev_name for ACPI enumerated I2C slaves) broke the lm-sensors which relies on I2C hwmon

Re: [PATCH 2/4] hwmon: max6697: move binding docs to proper place

On 08/08/2015 11:30 AM, Wolfram Sang wrote: The I2C dir is not for I2C client devices! Move it to the proper folder. Signed-off-by: Wolfram Sang w...@the-dreams.de Cc: Guenter Roeck li...@roeck-us.net Acked-by: Guenter Roeck li...@roeck-us.net -- To unsubscribe from this list: send the line

Re: [PATCH 3/4] hwmon: ina2xx: move binding docs to proper place

On 08/08/2015 11:30 AM, Wolfram Sang wrote: The I2C dir is not for I2C client devices! Move it to the proper folder. Signed-off-by: Wolfram Sang w...@the-dreams.de Cc: Guenter Roeck li...@roeck-us.net Acked-by: Guenter Roeck li...@roeck-us.net -- To unsubscribe from this list: send the line

Re: [PATCH 4/4] hwmon: ina209: move binding docs to proper place

On 08/08/2015 11:30 AM, Wolfram Sang wrote: The I2C dir is not for I2C client devices! Move it to the proper folder. Signed-off-by: Wolfram Sang w...@the-dreams.de Cc: Guenter Roeck li...@roeck-us.net Acked-by: Guenter Roeck li...@roeck-us.net -- To unsubscribe from this list: send the line

Re: [PATCH v4 2/3] i2c: i801: Create iTCO device on newer Intel PCHs

: linux-i2c@vger.kernel.org Reviewed-by: Guenter Roeck li...@roeck-us.net Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com Signed-off-by: Matt Fleming matt.flem...@intel.com Dunno which tree this should go through (probably MFD or watchdog), but doesn't look like I2C, so: Probably

Re: [PATCH v2 2/3] i2c: i801: Create iTCO device on newer Intel PCHs

. In order to support the iTCO watchdog on newer PCHs we need to create the platform device here in the SMBus driver and pass all known resources using platform data. Cc: Jean Delvare jdelv...@suse.com Cc: Wolfram Sang w...@the-dreams.de Cc: linux-i2c@vger.kernel.org Cc: Guenter Roeck li...@roeck-us.net

Re: [PATCH 2/5] i2c: i801: Create iTCO device on newer Intel PCHs

On 07/27/2015 06:38 AM, Matt Fleming wrote: From: Mika Westerberg mika.westerb...@linux.intel.com Starting from Intel Sunrisepoint (Skylake PCH) the iTCO watchdog resources have been moved to reside under the i801 SMBus host controller whereas previously they were under the LPC device. In

Re: [PATCH v2] hwmon: ads7828: Add devicetree documentation

Acked-by: Guenter Roeck li...@roeck-us.net Subject tag should probably have been DT: i2c:, similar to other patches for the same file. Something like DT: i2c: Add ADS7828 and ADS7830 to list of trivial devices Guenter --- ChangeLog v1-v2: - Added a commit message. --- Documentation/devicetree

Re: [PATCH v2 1/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips

On Wed, Jun 17, 2015 at 03:18:42PM +0200, Wolfram Sang wrote: Having said that, I am still not convinced that the driver should be in the kernel to start with. Browsing through Intel's datasheets, the registers are supported in E5-2600 v1, v2, and v3. However, in v3 Intel added

Re: [PATCH 3/4] watchdog: Add Congatec CGEB watchdog driver

On 06/11/2015 01:48 PM, Christian Gmeiner wrote: From: Sascha Hauer s.ha...@pengutronix.de This driver provides support for the CGEB watchdog found on some Congatec x86 modules. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com Hi

Re: clock driver

On Wed, May 27, 2015 at 10:45:32AM -0700, York Sun wrote: On 05/27/2015 10:30 AM, Michael Turquette wrote: Quoting York Sun (2015-05-26 17:32:13) Michael, Can you give me some guidance here? On 05/26/2015 05:20 PM, York Sun wrote: On 05/26/2015 03:38 PM, Guenter Roeck

Re: clock driver

On Wed, May 27, 2015 at 11:24:50AM -0700, York Sun wrote: Someone suggested earlier that the clocks should be set from the PCIe driver. Question here is really if you need to control the clocks from user space. Even if you do, the driver for the chip _using_ the clocks would be

Re: clock driver

On Wed, May 27, 2015 at 09:46:02AM -0700, York Sun wrote: [ ... ] Sebastian, Thanks for the insight. Looks like I should give up upstreaming this driver. I will find other ways to make this driver available if anyone wants to use it. You might consider putting it on github. That is

Re: clock driver

On 05/27/2015 04:58 PM, andrey wrote: On Wed, 27 May 2015 16:08:12 -0700 Guenter Roeckli...@roeck-us.net wrote On 05/27/2015 12:44 PM, andrey wrote: Hello all, Let me add a comment on using sysfs to simplify user space access to the clock features as opposed to

Re: clock driver

On 05/27/2015 12:44 PM, andrey wrote: Hello all, Let me add a comment on using sysfs to simplify user space access to the clock features as opposed to controlling them from a driver that uses the clock chip driver. It is common to use such advanced clock chips with the FPGA devices (as me and

Re: clock driver

On Tue, May 26, 2015 at 12:12:11PM -0700, York Sun wrote: Linux experts, I have rewritten a driver for Silicon Labs SI5338 programmable clock chip. The original driver was written by Andrey (CC'ed), but was floatingn outside of the kernel. The driver was written to use sysfs as the

Re: I2C class bitmask

On Thu, May 21, 2015 at 02:07:31PM -0700, York Sun wrote: Lee, Is there any convention regarding I2C class bitmask? I see only three are defined for 3.12.19 and four for 4.0 I2C_CLASS_HWMON, I2C_CLASS_DDC, I2C_CLASS_SPD, I2C_CLASS_DEPRECATED I am working on a clock chip driver (SI5338)

[PATCH v2] i2c: jz4780: Fix build for m68k and sparc64

-by: Guenter Roeck li...@roeck-us.net --- v2: HAS_IOMEM dependency already existed Fixed include file order drivers/i2c/busses/i2c-jz4780.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/busses/i2c-jz4780.c b/drivers/i2c/busses/i2c-jz4780.c index ce1d69324169..19b2d689a5ef

[PATCH] i2c: jz4780: Fix build for m68k and sparc64

...@imgtec.com Signed-off-by: Guenter Roeck li...@roeck-us.net --- drivers/i2c/busses/Kconfig | 1 + drivers/i2c/busses/i2c-jz4780.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 2255af23b9c7..c78b6cbd1106 100644

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On 03/27/2015 01:09 AM, Wolfram Sang wrote: just to give you an update: I do have some code, but it is a bit messy, and it doesn't work well for ds2482 (the chip behind it still hangs up if I access it in parallel through i2c-dev). On top of that, it causes pretty significant slow-downs when

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On 03/27/2015 06:01 AM, Wolfram Sang wrote: On Fri, Mar 27, 2015 at 05:51:11AM -0700, Guenter Roeck wrote: On 03/27/2015 01:09 AM, Wolfram Sang wrote: just to give you an update: I do have some code, but it is a bit messy, and it doesn't work well for ds2482 (the chip behind it still hangs

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On 03/27/2015 08:27 AM, Wolfram Sang wrote: On Fri, Mar 27, 2015 at 06:14:28AM -0700, Guenter Roeck wrote: On 03/27/2015 06:01 AM, Wolfram Sang wrote: On Fri, Mar 27, 2015 at 05:51:11AM -0700, Guenter Roeck wrote: On 03/27/2015 01:09 AM, Wolfram Sang wrote: just to give you an update: I do

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On 03/19/2015 02:39 PM, Wolfram Sang wrote: Turns out this is really easy to reproduce. One process reads the eeprom over and over again, another runs i2cdump in a loop, and voila ... lots of corruptions. Scary, especially considering how wide-spread this kind of i2c access is in the kernel.

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On Wed, Mar 25, 2015 at 05:15:04PM +0100, Wolfram Sang wrote: Guenter, thanks for the update Ultimately, the real problem is how i2c-dev accesses a client, not how i2c client drivers (who assume they have exclusive access to a chip) handle multi-command sequences. Forcing extensive

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On 03/19/2015 01:16 AM, Wolfram Sang wrote: I don't call that multi-master, though, so I guess we may have a bit of a terminology problem. This is definately not a multi-master issue, I agree. It is just another issue I saw when thinking about your patch thoroughly again. I'll see what I

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On Thu, Mar 19, 2015 at 09:16:21AM +0100, Wolfram Sang wrote: I don't call that multi-master, though, so I guess we may have a bit of a terminology problem. This is definately not a multi-master issue, I agree. It is just another issue I saw when thinking about your patch thoroughly

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On 03/18/2015 06:27 AM, Wolfram Sang wrote: On Mon, Mar 16, 2015 at 09:20:49PM -0700, Guenter Roeck wrote: On Mon, Feb 16, 2015 at 01:09:51PM +0100, Wolfram Sang wrote: Hi Guenter, I wonder where we are with thisp patch; I don't recall a reply to my previous e-mail. Sorry for the late

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On Mon, Feb 16, 2015 at 01:09:51PM +0100, Wolfram Sang wrote: Hi Guenter, I wonder where we are with thisp patch; I don't recall a reply to my previous e-mail. Sorry for the late reply. I needed to recover from a HDD headcrash :( Do you need some more time to think about it ?

Re: [PATCH v2 1/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips

On 03/09/2015 01:55 PM, Andy Lutomirski wrote: Sandy Bridge Xeon and Extreme chips have integrated memory controllers with (rather limited) onboard SMBUS masters. This driver gives access to the bus. There are various groups working on standardizing a way to arbitrate access to the bus between

Re: [PATCH 1/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips

On 03/08/2015 12:30 PM, Andy Lutomirski wrote: [ ... ] One other question: from my reading of the spec, it should be possible to augment this driver to expose a temporate sensor subdevice that shows recent cached temperatures from HW DIMM measurements. They would be redundant with the jc42

Re: [PATCH 1/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips

On 03/08/2015 07:03 AM, Andy Lutomirski wrote: On Mar 7, 2015 6:39 AM, Guenter Roeck li...@roeck-us.net wrote: On 03/06/2015 06:50 PM, Andy Lutomirski wrote: Sandy Bridge Xeon and Extreme chips have integrated memory controllers with (rather limited) onboard SMBUS masters. This driver gives

Re: [PATCH 2/2] i2c, i2c_imc: Add DIMM bus code

On 03/06/2015 06:50 PM, Andy Lutomirski wrote: Add i2c_scan_dimm_bus to declare that a particular i2c_adapter contains DIMMs. This will probe (and autoload modules!) for useful SMBUS devices that live on DIMMs. i2c_imc calls it. As more SMBUS-addressable DIMM components become supported, this

Re: [PATCH 1/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips

On 03/06/2015 06:50 PM, Andy Lutomirski wrote: Sandy Bridge Xeon and Extreme chips have integrated memory controllers with (rather limited) onboard SMBUS masters. This driver gives access to the bus. There are various groups working on standardizing a way to arbitrate access to the bus between

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On 02/16/2015 04:09 AM, Wolfram Sang wrote: Hi Guenter, I wonder where we are with thisp patch; I don't recall a reply to my previous e-mail. Sorry for the late reply. I needed to recover from a HDD headcrash :( Do you need some more time to think about it ? Otherwise I'll publish an

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On Thu, Feb 05, 2015 at 09:53:26AM -0800, Guenter Roeck wrote: On Thu, Feb 05, 2015 at 03:40:28PM +0100, Wolfram Sang wrote: At the same time multi-master access is quite rare. It should still work in those rare cases. A setup of an SoC, an EC (those like to be masters, as well

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On Thu, Feb 05, 2015 at 03:40:28PM +0100, Wolfram Sang wrote: At the same time multi-master access is quite rare. It should still work in those rare cases. A setup of an SoC, an EC (those like to be masters, as well), and an EEPROM is not very far off. To clarify: What I meant

[PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

82801I (ICH9). Signed-off-by: Guenter Roeck li...@roeck-us.net --- drivers/misc/eeprom/at24.c | 52 +- 1 file changed, 47 insertions(+), 5 deletions(-) diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c index 2d3db81..057d35c 100644

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On Wed, Feb 04, 2015 at 06:47:23PM +0100, Wolfram Sang wrote: On Wed, Feb 04, 2015 at 08:23:37AM -0800, Guenter Roeck wrote: Large EEPROMS (24c32 and larger) require a two-byte data address instead of just a single byte. Implement support for such EEPROMs with SMBus commands. Support

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On Wed, Feb 04, 2015 at 06:47:23PM +0100, Wolfram Sang wrote: On Wed, Feb 04, 2015 at 08:23:37AM -0800, Guenter Roeck wrote: Large EEPROMS (24c32 and larger) require a two-byte data address instead of just a single byte. Implement support for such EEPROMs with SMBus commands. Support

Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters

On Thu, Feb 05, 2015 at 12:35:16AM +0100, Wolfram Sang wrote: On Wed, Feb 04, 2015 at 11:08:19AM -0800, Guenter Roeck wrote: On Wed, Feb 04, 2015 at 06:47:23PM +0100, Wolfram Sang wrote: On Wed, Feb 04, 2015 at 08:23:37AM -0800, Guenter Roeck wrote: Large EEPROMS (24c32 and larger

Re: [PATCH] i2c: Mark instantiated device nodes with OF_POPULATE

On Thu, Jan 15, 2015 at 08:33:18PM +0200, Pantelis Antoniou wrote: 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

Re: [PATCH] i2c: Mark instantiated device nodes with OF_POPULATE

On Thu, Jan 15, 2015 at 09:12:36PM +0200, Pantelis Antoniou wrote: Hi Guenter, On Jan 15, 2015, at 20:55 , Guenter Roeck li...@roeck-us.net wrote: On Thu, Jan 15, 2015 at 08:33:18PM +0200, Pantelis Antoniou wrote: Mark (and unmark) device nodes with the POPULATE flag as appropriate

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

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 1/4] watchdog: da9063: Add restart handler support

to register. One option might be to make the message dev_warn instead of dev_err, but that is really a nitpick. Reviewed-by: Guenter Roeck li...@roeck-us.net Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org

Re: [PATCH v8 6/8] OF: i2c: Add OF notifier handler

On 11/20/2014 05:53 PM, Grant Likely wrote: On Tue, 28 Oct 2014 22:36:03 +0200 , Pantelis Antoniou pantelis.anton...@konsulko.com wrote: Add OF notifier handler needed for creating/destroying i2c devices according to dynamic runtime changes in the DT live tree. Signed-off-by: Pantelis

Re: [PATCH v3 1/2] i2c: mux: create symlink to actual mux device

...@the-dreams.de Cc: Jean Delvare jdelv...@suse.de Cc: Guenter Roeck li...@roeck-us.net Cc: Martin Belanger martin.belan...@cyaninc.com Cc: Rodolfo Giometti giome...@enneenne.com Cc: Michael Lawnick ml.lawn...@gmx.de Cc: Jeroen De Wachter jeroen.de.wach...@telenet.be Cc: Gerlando Falauto gerlando.fala

Re: [PATCH] i2c: mux: create proper topology in sysfs

On Tue, Nov 04, 2014 at 03:33:09PM +0100, Wolfram Sang wrote: Ok, I think I know the problem. In my case, the parent adapter and the mux device are the same (since both are on the same chip and the mux is really merged into the i2c controller). I'll have to figure out how to fix that.

Re: [RFC] i2c: mux: add mux device to the adapter name

...@suse.de Cc: Guenter Roeck li...@roeck-us.net Cc: Martin Belanger martin.belan...@cyaninc.com Cc: Rodolfo Giometti giome...@enneenne.com Cc: Michael Lawnick ml.lawn...@gmx.de Cc: Jeroen De Wachter jeroen.de.wach...@telenet.be --- This is probably the least ABI breaking solution? RFC for now

Re: [PATCH] i2c: mux: create proper topology in sysfs

On 11/03/2014 11:33 PM, Wolfram Sang wrote: What is your muxing setup? Complicated ;-). ... Ookay... well, for testing these patches, your setup is absolutely awesome, of course :D May I ask what you are doing with that amount of I2C? The HW folks are trying to have one bus per

Re: [PATCH] i2c: mux: create proper topology in sysfs

On 11/04/2014 06:33 AM, Wolfram Sang wrote: Ok, I think I know the problem. In my case, the parent adapter and the mux device are the same (since both are on the same chip and the mux is really merged into the i2c controller). I'll have to figure out how to fix that. Maybe something like

Re: [PATCH] i2c: mux: create proper topology in sysfs

(1 line left :)) and added the compatibility links.] Signed-off-by: Wolfram Sang w...@the-dreams.de Cc: Jean Delvare jdelv...@suse.de Cc: Guenter Roeck li...@roeck-us.net Cc: Martin Belanger martin.belan...@cyaninc.com Cc: Rodolfo Giometti giome...@enneenne.com Cc: Michael Lawnick ml.lawn

Re: [PATCH] i2c: mux: create proper topology in sysfs

(1 line left :)) and added the compatibility links.] Signed-off-by: Wolfram Sang w...@the-dreams.de Cc: Jean Delvare jdelv...@suse.de Cc: Guenter Roeck li...@roeck-us.net Cc: Martin Belanger martin.belan...@cyaninc.com Cc: Rodolfo Giometti giome...@enneenne.com Cc: Michael Lawnick ml.lawn

Re: [PATCH] i2c: mux: create proper topology in sysfs

On Mon, Nov 03, 2014 at 10:02:00PM +0100, Wolfram Sang wrote: + WARN(sysfs_create_link(parent-dev.kobj, priv-adap.dev.kobj, priv-adap.dev.kobj.name), + can't create compatibility link for old mux name scheme\n); + Something seems to be wrong with the

Re: Problem with multiple i2c multiplexers on the same bus

On 10/31/2014 02:03 PM, Wolfram Sang wrote: Hi, On Mon, Oct 27, 2014 at 11:46:01AM -0700, Martin Belanger wrote: This is regarding a series of emails between Guenter Roeck and Jean Delvare titled Problem with multiple i2c multiplexers on one bus, and mux bus naming sent in November 2013. Ref

Re: Problem with multiple i2c multiplexers on the same bus

emartin.belan...@cyaninc.com www.cyaninc.com On Fri, Oct 31, 2014 at 2:17 PM, Guenter Roeck li...@roeck-us.net wrote: On 10/31/2014 02:03 PM, Wolfram Sang wrote: Hi, On Mon, Oct 27, 2014 at 11:46:01AM -0700, Martin Belanger wrote: This is regarding a series of emails between Guenter Roeck and Jean

Re: [PATH v3 4/4] i2c: i2c-diolan-u2c: sysfs bus frequency support

On 10/15/2014 01:03 PM, Octavian Purdila wrote: Add support for showing and changing the bus frequency via sysfs. Tested on a DLN2 adapter run in U2C-12 compatibility mode. Cc: Guenter Roeck li...@roeck-us.net Signed-off-by: Octavian Purdila octavian.purd...@intel.com --- drivers/i2c/busses

Re: [RFC PATCH v2 3/3] i2c: show and change bus frequency via sysfs

On 10/15/2014 06:32 AM, Octavian Purdila wrote: On Wed, Oct 15, 2014 at 4:13 PM, Guenter Roeck li...@roeck-us.net wrote: On 10/15/2014 04:49 AM, Octavian Purdila wrote: On Tue, Oct 14, 2014 at 6:41 PM, Guenter Roeck li...@roeck-us.net wrote: On Tue, Oct 14, 2014 at 05:48:14PM +0300

Re: [RFC PATCH v2 3/3] i2c: show and change bus frequency via sysfs

On Tue, Oct 14, 2014 at 05:48:14PM +0300, Octavian Purdila wrote: This patch adds three new sysfs files: bus_frequency, bus_min_frequency and bus_max_frequency which allows the user to view or change the bus frequency on a per bus level. This is required for the case where multiple busses

Re: [RFC PATCH 3/3] i2c: show and change bus frequency via sysfs

On Sun, Oct 12, 2014 at 12:32:56PM +0300, Octavian Purdila wrote: On Sat, Oct 11, 2014 at 11:14 PM, Mark Roszko mark.ros...@gmail.com wrote: This seems limiting to arches with peripherals that can support a range of frequencies rather than fixed numbers. Also it creates some portability

Re: Fwd: [Proposal] PM sleep children of inactive I2C bus segments off Masters in multi-master systems

On Wed, Oct 01, 2014 at 11:39:49AM -0700, Danielle Costantino wrote: added proper mailing lists...I hope Hi Danielle, I don't see the actual proposal, and I don't find anything on the web either when looking for the headline :-(. Guenter -- To unsubscribe from this list: send the line

Re: Fwd: [Proposal] PM sleep children of inactive I2C bus segments off Masters in multi-master systems

On Wed, Oct 01, 2014 at 11:44:59AM -0700, Danielle Costantino wrote: Re-sending Proposal: Currently I2C mux devices that support multiple master arbitration are the i2c-mux-pca9541 and i2c-arb-gpio-challenge drivers. I propose to add the ability to configure an interrupt pin from the Master

Re: Fwd: [Proposal] PM sleep children of inactive I2C bus segments off Masters in multi-master systems

On Wed, Oct 01, 2014 at 01:03:59PM -0700, Danielle Costantino wrote: On Wed, Oct 1, 2014 at 12:41 PM, Guenter Roeck gro...@juniper.net wrote: On Wed, Oct 01, 2014 at 11:44:59AM -0700, Danielle Costantino wrote: Re-sending Proposal: Currently I2C mux devices that support multiple master

Re: Fwd: [Proposal] PM sleep children of inactive I2C bus segments off Masters in multi-master systems

, 2014 at 1:20 PM, Guenter Roeck gro...@juniper.net wrote: On Wed, Oct 01, 2014 at 01:03:59PM -0700, Danielle Costantino wrote: On Wed, Oct 1, 2014 at 12:41 PM, Guenter Roeck gro...@juniper.net wrote: On Wed, Oct 01, 2014 at 11:44:59AM -0700, Danielle Costantino wrote: Re-sending Proposal

Re: Fwd: [Proposal] PM sleep children of inactive I2C bus segments off Masters in multi-master systems

On Wed, Oct 01, 2014 at 11:10:47PM +0200, Wolfram Sang wrote: Maybe you can find an error code which with some level of confidence reflects lost mastership. Then you can implement whatever makes sense for your use case in your user space application(s). We have a documented fault code

Re: [PATCH 0/4] Driver for talking to PLX PEX8xxx PCIe switch over I2C

On Tue, Sep 30, 2014 at 11:13:39PM +0200, Wolfram Sang wrote: Since this is a driver for a PCIe switch, I currently put it under /driver/pci/. I'm very open to suggestions for moving this around (Does introducing drivers/pci/switch/ seem any better?). Especially I can see that the

Re: i2c-i801 driver quit working in 3.8.11

On 08/07/2014 01:11 AM, Jean Delvare wrote: Hi Guenter, Soren, Sorry for the late reply. Yes, one year, no kidding :( On Wed, 7 Aug 2013 12:25:56 -0700, Guenter Roeck wrote: On Wed, Aug 07, 2013 at 02:19:42PM -0400, Soren Harward wrote: Yeah, that fixed it. Sensors are working properly now

Re: i2c-i801 driver quit working in 3.8.11

On Thu, Aug 07, 2014 at 06:04:54PM +0200, Jean Delvare wrote: Hi Guenter, Le Thursday 07 August 2014 à 07:19 -0700, Guenter Roeck a écrit : On 08/07/2014 01:11 AM, Jean Delvare wrote: Guenter, I can confirm that the i2c-i801 driver only uses regular interrupts. The datasheet does

Re: i2c-i801 driver quit working in 3.8.11

On Thu, Aug 07, 2014 at 06:55:57PM +0200, Jean Delvare wrote: Hi Soren, Please keep the list and everyone else involved in Cc. On Thu, 7 Aug 2014 07:33:16 -0400, Soren Harward wrote: On Aug 7, 2014 4:11 AM, Jean Delvare jdelv...@suse.de wrote: Soren, what's the status on your side? Are

Re: [PATCH] i2c-stub: Avoid an array overrun on I2C block transfers

to be read (on I2C block reads.) In that case, we must shorten the transfer so that it does not exceed the address space. Signed-off-by: Jean Delvare jdelv...@suse.de Cc: Guenter Roeck li...@roeck-us.net Cc: Wolfram Sang w...@the-dreams.de --- drivers/i2c/i2c-stub.c |2 ++ 1

Re: [PATCH v2] i2c-stub: Allow increasing the SMBus block write length

On 07/13/2014 12:23 AM, Jean Delvare wrote: This is no good reason to not allow SMBus block writes longer than the first one was. Lift this limitation, this makes the code more simple. Signed-off-by: Jean Delvare jdelv...@suse.de Reviewed-by: Guenter Roeck li...@roeck-us.net Applied to my

Re: [PATCH v2] i2c: stub: Add support for SMBus block commands

On 07/13/2014 08:13 AM, Jean Delvare wrote: On Sun, 13 Jul 2014 08:04:54 -0700, Guenter Roeck wrote: On 07/13/2014 12:21 AM, Jean Delvare wrote: Hi Guenter, On Sat, 12 Jul 2014 08:05:49 -0700, Guenter Roeck wrote: Any idea how we could inject errors ? Error path testing would be quite useful

Re: [PATCH] i2c-stub: Avoid an array overrun on I2C block transfers

On 07/13/2014 09:24 AM, Jean Delvare wrote: Hi Guenter, On Sun, 13 Jul 2014 08:44:24 -0700, Guenter Roeck wrote: On 07/13/2014 08:17 AM, Jean Delvare wrote: I2C block transfers can have a size up to 32 bytes. If starting close to the end of the address space, there may not be enough room

Re: [PATCH v2] i2c: stub: Add support for SMBus block commands

On 07/12/2014 02:20 AM, Jean Delvare wrote: Hi Guenter, On Tue, 08 Jul 2014 13:05:41 -0700, Guenter Roeck wrote: On 07/08/2014 12:54 PM, Jean Delvare wrote: Just one thing I have been thinking about while reviewing the updated code... You decided to make the first SMBus block write select

Re: [PATCH v2] i2c: stub: Add support for SMBus block commands

Hi Jean, On 07/12/2014 02:20 AM, Jean Delvare wrote: Hi Guenter, Something else: Any idea how we could inject errors ? Error path testing would be quite useful. Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to

Re: [PATCH 1/2] i2c-stub: Remember the number of emulated chips

On 07/10/2014 03:45 AM, Jean Delvare wrote: This makes initialization, cleanup and look-up easier. Signed-off-by: Jean Delvare jdelv...@suse.de Cc: Guenter Roeck li...@roeck-us.net --- This applies on top of Guenter's patch i2c: stub: Add support for SMBus block commands, v2. Looks good

Re: [PATCH 2/2] i2c-stub: Add support for banked register ranges

support for this mechanism to the i2c-stub driver so that such chips can be emulated. All the bank settings are passed as module parameters. Signed-off-by: Jean Delvare jdelv...@suse.de Cc: Guenter Roeck li...@roeck-us.net --- Tested successfully with: http://jdelvare.nerim.net/devel/lm

Re: [PATCH 2/2] i2c-stub: Add support for banked register ranges

On Thu, Jul 10, 2014 at 11:30:40PM +0200, Jean Delvare wrote: On Thu, 10 Jul 2014 11:40:36 -0700, Guenter Roeck wrote: On Thu, Jul 10, 2014 at 12:56:59PM +0200, Jean Delvare wrote: Some chips implement banked register ranges. This allows implementing more registers than the limited 8-bit

Re: [PATCH 2/2] i2c-stub: Add support for banked register ranges

On 07/10/2014 02:30 PM, Jean Delvare wrote: On Thu, 10 Jul 2014 11:40:36 -0700, Guenter Roeck wrote: On Thu, Jul 10, 2014 at 12:56:59PM +0200, Jean Delvare wrote: Some chips implement banked register ranges. This allows implementing more registers than the limited 8-bit address space

Re: [PATCH v2] i2c: stub: Add support for SMBus block commands

Hi Jean, On 07/08/2014 12:54 PM, Jean Delvare wrote: Hi Guenter, On Mon, 7 Jul 2014 07:23:03 -0700, Guenter Roeck wrote: SMBus block commands are different to I2C block commands since the returned data is not normally accessible with byte or word commands on other command offsets. Add linked

Re: [RFC PATCH] i2c: stub: Add support for SMBus block commands

On 07/07/2014 01:27 AM, Jean Delvare wrote: Hi Guenter, On Sun, 6 Jul 2014 20:55:12 -0700, Guenter Roeck wrote: SMBus block commands are different to I2C block commands since the returned data is not normally accessible with byte or word commands on other command offsets. Add linked list

[PATCH v2] i2c: stub: Add support for SMBus block commands

they can be read. The first write selects the block length. Subsequent writes can be partial. Block read commands always return the number of bytes selected with the first write. Signed-off-by: Guenter Roeck li...@roeck-us.net --- v2: Make new functionality only available on request via

[RFC PATCH] i2c: stub: Add support for SMBus block commands

they can be read. The first write selects the block length. Subsequent writes can be partial. Block read commands always return the number of bytes selected with the first write. Signed-off-by: Guenter Roeck li...@roeck-us.net --- Documentation/i2c/i2c-stub | 7 +++- drivers/i2c/i2c-stub.c

Re: [PATCH 5/6] OF: Utility helper functions for dynamic nodes

On 06/23/2014 12:13 PM, Pantelis Antoniou wrote: Hi Ioan, I'm going to let Grant answer that but the code in question doesn't look right. On Jun 23, 2014, at 9:33 PM, Ioan Nicu wrote: Hi Pantelis, On Mon, Jun 23, 2014 at 07:57:24PM +0300, ext Pantelis Antoniou wrote: Hi Alexander, On Jun

Re: [PATCH 00/22] Random ARM randconfig fixes in drivers

On Thu, May 08, 2014 at 04:46:51PM +0200, Arnd Bergmann wrote: These are a bunch of fixes I had to do to get all randconfig configurations on ARM working. Most of these are really old bugs, but there are also some new ones. I don't think any of them require a backport to linux-stable. I

Re: [PATCH 02/16] i2c: diolan-u2c: remove unnecessary OOM messages

On 05/06/2014 09:16 PM, Jingoo Han wrote: The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han jg1@samsung.com Acked-by: Guenter Roeck li...@roeck-us.net The driver could also use a conversion

Re: [PATCH] Documentation: i2c: mention ACPI method for instantiating devices

On Sat, Feb 15, 2014 at 03:58:35PM +0100, Wolfram Sang wrote: Signed-off-by: Wolfram Sang w...@the-dreams.de Cc: Guenter Roeck li...@roeck-us.net --- Very basic, but probably should do for now? Good enough for me. Acked-by: Guenter Roeck li...@roeck-us.net Documentation/i2c

Re: [lm-sensors] I2C support for AMD Hudson-1

On Tue, Dec 17, 2013 at 07:32:26AM +0100, Christian Herzog wrote: Dear list, I'm currently beta testing a pretty cool embedded board for router applications etc. (http://www.pcengines.ch/apu.htm) that sports a Hudson-1 FCH which is pretty similar to the Hudson-2 your module supports but

Re: [lm-sensors] [PATCH 1/3] dt: Add adt7411 to trivial devices list

On 12/08/2013 01:02 PM, Ben Gamari wrote: Signed-off-by: Ben Gamari bgamari.f...@gmail.com --- Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt

Re: [PATCH 1/1] i2c: i2c-diolan-u2c: different usb endpoints for DLN-2-U2C

. This was tested on a current DLN-2-U2C board. Signed-off-by: Martin Vogt mvo...@gmail.com Reviewed-by: Guenter Roeck li...@roeck-us.net -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Compile error in i2c-bcm-kona.c

Upstream HEAD, arm allmodconfig: drivers/i2c/busses/i2c-bcm-kona.c:894:1: error: '__mod_of_device_table' aliased to undefined symbol 'kona_i2c_of_match' make[3]: *** [drivers/i2c/busses/i2c-bcm-kona.o] Error 1 make[2]: *** [drivers/i2c/busses] Error 2 make[1]: *** [drivers/i2c] Error 2 make[1]:

Re: Problem with multiple i2c multiplexers on one bus, and mux bus naming

On 11/16/2013 12:41 PM, Jean Delvare wrote: Hi Guenter, On Sat, 16 Nov 2013 10:31:00 -0800, Guenter Roeck wrote: I have an interesting situation with multiple i2c multiplexers (pca9548) on a single i2c bus. The problem with this is that multiple mux i2c adapters and up with the same name

Problem with multiple i2c multiplexers on one bus, and mux bus naming

Hi all, I have an interesting situation with multiple i2c multiplexers (pca9548) on a single i2c bus. The problem with this is that multiple mux i2c adapters and up with the same name, i2c-N-mux (chan_id M), where N is the parent bus number and M is the mux channel. This makes it difficult

  1   2   3   >