linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Takashi Iwai <tiwai@suse.de>,
	linuxppc-dev@ozlabs.org, alsa-devel@alsa-project.org,
	Tim Shepard <shep@alum.mit.edu>, Jaroslav Kysela <perex@perex.cz>
Subject: Re: [PATCH] sound: Don't assume i2c device probing always succeeds
Date: Wed, 30 Sep 2009 17:57:44 +0200	[thread overview]
Message-ID: <20090930175744.2ad791d3@hyperion.delvare> (raw)
In-Reply-To: <1254323111.3959.6.camel@johannes.local>

On Wed, 30 Sep 2009 17:05:11 +0200, Johannes Berg wrote:
> On Wed, 2009-09-30 at 17:00 +0200, Jean Delvare wrote:
> 
> > The NULL check of client->driver, if followed by a call to
> > i2c_unregister_device(), would indeed be enough. But unlike the onyx
> > driver which we know we sometimes load erroneously, the other drivers
> > should never fail.
> 
> All of these drivers can be loaded manually and then fail though, or am
> I misunderstanding something?

I don't think so. At least tas and keywest have checks before they
attempt to instantiate an i2c client, which I think are reliable. The
onyx case is different because apparently some machines have it but are
difficult to detect:

	/* if that didn't work, try desperate mode for older
	 * machines that have stuff missing from the device tree */

And then we have to attempt to instantiate i2c devices at a not
completely known address, and that may fail. I think this is the reason
why onyx has this extra client->driver NULL check and the other two
drivers do not.

I would really love if someone with good knowledge of the device tree
on mac would convert all these hacks to proper i2c device declarations.
All the infrastructure is available already, but I don't know enough
about open firmware and mac the device tree to do it myself.

-- 
Jean Delvare

  reply	other threads:[~2009-09-30 15:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-30 13:25 [PATCH] sound: Don't assume i2c device probing always succeeds Jean Delvare
2009-09-30 14:13 ` Takashi Iwai
2009-09-30 15:00   ` Jean Delvare
2009-09-30 15:05     ` Johannes Berg
2009-09-30 15:57       ` Jean Delvare [this message]
2009-09-30 15:15     ` Takashi Iwai
2009-09-30 16:55       ` Jean Delvare
2009-10-01  6:52         ` Takashi Iwai
2009-10-04  9:35           ` Jean Delvare
2009-10-05  5:30             ` Takashi Iwai

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=20090930175744.2ad791d3@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=johannes@sipsolutions.net \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=perex@perex.cz \
    --cc=shep@alum.mit.edu \
    --cc=tiwai@suse.de \
    /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).