From: David Daney <ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Pantelis Antoniou
<panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
Cc: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
"Ben Dooks (embedded platforms)"
<ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Koen Kooi
<koen-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org>,
Matt Porter <mporter-l0cyMroinI0@public.gmane.org>,
Russ Dill <Russ.Dill-l0cyMroinI0@public.gmane.org>,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] i2c-EEPROM: Export memory accessor
Date: Tue, 30 Oct 2012 11:46:17 -0700 [thread overview]
Message-ID: <50902079.30406@gmail.com> (raw)
In-Reply-To: <1351699009-4217-1-git-send-email-panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
On 10/31/2012 08:56 AM, Pantelis Antoniou wrote:
> Various platforms need access to the EEPROM in other
> places besides their platform registration callbacks.
> Export the memory accessor to the i2c_client
i2c_clients are *not* intrinsically memory, so adding this to the
generic i2c_client structure doesn't really make sense. What would the
semantics of this interface be with respect to temperature sensors and
GPIO expanders?
NACK.
> and implement
> it for the at24 driver.
>
> And before you ask, no, the platform callback can't be used
> for anything that depends on DT.
Why can't you just allocate (and populate) a struct at24_platform_data
for the device if it isn't supplied by whatever created the device?
WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney.cavm@gmail.com>
To: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Wolfram Sang <w.sang@pengutronix.de>,
"Ben Dooks (embedded platforms)" <ben-linux@fluff.org>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
Koen Kooi <koen@dominion.thruhere.net>,
Matt Porter <mporter@ti.com>, Russ Dill <Russ.Dill@ti.com>,
linux-omap@vger.kernel.org
Subject: Re: [PATCH] i2c-EEPROM: Export memory accessor
Date: Tue, 30 Oct 2012 11:46:17 -0700 [thread overview]
Message-ID: <50902079.30406@gmail.com> (raw)
In-Reply-To: <1351699009-4217-1-git-send-email-panto@antoniou-consulting.com>
On 10/31/2012 08:56 AM, Pantelis Antoniou wrote:
> Various platforms need access to the EEPROM in other
> places besides their platform registration callbacks.
> Export the memory accessor to the i2c_client
i2c_clients are *not* intrinsically memory, so adding this to the
generic i2c_client structure doesn't really make sense. What would the
semantics of this interface be with respect to temperature sensors and
GPIO expanders?
NACK.
> and implement
> it for the at24 driver.
>
> And before you ask, no, the platform callback can't be used
> for anything that depends on DT.
Why can't you just allocate (and populate) a struct at24_platform_data
for the device if it isn't supplied by whatever created the device?
next prev parent reply other threads:[~2012-10-30 18:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-31 15:56 [PATCH] i2c-EEPROM: Export memory accessor Pantelis Antoniou
[not found] ` <1351699009-4217-1-git-send-email-panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2012-10-30 18:46 ` David Daney [this message]
2012-10-30 18:46 ` David Daney
2012-10-30 18:51 ` Pantelis Antoniou
[not found] ` <4AF9EE5B-D1C1-45E7-B2FD-E96151F5772A-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2012-10-30 19:12 ` David Daney
2012-10-30 19:12 ` David Daney
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=50902079.30406@gmail.com \
--to=ddaney.cavm-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=Russ.Dill-l0cyMroinI0@public.gmane.org \
--cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
--cc=koen-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mporter-l0cyMroinI0@public.gmane.org \
--cc=panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org \
--cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@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.