From: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
To: Crestez Dan Leonard
<leonard.crestez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-spi <linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
Linux I2C <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC] regmap: Add regmap_pipe_read API
Date: Fri, 17 Jun 2016 10:05:49 +0200 [thread overview]
Message-ID: <5763AF5D.4090309@metafoo.de> (raw)
In-Reply-To: <643b0e6a-49a0-00bb-7aed-6d36c1e0bb6b-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On 06/17/2016 09:04 AM, Crestez Dan Leonard wrote:
> On 06/16/2016 06:43 PM, Geert Uytterhoeven wrote:
>> Hi Leonard,
>>
>> On Thu, Jun 16, 2016 at 5:24 PM, Crestez Dan Leonard
>> <leonard.crestez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>>> The regmap API usually assumes that bulk read operations will read a
>>> range of registers but some I2C/SPI devices have certain registers for
>>> which a such a read operation will return data from an internal FIFO
>>> instead. Add an explicit API to support bulk read with pipe rather than
>>> range semantics.
>>
>> Please settle on either "fifo" or "pipe", instead of mixing both.
>> Personally, I prefer the former.
>
> Well, it doesn't have to be a fifo. The device can return data from some
> other kind of buffer (maybe a stack). I can adjust the documentation to
> clarify.
>
> I considered naming it something like regmap_multi_read_one_reg or
> something but regmap_pipe_read sounds reasonable and short.
stream might be another option, but pipe is ok in my opinion.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Lars-Peter Clausen <lars@metafoo.de>
To: Crestez Dan Leonard <leonard.crestez@intel.com>,
Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Mark Brown <broonie@kernel.org>,
linux-spi <linux-spi@vger.kernel.org>,
Wolfram Sang <wsa@the-dreams.de>,
Linux I2C <linux-i2c@vger.kernel.org>,
Jonathan Cameron <jic23@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] regmap: Add regmap_pipe_read API
Date: Fri, 17 Jun 2016 10:05:49 +0200 [thread overview]
Message-ID: <5763AF5D.4090309@metafoo.de> (raw)
In-Reply-To: <643b0e6a-49a0-00bb-7aed-6d36c1e0bb6b@intel.com>
On 06/17/2016 09:04 AM, Crestez Dan Leonard wrote:
> On 06/16/2016 06:43 PM, Geert Uytterhoeven wrote:
>> Hi Leonard,
>>
>> On Thu, Jun 16, 2016 at 5:24 PM, Crestez Dan Leonard
>> <leonard.crestez@intel.com> wrote:
>>> The regmap API usually assumes that bulk read operations will read a
>>> range of registers but some I2C/SPI devices have certain registers for
>>> which a such a read operation will return data from an internal FIFO
>>> instead. Add an explicit API to support bulk read with pipe rather than
>>> range semantics.
>>
>> Please settle on either "fifo" or "pipe", instead of mixing both.
>> Personally, I prefer the former.
>
> Well, it doesn't have to be a fifo. The device can return data from some
> other kind of buffer (maybe a stack). I can adjust the documentation to
> clarify.
>
> I considered naming it something like regmap_multi_read_one_reg or
> something but regmap_pipe_read sounds reasonable and short.
stream might be another option, but pipe is ok in my opinion.
next prev parent reply other threads:[~2016-06-17 8:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 15:24 [RFC] regmap: Add regmap_pipe_read API Crestez Dan Leonard
2016-06-16 15:24 ` Crestez Dan Leonard
[not found] ` <7ca3857aa8869a1e1f4709860f57f7d92abf1c6b.1466089603.git.leonard.crestez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-06-16 15:43 ` Geert Uytterhoeven
2016-06-16 15:43 ` Geert Uytterhoeven
2016-06-17 7:04 ` Crestez Dan Leonard
[not found] ` <643b0e6a-49a0-00bb-7aed-6d36c1e0bb6b-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-06-17 8:05 ` Lars-Peter Clausen [this message]
2016-06-17 8:05 ` Lars-Peter Clausen
[not found] ` <5763AF5D.4090309-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
2016-06-19 19:40 ` Jonathan Cameron
2016-06-19 19:40 ` Jonathan Cameron
2016-06-21 18:42 ` Mark Brown
2016-06-21 18:42 ` Mark Brown
2016-06-22 8:32 ` Crestez Dan Leonard
2016-06-22 10:06 ` Mark Brown
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=5763AF5D.4090309@metafoo.de \
--to=lars-qo5elluwu/uelga04laivw@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
--cc=jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=leonard.crestez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@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.