* Jean Delvare | 2010-11-26 20:46:32 [+0100]: >Hi Sebastian, Hi Jean, >Huh? Is pdev a platform device? So you are instantiating platform >devices off a PCI device, and in turn each platform device gets to >create an i2c_adapter device? Yup, exactly. >Now I understand why you needed to craft a unique id. I don't quite get >why you came up with such a complicated setup in the first place >though. What's wrong with just making the i2c_adapter devices direct >children of the PCI device? Is this a limitation of >of_i2c_register_devices() that it needs platform devices to operate on? No. In the end we have one driver which may get probed viaa PCI device or a platform device. This leaves me two choices: - create a platform device out of the PCI device like I did - add PCI probing code to the platform driver so it provides two interfaces If you are look at the i2c_pxa_probe() function then you'll notice that there is no real cut between obtaining ressource informations and setting up the i2c device. So this would require to split this function into pieces and share the code between those two interfaces. While looking at it, I decided against the split. This way the patch way smaller and simpler. I don't see a disadvantage with the platform device here. Well maybe the pdev->id problem :) >Meanwhile I've updated i2c-tools to support dev minors beyond 255. You >should no longer need this, but at least it's ready if we ever need it. >Who knows, maybe we'll see a system with more than 255 I2C bus segments >someday. Yeah, I don't right now. Sebastian -- 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
