From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Subject: Re: [PATCH 0/4] i2c: Introduce i2c listeners Date: Wed, 4 Jun 2008 17:27:51 -0700 Message-ID: <200806041727.51746.david-b@pacbell.net> References: <20080604201334.19636f30@hyperion.delvare> <20080604233335.13459512@hyperion.delvare> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i2c-bounces-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org Errors-To: i2c-bounces-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org To: Trent Piepho Cc: Linux I2C List-Id: linux-i2c@vger.kernel.org On Wednesday 04 June 2008, Trent Piepho wrote: > Couldn't you say the probe function is called on a potential device? =A0T= he > probe function can return -ENODEV, in which can other driver's probes get > called, and it's perfectly ok if no driver binds to it. > = > The way PCI works, is that when a new pci bus is created, each address is > probed ... by config space accessors which all PCI devices support. > and a device is created if anything responds. =A0The generic bus code = > tries to match each device to a driver or drivers ... using a formally managed set of product identifiers. > and calls those drivers' = > probe functions. =A0The drivers don't have to claim the device in the pro= be > function. =A0The bus code handles all the cases of a driver or bus getting > added or removed in various orders. > = > So why can't I2C do this too? No such product identifiers, and in general no way to tell what's sitting at a given address. And in fact, there's no sure way to tell if a device is present there, since when an I2C device is busy, it's not required to ack its address. _______________________________________________ i2c mailing list i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org http://lists.lm-sensors.org/mailman/listinfo/i2c