[uml-devel] Emulate I2C subsystem/slaves

[uml-devel] Emulate I2C subsystem/slaves

[Peter Hüwe]

Hi,

I'm curious if there have ever been any attempts to emulate i2c devices under 
uml in order to facilitate driver development by using stub drivers.

If there weren't any attemps yet, what to you thing would be the best strategy  
to achieve this goal?
Are there any good starting points? 
The main thing I'm lacking is a good idea how to register the 'stub devices'.

Or is this something that is not really desired by the uml project?

Thanks,
Peter


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Emulate I2C subsystem/slaves

[Richard Weinberger]

[-- Attachment #1.1: Type: text/plain, Size: 976 bytes --]

Am 02.09.2012 22:45, schrieb Peter Hüwe:
> I'm curious if there have ever been any attempts to emulate i2c devices under 
> uml in order to facilitate driver development by using stub drivers.

I know none.

> If there weren't any attemps yet, what to you thing would be the best strategy  
> to achieve this goal?
> Are there any good starting points? 
> The main thing I'm lacking is a good idea how to register the 'stub devices'.

Look at any i2c driver. Implement the i2c driver interface and instead of directly
writing to hardware registers write to something else.
Same for read...
E.g. Your i2c emulator could have a TCP back-end.
Host<->Guest i2c pass-through is also possible.
BTW: All this is not UML specific. Iff it makes sense for only UML we can
put it into arch/um/drivers/.
Otherwise drivers/ is fine.

> Or is this something that is not really desired by the uml project?

If there is a use case, why not. :-)

Thanks,
//richard


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 395 bytes --]

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[-- Attachment #3: Type: text/plain, Size: 194 bytes --]

_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Emulate I2C subsystem/slaves

[Peter Hüwe]

[-- Attachment #1: Type: Text/Plain, Size: 1489 bytes --]

Hi Richard,

sorry for the late reply.

> > I'm curious if there have ever been any attempts to emulate i2c devices
> > under uml in order to facilitate driver development by using stub
> > drivers.
> I know none.

> If there is a use case, why not. :-)
Thanks for your encouraging words ;)

I had a look around and found the nice CONFIG_I2C_STUB driver,
which is described in detail at 
http://www.kernel.org/doc/Documentation/i2c/i2c-stub

"""This module is a very simple fake I2C/SMBus driver.  It implements five
types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w)
word data, and (r/w) I2C block data."""
which more or less exactly fits my need.

The only thing that was missing was general support for I2C which is dependent 
on CONFIG_HAS_IOMEM which unfortunately isn't available on UML,
but I simply added a || UML to the Kconfig and was now able to build the I2C 
Support, the i2c-dev module (for userspace access) and the i2c-stub driver.

If I  know load the i2c_stub module I have a emulated i2c device ;)

I adapted the stub driver to my needs and was now able to create my own 
emulated i2c device and start with driver and tools development for it ;)


I added the patch, in case you're interested.

Unfortunately some I2C drivers fail to build if CONFIG_HAS_IOMEM = n, but 
don't have that dependency in Kconfig - I simply added it to prevent them from 
inclusion.

Do you think I should try to push this mainline via the i2c subsystem?

Thanks,
Peter

[-- Attachment #2: 0001-i2c-Fix-Change-dependencies-to-make-I2C-available-on.patch --]
[-- Type: text/x-patch, Size: 2287 bytes --]

From 44d8ec6fa1466c226b605baae9483749ea9de200 Mon Sep 17 00:00:00 2001
From: Peter Huewe <peterhuewe@gmx.de>
Date: Sun, 9 Sep 2012 03:03:29 +0200
Subject: [PATCH] i2c: Fix/Change dependencies to make I2C available on UML

This patch overwrites the HAS_IOMEM dependency for I2C on UML, as it is not
really necessary to have HAS_IOMEM in order build the generic I2C part.

In addition to that, every I2C modules available in UML which really
needs HAS_IOMEM was given this dependency to its KConfig.

The I2C subsystem can now be used, e.g. by the i2c-stub driver, for
development of I2C device drivers.

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
 drivers/i2c/Kconfig        |    2 +-
 drivers/i2c/busses/Kconfig |    6 ++++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 5a3bb3d..03ce0cb 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig I2C
 	tristate "I2C support"
-	depends on HAS_IOMEM
+	depends on HAS_IOMEM || UML
 	select RT_MUTEXES
 	---help---
 	  I2C (pronounce: I-squared-C) is a slow serial bus protocol used in
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b4aaa1b..1e61ad9 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -498,7 +498,7 @@ config I2C_NUC900
 
 config I2C_OCORES
 	tristate "OpenCores I2C Controller"
-	depends on EXPERIMENTAL
+	depends on EXPERIMENTAL && HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  OpenCores I2C controller. For details see
@@ -525,6 +525,7 @@ config I2C_PASEMI
 
 config I2C_PCA_PLATFORM
 	tristate "PCA9564/PCA9665 as platform device"
+	depends on HAS_IOMEM
 	select I2C_ALGOPCA
 	default n
 	help
@@ -628,6 +629,7 @@ config I2C_SH_MOBILE
 
 config I2C_SIMTEC
 	tristate "Simtec Generic I2C interface"
+	depends on HAS_IOMEM
 	select I2C_ALGOBIT
 	help
 	  If you say yes to this option, support will be included for
@@ -772,7 +774,7 @@ config I2C_PARPORT_LIGHT
 
 config I2C_TAOS_EVM
 	tristate "TAOS evaluation module"
-	depends on EXPERIMENTAL
+	depends on EXPERIMENTAL && HAS_IOMEM
 	select SERIO
 	select SERIO_SERPORT
 	default n
-- 
1.7.8.6


[-- Attachment #3: Type: text/plain, Size: 395 bytes --]

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[-- Attachment #4: Type: text/plain, Size: 194 bytes --]

_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Emulate I2C subsystem/slaves

[Geert Uytterhoeven]

Hi Peter,

On Sun, Sep 9, 2012 at 3:08 AM, Peter Hüwe <PeterHuewe@gmx.de> wrote:
>> > I'm curious if there have ever been any attempts to emulate i2c devices
>> > under uml in order to facilitate driver development by using stub
>> > drivers.
>> I know none.
>
>> If there is a use case, why not. :-)
> Thanks for your encouraging words ;)
>
> I had a look around and found the nice CONFIG_I2C_STUB driver,
> which is described in detail at
> http://www.kernel.org/doc/Documentation/i2c/i2c-stub
>
> """This module is a very simple fake I2C/SMBus driver.  It implements five
> types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w)
> word data, and (r/w) I2C block data."""
> which more or less exactly fits my need.
>
> The only thing that was missing was general support for I2C which is dependent
> on CONFIG_HAS_IOMEM which unfortunately isn't available on UML,
> but I simply added a || UML to the Kconfig and was now able to build the I2C
> Support, the i2c-dev module (for userspace access) and the i2c-stub driver.

Yes, that's what you typically have to do to get such a thing working.

JFYI, on several occasions, I worked on Amiga Zorro bus probing under UML, using
fake Zorro devices and real but stubbed network and frame buffer drivers.

> If I  know load the i2c_stub module I have a emulated i2c device ;)
>
> I adapted the stub driver to my needs and was now able to create my own
> emulated i2c device and start with driver and tools development for it ;)
>
>
> I added the patch, in case you're interested.
>
> Unfortunately some I2C drivers fail to build if CONFIG_HAS_IOMEM = n, but
> don't have that dependency in Kconfig - I simply added it to prevent them from
> inclusion.

