All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin@ozlabs.org, linuxppc-dev@ozlabs.org,
	alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c    drivers
Date: Thu, 9 Apr 2009 16:21:42 +0200	[thread overview]
Message-ID: <20090409162142.653decf9@hyperion.delvare> (raw)
In-Reply-To: <1239280485.4953.6.camel@johannes.local>

Hi Johannes,

On Thu, 09 Apr 2009 14:34:44 +0200, Johannes Berg wrote:
> > My new approach doesn't auto-load anything. Here we go, what you think?
> > This time there is no logic change, I'm really only turning legacy code
> > into new-style i2c code (basically calling i2c_new_device() instead of
> > i2c_attach_client()) and that's about it.
> > 
> > (Once again this is only build-tested and I would like people with the
> > hardware to give it a try.)
> 
> Looks reasonable.
> 
> >  static int onyx_create(struct i2c_adapter *adapter,
> >  		       struct device_node *node,
> >  		       int addr)
> >  {
> > +	struct i2c_board_info info;
> > +	struct i2c_client *client;
> > +
> > +	memset(&info, 0, sizeof(struct i2c_board_info));
> > +	strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE);
> > +	if (node) {
> > +		info.addr = addr;
> > +		info.platform_data = node;
> > +		client = i2c_new_device(adapter, &info);
> > +	} else {
> > +		/* probe both possible addresses for the onyx chip */
> > +		unsigned short probe_onyx[] = {
> > +			0x46, 0x47, I2C_CLIENT_END
> > +		};
> > +
> > +		client = i2c_new_probed_device(adapter, &info, probe_onyx);
> > +	}
> > +	if (!client)
> > +		return -ENODEV;
> > +
> > +	list_add_tail(&client->detected, &client->driver->clients);
> 
> That list_add looks a little hackish, and wouldn't it be racy?

Yes it is a little hackish, the idea is to let i2c-core remove the
device if our i2c_driver is removed (which happens when you rmmod the
module). I'll add a comment to explain that. If there are more use
cases I might move that to a helper function in i2c-core.

No it's not racy, we're called with i2c-core's main mutex held.

> > +static const struct i2c_device_id onyx_i2c_id[] = {
> > +	{ "aoa_codec_onyx", 0 },
> > +	{ }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, onyx_i2c_id);
> 
> Should it really export the device table?
> 
> (same comments for tas)

No, that's a leftover, I intended to remove it but forgot. It's gone
now. That being said, it's useless, but I don't think it would hurt.

> It'll be until mid next week that I can test anything.

OK, thanks.

-- 
Jean Delvare

WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <khali@linux-fr.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin, linuxppc-dev@ozlabs.org, alsa-devel@alsa-project.org,
	Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c    drivers
Date: Thu, 9 Apr 2009 16:21:42 +0200	[thread overview]
Message-ID: <20090409162142.653decf9@hyperion.delvare> (raw)
In-Reply-To: <1239280485.4953.6.camel@johannes.local>

Hi Johannes,

On Thu, 09 Apr 2009 14:34:44 +0200, Johannes Berg wrote:
> > My new approach doesn't auto-load anything. Here we go, what you think?
> > This time there is no logic change, I'm really only turning legacy code
> > into new-style i2c code (basically calling i2c_new_device() instead of
> > i2c_attach_client()) and that's about it.
> > 
> > (Once again this is only build-tested and I would like people with the
> > hardware to give it a try.)
> 
> Looks reasonable.
> 
> >  static int onyx_create(struct i2c_adapter *adapter,
> >  		       struct device_node *node,
> >  		       int addr)
> >  {
> > +	struct i2c_board_info info;
> > +	struct i2c_client *client;
> > +
> > +	memset(&info, 0, sizeof(struct i2c_board_info));
> > +	strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE);
> > +	if (node) {
> > +		info.addr = addr;
> > +		info.platform_data = node;
> > +		client = i2c_new_device(adapter, &info);
> > +	} else {
> > +		/* probe both possible addresses for the onyx chip */
> > +		unsigned short probe_onyx[] = {
> > +			0x46, 0x47, I2C_CLIENT_END
> > +		};
> > +
> > +		client = i2c_new_probed_device(adapter, &info, probe_onyx);
> > +	}
> > +	if (!client)
> > +		return -ENODEV;
> > +
> > +	list_add_tail(&client->detected, &client->driver->clients);
> 
> That list_add looks a little hackish, and wouldn't it be racy?

