From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Alexander Holler <holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Till Harbaum <till-RcHadlBFbzVAfugRpC6u6w@public.gmane.org>
Subject: Re: [PATCH 1/2] i2c: Add possibility for user-defined (i2c-)devices for bus-drivers.
Date: Tue, 13 Nov 2012 22:42:46 +0100 [thread overview]
Message-ID: <20121113224246.768bf734@endymion.delvare> (raw)
In-Reply-To: <50A2BAA2.6090009-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
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 questioning the quality of your code, I did not even look at
> > it. I'm questioning the pertinence of adding yet another way to
> > instantiate i2c devices when we already have 4 which made everybody
> > else happy for the past 3 years AFAIK.
>
> As said, currently there is no way to do that whithout either patching
> the kernel or working in userspace. And a RTC is just an example for a
> device you really want before userspace starts (but imho a very good).
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.
--
Jean Delvare
next prev parent reply other threads:[~2012-11-13 21:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-13 18:06 [PATCH 1/2] i2c: Add possibility for user-defined (i2c-)devices for bus-drivers Alexander Holler
2012-11-13 18:06 ` [PATCH 2/2] i2c: i2c-tiny-usb: Add parameter for optional user-defined devices Alexander Holler
[not found] ` <1352829968-4908-1-git-send-email-holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
2012-11-13 18:55 ` [PATCH 1/2] i2c: Add possibility for user-defined (i2c-)devices for bus-drivers Jean Delvare
[not found] ` <20121113195533.6db71716-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-11-13 20:23 ` Alexander Holler
2012-11-13 20:52 ` [PATCH] i2c: i2c-tiny-usb: Add parameter for optional i2c-devices Alexander Holler
[not found] ` <1352839940-7559-1-git-send-email-holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
2012-11-13 22:42 ` Alan Cox
[not found] ` <20121113224251.20b52f34-38n7/U1jhRXW96NNrWNlrekiAK3p4hvP@public.gmane.org>
2012-11-13 23:41 ` Alexander Holler
[not found] ` <50A2AC28.7050304-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
2012-11-13 21:08 ` [PATCH 1/2] i2c: Add possibility for user-defined (i2c-)devices for bus-drivers Jean Delvare
[not found] ` <20121113220835.111a178a-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-11-13 21:24 ` Alexander Holler
[not found] ` <50A2BAA2.6090009-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
2012-11-13 21:42 ` Jean Delvare [this message]
2012-11-13 23:38 ` Alexander Holler
[not found] ` <50A2DA0C.3090507-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
2012-11-14 9:40 ` Jean Delvare
[not found] ` <20121114104050.79df8cd9-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-11-14 12:38 ` Alexander Holler
[not found] ` <50A390CC.9000208-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
2012-11-14 19:22 ` till-RcHadlBFbzVAfugRpC6u6w
2012-11-14 23:34 ` Alexander Holler
[not found] ` <1639554.ZUOmHr6Yka@lxtiha>
2012-11-15 11:44 ` Alexander Holler
2012-11-19 13:38 ` Alexander Holler
2012-11-23 14:35 ` Alexander Holler
2012-11-14 2:47 ` Alexander Holler
[not found] ` <50A30652.1020208-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
2012-11-14 9:08 ` Alexander Holler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121113224246.768bf734@endymion.delvare \
--to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
--cc=holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=till-RcHadlBFbzVAfugRpC6u6w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).