That's because they rely on the HAS_IOMEM dependency for the whole subsystem.
In fact, I'm surprised you didn't have to add HAS_IOMEM dependencies
to more drivers.

> Do you think I should try to push this mainline via the i2c subsystem?

As long as there are no "real" i2c drivers for UML, but only
dummy/development ones,
that is up to the i2c maintainer (in CC).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [uml-devel] Emulate I2C subsystem/slaves

[Peter Hüwe]

Hi Geert,

> That's because they rely on the HAS_IOMEM dependency for the whole
> subsystem. In fact, I'm surprised you didn't have to add HAS_IOMEM
> dependencies to more drivers.
I changed only the ones which are available in UML.
I now rewrote the patch to remove the global dependency and move it to all the 
drivers that really rely on HAS_IOMEM - see below.


> > Do you think I should try to push this mainline via the i2c subsystem?
> As long as there are no "real" i2c drivers for UML, but only
> dummy/development ones,
> that is up to the i2c maintainer (in CC).
Nevertheless it would probably be a good starting point for developers - if a 
subsystem is available the probability that someone hacks on it is much higher 
;)

Thanks,
Peter

---

From 25268d4cdd4b1dd1e5d03c9b90c179758dd41e2e Mon Sep 17 00:00:00 2001
From: Peter Huewe <peterhuewe@gmx.de>
Date: Sun, 9 Sep 2012 03:03:29 +0200
Subject: [PATCH] i2c: Fix/Change dependencies to make I2C available on UML

This patch removes the global dependency of the I2C subsystem on
HAS_IOMEM and moves the dependency to the drivers which really rely on
HAS_IOMEM.

The generic I2C part does not need to have HAS_IOMEM set and thus now
becomes available in UML so the I2C subsystem can now be used, e.g.
by the i2c-stub driver, for development of I2C device drivers.

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
 drivers/i2c/Kconfig        |    1 -
 drivers/i2c/busses/Kconfig |   60 ++++++++++++++++++++++++++-----------------
 2 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 5a3bb3d..e4e02e2 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -4,7 +4,6 @@
 
 menuconfig I2C
 	tristate "I2C support"
-	depends on HAS_IOMEM
 	select RT_MUTEXES
 	---help---
 	  I2C (pronounce: I-squared-C) is a slow serial bus protocol used in
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b4aaa1b..27d1d98 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -79,6 +79,7 @@ config I2C_AMD8111
 config I2C_I801
 	tristate "Intel 82801 (ICH/PCH)"
 	depends on PCI
+	depends on HAS_IOMEM
 	select CHECK_SIGNATURE if X86 && DMI
 	help
 	  If you say yes to this option, support will be included for the Intel
@@ -264,7 +265,7 @@ comment "Mac SMBus host controller drivers"
 
 config I2C_HYDRA
 	tristate "CHRP Apple Hydra Mac I/O I2C interface"
-	depends on PCI && PPC_CHRP && EXPERIMENTAL
+	depends on PCI && PPC_CHRP && EXPERIMENTAL && HAS_IOMEM
 	select I2C_ALGOBIT
 	help
 	  This supports the use of the I2C interface in the Apple Hydra Mac
@@ -291,6 +292,7 @@ comment "I2C system bus drivers (mostly embedded / system-
on-chip)"
 config I2C_AT91
 	tristate "Atmel AT91 I2C Two-Wire interface (TWI)"
 	depends on ARCH_AT91 && EXPERIMENTAL && BROKEN
+	depends on HAS_IOMEM
 	help
 	  This supports the use of the I2C interface on Atmel AT91
 	  processors.
@@ -305,7 +307,7 @@ config I2C_AT91
 
 config I2C_AU1550
 	tristate "Au1550/Au1200/Au1300 SMBus interface"
-	depends on MIPS_ALCHEMY
+	depends on MIPS_ALCHEMY && HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  Au1550/Au1200/Au1300 SMBus interface.
@@ -315,7 +317,7 @@ config I2C_AU1550
 
 config I2C_BLACKFIN_TWI
 	tristate "Blackfin TWI I2C support"
-	depends on BLACKFIN
+	depends on BLACKFIN && HAS_IOMEM
 	depends on !BF561 && !BF531 && !BF532 && !BF533
 	help
 	  This is the I2C bus driver for Blackfin on-chip TWI interface.
@@ -343,7 +345,7 @@ config I2C_CPM
 
 config I2C_DAVINCI
 	tristate "DaVinci I2C driver"
-	depends on ARCH_DAVINCI
+	depends on ARCH_DAVINCI && HAS_IOMEM
 	help
 	  Support for TI DaVinci I2C controller driver.
 
