All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: linux-iio <linux-iio@vger.kernel.org>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [RFC PATCH 1/4] iio: core: Introduce iio_push_to_buffers_with_ts_na() for non aligned case.
Date: Sun, 2 May 2021 16:53:20 +0100	[thread overview]
Message-ID: <20210502165320.1eaea741@jic23-huawei> (raw)
In-Reply-To: <CAHp75VdRTh6Pzj8yy6sDQqfhfAJj1nGZ79UmzBckNR4b1h5sog@mail.gmail.com>

On Sat, 1 May 2021 22:25:55 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Sat, May 1, 2021 at 8:28 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > Whilst it is almost always possible to arrange for scan data to be
> > read directly into a buffer that is suitable for passing to
> > iio_push_to_buffers_with_timestamp(), there are a few places where
> > leading data needs to be skipped over.
> >
> > For these cases introduce a function that will allocate an appropriate
> > sized and aligned bounce buffer (if not already allocated) and copy
> > the unaligned data into that before calling
> > iio_push_to_buffers_with_timestamp() on the bounce buffer.
> > We tie the lifespace of this buffer to that of the iio_dev.dev
> > which should ensure no memory leaks occur.  
> 
> ...
> 
> > +/**
> > + * iio_push_to_buffers_with_ts_na() - push to registered buffer,
> > + *    no alignment or space requirements.
> > + * @indio_dev:         iio_dev structure for device.
> > + * @data:              channel data excluding the timestamp.
> > + * @data_sz:           size of data.
> > + * @timestamp:         timestamp for the sample data.
> > + *
> > + * This special variant of iio_push_to_buffers_with_timetamp() does
> > + * not require space for the timestamp, or 8 byte alignment of data.
> > + * It does however require an allocation on first call and additional
> > + * coppies on all calls, so should be avoided if possible  
> 
> copies

One day I'll remember to actually spell check *sigh*

> 
> > + */  
> 
> I do not like the _na part in the name (My first impression was with a
> Timestamp that was not available, what?!). Can we spell it better?

I struggled with the naming.  Ideally we'd have started with this
as the iio_push_to_buffers_with_timestamp() and had
an _aligned version for the existing case.

Perhaps spend the characters and just make it
_with_ts_unaligned()

> 
> > +int iio_push_to_buffers_with_ts_na(struct iio_dev *indio_dev,
> > +                                  const void *data,
> > +                                  size_t data_sz,
> > +                                  int64_t timestamp)
> > +{
> > +       struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
> > +
> > +       data_sz = min_t(size_t, indio_dev->scan_bytes, data_sz);
> > +       if (iio_dev_opaque->bounce_buffer_size !=  indio_dev->scan_bytes) {  
> 
> > +               iio_dev_opaque->bounce_buffer =
> > +                       devm_krealloc(&indio_dev->dev,
> > +                                     iio_dev_opaque->bounce_buffer,  
> 
> Oh la la, foo = realloc(foo, ...) is 101 type of mistakes.
> Please, don't do this.

For realloc I'd agree because if the new allocation fails we'd just have
lost the pointer, but with a managed case, I think we'll leave the original
pointer alone from the point of view of the devm_ cleanup. 

The only exit paths of interest in devm_krealloc() are the ones where we
are trying to allocate a new larger object (otherwise it either does nothing
or it is just a call to devm_kmalloc().

The one on failure to find the original managed resource, so can't loose
it because it wasn't there.

Am I missing something?

> 
> > +                                     indio_dev->scan_bytes, GFP_KERNEL);
> > +               if (!iio_dev_opaque)
> > +                       return -ENOMEM;

As you observed this is clearly garbage. I should have sat on this patch
for a day and at least reread it or ideally done some testing.

Failing to set the bounce_buffer_size() definitely doesn't help either..

> > +       }
> > +       memcpy(iio_dev_opaque->bounce_buffer, data, data_sz);
> > +       return iio_push_to_buffers_with_timestamp(indio_dev,
> > +                                                 iio_dev_opaque->bounce_buffer,
> > +                                                 timestamp);
> > +}  
> 


  parent reply	other threads:[~2021-05-02 15:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-01 17:25 [RFC PATCH 0/4] IIO: Alignment fixes part 4 - bounce buffers for the hard cases Jonathan Cameron
2021-05-01 17:25 ` [RFC PATCH 1/4] iio: core: Introduce iio_push_to_buffers_with_ts_na() for non aligned case Jonathan Cameron
2021-05-01 19:25   ` Andy Shevchenko
2021-05-01 19:27     ` Andy Shevchenko
2021-05-02 15:37       ` Jonathan Cameron
2021-05-02 15:53     ` Jonathan Cameron [this message]
2021-05-02  9:10   ` Sa, Nuno
2021-05-02 16:08     ` Jonathan Cameron
2021-05-03  7:15       ` Sa, Nuno
2021-05-03  7:46         ` Sa, Nuno
2021-05-03 10:34           ` Andy Shevchenko
2021-05-03 10:39           ` Jonathan Cameron
2021-05-03 11:20             ` Sa, Nuno
2021-05-01 17:25 ` [RFC PATCH 2/4] iio: adc: ti-adc108s102: Fix alignment of buffer pushed to iio buffers Jonathan Cameron
2021-05-01 17:25 ` [RFC PATCH 3/4] iio: gyro: mpu3050: Fix alignment and size issues with buffers Jonathan Cameron
2021-05-05 12:58   ` Linus Walleij
2021-05-01 17:25 ` [RFC PATCH 4/4] iio: imu: adis16400: Fix buffer alignment requirements Jonathan Cameron
2021-05-02  8:52   ` Sa, Nuno

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=20210502165320.1eaea741@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=linux-iio@vger.kernel.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.