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
WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <khali@linux-fr.org>
To: Alexander Holler <holler@ahsoftware.de>
Cc: linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
Till Harbaum <till@harbaum.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@ahsoftware.de>
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: 36+ 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 ` 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
2012-11-13 18:55 ` Jean Delvare
[not found] ` <20121113195533.6db71716-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-11-13 20:23 ` Alexander Holler
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
2012-11-13 22:42 ` Alan Cox
[not found] ` <20121113224251.20b52f34-38n7/U1jhRXW96NNrWNlrekiAK3p4hvP@public.gmane.org>
2012-11-13 23:41 ` Alexander Holler
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
2012-11-13 21:08 ` Jean Delvare
[not found] ` <20121113220835.111a178a-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-11-13 21:24 ` Alexander Holler
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 21:42 ` Jean Delvare
2012-11-13 23:38 ` Alexander Holler
[not found] ` <50A2DA0C.3090507-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
2012-11-14 9:40 ` Jean Delvare
2012-11-14 9:40 ` Jean Delvare
[not found] ` <20121114104050.79df8cd9-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-11-14 12:38 ` Alexander Holler
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 19:22 ` till
2012-11-14 23:34 ` Alexander Holler
2012-11-14 23:34 ` Alexander Holler
[not found] ` <1639554.ZUOmHr6Yka@lxtiha>
2012-11-15 11:44 ` Alexander Holler
2012-11-15 11:44 ` Alexander Holler
2012-11-19 13:38 ` Alexander Holler
2012-11-19 13:38 ` Alexander Holler
2012-11-23 14:35 ` 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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.