@@ -356,7 +358,7 @@ config I2C_DAVINCI
 
 config I2C_DESIGNWARE_PLATFORM
 	tristate "Synopsys DesignWare Platform"
-	depends on HAVE_CLK
+	depends on HAVE_CLK && HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  Synopsys DesignWare I2C adapter. Only master mode is supported.
@@ -366,7 +368,7 @@ config I2C_DESIGNWARE_PLATFORM
 
 config I2C_DESIGNWARE_PCI
 	tristate "Synopsys DesignWare PCI"
-	depends on PCI
+	depends on PCI && HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  Synopsys DesignWare I2C adapter. Only master mode is supported.
@@ -399,7 +401,7 @@ config I2C_GPIO
 
 config I2C_HIGHLANDER
 	tristate "Highlander FPGA SMBus interface"
-	depends on SH_HIGHLANDER
+	depends on SH_HIGHLANDER && HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for
 	  the SMBus interface located in the FPGA on various Highlander
@@ -421,7 +423,7 @@ config I2C_IBM_IIC
 
 config I2C_IMX
 	tristate "IMX I2C interface"
-	depends on ARCH_MXC
+	depends on ARCH_MXC && HAS_IOMEM
 	help
 	  Say Y here if you want to use the IIC bus controller on
 	  the Freescale i.MX/MXC processors.
@@ -431,7 +433,7 @@ config I2C_IMX
 
 config I2C_INTEL_MID
 	tristate "Intel Moorestown/Medfield Platform I2C controller"
-	depends on PCI
+	depends on PCI && HAS_IOMEM
 	help
 	  Say Y here if you have an Intel Moorestown/Medfield platform I2C
 	  controller.
@@ -442,6 +444,7 @@ config I2C_INTEL_MID
 config I2C_IOP3XX
 	tristate "Intel IOPx3xx and IXP4xx on-chip I2C interface"
 	depends on ARCH_IOP32X || ARCH_IOP33X || ARCH_IXP4XX || ARCH_IOP13XX
+	depends on HAS_IOMEM
 	help
 	  Say Y here if you want to use the IIC bus controller on
 	  the Intel IOPx3xx I/O Processors or IXP4xx Network Processors.
@@ -451,7 +454,7 @@ config I2C_IOP3XX
 
 config I2C_MPC
 	tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx"
-	depends on PPC
+	depends on PPC && HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx,
@@ -463,6 +466,7 @@ config I2C_MPC
 config I2C_MV64XXX
 	tristate "Marvell mv64xxx I2C Controller"
 	depends on (MV64X60 || PLAT_ORION)
+	depends on HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  built-in I2C interface on the Marvell 64xxx line of host bridges.
@@ -473,6 +477,7 @@ config I2C_MV64XXX
 config I2C_MXS
 	tristate "Freescale i.MX28 I2C interface"
 	depends on SOC_IMX28
+	depends on HAS_IOMEM
 	select STMP_DEVICE
 	help
 	  Say Y here if you want to use the I2C bus controller on
@@ -483,7 +488,7 @@ config I2C_MXS
 
 config I2C_NOMADIK
 	tristate "ST-Ericsson Nomadik/Ux500 I2C Controller"
-	depends on ARM_AMBA
+	depends on ARM_AMBA && HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  I2C interface from ST-Ericsson's Nomadik and Ux500 architectures,
@@ -491,14 +496,14 @@ config I2C_NOMADIK
 
 config I2C_NUC900
 	tristate "NUC900 I2C Driver"
-	depends on ARCH_W90X900
+	depends on ARCH_W90X900 && HAS_IOMEM
 	help
 	  Say Y here to include support for I2C controller in the
 	  Winbond/Nuvoton NUC900 based System-on-Chip devices.
 
 config I2C_OCORES
 	tristate "OpenCores I2C Controller"
-	depends on EXPERIMENTAL
+	depends on EXPERIMENTAL && HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  OpenCores I2C controller. For details see
@@ -509,7 +514,7 @@ config I2C_OCORES
 
 config I2C_OMAP
 	tristate "OMAP I2C adapter"
-	depends on ARCH_OMAP
+	depends on ARCH_OMAP && HAS_IOMEM
 	default y if MACH_OMAP_H3 || MACH_OMAP_OSK
 	help
 	  If you say yes to this option, support will be included for the
@@ -525,6 +530,7 @@ config I2C_PASEMI
 
 config I2C_PCA_PLATFORM
 	tristate "PCA9564/PCA9665 as platform device"
+	depends on HAS_IOMEM
 	select I2C_ALGOPCA
 	default n
 	help
@@ -536,7 +542,7 @@ config I2C_PCA_PLATFORM
 
 config I2C_PMCMSP
 	tristate "PMC MSP I2C TWI Controller"
-	depends on PMC_MSP
+	depends on PMC_MSP && HAS_IOMEM
 	help
 	  This driver supports the PMC TWI controller on MSP devices.
 
@@ -546,6 +552,7 @@ config I2C_PMCMSP
 config I2C_PNX
 	tristate "I2C bus support for Philips PNX and NXP LPC targets"
 	depends on ARCH_PNX4008 || ARCH_LPC32XX
+	depends on HAS_IOMEM
 	help
 	  This driver supports the Philips IP3204 I2C IP block master and/or
 	  slave controller
@@ -567,6 +574,7 @@ config I2C_PUV3
 config I2C_PXA
 	tristate "Intel PXA2XX I2C adapter"
 	depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+	depends on HAS_IOMEM
 	help
 	  If you have devices in the PXA I2C bus, say yes to this option.
 	  This driver can also be built as a module.  If so, the module
@@ -592,14 +600,14 @@ config HAVE_S3C2410_I2C
 
 config I2C_S3C2410
 	tristate "S3C2410 I2C Driver"
-	depends on HAVE_S3C2410_I2C
+	depends on HAVE_S3C2410_I2C && HAS_IOMEM
 	help
 	  Say Y here to include support for I2C controller in the
 	  Samsung SoCs.
 
 config I2C_S6000
 	tristate "S6000 I2C support"
