[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220719102055.00000315@Huawei.com>
Date: Tue, 19 Jul 2022 10:20:55 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Angel Iglesias <ang.iglesiasg@...il.com>
CC: Jonathan Cameron <jic23@...nel.org>,
Dan Carpenter <dan.carpenter@...cle.com>,
kernel test robot <lkp@...el.com>,
"Lars-Peter Clausen" <lars@...afoo.de>,
Ulf Hansson <ulf.hansson@...aro.org>,
"Paul Cercueil" <paul@...pouillou.net>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
<linux-iio@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 4/5] iio: pressure: bmp280: Add support for BMP380
sensor family
> > > +
> > > +static int bmp380_read_calib(struct bmp280_data *data, unsigned int chip)
> > > +{
> > > + int ret;
> > > + struct bmp380_calib *calib = &data->calib.bmp380;
> > > + u8 buf[BMP380_CALIB_REG_COUNT];
> >
> > I'd missed this previously but for SPI drivers, we should be providing
> > regmap_bulk accesses with DMA safe buffers. That means they can't be on the
> > stack and need to be appropriately aligned IIO_DMA_MINALIGN as part of
> > the *data structure.
> >
> > Last time I checked the SPI regmap implementation doesn't currently use
> > the buffers directly but it has in the past and may do again in the future
> > - hence we should be careful to allow for that.
> >
>
> As we only use this buffer once to store temporally the calibration data to
> parse, I would like to avoid adding extra overhead to the device data struct.
> I've been consulting on DMA rules and safety, and if I understood correctly
> (listed the sources below), it should be safe to use a buffer allocated at
> runtime with kmalloc, right?
Yes. That works too.
> * https://elinux.org/images/0/03/20181023-Wolfram-Sang-ELCE18-
> safe_dma_buffers.pdf
> * https://linux-arm-kernel.infradead.narkive.com/vyJqy0RQ/question-devm-
> kmalloc-for-dma
>
> Thanks in advance,
> Angel
Powered by blists - more mailing lists