On Tue, 13 Nov 2012 22:24:50 +0100, Alexander Holler wrote:Am 13.11.2012 22:08, schrieb Jean Delvare:It probes in the sense "check if a device is present", not in the sense
"check if the device there is really what the user told me." So very
easy to get wrong. Plus there is no universal probe method on I2C,
i2c_new_probed_device() uses a default heuristic which may not only
fail to detect a device's presence, but may even heavily confuse the
device in question. Usage of i2c_new_probed_device() should be limited
to very specific cases.
I know about that too. But I prefer such a probe instead of doing it
without an probe. Just try what happens if you add e.g. an pcf8563 (or
ds1307) which is not available. The driver doesn't care and you will
find an /dev/rtcN afterwards in your system. So probing is imho better
than not.
Question is, what will you do the day someone wants to instantiate a
device for which the default probing mechanism doesn't work?
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
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...
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.