-	depends on XTENSA_VARIANT_S6000
+	depends on XTENSA_VARIANT_S6000 && HAS_IOMEM
 	help
 	  This driver supports the on chip I2C device on the
 	  S6000 xtensa processor family.
@@ -610,6 +618,7 @@ config I2C_S6000
 config I2C_SH7760
 	tristate "Renesas SH7760 I2C Controller"
 	depends on CPU_SUBTYPE_SH7760
+	depends on HAS_IOMEM
 	help
 	  This driver supports the 2 I2C interfaces on the Renesas SH7760.
 
@@ -619,6 +628,7 @@ config I2C_SH7760
 config I2C_SH_MOBILE
 	tristate "SuperH Mobile I2C Controller"
 	depends on SUPERH || ARCH_SHMOBILE
+	depends on HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  built-in I2C interface on the Renesas SH-Mobile processor.
@@ -628,6 +638,7 @@ config I2C_SH_MOBILE
 
 config I2C_SIMTEC
 	tristate "Simtec Generic I2C interface"
+	depends on HAS_IOMEM
 	select I2C_ALGOBIT
 	help
 	  If you say yes to this option, support will be included for
@@ -640,7 +651,7 @@ config I2C_SIMTEC
 
 config I2C_SIRF
 	tristate "CSR SiRFprimaII I2C interface"
-	depends on ARCH_PRIMA2
+	depends on ARCH_PRIMA2 && HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  CSR SiRFprimaII I2C interface.
@@ -650,7 +661,7 @@ config I2C_SIRF
 
 config I2C_STU300
 	tristate "ST Microelectronics DDC I2C interface"
-	depends on MACH_U300
+	depends on MACH_U300 && HAS_IOMEM
 	default y if MACH_U300
 	help
 	  If you say yes to this option, support will be included for the
@@ -663,7 +674,7 @@ config I2C_STU300
 
 config I2C_TEGRA
 	tristate "NVIDIA Tegra internal I2C controller"
-	depends on ARCH_TEGRA
+	depends on ARCH_TEGRA && HAS_IOMEM
 	help
 	  If you say yes to this option, support will be included for the
 	  I2C controller embedded in NVIDIA Tegra SOCs
@@ -671,6 +682,7 @@ config I2C_TEGRA
 config I2C_VERSATILE
 	tristate "ARM Versatile/Realview I2C bus support"
 	depends on ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS
+	depends on HAS_IOMEM
 	select I2C_ALGOBIT
 	help
 	  Say yes if you want to support the I2C serial bus on ARMs Versatile
@@ -681,7 +693,7 @@ config I2C_VERSATILE
 
 config I2C_OCTEON
 	tristate "Cavium OCTEON I2C bus support"
-	depends on CPU_CAVIUM_OCTEON
+	depends on CPU_CAVIUM_OCTEON && HAS_IOMEM
 	help
 	  Say yes if you want to support the I2C serial bus on Cavium
 	  OCTEON SOC.
@@ -701,7 +713,7 @@ config I2C_XILINX
 
 config I2C_XLR
 	tristate "XLR I2C support"
-	depends on CPU_XLR
+	depends on CPU_XLR && HAS_IOMEM
 	help
 	  This driver enables support for the on-chip I2C interface of
 	  the Netlogic XLR/XLS MIPS processors.
@@ -772,7 +784,7 @@ config I2C_PARPORT_LIGHT
 
 config I2C_TAOS_EVM
 	tristate "TAOS evaluation module"
-	depends on EXPERIMENTAL
+	depends on EXPERIMENTAL && HAS_IOMEM
 	select SERIO
 	select SERIO_SERPORT
 	default n
@@ -811,7 +823,7 @@ config I2C_ACORN
 
 config I2C_ELEKTOR
 	tristate "Elektor ISA card"
-	depends on ISA && HAS_IOPORT && BROKEN_ON_SMP
+	depends on ISA && HAS_IOPORT && BROKEN_ON_SMP && HAS_IOMEM
 	select I2C_ALGOPCF
 	help
 	  This supports the PCF8584 ISA bus I2C adapter.  Say Y if you own
-- 
1.7.8.6

Re: [uml-devel] Emulate I2C subsystem/slaves

[Jean Delvare]

Hi all,

Thanks for the info. I thought UML was no longer used with all the
virtualization solutions available, but apparently I was wrong.

On Sun, 9 Sep 2012 12:49:03 +0200, Peter Hüwe wrote:
> > That's because they rely on the HAS_IOMEM dependency for the whole
> > subsystem. In fact, I'm surprised you didn't have to add HAS_IOMEM
> > dependencies to more drivers.
> I changed only the ones which are available in UML.
> I now rewrote the patch to remove the global dependency and move it to all the 
> drivers that really rely on HAS_IOMEM - see below.

My bet is that all I2C bus drivers do use I/O or memory mapped
operations directly or indirectly, except i2c-stub. So it would
probably make more sense, and be a less intrusive change, to move the
HAS_IOMEM dependency to drivers/i2c/busses, and move (logically or for
real) i2c-stub out of it.

Or are there really other I2C bus drivers which make sense to enable
under UML?

Are there other subsystems where the HAS_IOMEM dependency is at the
individual driver level?

-- 
Jean Delvare

Re: [uml-devel] Emulate I2C subsystem/slaves

[Peter Hüwe]

Am Sonntag, 9. September 2012, 13:28:38 schrieb Jean Delvare:
> Thanks for the info. I thought UML was no longer used with all the
> virtualization solutions available, but apparently I was wrong.
I guess it's mainly used for sandboxing, testing and development ;)


> My bet is that all I2C bus drivers do use I/O or memory mapped
> operations directly or indirectly, except i2c-stub. So it would
> probably make more sense, and be a less intrusive change, to move the
> HAS_IOMEM dependency to drivers/i2c/busses, and move (logically or for
> real) i2c-stub out of it.
> 
> Or are there really other I2C bus drivers which make sense to enable
> under UML?
The only other available in UML which doesn't rely on HAS_IOMEM is the 
PARPORT_LIGHT which relies on direct io access - so I guess this one doesn't 
make sense either.

I created a patch for your proposed solution, I moved the stub driver to the 
end in order to have only one big if HAS_IOMEM.


