On Sun, Jul 5, 2009 at 22:56, Jean Delvare<khali@xxxxxxxxxxxx> wrote: > On Sun, 5 Jul 2009 22:19:46 +0200, Kay Sievers wrote: >> > * 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. > > In which git tree? In Linus' tree, struct bus_type definitely doesn't > use dev_pm_ops yet. But it removed all the other stuff: commit 00725787511e20dbd1fdc1fb233606120ae5c8cf Author: Magnus Damm <damm@xxxxxxxxxx> Date: Thu Jun 4 22:13:25 2009 +0200 PM: Remove device_type suspend()/resume() >> > * 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. > > It will probably have do be a little different, as it is valid to > register a device without a parent, to have it appear at the root > (actually 1st level) of the device tree. So we'll need a way to > differentiate between this case and the virtual device case. > > I admit I am a little surprised that I am the first person asking for > virtual bus devices, especially given how you like to repeat that i2c > was doing things differently from the rest of the world so far and I am > merely changing i2c to fit in the common model. Usually bus devices are a child of root device like pci or some platform stuff. If i2c does not have any parents like this, and is by itself a root for other stuff, maybe we get /sys/devices/i2c, like we have for pci, acpi, ccw (IBM s390), and all these device roots. >> > 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. > > Yes, this is a good summary of my needs. With some room for discussion > on both points: > * Do we need an actually struct class for each fake class, or just a > class name? We will need to create a kobject for the compat class directory, we will not need a "struct class" for it and can just use a simple pointer to the registered kobject. If we use a string, we would need to find the registered kobject with every call to create a link there, not necessarily bad, but an explicitely registered object might be easier. > * Do we want to put virtual devices in devices/virtual directly, or do > we want separate namespaces? > But these are details which can be solved on the way, and I have no > strong opinion about them anyway. It's basically the question if these objects usually represent real hardware or not. If the root i2c device just happens to have no other existing bus as a parent, we might just want: /sys/devices/i2c/. 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
