From: Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: Srinivas Pandruvada
<srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] i2c / ACPI: Pick the first address if device has multiple
Date: Tue, 13 Jan 2015 19:00:07 +0200 [thread overview]
Message-ID: <20150113170007.GV1386@lahna.fi.intel.com> (raw)
In-Reply-To: <20150113164829.GO7660@katana>
On Tue, Jan 13, 2015 at 05:48:29PM +0100, Wolfram Sang wrote:
> On Tue, Jan 13, 2015 at 08:44:37AM -0800, Srinivas Pandruvada wrote:
> > On Tue, 2015-01-13 at 16:50 +0100, Wolfram Sang wrote:
> > > On Mon, Dec 29, 2014 at 03:48:48PM +0200, Mika Westerberg wrote:
> > > > ACPI specification allows I2C devices with multiple addresses. The current
> > > > implementation goes over all addresses and assigns the last one to the
> > > > device. This is typically not the primary address of the device.
> > > >
> > > > Instead of doing that we assign the first address to the device and then
> > > > let the driver handle rest of the addresses as it wishes.
> > > >
> > > > Signed-off-by: Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > > Cc: Srinivas Pandruvada <srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > >
> > > Yes, seems better than what we do know. But maybe taking the lowest
> > > address is a bit better heuristic than taking the first address?
> > > Not sure, though...
> > The problem in taking lowest is that in many cases in current devices,
> > the lowest address may end being 0x0C, which is reserved address for
> > SMBUS (ARA). This will require different handling. Unfortunately ACPI
> > doesn't have a way to distinguish whether SMBUS support is desired or
> > not.
> > The other option is to skip all reserved addresses for SMBUS also and
> > then create on the lowest.
>
> Well, this makes me think that Mika's approach is probably the sanest
> one...
Also I think it is more consistent that way.
WARNING: multiple messages have this Message-ID (diff)
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i2c / ACPI: Pick the first address if device has multiple
Date: Tue, 13 Jan 2015 19:00:07 +0200 [thread overview]
Message-ID: <20150113170007.GV1386@lahna.fi.intel.com> (raw)
In-Reply-To: <20150113164829.GO7660@katana>
On Tue, Jan 13, 2015 at 05:48:29PM +0100, Wolfram Sang wrote:
> On Tue, Jan 13, 2015 at 08:44:37AM -0800, Srinivas Pandruvada wrote:
> > On Tue, 2015-01-13 at 16:50 +0100, Wolfram Sang wrote:
> > > On Mon, Dec 29, 2014 at 03:48:48PM +0200, Mika Westerberg wrote:
> > > > ACPI specification allows I2C devices with multiple addresses. The current
> > > > implementation goes over all addresses and assigns the last one to the
> > > > device. This is typically not the primary address of the device.
> > > >
> > > > Instead of doing that we assign the first address to the device and then
> > > > let the driver handle rest of the addresses as it wishes.
> > > >
> > > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> > >
> > > Yes, seems better than what we do know. But maybe taking the lowest
> > > address is a bit better heuristic than taking the first address?
> > > Not sure, though...
> > The problem in taking lowest is that in many cases in current devices,
> > the lowest address may end being 0x0C, which is reserved address for
> > SMBUS (ARA). This will require different handling. Unfortunately ACPI
> > doesn't have a way to distinguish whether SMBUS support is desired or
> > not.
> > The other option is to skip all reserved addresses for SMBUS also and
> > then create on the lowest.
>
> Well, this makes me think that Mika's approach is probably the sanest
> one...
Also I think it is more consistent that way.
next prev parent reply other threads:[~2015-01-13 17:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-29 13:48 [PATCH] i2c / ACPI: Pick the first address if device has multiple Mika Westerberg
2014-12-29 13:48 ` Mika Westerberg
2015-01-13 15:50 ` Wolfram Sang
2015-01-13 16:44 ` Srinivas Pandruvada
2015-01-13 16:44 ` Srinivas Pandruvada
[not found] ` <1421167477.4459.229.camel-hINH/TbAiWppyMZ9rn1DP+ejPoqOX1/hEvhb3Hwu1Ks@public.gmane.org>
2015-01-13 16:48 ` Wolfram Sang
2015-01-13 16:48 ` Wolfram Sang
2015-01-13 17:00 ` Mika Westerberg [this message]
2015-01-13 17:00 ` Mika Westerberg
[not found] ` <1419860928-195404-1-git-send-email-mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2015-01-14 10:55 ` Wolfram Sang
2015-01-14 10:55 ` Wolfram Sang
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=20150113170007.GV1386@lahna.fi.intel.com \
--to=mika.westerberg-vuqaysv1563yd54fqh9/ca@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.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.