Thanks,
Peter

---
From 923bc2feac0a04ee35382e60bb523d08baf92d48 Mon Sep 17 00:00:00 2001
From: Peter Huewe <peterhuewe@gmx.de>
Date: Sun, 9 Sep 2012 14:10:05 +0200
Subject: [PATCH] i2c: Move HAS_IOMEM dependency to i2c/busses to make I2C
 available on UML

This patch removes the global dependency of the I2C subsystem on
HAS_IOMEM and moves the dependency to the i2c/busses submenu, with an
exception for i2c-stub.

The generic I2C part does not need to have HAS_IOMEM set and thus now
becomes available in UML, so the I2C subsystem can now be used, e.g.
by the i2c-stub driver, for development of I2C device drivers.

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
 drivers/i2c/Kconfig        |    1 -
 drivers/i2c/busses/Kconfig |   28 +++++++++++++++-------------
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 5a3bb3d..e4e02e2 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -4,7 +4,6 @@
 
 menuconfig I2C
 	tristate "I2C support"
-	depends on HAS_IOMEM
 	select RT_MUTEXES
 	---help---
 	  I2C (pronounce: I-squared-C) is a slow serial bus protocol used in
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b4aaa1b..84954de 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -4,6 +4,7 @@
 
 menu "I2C Hardware Bus support"
 
+if HAS_IOMEM
 comment "PC SMBus host controller drivers"
 	depends on PCI
 
@@ -843,19 +844,6 @@ config I2C_SIBYTE
 	help
 	  Supports the SiByte SOC on-chip I2C interfaces (2 channels).
 
-config I2C_STUB
-	tristate "I2C/SMBus Test Stub"
-	depends on EXPERIMENTAL && m
-	default 'n'
-	help
-	  This module may be useful to developers of SMBus client drivers,
-	  especially for certain kinds of sensor chips.
-
-	  If you do build this module, be sure to read the notes and warnings
-	  in <file:Documentation/i2c/i2c-stub>.
-
-	  If you don't know what to do here, definitely say N.
-
 config SCx200_I2C
 	tristate "NatSemi SCx200 I2C using GPIO pins (DEPRECATED)"
 	depends on SCx200_GPIO
@@ -898,5 +886,19 @@ config SCx200_ACB
 
 	  This support is also available as a module.  If so, the module
 	  will be called scx200_acb.
+endif
+
+config I2C_STUB
+	tristate "I2C/SMBus Test Stub"
+	depends on EXPERIMENTAL && m
+	default 'n'
+	help
+	  This module may be useful to developers of SMBus client drivers,
+	  especially for certain kinds of sensor chips.
+
+	  If you do build this module, be sure to read the notes and warnings
+	  in <file:Documentation/i2c/i2c-stub>.
+
+	  If you don't know what to do here, definitely say N.
 
 endmenu
-- 
1.7.8.6

Re: [uml-devel] Emulate I2C subsystem/slaves

[Geert Uytterhoeven]

On Sun, Sep 9, 2012 at 2:15 PM, Peter Hüwe <PeterHuewe@gmx.de> wrote:
>> My bet is that all I2C bus drivers do use I/O or memory mapped
>> operations directly or indirectly, except i2c-stub. So it would
>> probably make more sense, and be a less intrusive change, to move the
>> HAS_IOMEM dependency to drivers/i2c/busses, and move (logically or for
>> real) i2c-stub out of it.
>>
>> Or are there really other I2C bus drivers which make sense to enable
>> under UML?
> The only other available in UML which doesn't rely on HAS_IOMEM is the
> PARPORT_LIGHT which relies on direct io access - so I guess this one doesn't
> make sense either.
>
> I created a patch for your proposed solution, I moved the stub driver to the
> end in order to have only one big if HAS_IOMEM.

I was just going to comment that adding "&& HAS_IOMEM" doesn't make much
sense for e.g. "depends on PPC", as we know PPC always has HAS_IOMEM.
Only s390, PCI-less tile, and UML don't have HAS_IOMEM.

Doing it in the submenu is indeed better.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [uml-devel] Emulate I2C subsystem/slaves

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]

Am 09.09.2012 14:15, schrieb Peter Hüwe:
> Am Sonntag, 9. September 2012, 13:28:38 schrieb Jean Delvare:
>> Thanks for the info. I thought UML was no longer used with all the
>> virtualization solutions available, but apparently I was wrong.
> I guess it's mainly used for sandboxing, testing and development ;)

It's mostly used where KVM does not work.
For example low end i586 servers in schools.
Using UML you can still run 10+ instances on a P3 with 512MiB ram.

> 
>> My bet is that all I2C bus drivers do use I/O or memory mapped
>> operations directly or indirectly, except i2c-stub. So it would
>> probably make more sense, and be a less intrusive change, to move the
>> HAS_IOMEM dependency to drivers/i2c/busses, and move (logically or for
>> real) i2c-stub out of it.
>>
>> Or are there really other I2C bus drivers which make sense to enable
>> under UML?
> The only other available in UML which doesn't rely on HAS_IOMEM is the 
> PARPORT_LIGHT which relies on direct io access - so I guess this one doesn't 
> make sense either.
> 
> I created a patch for your proposed solution, I moved the stub driver to the 
> end in order to have only one big if HAS_IOMEM.

UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which is
often too coarse grained.
To deal with that I've introduced GENERIC_IO some time ago to support MTD (and nandsim)
on UML.
Maybe some parts of the I2C sub-system can also just depend on GENERIC_IO instead of
HAS_IOMEM.
An arch has GENERIC_IO=y if it supports everything defined in generic-asm/io.h which is
more than enough for most stub drivers.

Please look at this patch series:
https://lkml.org/lkml/2012/2/6/489

I'm sure it will help you in bringing I2C to UML.

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [uml-devel] Emulate I2C subsystem/slaves

[Peter Hüwe]

Am Sonntag, 9. September 2012, 14:23:06 schrieb Richard Weinberger: 
> UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which
> is often too coarse grained.
> To deal with that I've introduced GENERIC_IO some time ago to support MTD
> (and nandsim) on UML.
> Maybe some parts of the I2C sub-system can also just depend on GENERIC_IO
> instead of HAS_IOMEM.
> An arch has GENERIC_IO=y if it supports everything defined in
> generic-asm/io.h which is more than enough for most stub drivers.

