[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121105161920.44e8e1cb@endymion.delvare>
Date: Mon, 5 Nov 2012 16:19:20 +0100
From: Jean Delvare <khali@...ux-fr.org>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
Linus Walleij <linus.walleij@...aro.org>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
linux-kernel@...r.kernel.org, lenb@...nel.org,
rafael.j.wysocki@...el.com, grant.likely@...retlab.ca,
ben-linux@...ff.org, w.sang@...gutronix.de,
mathias.nyman@...ux.intel.com, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support
On Mon, 5 Nov 2012 16:53:15 +0200, Mika Westerberg wrote:
> On Mon, Nov 05, 2012 at 03:19:58PM +0100, Rafael J. Wysocki wrote:
> >
> > In the ACPI namespace we have device nodes and serial interfaces below them.
> > In the above case we see that a single device node supports two different
> > interfaces and in that case we probably should create two different
> > struct i2c_adapter objects for the same ACPI device node.
> >
> > Mika, what do you think?
>
> I agree.
>
> Only problem I see is that then we have two I2C adapter devices with the
> same ACPI ID (and hence the same i2c_client->name). I wonder what the I2C
> core thinks about that.
I2C core fears that you're mixing up everything ;) I2C adapter devices
are struct i2c_adapter aka i2c-0, i2c-1 etc. i2c_client is for slave
devices. There's nothing wrong with i2c_clients sharing ->name, that's
even how device driver matching is achieved. The uniqueness of
i2c_clients is on their bus_id which is the combination of i2c adapter
number and slave address (e.g. 0-0050)
i2c_adapter->name should, OTOH, be unique. In i2c bus drivers we
usually append the base I/O address at the end of the name to guarantee
that. ACPI will have to come up with something similar.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists