Re: [uml-devel] Emulate I2C subsystem/slaves
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 peterhu...@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 peterhu...@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 peterhu...@gmx.de Signed-off-by: Jean Delvare kh...@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.0 +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.0 +0200 +++ linux-3.6-rc4/drivers/i2c/busses/Kconfig2012-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
Re: [uml-devel] Emulate I2C subsystem/slaves
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 -- 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
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 signature.asc Description: OpenPGP digital signature -- 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
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 -- 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
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 -- 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
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 -- 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
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 signature.asc Description: OpenPGP digital signature -- 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
On Sun, Sep 9, 2012 at 3:27 PM, Richard Weinberger rich...@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 -- ge...@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 -- 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
Geert Uytterhoeven ge...@linux-m68k.org schrieb: On Sun, Sep 9, 2012 at 3:27 PM, Richard Weinberger rich...@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 -- ge...@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. -- 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
On Sun, 09 Sep 2012 17:00:54 +0200, Richard Weinberger wrote: Geert Uytterhoeven ge...@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 -- 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
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 -- 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
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 From 44d8ec6fa1466c226b605baae9483749ea9de200 Mon Sep 17 00:00:00 2001 From: Peter Huewe peterhu...@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 peterhu...@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 -- 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
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 signature.asc Description: OpenPGP digital signature -- 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