On Wed, 14 Nov 2012 00:38:52 +0100, Alexander Holler wrote: > Am 13.11.2012 22:42, schrieb Jean Delvare: > > Question is, what will you do the day someone wants to instantiate a > > device for which the default probing mechanism doesn't work? > > Do you solve all problems you and others might have in the future > already now? Not all. But at least I try to avoid artificial limitations when writing new code and to anticipate misbehavior in use cases other than my own. I also try to learn from our past collective mistakes (starting with my own.) For clarity: it doesn't matter if new code doesn't cover all possible present and future use cases, but it should not allow users to screw up their system, and it should be possible to extend it to other foreseeable use cases without breaking compatibility or making the code unmaintainable or the interface ugly and confusing. > > Plus you don't address the main issues. Your syntax gives you no way to > > support two i2c-tiny-usb adapters with different chips at a specific > > address. The sysfs interface supports such a setup. Also instantiating > > It isn't possible to do such, because the only ID available for > i2c-busses is given them at runtime. So people have to live with that > imho artificially problem, if they use my patch. I don't have any other > solution until the numbering is predictable. But I assume you already > know all that, otherwise you wouldn't have mentioned it. The problem is inherent to external, hot-plug I2C adapters. You can't predict their bus number, and actually you can't even always predict their name. In the case of usb-tiny-i2c, you may be able to look-up the bus number from the adapter name, but you won't be able to always differentiate between two adapters, if they are connected to paired USB ports. This is a design issue with the i2c-tiny-usb hardware in the first place. If it is needed to differentiate between adapters, their would need to be a locally unique ID in every adapter, which the kernel can query. I suppose this was not deemed necessary at design time, as most people will only connect one such adapter at a time to their system. So I would agree that the problem I pointed out probably doesn't exist in practice. Still, the limitation should at least be documented. > > the wrong devices is worse than instating a device that doesn't exist > > at all. So the use of i2c_new_probed_device() here will randomly help > > in a limited number of cases and randomly be problematic in others. > > Hard to justify... > > So would you be satisfied if I would make the syntax more complicated by > adding something which would allow them to define if the devices gets > probed? E.g. dev1@addr1,dev2@addr2.noprobe,... ? No. I would be more satisfied (although still not thinking your code should make it into the kernel - but I am no longer the one to decide) if you did use i2c_new_device() instead of i2c_new_probed_device(). You said yourself that this module parameter was for users who knew what they were doing. > > I am not familiar with RTC constraints. What is so important about it > > that it can't wait for user-space? It'll have to wait for the USB and > > I2C stacks to initialize anyway, so it won't be available at the very > > early stages of the boot. > > Try playing with a system which does have the wrong time. There is so > much stuff which depends on the correct time, it is just a pain if the > time is wrong or even the same across multiple system starts. And even > if you know that, you might e.g. forget it and will use git to send some > email and patches with erroneous times. But that is just an example. I have already experienced this and yes, it is a pain. But I would think that a system designed without a RTC in the first place has another way of getting its time correct at boot time, for example NTP. As I understand it the RTC chip is only there to set the system time at boot, right, the actual timekeeping during run-time is still done by the CPU? > And as I said, there might some other devices you might want or need in > the future before usespace starts, so it solves a problem as the one > above which I didn't have solved. ;) Or maybe this will never happen. -- Jean Delvare -- 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
