All of lore.kernel.org
 help / color / mirror / Atom feed
From: lutchann@litech.org (Nathan Lutchansky)
To: Jean Delvare <khali@linux-fr.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	LM Sensors <lm-sensors@lm-sensors.org>, Greg KH <greg@kroah.com>
Subject: [lm-sensors] Re: [PATCH 4/5] add i2c_probe_device and
Date: Tue, 16 Aug 2005 05:34:30 +0000	[thread overview]
Message-ID: <20050816033353.GI24959@litech.org> (raw)
In-Reply-To: <20050816001413.50b9c6be.khali@linux-fr.org>

On Tue, Aug 16, 2005 at 12:14:13AM +0200, Jean Delvare wrote:
> > These functions can be used for special-purpose adapters, such as
> > those on TV tuner cards, where we generally know in advance what
> > devices are attached.  This is important in cases where the adapter
> > does not support probing or when probing is potentially dangerous to
> > the connected devices.
> 
> Do you know of any adapter actually not supporting the SMBus Quick
> command (which we use for probing)?

I do, in fact, which is the reason I submitted these patches in the
first place.  :-)

The WIS GO7007, which is the MPEG1/2/4 video encoder used in the Plextor
ConvertX, has an on-board i2c interface that supports nothing but 8-bit
and 16-bit register reads and writes.  Worse, it does not correctly
report i2c errors.  Even if it did support probing, though, I wouldn't
want to use it because the i2c adapter generally lives on the other end
of a USB and requires a minimum of 15 USB round trips per i2c
transaction, so probing 124 i2c addresses would take a while.

> > +	if (kind < 0 && !i2c_check_functionality(adapter,I2C_FUNC_SMBUS_QUICK))
> > +		return -EINVAL;
> 
> Coding style please: one space after the comma. 
> 
> > +
> > +	down(&core_lists);
> > +	list_for_each(item,&drivers) {
> 
> Ditto.

Yeah, I copied those lines from other parts of i2c-core.c.  But I'll fix
them.

> > +		driver = list_entry(item, struct i2c_driver, list);
> > +		if (driver->id = driver_id)
> > +			break;
> > +	}
> > +	up(&core_lists);
> > +	if (!item)
> > +		return -ENOENT;
> > +
> > +	/* Already in use? */
> > +	if (i2c_check_addr(adapter, addr))
> > +		return -EBUSY;
> > +
> > +	/* Make sure there is something at this address, unless forced */
> > +	if (kind < 0) {
> > +		if (i2c_smbus_xfer(adapter, addr, 0, 0, 0,
> > +				   I2C_SMBUS_QUICK, NULL) < 0)
> > +			return -ENODEV;
> > +
> > +		/* prevent 24RF08 corruption */
> > +		if ((addr & ~0x0f) = 0x50)
> > +			i2c_smbus_xfer(adapter, addr, 0, 0, 0,
> > +				       I2C_SMBUS_QUICK, NULL);
> > +	}
> > +
> > +	return driver->detect_client(adapter, addr, kind);
> > +}
> 
> You are duplicating a part of i2c_probe_address() here. Why don't you
> simply call it?

I could, I guess.  Is there a reason i2c_probe_address is limited to
7-bit addresses?  Clients with 10-bit addresses (I've never seen one,
but I guess they exist?) should be able to be instantiated though the
known-device list.

I think the way to go about this would be to rework and resubmit the
first 3 patches once we decide how to handle the no-probe adapter flag,
and later I will send a separate patch set for review with the
known-device list implementation.

Thank you for all your help!  -Nathan

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Lutchansky <lutchann@litech.org>
To: Jean Delvare <khali@linux-fr.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	LM Sensors <lm-sensors@lm-sensors.org>, Greg KH <greg@kroah.com>
Subject: Re: [PATCH 4/5] add i2c_probe_device and i2c_remove_device
Date: Mon, 15 Aug 2005 23:33:53 -0400	[thread overview]
Message-ID: <20050816033353.GI24959@litech.org> (raw)
In-Reply-To: <20050816001413.50b9c6be.khali@linux-fr.org>

On Tue, Aug 16, 2005 at 12:14:13AM +0200, Jean Delvare wrote:
> > These functions can be used for special-purpose adapters, such as
> > those on TV tuner cards, where we generally know in advance what
> > devices are attached.  This is important in cases where the adapter
> > does not support probing or when probing is potentially dangerous to
> > the connected devices.
> 
> Do you know of any adapter actually not supporting the SMBus Quick
> command (which we use for probing)?

I do, in fact, which is the reason I submitted these patches in the
first place.  :-)

The WIS GO7007, which is the MPEG1/2/4 video encoder used in the Plextor
ConvertX, has an on-board i2c interface that supports nothing but 8-bit
and 16-bit register reads and writes.  Worse, it does not correctly
report i2c errors.  Even if it did support probing, though, I wouldn't
want to use it because the i2c adapter generally lives on the other end
of a USB and requires a minimum of 15 USB round trips per i2c
transaction, so probing 124 i2c addresses would take a while.