The only thing which seems to be missing on UML is the ioremap function family 
;/


Peter

Re: [uml-devel] Emulate I2C subsystem/slaves

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

Am 09.09.2012 14:52, schrieb Peter Hüwe:
> Am Sonntag, 9. September 2012, 14:23:06 schrieb Richard Weinberger: 
>> UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which
>> is often too coarse grained.
>> To deal with that I've introduced GENERIC_IO some time ago to support MTD
>> (and nandsim) on UML.
>> Maybe some parts of the I2C sub-system can also just depend on GENERIC_IO
>> instead of HAS_IOMEM.
>> An arch has GENERIC_IO=y if it supports everything defined in
>> generic-asm/io.h which is more than enough for most stub drivers.
> 
> The only thing which seems to be missing on UML is the ioremap function family 
> ;/

Why do you need ioremap() in a stub driver?
This sounds strange.

Thanks,
//richard



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [uml-devel] Emulate I2C subsystem/slaves

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

Am 09.09.2012 14:52, schrieb Peter Hüwe:
> Am Sonntag, 9. September 2012, 14:23:06 schrieb Richard Weinberger: 
>> UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which
>> is often too coarse grained.
>> To deal with that I've introduced GENERIC_IO some time ago to support MTD
>> (and nandsim) on UML.
>> Maybe some parts of the I2C sub-system can also just depend on GENERIC_IO
>> instead of HAS_IOMEM.
>> An arch has GENERIC_IO=y if it supports everything defined in
>> generic-asm/io.h which is more than enough for most stub drivers.
> 
> The only thing which seems to be missing on UML is the ioremap function family 
> ;/

BTW: What about io_remap_pfn_range()?

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [uml-devel] Emulate I2C subsystem/slaves

[Peter Hüwe]

> >> Maybe some parts of the I2C sub-system can also just depend on
> >> GENERIC_IO instead of HAS_IOMEM.
> >> An arch has GENERIC_IO=y if it supports everything defined in
> >> generic-asm/io.h which is more than enough for most stub drivers.
> > 
> > The only thing which seems to be missing on UML is the ioremap function
> > family ;/
> 
> Why do you need ioremap() in a stub driver?
> This sounds strange.


This was a misunderstanding - the main part of the I2C subsystem doesn't 
depend at all on HAS_IOMEM, only the main part of the i2c/busses section.
And almost all of those drivers use ioremap.

For my stub driver I don't need any of that, I'd be fine with the move of 
HAS_IOMEM as proposed by Jean.


Peter

Re: [uml-devel] Emulate I2C subsystem/slaves

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

Am 09.09.2012 15:11, schrieb Peter Hüwe:
>>>> Maybe some parts of the I2C sub-system can also just depend on
>>>> GENERIC_IO instead of HAS_IOMEM.
>>>> An arch has GENERIC_IO=y if it supports everything defined in
>>>> generic-asm/io.h which is more than enough for most stub drivers.
>>>
>>> The only thing which seems to be missing on UML is the ioremap function
>>> family ;/
>>
>> Why do you need ioremap() in a stub driver?
>> This sounds strange.
> 
> 
> This was a misunderstanding - the main part of the I2C subsystem doesn't 
> depend at all on HAS_IOMEM, only the main part of the i2c/busses section.
> And almost all of those drivers use ioremap.

Sure. They need real hardware. :-)

> For my stub driver I don't need any of that, I'd be fine with the move of 
> HAS_IOMEM as proposed by Jean.

IMHO you should replace the HAS_IOMEM with GENERIC_IO.
Otherwise you may break the build on s390.

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [uml-devel] Emulate I2C subsystem/slaves

[Geert Uytterhoeven]

On Sun, Sep 9, 2012 at 3:27 PM, Richard Weinberger <richard@nod.at> wrote:
>> For my stub driver I don't need any of that, I'd be fine with the move of
>> HAS_IOMEM as proposed by Jean.
>
> IMHO you should replace the HAS_IOMEM with GENERIC_IO.
> Otherwise you may break the build on s390.

s390 has neither of HAS_IOMEM and GENERIC_IO, so it won't break their
build.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [uml-devel] Emulate I2C subsystem/slaves

[Richard Weinberger]

Geert Uytterhoeven <geert@linux-m68k.org> schrieb:

>On Sun, Sep 9, 2012 at 3:27 PM, Richard Weinberger <richard@nod.at>
>wrote:
>>> For my stub driver I don't need any of that, I'd be fine with the
>move of
>>> HAS_IOMEM as proposed by Jean.
>>
>> IMHO you should replace the HAS_IOMEM with GENERIC_IO.
>> Otherwise you may break the build on s390.
>
>s390 has neither of HAS_IOMEM and GENERIC_IO, so it won't break their
>build.
>
>Gr{oetje,eeting}s,
>
>                        Geert
>
>--
>Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>geert@linux-m68k.org
>
>In personal conversations with technical people, I call myself a
>hacker. But
>when I'm talking to journalists I just say "programmer" or something
>like that.
>                                -- Linus Torvalds

That's why it may break. If you remove the depends on HAS_IOMEM, it will be built on s390 and fail if that codes uses io memory functions. Depending on GENERIC_IO fixes that.

Re: [uml-devel] Emulate I2C subsystem/slaves

[Jean Delvare]

On Sun, 09 Sep 2012 17:00:54 +0200, Richard Weinberger wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> schrieb:
> >s390 has neither of HAS_IOMEM and GENERIC_IO, so it won't break their
> >build.
>
> That's why it may break. If you remove the depends on HAS_IOMEM, it will be built on s390 and fail if that codes uses io memory functions. Depending on GENERIC_IO fixes that.

Where "that" is a problem which may not exist in the first place.

-- 
Jean Delvare

Re: [uml-devel] Emulate I2C subsystem/slaves

[Jean Delvare]

Hallo Petter,

