On Sat, Jul 4, 2009 at 19:14, Jean Delvare<khali@xxxxxxxxxxxx> wrote: > On Mon, 4 May 2009 14:40:36 +0200, Kay Sievers wrote: >> (The less difference between classes and buses the better. It is wrong >> to have two types of subsystems, doing almost the same thing. One >> could argue that it could be useful inside the kernel, which it isn't, >> I think, but exporting them to userspace was definitely the wrong >> thing.) > > I finally took a stab at this. The resulting patch is below. I have > used device_type to differentiate between I2C clients and I2C adapters. > Is this what you had in mind? Looks fine, by just looking at the patch. > It seems to work reasonably well, with the following issues remaining: > > * The change breaks at least sensors-detect and libsensors. I can > easily modify them so that they work again, but we still have a > compatibility issue. Is it possible to have a compatibility option > that would add symbolic links from class/i2c-adapter/i2c-* to > bus/i2c/devices/i2c-* for a couple years? Yeah, we can add that. I guess others will need that too, if we convert things from class to bus. How would that look like? Like a device_add_class_compat_link(*dev, *class)? > * Now that i2c-core makes use of device_type, I tried to move the power > management handling callbacks there from bus_type, to save a test in > each function, however I found that the callback set is different > between bus_type and device_type.pm. Why is it so? Is there a document > explaining the difference? Is the whole world (including bus_type) > eventually moving to dev_pm_ops? I think this is already removed in the current git tree, and all should use dev_pm_ops, yes. > * When i2c-adapters were class devices, virtual ones (for example > i2c-stub) appeared in sysfs as devices/virtual/i2c-adapter/i2c-*, > which made sense and seemed safe. Now that I have turned them into > bus devices, virtual ones appear in sysfs as devices/i2c-* directly, > which looks dirty and could result in collisions someday. What should > be done about this? I wanted to use virtual_device_parent() but it is > internal to the driver core at the moment, and doesn't even exist if > CONFIG_SYSFS_DEPRECATED=y. Yeah, we just need to apply the /sys/devices/virtual logic to bus devices too, it's currently limited to class devices, because there was no bus device so far who needed this, but should be an easy change. > I would be grateful if you can advise on any of the above points. If you decide to do it that way, you would need the driver core to be able: - to create a link from an otherwise empty "struct class" to an existing bus-device - put bus devices without a parent into the /sys/devices/virtual logic right? Let me know, I can look into that, if you need that. Thanks, Kay -- 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
