Jean Delvare said the following: > On Mon, 09 Mar 2009 15:13:16 +0100, Michael Lawnick wrote: >> Hi Jean, >> >> I have now got a 2.6.28.7 Kernel to play with on my board. I assume >> I have to patch some files to get the same play ground as you, >> right? Could you give me the msgIds/links? > > Sorry but I don't quire follow you here. What play ground are you > talking about? > I was talking about the version of I2C sub system you are currently working on ... Oh, I see, the patches of July are already in Kernel 2.6.28.7. >> I'm currently thinking about making a module that allows to trigger >> probing of buses, something like insmod i2cDevProbe.ko >> "modname",busNo,devNo Could finally be integrated into subsystem if >> there are more folks that like it. > > I don't like the idea at all. I know :-D > Module parameters are not exactly a convenient interface. As a matter > of fact this is what we have today, with the difference that the > parameters are passed to relevant driver directly rather than to a > dedicated module (see the I2C_CLIENT_INSMOD* macros in > include/linux/i2c.h), and we are trying to move away from it because > they are highly user-unfriendly. What you propose is slightly better > than what we have in some respects, but that's not a significant > enough improvement to justify the move. > > And your proposal has many drawbacks/lacks, too. For example, how do > you remove a device instance which you have created by mistake? How > do you create a new device instance when the i2cDevProbe.ko module is > already loaded? Just two problems off the top of my head, but there > are probably more. > Well, I currently don't see user space support in the way I need. My module i2cDevProbe will do the probe/attach, a i2cDevDetach will do a remove. Just as a first test version. The idea of module parameters was not meant as the final solution. > I definitely prefer a sysfs-based approach as I initially mentioned, > this is much more flexible. If you have an urgent need for this > feature, we can add an action point to the wiki and start working on > an implementation. I suggest you start with creating your wiki > account then. > Incorporating such methods into subsystem would be much better of course. Probably as a sysFs entry automatically added to every adapter in /sys/class/i2c-adapter/i2c-x AFAICS I will do this in the next weeks. Regarding wiki the other question is whether I can take some official responsibility for such a patch. I'm doing it as a professional, bound to a project. Further development because of kernel changes in future wouldn't be supported in sufficient way :-( -- Regards, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