On Sun, 9 Sep 2012 14:15:02 +0200, Peter Hüwe wrote:
> I created a patch for your proposed solution, I moved the stub driver to the 
> end in order to have only one big if HAS_IOMEM.

There is a problem with the mux chip drivers, which then no longer
depend on HAS_IOMEM. Also, I think it is about time to admit that
i2c-stub does not fit under "I2C Hardware Bus support". It is a driver
for development, not hardware support.

So I propose the following instead:

 drivers/i2c/Kconfig        |   14 +++++++++++++-
 drivers/i2c/busses/Kconfig |   14 +-------------
 drivers/i2c/muxes/Kconfig  |    2 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

--- linux-3.6-rc4.orig/drivers/i2c/Kconfig	2012-07-21 22:58:29.000000000 +0200
+++ linux-3.6-rc4/drivers/i2c/Kconfig	2012-09-09 18:34:08.169196654 +0200
@@ -4,7 +4,6 @@
 
 menuconfig I2C
 	tristate "I2C support"
-	depends on HAS_IOMEM
 	select RT_MUTEXES
 	---help---
 	  I2C (pronounce: I-squared-C) is a slow serial bus protocol used in
@@ -86,6 +85,19 @@ config I2C_SMBUS
 source drivers/i2c/algos/Kconfig
 source drivers/i2c/busses/Kconfig
 
+config I2C_STUB
+	tristate "I2C/SMBus Test Stub"
+	depends on EXPERIMENTAL && m
+	default 'n'
+	help
+	  This module may be useful to developers of SMBus client drivers,
+	  especially for certain kinds of sensor chips.
+
+	  If you do build this module, be sure to read the notes and warnings
+	  in <file:Documentation/i2c/i2c-stub>.
+
+	  If you don't know what to do here, definitely say N.
+
 config I2C_DEBUG_CORE
 	bool "I2C Core debugging messages"
 	help
--- linux-3.6-rc4.orig/drivers/i2c/busses/Kconfig	2012-09-08 09:36:32.086553711 +0200
+++ linux-3.6-rc4/drivers/i2c/busses/Kconfig	2012-09-09 18:33:58.598196535 +0200
@@ -3,6 +3,7 @@
 #
 
 menu "I2C Hardware Bus support"
+	depends on HAS_IOMEM
 
 comment "PC SMBus host controller drivers"
 	depends on PCI
@@ -850,19 +851,6 @@ config I2C_SIBYTE
 	help
 	  Supports the SiByte SOC on-chip I2C interfaces (2 channels).
 
-config I2C_STUB
-	tristate "I2C/SMBus Test Stub"
-	depends on EXPERIMENTAL && m
-	default 'n'
-	help
-	  This module may be useful to developers of SMBus client drivers,
-	  especially for certain kinds of sensor chips.
-
-	  If you do build this module, be sure to read the notes and warnings
-	  in <file:Documentation/i2c/i2c-stub>.
-
-	  If you don't know what to do here, definitely say N.
-
 config SCx200_I2C
 	tristate "NatSemi SCx200 I2C using GPIO pins (DEPRECATED)"
 	depends on SCx200_GPIO
--- linux-3.6-rc4.orig/drivers/i2c/muxes/Kconfig	2012-07-21 22:58:29.000000000 +0200
+++ linux-3.6-rc4/drivers/i2c/muxes/Kconfig	2012-09-09 19:20:13.032141164 +0200
@@ -3,7 +3,7 @@
 #
 
 menu "Multiplexer I2C Chip support"
-	depends on I2C_MUX
+	depends on HAS_IOMEM && I2C_MUX
 
 config I2C_MUX_GPIO
 	tristate "GPIO-based I2C multiplexer"


-- 
Jean Delvare

Re: [uml-devel] Emulate I2C subsystem/slaves

[Peter Hüwe]

> That's why it may break. If you remove the depends on HAS_IOMEM, it will be
> built on s390 and fail if that codes uses io memory functions. Depending
> on GENERIC_IO fixes that.

Everything I can select in I2C subsystem compiles fine on s390.
(using defconfig + menuconfig).
Just compiled it.

Thanks,
Peter

Re: [uml-devel] Emulate I2C subsystem/slaves

[Peter Hüwe]

Hi Jean,
Am Sonntag, 9. September 2012, 20:40:36 schrieb Jean Delvare:
> There is a problem with the mux chip drivers, which then no longer
> depend on HAS_IOMEM.
The selectables on my x86 and UML machine build fine ;)
But you're correct, we should exclude/guard them.

> Also, I think it is about time to admit that
> i2c-stub does not fit under "I2C Hardware Bus support". It is a driver
> for development, not hardware support.
> 
> So I propose the following instead:
> 
>  drivers/i2c/Kconfig        |   14 +++++++++++++-
>  drivers/i2c/busses/Kconfig |   14 +-------------
>  drivers/i2c/muxes/Kconfig  |    2 +-
>  3 files changed, 15 insertions(+), 15 deletions(-)


I'm perfectly fine with this.

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>

Re: [uml-devel] Emulate I2C subsystem/slaves

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

Am 09.09.2012 21:12, schrieb Peter Hüwe:
>> That's why it may break. If you remove the depends on HAS_IOMEM, it will be
>> built on s390 and fail if that codes uses io memory functions. Depending
>> on GENERIC_IO fixes that.
> 
> Everything I can select in I2C subsystem compiles fine on s390.
> (using defconfig + menuconfig).
> Just compiled it.

Very good. :-)

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [uml-devel] Emulate I2C subsystem/slaves

[Jean Delvare]

On Sun, 9 Sep 2012 21:17:20 +0200, Peter Hüwe wrote:
> Hi Jean,
> Am Sonntag, 9. September 2012, 20:40:36 schrieb Jean Delvare:
> > There is a problem with the mux chip drivers, which then no longer
> > depend on HAS_IOMEM.
> The selectables on my x86 and UML machine build fine ;)
> But you're correct, we should exclude/guard them.
> 
> > Also, I think it is about time to admit that
> > i2c-stub does not fit under "I2C Hardware Bus support". It is a driver
> > for development, not hardware support.
> > 
> > So I propose the following instead:
> > 
> >  drivers/i2c/Kconfig        |   14 +++++++++++++-
> >  drivers/i2c/busses/Kconfig |   14 +-------------
> >  drivers/i2c/muxes/Kconfig  |    2 +-
> >  3 files changed, 15 insertions(+), 15 deletions(-)
> 
> 
> I'm perfectly fine with this.
> 
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>

