All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Fornero <matthew.fornero@gmail.com>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>,
	linux-iio@vger.kernel.org,
	Matt Fornero <matt.fornero@mathworks.com>
Subject: Re: [PATCH] iio: buffer-dma: Expose data available
Date: Tue, 05 Dec 2017 18:01:13 +0000	[thread overview]
Message-ID: <CABdUomw1Z=CTq5m5jBic-=PNtn3DGU1L3b3O6bhzX-MOo2iCrw@mail.gmail.com> (raw)
In-Reply-To: <d260e712-ec2f-33d5-e368-86c2e7ffa19e@metafoo.de>

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On Tue, Dec 5, 2017 at 1:32 AM Lars-Peter Clausen <lars@metafoo.de> wrote:
> I guess one question is whether this should be generic.
> iio_dma_buffer_data_available() is a generic function and not specific to
the
> DMA buffers, so it would work just fine for FIFO based buffers as well.

So it looks like we could implement this generically as a member of
iio_buffer_attrs, and have it simply use iio_buffer_data_available()
instead of iio_dma_buffer_data_available().

This would also be a bit cleaner, as the iio_buffer_attrs logic already
has code to append existings attrs, allowing device-specific attrs to be
easily added.

What about the case when the data_available element in
iio_buffer_access_funcs is undefined (e.g. industrialio-buffer-cb)?
Do we modify iio_buffer_data_available() to return 0, do we make the
sysfs function return -ENOENT or -EINVAL, or simply not expose the sysfs
interface for this case?
-- 

--

Matthew Fornero

matthew.fornero@gmail.com

(734)-846-4968

[-- Attachment #2: Type: text/html, Size: 1459 bytes --]

  reply	other threads:[~2017-12-05 18:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01 20:46 [PATCH] iio: buffer-dma: Expose data available mfornero
2017-12-02 11:52 ` Jonathan Cameron
2017-12-05  9:32   ` Lars-Peter Clausen
2017-12-05 18:01     ` Matthew Fornero [this message]
2017-12-05 18:08       ` Lars-Peter Clausen
2017-12-05 18:11         ` Matthew Fornero
2017-12-05 18:38           ` Lars-Peter Clausen
2017-12-05 18:05     ` Matthew Fornero
2017-12-05 20:56 ` [PATCH v2] iio: buffer: " mfornero
2017-12-06 12:10   ` Lars-Peter Clausen
2017-12-06 19:43 ` [PATCH v3] " mfornero
2017-12-10 16:21   ` Jonathan Cameron
  -- strict thread matches above, loose matches on Subject: below --
2017-12-01 19:43 [PATCH] iio: buffer-dma: " Matthew Fornero

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='CABdUomw1Z=CTq5m5jBic-=PNtn3DGU1L3b3O6bhzX-MOo2iCrw@mail.gmail.com' \
    --to=matthew.fornero@gmail.com \
    --cc=jic23@jic23.retrosnub.co.uk \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=matt.fornero@mathworks.com \
    /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.