From: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Cc: Jon Smirl <jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Michael Lawnick <ml.lawnick-Mmb7MZpHnFY@public.gmane.org>,
Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Delvare,
Jean" <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Subject: Re: [Patch] MPC Adapter: read class attribute from device tree
Date: Sun, 3 May 2009 23:13:01 +0100 [thread overview]
Message-ID: <20090503221301.GA5750@fluff.org.uk> (raw)
In-Reply-To: <49F575E2.1070005-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Mon, Apr 27, 2009 at 11:07:46AM +0200, Wolfgang Grandegger wrote:
> Jon Smirl wrote:
> > On Fri, Apr 24, 2009 at 6:53 AM, Michael Lawnick <ml.lawnick-Mmb7MZpHnFY@public.gmane.org> wrote:
> >> Wolfram Sang said the following:
> >> ...
> >>>> Allowing only clients that are mentioned in DTS?
> >>> For now, yes. This is still the common case (=avoid probing). Until a
> >>> mainline solution comes up (which is needed, I agree on that), not so
> >>> common cases could simply patch the driver to add a .class field.
> >>>
> >> Especially it is ugly that devices which are mentioned in DTS but are
> >> not present (because the component isn't plugged in or powered) get an
> >> directory entry in /sys/bus/i2c/devices with bind, unbind, ...
> >> This is my 'problem': I search for a clean way to instantiate on demand
> >> with no zombies in case of missing H/W. I know there are problems in
> >> identification of devices, but to remove all possibilities to try it
> >> seems not a good way for me.
> >
> > You might want to ask about this on the linux-ppc mailing list.
> >
> > You're stuck because i2c hardware does not support hotplug. Since the
> > hardware doesn't support hotplug there's no software support for it in
> > the kernel. So you want to fall back to polled probing.
> >
> > But probing is bad because it isn't standardized and coordinated, one
> > device's probe can cause another device to destroy things (like set a
> > voltage too high on a motherboard). Because of this probing can't be
> > turned on in general.
>
> To decide if a device exists and responds at a specified I2C address, it
> would be sufficient to just read some data without causing trouble. Is
> that assumption correct or have I missed something? Trying to identify
> the device is a different issue and should be avoided.
It depends if you know what you are expecting to find there, due to
the limited addressing space used by i2c, a number of devices use the
same address and often do not have any indentification information.
Worse, doing a read of the chip requires knowing whether you need to
issue an register address or not, so this makes life even harder if
you are trying to do some form of autodetect.
> Wolfgang.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
next prev parent reply other threads:[~2009-05-03 22:13 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-21 6:42 [Patch] MPC Adapter: read class attribute from device tree Michael Lawnick
[not found] ` <49ED6AD3.2060808-Mmb7MZpHnFY@public.gmane.org>
2009-04-21 7:00 ` Wolfgang Grandegger
[not found] ` <49ED6F03.5050107-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2009-04-21 9:26 ` Michael Lawnick
[not found] ` <49ED9132.9050806-Mmb7MZpHnFY@public.gmane.org>
2009-04-21 9:51 ` Wolfram Sang
[not found] ` <20090421095112.GB3100-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2009-04-21 13:05 ` Michael Lawnick
[not found] ` <49EDC487.8010201-Mmb7MZpHnFY@public.gmane.org>
2009-04-21 13:37 ` Wolfgang Grandegger
[not found] ` <49EDCC31.2030506-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2009-04-21 14:22 ` Michael Lawnick
[not found] ` <49EDD69D.1020104-Mmb7MZpHnFY@public.gmane.org>
2009-04-22 7:38 ` Wolfgang Grandegger
2009-04-24 8:52 ` Wolfram Sang
[not found] ` <20090424085256.GA26169-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2009-04-24 9:35 ` Jean Delvare
[not found] ` <20090424113527.4fb94f38-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-04-24 10:49 ` Michael Lawnick
2009-04-24 10:53 ` Michael Lawnick
[not found] ` <49F19A11.3090700-Mmb7MZpHnFY@public.gmane.org>
2009-04-24 15:38 ` Jon Smirl
[not found] ` <9e4733910904240838k5f425d7m849cd6b7fad19f27-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-04-27 5:54 ` Michael Lawnick
2009-04-27 9:07 ` Wolfgang Grandegger
[not found] ` <49F575E2.1070005-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2009-05-03 22:13 ` Ben Dooks [this message]
2009-04-27 10:17 ` Jean Delvare
[not found] ` <20090427121758.7965c48a-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-05-20 6:28 ` Jean Delvare
2009-04-21 9:59 ` Jean Delvare
[not found] ` <20090421115936.28656d09-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-04-21 14:11 ` Michael Lawnick
[not found] ` <49EDD423.3050302-Mmb7MZpHnFY@public.gmane.org>
2009-04-21 16:00 ` Jon Smirl
[not found] ` <9e4733910904210900r4c5d1a8en178ad106134b7e6d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-04-21 16:33 ` Jean Delvare
[not found] ` <20090421183310.50ff7e0c-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-04-21 19:18 ` Jon Smirl
[not found] ` <9e4733910904211218l8428128k1f8dd021c50c7846-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-04-22 5:37 ` Michael Lawnick
2009-04-24 9:09 ` Wolfram Sang
2009-04-22 7:40 ` Jean Delvare
2009-04-21 10:35 ` Wolfgang Grandegger
[not found] ` <49EDA185.7040206-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2009-04-21 11:01 ` Jean Delvare
[not found] ` <20090421130134.1e82a078-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-04-21 11:26 ` Wolfgang Grandegger
2009-04-21 8:37 ` Wolfram Sang
2009-04-21 8:39 ` Jean Delvare
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=20090503221301.GA5750@fluff.org.uk \
--to=ben-linux-elnmno+kys3ytjvyw6ydsg@public.gmane.org \
--cc=jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=ml.lawnick-Mmb7MZpHnFY@public.gmane.org \
--cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=wg-5Yr1BZd7O62+XT7JhA+gdA@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).