I slept over it and my approach makes little sense for multiplexing.
i2c-mux is useless without at least one multiplexer driver, and
with my patch, the user can't select any without CONFIG_IOMEM.

So either i2c-mux should depend on CONFIG_IOMEM too (in which case we
no longer need this dependency in drivers/i2c/muxes/Kconfig, as we will
get it by transitivity) or we should let i2c multiplexer drivers be
built even without CONFIG_IOMEM. After all, if they can be selected,
they will build, as they are all accessing the hardware indirectly
(through gpio or i2c layers.)

At the moment, it makes no sense to enable multiplexing without
CONFIG_IOMEM, as the only driver which can instantiate a root I2C
segment is i2c-stub and that driver wouldn't know how to deal with
multiplexing. So option #1 has my favors for now. If anyone ever
implements multiplexing emulation in i2c-stub then we can revisit and
let i2c-mux + the driver for the emulated mux chip be built
under !CONFIG_IOMEM. OK?

I also noticed that I2C_DEBUG_BUS has no effect under !CONFIG_IOMEM
with my previous patch, so we can hide it.

Leads me to:

From: Peter Huewe <peterhuewe@gmx.de>
Subject: i2c: Make I2C available on UML

Remove the global dependency of the I2C subsystem on HAS_IOMEM and
move the dependency to the i2c/busses submenu, with an exception for
i2c-stub.

The generic I2C part does not need to have HAS_IOMEM set and thus now
becomes available in UML, so the I2C subsystem can now be used, e.g.
by the i2c-stub driver, for development of I2C device drivers.

[JD: Some adjustments.]

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
 drivers/i2c/Kconfig        |   16 +++++++++++++++-
 drivers/i2c/busses/Kconfig |   14 +-------------
 2 files changed, 16 insertions(+), 14 deletions(-)

--- linux-3.6-rc4.orig/drivers/i2c/Kconfig	2012-07-21 22:58:29.000000000 +0200
+++ linux-3.6-rc4/drivers/i2c/Kconfig	2012-09-10 09:19:06.485756611 +0200
@@ -4,7 +4,6 @@
 
 menuconfig I2C
 	tristate "I2C support"
-	depends on HAS_IOMEM
 	select RT_MUTEXES
 	---help---
 	  I2C (pronounce: I-squared-C) is a slow serial bus protocol used in
@@ -49,6 +48,7 @@ config I2C_CHARDEV
 
 config I2C_MUX
 	tristate "I2C bus multiplexing support"
+	depends on HAS_IOMEM
 	help
 	  Say Y here if you want the I2C core to support the ability to
 	  handle multiplexed I2C bus topologies, by presenting each
@@ -86,6 +86,19 @@ config I2C_SMBUS
 source drivers/i2c/algos/Kconfig
 source drivers/i2c/busses/Kconfig
 
+config I2C_STUB
+	tristate "I2C/SMBus Test Stub"
+	depends on EXPERIMENTAL && m
+	default 'n'
+	help
+	  This module may be useful to developers of SMBus client drivers,
+	  especially for certain kinds of sensor chips.
+
+	  If you do build this module, be sure to read the notes and warnings
+	  in <file:Documentation/i2c/i2c-stub>.
+
+	  If you don't know what to do here, definitely say N.
+
 config I2C_DEBUG_CORE
 	bool "I2C Core debugging messages"
 	help
@@ -103,6 +116,7 @@ config I2C_DEBUG_ALGO
 
 config I2C_DEBUG_BUS
 	bool "I2C Bus debugging messages"
+	depends on HAS_IOMEM
 	help
 	  Say Y here if you want the I2C bus drivers to produce a bunch of
 	  debug messages to the system log.  Select this if you are having
--- linux-3.6-rc4.orig/drivers/i2c/busses/Kconfig	2012-09-08 09:36:32.000000000 +0200
+++ linux-3.6-rc4/drivers/i2c/busses/Kconfig	2012-09-09 18:33:58.598196535 +0200
@@ -3,6 +3,7 @@
 #
 
 menu "I2C Hardware Bus support"
+	depends on HAS_IOMEM
 
 comment "PC SMBus host controller drivers"
 	depends on PCI
@@ -850,19 +851,6 @@ config I2C_SIBYTE
 	help
 	  Supports the SiByte SOC on-chip I2C interfaces (2 channels).
 
-config I2C_STUB
-	tristate "I2C/SMBus Test Stub"
-	depends on EXPERIMENTAL && m
-	default 'n'
-	help
-	  This module may be useful to developers of SMBus client drivers,
-	  especially for certain kinds of sensor chips.
-
-	  If you do build this module, be sure to read the notes and warnings
-	  in <file:Documentation/i2c/i2c-stub>.
-
-	  If you don't know what to do here, definitely say N.
-
 config SCx200_I2C
 	tristate "NatSemi SCx200 I2C using GPIO pins (DEPRECATED)"
 	depends on SCx200_GPIO


If everybody is happy with this, I'll queue it up for 3.7.

-- 
Jean Delvare

Re: [uml-devel] Emulate I2C subsystem/slaves

[Peter Hüwe]

Am Montag, 10. September 2012, 09:29:18 schrieb Jean Delvare: 
> If everybody is happy with this, I'll queue it up for 3.7.

I'm happy with this ;)

Thanks,
Peter

Re: [uml-devel] Emulate I2C subsystem/slaves

[Richard Weinberger]

Am Mon, 10 Sep 2012 21:21:52 +0200
schrieb Peter Hüwe <PeterHuewe@gmx.de>:

> Am Montag, 10. September 2012, 09:29:18 schrieb Jean Delvare: 
> > If everybody is happy with this, I'll queue it up for 3.7.
> 
> I'm happy with this ;)
> 

As no UML specific changes are needed I'm also fine.^^

Thanks,
//richard