> > +	if (kind < 0 && !i2c_check_functionality(adapter,I2C_FUNC_SMBUS_QUICK))
> > +		return -EINVAL;
> 
> Coding style please: one space after the comma. 
> 
> > +
> > +	down(&core_lists);
> > +	list_for_each(item,&drivers) {
> 
> Ditto.

Yeah, I copied those lines from other parts of i2c-core.c.  But I'll fix
them.

> > +		driver = list_entry(item, struct i2c_driver, list);
> > +		if (driver->id == driver_id)
> > +			break;
> > +	}
> > +	up(&core_lists);
> > +	if (!item)
> > +		return -ENOENT;
> > +
> > +	/* Already in use? */
> > +	if (i2c_check_addr(adapter, addr))
> > +		return -EBUSY;
> > +
> > +	/* Make sure there is something at this address, unless forced */
> > +	if (kind < 0) {
> > +		if (i2c_smbus_xfer(adapter, addr, 0, 0, 0,
> > +				   I2C_SMBUS_QUICK, NULL) < 0)
> > +			return -ENODEV;
> > +
> > +		/* prevent 24RF08 corruption */
> > +		if ((addr & ~0x0f) == 0x50)
> > +			i2c_smbus_xfer(adapter, addr, 0, 0, 0,
> > +				       I2C_SMBUS_QUICK, NULL);
> > +	}
> > +
> > +	return driver->detect_client(adapter, addr, kind);
> > +}
> 
> You are duplicating a part of i2c_probe_address() here. Why don't you
> simply call it?

I could, I guess.  Is there a reason i2c_probe_address is limited to
7-bit addresses?  Clients with 10-bit addresses (I've never seen one,
but I guess they exist?) should be able to be instantiated though the
known-device list.

I think the way to go about this would be to rework and resubmit the
first 3 patches once we decide how to handle the no-probe adapter flag,
and later I will send a separate patch set for review with the
known-device list implementation.

Thank you for all your help!  -Nathan

  reply	other threads:[~2005-08-16  5:34 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-15 17:51 [PATCH 0/5] improve i2c probing Nathan Lutchansky
2005-08-15 19:51 ` [lm-sensors] " Nathan Lutchansky
2005-08-15 17:52 ` [PATCH 1/5] call i2c_probe from i2c core Nathan Lutchansky
2005-08-15 19:53   ` [lm-sensors] " Nathan Lutchansky
2005-08-15 21:55   ` Jean Delvare
2005-08-15 23:55     ` [lm-sensors] " Jean Delvare
2005-08-16  3:14     ` Nathan Lutchansky
2005-08-16  5:15       ` [lm-sensors] " Nathan Lutchansky
2005-08-16 12:13       ` Jean Delvare
2005-08-16 14:13         ` [lm-sensors] " Jean Delvare
2005-08-15 17:53 ` [PATCH 2/5] remove attach_adapter from i2c hwmon drivers Nathan Lutchansky
2005-08-15 19:54   ` [lm-sensors] [PATCH 2/5] remove attach_adapter from i2c hwmon Nathan Lutchansky
2005-08-15 22:00   ` [PATCH 2/5] remove attach_adapter from i2c hwmon drivers Jean Delvare
2005-08-16  0:00     ` [lm-sensors] Re: [PATCH 2/5] remove attach_adapter from i2c hwmon Jean Delvare
2005-08-15 17:54 ` [PATCH 3/5] remove attach_adapter from misc i2c chip drivers Nathan Lutchansky
2005-08-15 19:54   ` [lm-sensors] [PATCH 3/5] remove attach_adapter from misc i2c chip Nathan Lutchansky
2005-08-15 17:54 ` [PATCH 4/5] add i2c_probe_device and i2c_remove_device Nathan Lutchansky
2005-08-15 19:55   ` [lm-sensors] " Nathan Lutchansky
2005-08-15 22:14   ` Jean Delvare
2005-08-16  0:14     ` [lm-sensors] Re: [PATCH 4/5] add i2c_probe_device and Jean Delvare
2005-08-16  3:33     ` Nathan Lutchansky [this message]
2005-08-16  5:34       ` Nathan Lutchansky
2005-08-16 16:38       ` [PATCH 4/5] add i2c_probe_device and i2c_remove_device Jean Delvare
2005-08-16 18:38         ` [lm-sensors] Re: [PATCH 4/5] add i2c_probe_device and Jean Delvare
2005-08-15 17:55 ` [PATCH 5/5] new flag to disable i2c probing for an adapter Nathan Lutchansky
2005-08-15 19:55   ` [lm-sensors] [PATCH 5/5] new flag to disable i2c probing for an Nathan Lutchansky
2005-08-15 21:39 ` [PATCH 0/5] improve i2c probing Jean Delvare
2005-08-16  9:43   ` [lm-sensors] " Jean Delvare
2005-08-16  3:05   ` Nathan Lutchansky
2005-08-16 10:01     ` [lm-sensors] " Nathan Lutchansky
2005-08-16 20:30     ` Jean Delvare
2005-08-16 22:30       ` [lm-sensors] " Jean Delvare
2005-08-18 18:54 ` Greg KH
2005-08-18 20:56   ` [lm-sensors] " Greg KH
2005-08-20  0:11   ` Nathan Lutchansky
2005-08-20  2:12     ` [lm-sensors] " Nathan Lutchansky

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=20050816033353.GI24959@litech.org \
    --to=lutchann@litech.org \
    --cc=greg@kroah.com \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.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.