From: Alexander Holler <holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@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:24:50 +0100 [thread overview]
Message-ID: <50A2BAA2.6090009@ahsoftware.de> (raw)
In-Reply-To: <20121113220835.111a178a-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
Am 13.11.2012 22:08, schrieb Jean Delvare:
>>> No, no, no. We did that 10 years ago, killed all the code 3 years ago
Btw. I wonder where all you kernel devs have learned that "No, no, no".
Do you all attend the same rhetoric courses at some conferences? ;)
>>> [1], let's not do the same mistake again, please. We have a sysfs
>>> interface for instantiating clients dynamically from user-space, it's
>>> way more powerful and flexible than your proposal. Just try plugging two
>>
>> So how do I define a device, e.g. an RTC which I want to have alive
>> before userland starts? Currently imho not possible.
>
> If your system relies on a an RTC clock chip hanging off an USB-to-I2C
> adapter, I'd say your design is very wrong to start with. I can only
> suppose (hope!) you are doing that during some development phase and
> the final hardware design is totally different.
>
> If you need I2C devices to be instantiated early in the boot process,
> this would typically be done by platform code. This is going to be a
> little difficult with i2c-tiny-usb as it was definitely not meant to
> host system-critical chips. But you can probably get it to work if you
> try hard enough (in particular by allowing i2c-tiny-usb to claim
> specific i2c bus number(s).) If you want your development system to
> mimic the final hardware as closely as possible, this is the best
> approach anyway.
I never would develop some hardware meant for usage with Linux which
doesn't have a RTC. But there are several such boards available. E.g.
that currently so much hyped Rasberry PI. So there are certainly some
people which have a usage for such a parameter (including me).
Maybe you could forward your suggestion to those hw-devs which are
responsible for linux-hw without an RTC. I don't know such poeple. ;)
> 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.
> 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).
Regards,
Alexander
next prev parent reply other threads:[~2012-11-13 21:24 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 [this message]
[not found] ` <50A2BAA2.6090009-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
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
[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=50A2BAA2.6090009@ahsoftware.de \
--to=holler-sxc+2es9fhnfweyvqqpykw@public.gmane.org \
--cc=khali-PUYAD+kWke1g9hUCZPvPmw@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).