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 12:12:47 -0700 [thread overview]
Message-ID: <509026AF.7000206@gmail.com> (raw)
In-Reply-To: <4AF9EE5B-D1C1-45E7-B2FD-E96151F5772A-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
On 10/30/2012 11:51 AM, Pantelis Antoniou wrote:
> Hi David,
>
> On Oct 30, 2012, at 8:46 PM, David Daney wrote:
>
>> 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.
>>
>
> It's only filled in for EEPROM devices. There's no other I2C memory read interface for kernel clients.
Basically you are tacking on a registery of memory devices to some
random data structure that has nothing to do with memory.
Instead ...
>
>>
>>> 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?
>>
>>
>>
>
> There are no platform_data in the case of device tree only generic-boards. Everything is configured via the DT and there are
> no callbacks. DT is a purely data driver concept.
>
> I'm open to suggestions on how to read an EEPROM from another kernel client, when there's no such thing as platform_data anymore.
>
... you need some sort of collection memory devices that can be queried
by phandle and/or some other handle.
Any device that implements the struct memory_accessor interface could
add itself to the collection, then code that needs to use the
memory_accessor interface would look up the proper target for the
operation by phandle or whatever other handle the system is using.
Similar to how of_phy_find_device() works.
I don't know if it would be possible to create a 'memory_accessor' bus,
but that is one idea I had.
David Daney
> Regards
>
> -- Pantelis
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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 12:12:47 -0700 [thread overview]
Message-ID: <509026AF.7000206@gmail.com> (raw)
In-Reply-To: <4AF9EE5B-D1C1-45E7-B2FD-E96151F5772A@antoniou-consulting.com>
On 10/30/2012 11:51 AM, Pantelis Antoniou wrote:
> Hi David,
>
> On Oct 30, 2012, at 8:46 PM, David Daney wrote:
>
>> 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.
>>
>
> It's only filled in for EEPROM devices. There's no other I2C memory read interface for kernel clients.
Basically you are tacking on a registery of memory devices to some
random data structure that has nothing to do with memory.
Instead ...
>
>>
>>> 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?
>>
>>
>>
>
> There are no platform_data in the case of device tree only generic-boards. Everything is configured via the DT and there are
> no callbacks. DT is a purely data driver concept.
>
> I'm open to suggestions on how to read an EEPROM from another kernel client, when there's no such thing as platform_data anymore.
>
... you need some sort of collection memory devices that can be queried
by phandle and/or some other handle.
Any device that implements the struct memory_accessor interface could
add itself to the collection, then code that needs to use the
memory_accessor interface would look up the proper target for the
operation by phandle or whatever other handle the system is using.
Similar to how of_phy_find_device() works.
I don't know if it would be possible to create a 'memory_accessor' bus,
but that is one idea I had.
David Daney
> Regards
>
> -- Pantelis
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2012-10-30 19:12 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
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 [this message]
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=509026AF.7000206@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.