Yes it is a little hackish, the idea is to let i2c-core remove the
device if our i2c_driver is removed (which happens when you rmmod the
module). I'll add a comment to explain that. If there are more use
cases I might move that to a helper function in i2c-core.

No it's not racy, we're called with i2c-core's main mutex held.

> > +static const struct i2c_device_id onyx_i2c_id[] = {
> > +	{ "aoa_codec_onyx", 0 },
> > +	{ }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, onyx_i2c_id);
> 
> Should it really export the device table?
> 
> (same comments for tas)

No, that's a leftover, I intended to remove it but forgot. It's gone
now. That being said, it's useless, but I don't think it would hurt.

> It'll be until mid next week that I can test anything.

OK, thanks.

-- 
Jean Delvare

  reply	other threads:[~2009-04-09 14:21 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-08 13:02 [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers Jean Delvare
2009-04-08 13:02 ` Jean Delvare
2009-04-08 15:51 ` Johannes Berg
2009-04-08 15:51   ` Johannes Berg
2009-04-08 20:48   ` Jean Delvare
2009-04-08 20:48     ` Jean Delvare
2009-04-09  7:44     ` Johannes Berg
2009-04-09  7:44       ` Johannes Berg
2009-04-09 12:19       ` Jean Delvare
2009-04-09 12:19         ` Jean Delvare
2009-04-09 12:34         ` Johannes Berg
2009-04-09 12:34           ` Johannes Berg
2009-04-09 14:21           ` Jean Delvare [this message]
2009-04-09 14:21             ` Jean Delvare
2009-04-10 15:02         ` Jean Delvare
2009-04-10 15:02           ` Jean Delvare
2009-04-14 14:37           ` Jean Delvare
2009-04-14 14:37             ` Jean Delvare
2009-04-14 14:45             ` Takashi Iwai
2009-04-16  7:53               ` Jean Delvare
2009-04-16  7:53                 ` Jean Delvare
2009-04-16  7:56                 ` Takashi Iwai
2009-04-16  7:56                   ` Takashi Iwai
2009-04-14 15:40         ` Johannes Berg
2009-04-14 15:40           ` Johannes Berg
2009-04-14 15:50           ` Johannes Berg
2009-04-14 15:50             ` Johannes Berg
2009-04-14 16:57             ` Jean Delvare
2009-04-14 16:57               ` Jean Delvare
2009-04-14 17:41             ` Johannes Berg
2009-04-14 17:41               ` Johannes Berg
2009-04-14 19:49               ` Jean Delvare
2009-04-14 19:49                 ` Jean Delvare
2009-04-14 21:59                 ` Johannes Berg
2009-04-14 21:59                   ` Johannes Berg
2009-04-15 12:15                   ` Jean Delvare
2009-04-15 12:15                     ` Jean Delvare
2009-04-15 12:52                     ` Johannes Berg
2009-04-15 12:52                       ` Johannes Berg
2009-04-15 13:06                       ` Jean Delvare
2009-04-15 13:06                         ` Jean Delvare
2009-04-15 13:18                         ` Johannes Berg
2009-04-15 13:18                           ` Johannes Berg
2009-04-15 13:52                           ` Jean Delvare
2009-04-15 13:52                             ` Jean Delvare
2009-04-14 22:48                 ` Andreas Schwab
2009-04-15  8:19                   ` Jean Delvare
2009-04-15  8:19                     ` Jean Delvare
2009-04-14 16:48           ` Andreas Schwab
2009-04-14 17:20             ` Johannes Berg
2009-04-14 17:20               ` Johannes Berg
  -- strict thread matches above, loose matches on Subject: below --
2009-04-20 20:54 Jean Delvare
2009-04-20 20:54 ` Jean Delvare
2009-04-20 21:04 ` Johannes Berg
2009-04-20 21:04   ` Johannes Berg
2009-04-21  9:29   ` Jean Delvare
2009-04-21  9:41     ` Johannes Berg
2009-04-21  9:41       ` Johannes Berg
2009-04-21  6:30 ` Takashi Iwai
2009-04-21  6: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=20090409162142.653decf9@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=Benjamin@ozlabs.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=johannes@sipsolutions.net \
    --cc=linuxppc-dev@ozlabs.org \
    --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 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.