| Message ID | cover.1695380366.git.mazziesaccount@gmail.com |
|---|---|
| Headers | show |
| Series | Support ROHM BM1390 pressure sensor | expand |
On Fri, 22 Sep 2023 14:16:08 +0300 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > The iio_generic_buffer can return garbage values when the total size of > scan data is not a multiple of largest element in the scan. This can be > demonstrated by reading a scan consisting for example of one 4 byte and > one 2 byte element, where the 4 byte elemnt is first in the buffer. > > The IIO generic buffert code does not take into accunt the last two > padding bytes that are needed to ensure that the 4byte data for next > scan is correctly aligned. > > Add padding bytes required to align the next sample into the scan size. > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > --- > Please note, This one could have RFC in subject.: > I attempted to write the fix so that the alignment is done based on the > biggest channel data. This may be wrong. Maybe a fixed 8 byte alignment > should be used instead? This patch can be dropped from the series if the > fix is not correct / agreed. > > tools/iio/iio_generic_buffer.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c > index 44bbf80f0cfd..fc562799a109 100644 > --- a/tools/iio/iio_generic_buffer.c > +++ b/tools/iio/iio_generic_buffer.c > @@ -54,9 +54,12 @@ enum autochan { > static unsigned int size_from_channelarray(struct iio_channel_info *channels, int num_channels) > { > unsigned int bytes = 0; > - int i = 0; > + int i = 0, max = 0; > + unsigned int misalignment; > > while (i < num_channels) { > + if (channels[i].bytes > max) > + max = channels[i].bytes; > if (bytes % channels[i].bytes == 0) > channels[i].location = bytes; > else > @@ -66,6 +69,16 @@ static unsigned int size_from_channelarray(struct iio_channel_info *channels, in > bytes = channels[i].location + channels[i].bytes; > i++; > } > + /* > + * We wan't the data in next sample to also be properly aligned so > + * we'll add padding at the end if needed. TODO: should we use fixed > + * 8 byte alignment instead of the size of the biggest samnple? > + */ Should be aligned to max size seen in the scan. > + misalignment = bytes % max; > + if (misalignment) { > + printf("Misalignment %u. Adding Padding %u\n", misalignment, max - misalignment); No print statement as this is correct behaviour (well the tool is buggy but the kernel generates it correctly I believe). Fine to add a comment though! > + bytes += max - misalignment; > + } > > return bytes; > }
On Sun, 24 Sep 2023 17:07:26 +0100 Jonathan Cameron <jic23@kernel.org> wrote: > On Fri, 22 Sep 2023 14:17:49 +0300 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > > > When IIO goes through the available scan masks in order to select the > > best suiting one, it will just accept the first listed subset of channels > > which meets the user's requirements. This works great for most of the > > drivers as they can sort the list of channels in the order where > > the 'least costy' channel selections come first. > > > > It may be that in some cases the ordering of the list of available scan > > masks is not thoroughly considered. We can't really try outsmarting the > > drivers by selecting the smallest supported subset - as this might not > > be the 'least costy one' - but we can at least try searching through the > > list to see if we have an exactly matching mask. It should be sane > > assumption that if the device can support reading only the exact > > channels user is interested in, then this should be also the least costy > > selection - and if it is not and optimization is important, then the > > driver could consider omitting setting the 'available_scan_mask' and > > doing demuxing - or just omitting the 'costy exact match' and providing > > only the more efficient broader selection of channels. > > > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > > Whilst I fully agree with the reasoning behind this, I'd rather we > did an audit of drivers to find any that have a non logical order > (one came up today in review) and fix them up. > > A quick and dirty grep didn't find it to be a common problem, at least > partly as most users of this feature only provide one valid mask. > The few complex corners I found appear to be fine with the expected > shortest sequences first. > > Defending against driver bugs is losing game if it makes the core > code more complex to follow by changing stuff in non debug paths. > One option might be to add a trivial check at iio_device_register() > that we don't have scan modes that are subsets of modes earlier in the list. > These lists are fairly short so should be cheap to run. > > That would incorporate ensuring exact matches come earlier by default. BTW I'd have sent these as a separate series as there is potential that this will distract from or slow down the driver + not all the CC list will care about this core cleanup. Jonathan > > Jonathan > > > > --- > > drivers/iio/industrialio-buffer.c | 25 +++++++++++++++++++------ > > 1 file changed, 19 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c > > index 176d31d9f9d8..e97396623373 100644 > > --- a/drivers/iio/industrialio-buffer.c > > +++ b/drivers/iio/industrialio-buffer.c > > @@ -411,19 +411,32 @@ static const unsigned long *iio_scan_mask_match(const unsigned long *av_masks, > > const unsigned long *mask, > > bool strict) > > { > > + const unsigned long *first_subset = NULL; > > + > > if (bitmap_empty(mask, masklength)) > > return NULL; > > - while (*av_masks) { > > - if (strict) { > > + > > + if (strict) { > > + while (*av_masks) { > > if (bitmap_equal(mask, av_masks, masklength)) > > return av_masks; > > - } else { > > - if (bitmap_subset(mask, av_masks, masklength)) > > - return av_masks; > > + > > + av_masks += BITS_TO_LONGS(masklength); > > } > > + > > + return NULL; > > + } > > + while (*av_masks) { > > + if (bitmap_equal(mask, av_masks, masklength)) > > + return av_masks; > > + > > + if (!first_subset && bitmap_subset(mask, av_masks, masklength)) > > + first_subset = av_masks; > > + > > av_masks += BITS_TO_LONGS(masklength); > > } > > - return NULL; > > + > > + return first_subset; > > } > > > > static bool iio_validate_scan_mask(struct iio_dev *indio_dev, >
On Fri, 22 Sep 2023 14:19:10 +0300 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure > pressures ranging from 300 hPa to 1300 hPa with configurable measurement > averaging and internal FIFO. The sensor does also provide temperature > measurements. > > Sensor does also contain IIR filter implemented in HW. The data-sheet > says the IIR filter can be configured to be "weak", "middle" or > "strong". Some RMS noise figures are provided in data sheet but no > accurate maths for the filter configurations is provided. Hence, the IIR > filter configuration is not supported by this driver and the filter is > configured to the "middle" setting (at least not for now). > > The FIFO measurement mode is only measuring the pressure and not the > temperature. The driver measures temperature when FIFO is flushed and > simply uses the same measured temperature value to all reported > temperatures. This should not be a problem when temperature is not > changing very rapidly (several degrees C / second) but allows users to > get the temperature measurements from sensor without any additional logic. > > This driver allows the sensor to be used in two muitually exclusive ways, > > 1. With trigger (data-ready IRQ). > In this case the FIFO is not used as we get data ready for each collected > sample. Instead, for each data-ready IRQ we read the sample from sensor > and push it to the IIO buffer. > > 2. With hardware FIFO and watermark IRQ. > In this case the data-ready is not used but we enable watermark IRQ. At > each watermark IRQ we go and read all samples in FIFO and push them to the > IIO buffer. > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Main question here is whether the fifo mode is useable if now interrupt is wired up? I'm guessing not really as it's not worth dealing with making it work if someone can't be bothered to connect the wire. In which case I'd expect few more things to be disable if no IRQ. Also, didn't think we'd have a validate_own_trigger callback set as that means the buffer is potentially also something that should go away if no interrupts are wired. Anyhow, other than that a few trivial things inline. Jonathan > > --- > Revision history: > > v2 => v3: > - Read temperature only after FIFO is read to overcome a HW quirck > - Drop unused defines > - Allow scanning the pressure only > - Some clarifying comments added, some made less verbose > - warn if measurement stp fails > - use IIO_VAL_FRACTIONAL for pressure scale > - don't disable IRQ but use timestamp from stack > - fix amount of samples to read > - minor styling > - better separate buffer and trigger parts > - allow buffer even when there is no IRQ > with external trigger to be supported. > - add completely, utterly useless NULL check because we have the cycles > to waste (grumbles) )Smiles) > diff --git a/drivers/iio/pressure/Makefile b/drivers/iio/pressure/Makefile > index c90f77210e94..436aec7e65f3 100644 > --- a/drivers/iio/pressure/Makefile > +++ b/drivers/iio/pressure/Makefile > @@ -5,6 +5,7 @@ > > # When adding new entries keep the list in alphabetical order > obj-$(CONFIG_ABP060MG) += abp060mg.o > +obj-$(CONFIG_ROHM_BM1390) += rohm-bm1390.o > obj-$(CONFIG_BMP280) += bmp280.o > bmp280-objs := bmp280-core.o bmp280-regmap.o > obj-$(CONFIG_BMP280_I2C) += bmp280-i2c.o > diff --git a/drivers/iio/pressure/rohm-bm1390.c b/drivers/iio/pressure/rohm-bm1390.c > new file mode 100644 > index 000000000000..82a0cd61d215 > --- /dev/null > +++ b/drivers/iio/pressure/rohm-bm1390.c > + > +/* > + * If the trigger is not used we just wait until the measurement has > + * completed. The data-sheet says maximum measurement cycle (regardless > + * the AVE_NUM) is 200 mS so let's just sleep at least that long. If speed > + * is needed the trigger should be used. > + */ > +#define BM1390_MAX_MEAS_TIME_MS 205 > + > +static int bm1390_read_data(struct bm1390_data *data, > + struct iio_chan_spec const *chan, int *val, int *val2) > +{ > + int ret, warn; > + > + mutex_lock(&data->mutex); > + /* > + * We use 'continuous mode' even for raw read because according to the > + * data-sheet an one-shot mode can't be used with IIR filter. > + */ > + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); > + if (ret) > + goto unlock_out; > + > + switch (chan->type) { > + case IIO_PRESSURE: > + msleep(BM1390_MAX_MEAS_TIME_MS); > + ret = bm1390_pressure_read(data, val); > + break; > + case IIO_TEMP: > + msleep(BM1390_MAX_MEAS_TIME_MS); > + ret = bm1390_read_temp(data, val); > + break; > + default: > + ret = -EINVAL; > + } > + warn = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); > + if (warn) > + dev_warn(data->dev, "Failed to stop measurementi (%d)\n", warn); measurement > +unlock_out: > + mutex_unlock(&data->mutex); > + > + return ret; > +} > + > +static int __bm1390_fifo_flush(struct iio_dev *idev, unsigned int samples, > + s64 timestamp) > +{ > + /* BM1390_FIFO_LENGTH is small so we shouldn't run out of stack */ > + struct bm1390_data_buf buffer[BM1390_FIFO_LENGTH]; > + struct bm1390_data *data = iio_priv(idev); > + int smp_lvl, ret, i, warn, dummy; > + u64 sample_period; > + __be16 temp = 0; > + > + ret = regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &smp_lvl); > + if (ret) > + return ret; > + > + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); > + if (!smp_lvl) > + return 0; > + > + if (smp_lvl > BM1390_FIFO_LENGTH) { > + /* > + * The fifo holds maximum of 4 samples so valid values > + * should be 0, 1, 2, 3, 4 - rest are probably bit errors > + * in I2C line. Don't overflow if this happens. > + */ > + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); > + smp_lvl = BM1390_FIFO_LENGTH; > + } > + > + sample_period = timestamp - data->old_timestamp; > + do_div(sample_period, smp_lvl); > + > + if (samples && smp_lvl > samples) > + smp_lvl = samples; > + > + > + /* > + * After some testing it appears that the temperature is not readable > + * untill the FIFO access has been done after the WMI. Thus, we need Spell check. until (Why it doesn't have 2 ls is beyond me but that's English being annoyingly irregular) > + * to read the all pressure values to memory and read the temperature > + * only after that. > + */ > + for (i = 0; i < smp_lvl; i++) { > + /* > + * When we start reading data from the FIFO the sensor goes to > + * special FIFO reading mode. If any other register is accessed > + * during the FIFO read, samples can be dropped. Prevent access > + * until FIFO_LVL is read. We have mutex locked and we do also > + * go performing reading of FIFO_LVL even if this read fails. > + */ > + if (test_bit(BM1390_CHAN_PRESSURE, idev->active_scan_mask)) { > + ret = bm1390_pressure_read(data, &buffer[i].pressure); > + if (ret) > + break; > + } > + > + /* > + * Old timestamp is either the previous sample IRQ time, > + * previous flush-time or, if this was first sample, the enable > + * time. When we add a sample period to that we should get the > + * best approximation of the time-stamp we are handling. > + * > + * Idea is to always keep the "old_timestamp" matching the > + * timestamp which we are currently handling. > + */ > + data->old_timestamp += sample_period; > + buffer[i].ts = data->old_timestamp; > + } > + /* Reading the FIFO_LVL closes the FIFO access sequence */ > + warn = regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &dummy); > + if (warn) > + dev_warn(data->dev, "Closing FIFO sequence failed\n"); > + > + if (ret) > + return ret; > + > + if (test_bit(BM1390_CHAN_TEMP, idev->active_scan_mask)) { > + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp, > + sizeof(temp)); > + if (ret) > + return ret; > + pr_info("Temp before reading the FIFO %u\n", be16_to_cpu(temp)); Why this print? > + } > + > + if (ret) > + return ret; > + > + for (i = 0; i < smp_lvl; i++) { > + buffer[i].temp = temp; > + iio_push_to_buffers_with_timestamp(idev, &buffer[i], > + buffer[i].ts); You can just use iio_push_to_buffers() if you've already filled in the timestamp by hand. The _with_timestamp() version was just to reduce boilerplate (and given the main it has caused over the years, I'm not sure it was a good idea!) > + } > + > + return smp_lvl; > +} > + > +static const struct iio_info bm1390_info = { > + .read_raw = &bm1390_read_raw, > + .validate_trigger = iio_validate_own_trigger, > + .hwfifo_set_watermark = bm1390_set_watermark, > + .hwfifo_flush_to_buffer = bm1390_fifo_flush, Given my (possibly incorrect assumption) that the fifo is useless without the interrupt, I'd expect to see another version of this that has read_raw only set. Also, why do we need validate_own_trigger. I thought this could be used with other triggers. If not, then don't register the buffer for the case with no interrupt either. > +}; > + > + > +static int bm1390_fifo_set_wmi(struct bm1390_data *data) > +{ > + u8 regval; > + > + regval = data->watermark - BM1390_WMI_MIN; Trivial: I'd rather we didn't put stuff that clearly isn't the register value in a variable called regval. I'd just go directly to regval = FIELD_PREP(BM1390_MASK_FIFO_LEN, data->watermark - BMI1390_WMI_MIN); and avoid that first 'mis'use. > + regval = FIELD_PREP(BM1390_MASK_FIFO_LEN, regval); > + > + return regmap_update_bits(data->regmap, BM1390_REG_FIFO_CTRL, > + BM1390_MASK_FIFO_LEN, regval); > +} > + > +static int bm1390_fifo_enable(struct iio_dev *idev) > +{ > + struct bm1390_data *data = iio_priv(idev); > + int ret; > + > + /* We can't do buffered stuff without IRQ as we never get WMI */ > + if (data->irq <= 0) > + return -EINVAL; > + > + mutex_lock(&data->mutex); > + if (data->trigger_enabled) { > + ret = -EBUSY; > + goto unlock_out; > + } > + > + /* Update watermark to HW */ > + ret = bm1390_fifo_set_wmi(data); > + if (ret) > + goto unlock_out; > + > + /* Enable WMI_IRQ */ > + ret = regmap_set_bits(data->regmap, BM1390_REG_MODE_CTRL, > + BM1390_MASK_WMI_EN); > + if (ret) > + goto unlock_out; > + > + /* Enable FIFO */ > + ret = regmap_set_bits(data->regmap, BM1390_REG_FIFO_CTRL, > + BM1390_MASK_FIFO_EN); > + if (ret) > + goto unlock_out; > + > + data->state = BM1390_STATE_FIFO; > + > + data->old_timestamp = iio_get_time_ns(idev); > + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); > + > +unlock_out: > + mutex_unlock(&data->mutex); > + > + return ret; > +} > + > +static int bm1390_fifo_disable(struct iio_dev *idev) > +{ > + struct bm1390_data *data = iio_priv(idev); > + int ret; > + > + msleep(1); > + > + mutex_lock(&data->mutex); > + /* Disable FIFO */ > + ret = regmap_clear_bits(data->regmap, BM1390_REG_FIFO_CTRL, > + BM1390_MASK_FIFO_EN); > + if (ret) > + goto unlock_out; > + > + data->state = BM1390_STATE_SAMPLE; > + > + /* Disable WMI_IRQ */ > + ret = regmap_clear_bits(data->regmap, BM1390_REG_MODE_CTRL, > + BM1390_MASK_WMI_EN); > + if (ret) > + goto unlock_out; > + > + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); I'm sure it works in this order but to my mind it would make more sense (and might still work) for fifo_disable() to be reverse of steps in fifo_enable(). So I'd expect the mode change first. > + > +unlock_out: > + mutex_unlock(&data->mutex); > + > + return ret; > +} > +static int bm1390_probe(struct i2c_client *i2c) > +{ > + struct bm1390_data *data; > + struct regmap *regmap; > + struct iio_dev *idev; > + struct device *dev; > + unsigned int part_id; > + int ret; > + > + dev = &i2c->dev; > + > + regmap = devm_regmap_init_i2c(i2c, &bm1390_regmap); > + if (IS_ERR(regmap)) > + return dev_err_probe(dev, PTR_ERR(regmap), > + "Failed to initialize Regmap\n"); > + > + ret = devm_regulator_get_enable(dev, "vdd"); > + if (ret) > + return dev_err_probe(dev, ret, "Failed to get regulator\n"); > + > + ret = regmap_read(regmap, BM1390_REG_PART_ID, &part_id); > + if (ret) > + return dev_err_probe(dev, ret, "Failed to access sensor\n"); > + > + if (part_id != BM1390_ID) > + dev_warn(dev, "unknown device 0x%x\n", part_id); > + > + idev = devm_iio_device_alloc(dev, sizeof(*data)); > + if (!idev) > + return -ENOMEM; > + > + data = iio_priv(idev); > + data->regmap = regmap; > + data->dev = dev; > + data->irq = i2c->irq; > + /* > + * For now we just allow BM1390_WMI_MIN to BM1390_WMI_MAX and > + * discard every other configuration when triggered mode is not used. > + */ > + data->watermark = BM1390_WMI_MAX; > + mutex_init(&data->mutex); > + > + idev->channels = bm1390_channels; > + idev->num_channels = ARRAY_SIZE(bm1390_channels); > + idev->name = "bm1390"; > + idev->info = &bm1390_info; > + idev->modes = INDIO_DIRECT_MODE | INDIO_BUFFER_SOFTWARE; Silly question that I might resolve as I read on. If we don't have the WMI interrupt, do we have buffer_software support? It could be made to work with a timer, but do you do so? > + > + ret = bm1390_chip_init(data); > + if (ret) > + return dev_err_probe(dev, ret, "sensor init failed\n"); > + > + ret = bm1390_setup_buffer(data, idev); > + if (ret) > + return ret; > + > + /* No trigger if we don't have IRQ for data-ready and WMI */ > + if (i2c->irq > 0) { > + ret = bm1390_setup_trigger(data, idev, i2c->irq); > + if (ret) > + return ret; > + } > + > + ret = devm_iio_device_register(dev, idev); > + if (ret < 0) > + return dev_err_probe(dev, ret, > + "Unable to register iio device\n"); > + > + return 0; > +}
On 9/24/23 18:57, Jonathan Cameron wrote: > On Fri, 22 Sep 2023 14:16:08 +0300 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > >> The iio_generic_buffer can return garbage values when the total size of >> scan data is not a multiple of largest element in the scan. This can be >> demonstrated by reading a scan consisting for example of one 4 byte and >> one 2 byte element, where the 4 byte elemnt is first in the buffer. >> >> The IIO generic buffert code does not take into accunt the last two >> padding bytes that are needed to ensure that the 4byte data for next >> scan is correctly aligned. >> >> Add padding bytes required to align the next sample into the scan size. >> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> >> --- >> Please note, This one could have RFC in subject.: >> I attempted to write the fix so that the alignment is done based on the >> biggest channel data. This may be wrong. Maybe a fixed 8 byte alignment >> should be used instead? This patch can be dropped from the series if the >> fix is not correct / agreed. >> >> tools/iio/iio_generic_buffer.c | 15 ++++++++++++++- >> 1 file changed, 14 insertions(+), 1 deletion(-) >> >> diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c >> index 44bbf80f0cfd..fc562799a109 100644 >> --- a/tools/iio/iio_generic_buffer.c >> +++ b/tools/iio/iio_generic_buffer.c >> @@ -54,9 +54,12 @@ enum autochan { >> static unsigned int size_from_channelarray(struct iio_channel_info *channels, int num_channels) >> { >> unsigned int bytes = 0; >> - int i = 0; >> + int i = 0, max = 0; >> + unsigned int misalignment; >> >> while (i < num_channels) { >> + if (channels[i].bytes > max) >> + max = channels[i].bytes; >> if (bytes % channels[i].bytes == 0) >> channels[i].location = bytes; >> else >> @@ -66,6 +69,16 @@ static unsigned int size_from_channelarray(struct iio_channel_info *channels, in >> bytes = channels[i].location + channels[i].bytes; >> i++; >> } >> + /* >> + * We wan't the data in next sample to also be properly aligned so >> + * we'll add padding at the end if needed. TODO: should we use fixed >> + * 8 byte alignment instead of the size of the biggest samnple? >> + */ > > Should be aligned to max size seen in the scan. Or, maybe it should be min(max_size_in_scan, 8); ? I think my suggestion above may yield undesirable effects should the scan elements be greater than 8 bytes. (Don't know if this is supported though) > >> + misalignment = bytes % max; >> + if (misalignment) { >> + printf("Misalignment %u. Adding Padding %u\n", misalignment, max - misalignment); > > No print statement as this is correct behaviour (well the tool is buggy but the kernel generates it > correctly I believe). Fine to add a comment though! Oh, indeed. The print was forgotten from my test runs. Thanks for pointing it out! > >> + bytes += max - misalignment; >> + } >> >> return bytes; >> } > Yours, -- Matti
On 9/24/23 19:07, Jonathan Cameron wrote: > On Fri, 22 Sep 2023 14:17:49 +0300 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > >> When IIO goes through the available scan masks in order to select the >> best suiting one, it will just accept the first listed subset of channels >> which meets the user's requirements. This works great for most of the >> drivers as they can sort the list of channels in the order where >> the 'least costy' channel selections come first. >> >> It may be that in some cases the ordering of the list of available scan >> masks is not thoroughly considered. We can't really try outsmarting the >> drivers by selecting the smallest supported subset - as this might not >> be the 'least costy one' - but we can at least try searching through the >> list to see if we have an exactly matching mask. It should be sane >> assumption that if the device can support reading only the exact >> channels user is interested in, then this should be also the least costy >> selection - and if it is not and optimization is important, then the >> driver could consider omitting setting the 'available_scan_mask' and >> doing demuxing - or just omitting the 'costy exact match' and providing >> only the more efficient broader selection of channels. >> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > > Whilst I fully agree with the reasoning behind this, I'd rather we > did an audit of drivers to find any that have a non logical order > (one came up today in review) and fix them up. > > A quick and dirty grep didn't find it to be a common problem, at least > partly as most users of this feature only provide one valid mask. It's always good to hear there is not many problems found :) This patch was not inspired by auditing the existing code - it was inspired by the fact that I would have wrongly ordered the available_scan_masks for bm1390 myself. I just happened to notice the oddity in active_scan_masks while I was trying to figure out if it was the driver, IIO or user-space code which messed my buffer when I disabled timestamps. > The few complex corners I found appear to be fine with the expected > shortest sequences first. > > Defending against driver bugs is losing game if it makes the core > code more complex to follow by changing stuff in non debug paths. I think I agree, although I could argue that it depends on the amount of added complexity. Still ... > One option might be to add a trivial check at iio_device_register() ... this suggestion is superior to the check added in this patch. > that we don't have scan modes that are subsets of modes earlier in the list. > These lists are fairly short so should be cheap to run. Yes. And running the check at the registration phase should not be a big problem. And, if it appears to be a problem, then we can add a registration variant which omits the checks for those rare drivers which would _really_ be hurt by the few extra cycles spent on registration. > That would incorporate ensuring exact matches come earlier by default. Yes. I like the idea, wish I had invented it myself ;) > > Jonathan > > >> --- >> drivers/iio/industrialio-buffer.c | 25 +++++++++++++++++++------ >> 1 file changed, 19 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c >> index 176d31d9f9d8..e97396623373 100644 >> --- a/drivers/iio/industrialio-buffer.c >> +++ b/drivers/iio/industrialio-buffer.c >> @@ -411,19 +411,32 @@ static const unsigned long *iio_scan_mask_match(const unsigned long *av_masks, >> const unsigned long *mask, >> bool strict) >> { >> + const unsigned long *first_subset = NULL; >> + >> if (bitmap_empty(mask, masklength)) >> return NULL; >> - while (*av_masks) { >> - if (strict) { >> + >> + if (strict) { >> + while (*av_masks) { >> if (bitmap_equal(mask, av_masks, masklength)) >> return av_masks; >> - } else { >> - if (bitmap_subset(mask, av_masks, masklength)) >> - return av_masks; >> + >> + av_masks += BITS_TO_LONGS(masklength); >> } >> + >> + return NULL; >> + } >> + while (*av_masks) { >> + if (bitmap_equal(mask, av_masks, masklength)) >> + return av_masks; >> + >> + if (!first_subset && bitmap_subset(mask, av_masks, masklength)) >> + first_subset = av_masks; >> + >> av_masks += BITS_TO_LONGS(masklength); >> } >> - return NULL; >> + >> + return first_subset; >> } >> >> static bool iio_validate_scan_mask(struct iio_dev *indio_dev, >
On 9/24/23 19:29, Jonathan Cameron wrote: > On Fri, 22 Sep 2023 14:19:10 +0300 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > >> Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure >> pressures ranging from 300 hPa to 1300 hPa with configurable measurement >> averaging and internal FIFO. The sensor does also provide temperature >> measurements. >> >> Sensor does also contain IIR filter implemented in HW. The data-sheet >> says the IIR filter can be configured to be "weak", "middle" or >> "strong". Some RMS noise figures are provided in data sheet but no >> accurate maths for the filter configurations is provided. Hence, the IIR >> filter configuration is not supported by this driver and the filter is >> configured to the "middle" setting (at least not for now). >> >> The FIFO measurement mode is only measuring the pressure and not the >> temperature. The driver measures temperature when FIFO is flushed and >> simply uses the same measured temperature value to all reported >> temperatures. This should not be a problem when temperature is not >> changing very rapidly (several degrees C / second) but allows users to >> get the temperature measurements from sensor without any additional logic. >> >> This driver allows the sensor to be used in two muitually exclusive ways, >> >> 1. With trigger (data-ready IRQ). >> In this case the FIFO is not used as we get data ready for each collected >> sample. Instead, for each data-ready IRQ we read the sample from sensor >> and push it to the IIO buffer. >> >> 2. With hardware FIFO and watermark IRQ. >> In this case the data-ready is not used but we enable watermark IRQ. At >> each watermark IRQ we go and read all samples in FIFO and push them to the >> IIO buffer. >> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > > Main question here is whether the fifo mode is useable if now interrupt > is wired up? I don't think it is. > I'm guessing not really as it's not worth dealing with making > it work if someone can't be bothered to connect the wire. In which case > I'd expect few more things to be disable if no IRQ. > Also, didn't think we'd have a validate_own_trigger callback set > as that means the buffer is potentially also something that should go > away if no interrupts are wired. This was what I originally had been thinking. You made me think that we should perhaps allow using an external trigger as well - and I tried doing that (but obviously didn't test it as I forgot the validate_own_trigger in place). I don't really know the potential applications for this sensor so I can't imagine if it'd be useful to support external triggers. Still, if it is just a matter of dropping the validate_own_trigger - then, why limiting the users? > Anyhow, other than that a few trivial things inline. > > >> >> --- >> Revision history: >> >> v2 => v3: >> - Read temperature only after FIFO is read to overcome a HW quirck >> - Drop unused defines >> - Allow scanning the pressure only >> - Some clarifying comments added, some made less verbose >> - warn if measurement stp fails >> - use IIO_VAL_FRACTIONAL for pressure scale >> - don't disable IRQ but use timestamp from stack >> - fix amount of samples to read >> - minor styling >> - better separate buffer and trigger parts >> - allow buffer even when there is no IRQ >> with external trigger to be supported. >> - add completely, utterly useless NULL check because we have the cycles >> to waste (grumbles) > > )Smiles) > > > >> diff --git a/drivers/iio/pressure/Makefile b/drivers/iio/pressure/Makefile >> index c90f77210e94..436aec7e65f3 100644 >> --- a/drivers/iio/pressure/Makefile >> +++ b/drivers/iio/pressure/Makefile >> @@ -5,6 +5,7 @@ >> >> # When adding new entries keep the list in alphabetical order >> obj-$(CONFIG_ABP060MG) += abp060mg.o >> +obj-$(CONFIG_ROHM_BM1390) += rohm-bm1390.o >> obj-$(CONFIG_BMP280) += bmp280.o >> bmp280-objs := bmp280-core.o bmp280-regmap.o >> obj-$(CONFIG_BMP280_I2C) += bmp280-i2c.o >> diff --git a/drivers/iio/pressure/rohm-bm1390.c b/drivers/iio/pressure/rohm-bm1390.c >> new file mode 100644 >> index 000000000000..82a0cd61d215 >> --- /dev/null >> +++ b/drivers/iio/pressure/rohm-bm1390.c > >> + >> +/* >> + * If the trigger is not used we just wait until the measurement has >> + * completed. The data-sheet says maximum measurement cycle (regardless >> + * the AVE_NUM) is 200 mS so let's just sleep at least that long. If speed >> + * is needed the trigger should be used. >> + */ >> +#define BM1390_MAX_MEAS_TIME_MS 205 >> + >> +static int bm1390_read_data(struct bm1390_data *data, >> + struct iio_chan_spec const *chan, int *val, int *val2) >> +{ >> + int ret, warn; >> + >> + mutex_lock(&data->mutex); >> + /* >> + * We use 'continuous mode' even for raw read because according to the >> + * data-sheet an one-shot mode can't be used with IIR filter. >> + */ >> + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); >> + if (ret) >> + goto unlock_out; >> + >> + switch (chan->type) { >> + case IIO_PRESSURE: >> + msleep(BM1390_MAX_MEAS_TIME_MS); >> + ret = bm1390_pressure_read(data, val); >> + break; >> + case IIO_TEMP: >> + msleep(BM1390_MAX_MEAS_TIME_MS); >> + ret = bm1390_read_temp(data, val); >> + break; >> + default: >> + ret = -EINVAL; >> + } >> + warn = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); >> + if (warn) >> + dev_warn(data->dev, "Failed to stop measurementi (%d)\n", warn); > > measurement Thanks! Seems like an useless vim 'insert' mode change ;) > >> +unlock_out: >> + mutex_unlock(&data->mutex); >> + >> + return ret; >> +} >> + > >> +static int __bm1390_fifo_flush(struct iio_dev *idev, unsigned int samples, >> + s64 timestamp) >> +{ >> + /* BM1390_FIFO_LENGTH is small so we shouldn't run out of stack */ >> + struct bm1390_data_buf buffer[BM1390_FIFO_LENGTH]; >> + struct bm1390_data *data = iio_priv(idev); >> + int smp_lvl, ret, i, warn, dummy; >> + u64 sample_period; >> + __be16 temp = 0; >> + >> + ret = regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &smp_lvl); >> + if (ret) >> + return ret; >> + >> + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); >> + if (!smp_lvl) >> + return 0; >> + >> + if (smp_lvl > BM1390_FIFO_LENGTH) { >> + /* >> + * The fifo holds maximum of 4 samples so valid values >> + * should be 0, 1, 2, 3, 4 - rest are probably bit errors >> + * in I2C line. Don't overflow if this happens. >> + */ >> + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); >> + smp_lvl = BM1390_FIFO_LENGTH; >> + } >> + >> + sample_period = timestamp - data->old_timestamp; >> + do_div(sample_period, smp_lvl); >> + >> + if (samples && smp_lvl > samples) >> + smp_lvl = samples; >> + >> + >> + /* >> + * After some testing it appears that the temperature is not readable >> + * untill the FIFO access has been done after the WMI. Thus, we need > Spell check. until (Why it doesn't have 2 ls is beyond me but that's English being > annoyingly irregular) Thanks. I keep mistyping it. I think I've seen checkpatch warnings on this kind of mistakes before. Makes me wonder if I forgot to run the checkpatch after latest modifications... > >> + * to read the all pressure values to memory and read the temperature >> + * only after that. >> + */ >> + for (i = 0; i < smp_lvl; i++) { >> + /* >> + * When we start reading data from the FIFO the sensor goes to >> + * special FIFO reading mode. If any other register is accessed >> + * during the FIFO read, samples can be dropped. Prevent access >> + * until FIFO_LVL is read. We have mutex locked and we do also >> + * go performing reading of FIFO_LVL even if this read fails. >> + */ >> + if (test_bit(BM1390_CHAN_PRESSURE, idev->active_scan_mask)) { >> + ret = bm1390_pressure_read(data, &buffer[i].pressure); >> + if (ret) >> + break; >> + } >> + >> + /* >> + * Old timestamp is either the previous sample IRQ time, >> + * previous flush-time or, if this was first sample, the enable >> + * time. When we add a sample period to that we should get the >> + * best approximation of the time-stamp we are handling. >> + * >> + * Idea is to always keep the "old_timestamp" matching the >> + * timestamp which we are currently handling. >> + */ >> + data->old_timestamp += sample_period; >> + buffer[i].ts = data->old_timestamp; >> + } >> + /* Reading the FIFO_LVL closes the FIFO access sequence */ >> + warn = regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &dummy); >> + if (warn) >> + dev_warn(data->dev, "Closing FIFO sequence failed\n"); >> + >> + if (ret) >> + return ret; >> + >> + if (test_bit(BM1390_CHAN_TEMP, idev->active_scan_mask)) { >> + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp, >> + sizeof(temp)); >> + if (ret) >> + return ret; >> + pr_info("Temp before reading the FIFO %u\n", be16_to_cpu(temp)); > > Why this print? Thanks! Forgot a debug phase print here... > >> + } >> + >> + if (ret) >> + return ret; >> + >> + for (i = 0; i < smp_lvl; i++) { >> + buffer[i].temp = temp; >> + iio_push_to_buffers_with_timestamp(idev, &buffer[i], >> + buffer[i].ts); > You can just use iio_push_to_buffers() if you've already filled > in the timestamp by hand. The _with_timestamp() version was just to reduce > boilerplate (and given the main it has caused over the years, I'm not > sure it was a good idea!) Right. I had a brainfart on this one. Thought that the iio_push_to_buffers_with_timestamp() would help in case where timestamp was disabled by the user. Now I see this thought was very much not correct. That's what I get when writing code at the afternoon, and especially at Friday afternoon :) My brains are shutting down early :) >> + } >> + >> + return smp_lvl; >> +} > >> + >> +static const struct iio_info bm1390_info = { >> + .read_raw = &bm1390_read_raw, >> + .validate_trigger = iio_validate_own_trigger, >> + .hwfifo_set_watermark = bm1390_set_watermark, >> + .hwfifo_flush_to_buffer = bm1390_fifo_flush, > > Given my (possibly incorrect assumption) that the fifo is useless > without the interrupt, I'd expect to see another version of this > that has read_raw only set. Yes... > Also, why do we need validate_own_trigger. I thought this could > be used with other triggers. If not, then don't register the buffer > for the case with no interrupt either. ... and yes. Thank you :) > >> +}; >> + > >> + >> +static int bm1390_fifo_set_wmi(struct bm1390_data *data) >> +{ >> + u8 regval; >> + >> + regval = data->watermark - BM1390_WMI_MIN; > Trivial: I'd rather we didn't put stuff that clearly isn't the register > value in a variable called regval. I'd just go directly to > > regval = FIELD_PREP(BM1390_MASK_FIFO_LEN, > data->watermark - BMI1390_WMI_MIN); > and avoid that first 'mis'use. Ok. > >> + regval = FIELD_PREP(BM1390_MASK_FIFO_LEN, regval); >> + >> + return regmap_update_bits(data->regmap, BM1390_REG_FIFO_CTRL, >> + BM1390_MASK_FIFO_LEN, regval); >> +} >> + >> +static int bm1390_fifo_enable(struct iio_dev *idev) >> +{ >> + struct bm1390_data *data = iio_priv(idev); >> + int ret; >> + >> + /* We can't do buffered stuff without IRQ as we never get WMI */ >> + if (data->irq <= 0) >> + return -EINVAL; >> + >> + mutex_lock(&data->mutex); >> + if (data->trigger_enabled) { >> + ret = -EBUSY; >> + goto unlock_out; >> + } >> + >> + /* Update watermark to HW */ >> + ret = bm1390_fifo_set_wmi(data); >> + if (ret) >> + goto unlock_out; >> + >> + /* Enable WMI_IRQ */ >> + ret = regmap_set_bits(data->regmap, BM1390_REG_MODE_CTRL, >> + BM1390_MASK_WMI_EN); >> + if (ret) >> + goto unlock_out; >> + >> + /* Enable FIFO */ >> + ret = regmap_set_bits(data->regmap, BM1390_REG_FIFO_CTRL, >> + BM1390_MASK_FIFO_EN); >> + if (ret) >> + goto unlock_out; >> + >> + data->state = BM1390_STATE_FIFO; >> + >> + data->old_timestamp = iio_get_time_ns(idev); >> + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); >> + >> +unlock_out: >> + mutex_unlock(&data->mutex); >> + >> + return ret; >> +} >> + >> +static int bm1390_fifo_disable(struct iio_dev *idev) >> +{ >> + struct bm1390_data *data = iio_priv(idev); >> + int ret; >> + >> + msleep(1); >> + >> + mutex_lock(&data->mutex); >> + /* Disable FIFO */ >> + ret = regmap_clear_bits(data->regmap, BM1390_REG_FIFO_CTRL, >> + BM1390_MASK_FIFO_EN); >> + if (ret) >> + goto unlock_out; >> + >> + data->state = BM1390_STATE_SAMPLE; >> + >> + /* Disable WMI_IRQ */ >> + ret = regmap_clear_bits(data->regmap, BM1390_REG_MODE_CTRL, >> + BM1390_MASK_WMI_EN); >> + if (ret) >> + goto unlock_out; >> + >> + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); > > I'm sure it works in this order but to my mind it would make more sense > (and might still work) for fifo_disable() to be reverse of steps > in fifo_enable(). So I'd expect the mode change first. I think stopping the masurement should indeed be done first. I'm not sure why the order is this. I know I tried suffling the order of starting the measurement while trying to figure out the temperature measurements for first FIFO sample - but I don't think I touched the disabling. So, it has probably been like this from the v1. I'll revise this, thanks! >> + >> +unlock_out: >> + mutex_unlock(&data->mutex); >> + >> + return ret; >> +} > > > >> +static int bm1390_probe(struct i2c_client *i2c) >> +{ >> + struct bm1390_data *data; >> + struct regmap *regmap; >> + struct iio_dev *idev; >> + struct device *dev; >> + unsigned int part_id; >> + int ret; >> + >> + dev = &i2c->dev; >> + >> + regmap = devm_regmap_init_i2c(i2c, &bm1390_regmap); >> + if (IS_ERR(regmap)) >> + return dev_err_probe(dev, PTR_ERR(regmap), >> + "Failed to initialize Regmap\n"); >> + >> + ret = devm_regulator_get_enable(dev, "vdd"); >> + if (ret) >> + return dev_err_probe(dev, ret, "Failed to get regulator\n"); >> + >> + ret = regmap_read(regmap, BM1390_REG_PART_ID, &part_id); >> + if (ret) >> + return dev_err_probe(dev, ret, "Failed to access sensor\n"); >> + >> + if (part_id != BM1390_ID) >> + dev_warn(dev, "unknown device 0x%x\n", part_id); >> + >> + idev = devm_iio_device_alloc(dev, sizeof(*data)); >> + if (!idev) >> + return -ENOMEM; >> + >> + data = iio_priv(idev); >> + data->regmap = regmap; >> + data->dev = dev; >> + data->irq = i2c->irq; >> + /* >> + * For now we just allow BM1390_WMI_MIN to BM1390_WMI_MAX and >> + * discard every other configuration when triggered mode is not used. >> + */ >> + data->watermark = BM1390_WMI_MAX; >> + mutex_init(&data->mutex); >> + >> + idev->channels = bm1390_channels; >> + idev->num_channels = ARRAY_SIZE(bm1390_channels); >> + idev->name = "bm1390"; >> + idev->info = &bm1390_info; >> + idev->modes = INDIO_DIRECT_MODE | INDIO_BUFFER_SOFTWARE; > > Silly question that I might resolve as I read on. > If we don't have the WMI interrupt, do we have buffer_software support? > It could be made to work with a timer, but do you do so? No. I can't say the exact meaning of all these flags is 100% clear to me - but I think we only have the INDIO_BUFFER_TRIGGERED if we don't have the IRQ. Thanks! > >> + >> + ret = bm1390_chip_init(data); >> + if (ret) >> + return dev_err_probe(dev, ret, "sensor init failed\n"); >> + >> + ret = bm1390_setup_buffer(data, idev); >> + if (ret) >> + return ret; >> + >> + /* No trigger if we don't have IRQ for data-ready and WMI */ >> + if (i2c->irq > 0) { >> + ret = bm1390_setup_trigger(data, idev, i2c->irq); >> + if (ret) >> + return ret; >> + } >> + >> + ret = devm_iio_device_register(dev, idev); >> + if (ret < 0) >> + return dev_err_probe(dev, ret, >> + "Unable to register iio device\n"); >> + >> + return 0; >> +} >
On Tue, 26 Sep 2023 13:29:02 +0300 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On 9/25/23 16:16, Jonathan Cameron wrote: > > On Mon, 25 Sep 2023 10:01:09 +0300 > > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > > > >> On 9/24/23 18:57, Jonathan Cameron wrote: > >>> On Fri, 22 Sep 2023 14:16:08 +0300 > >>> Matti Vaittinen <mazziesaccount@gmail.com> wrote: > >>> > >>>> The iio_generic_buffer can return garbage values when the total size of > >>>> scan data is not a multiple of largest element in the scan. This can be > >>>> demonstrated by reading a scan consisting for example of one 4 byte and > >>>> one 2 byte element, where the 4 byte elemnt is first in the buffer. > >>>> > >>>> The IIO generic buffert code does not take into accunt the last two > >>>> padding bytes that are needed to ensure that the 4byte data for next > >>>> scan is correctly aligned. > >>>> > >>>> Add padding bytes required to align the next sample into the scan size. > >>>> > >>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > >>>> --- > >>>> Please note, This one could have RFC in subject.: > >>>> I attempted to write the fix so that the alignment is done based on the > >>>> biggest channel data. This may be wrong. Maybe a fixed 8 byte alignment > >>>> should be used instead? This patch can be dropped from the series if the > >>>> fix is not correct / agreed. > >>>> > >>>> tools/iio/iio_generic_buffer.c | 15 ++++++++++++++- > >>>> 1 file changed, 14 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c > >>>> index 44bbf80f0cfd..fc562799a109 100644 > >>>> --- a/tools/iio/iio_generic_buffer.c > >>>> +++ b/tools/iio/iio_generic_buffer.c > >>>> @@ -54,9 +54,12 @@ enum autochan { > >>>> static unsigned int size_from_channelarray(struct iio_channel_info *channels, int num_channels) > >>>> { > >>>> unsigned int bytes = 0; > >>>> - int i = 0; > >>>> + int i = 0, max = 0; > >>>> + unsigned int misalignment; > >>>> > >>>> while (i < num_channels) { > >>>> + if (channels[i].bytes > max) > >>>> + max = channels[i].bytes; > >>>> if (bytes % channels[i].bytes == 0) > >>>> channels[i].location = bytes; > >>>> else > >>>> @@ -66,6 +69,16 @@ static unsigned int size_from_channelarray(struct iio_channel_info *channels, in > >>>> bytes = channels[i].location + channels[i].bytes; > >>>> i++; > >>>> } > >>>> + /* > >>>> + * We wan't the data in next sample to also be properly aligned so > >>>> + * we'll add padding at the end if needed. TODO: should we use fixed > >>>> + * 8 byte alignment instead of the size of the biggest samnple? > >>>> + */ > >>> > >>> Should be aligned to max size seen in the scan. > >> > >> Or, maybe it should be > >> min(max_size_in_scan, 8); > >> ? > > > > Definitely not. If you are grabbing just one channel of 8 bit data, > > we want it to be tightly packed. > > I think that in this case the max_size_in_scan would be 1, and min(1, 8) > would be 1 as well, resulting a tightly packed data. I am just wondering > if we should use 8 as maximum alignment - eg, if our scan has 16 bytes > data + 1 byte data, we would add 7 bytes of padding, not 15 bytes of > padding. I am not sure what is the right thing to do. Ah I read that backwards as you've noticed. We don't have any such big channels, so indeed have some flexibility here. I think we stick to naturally aligned so 16 bytes case would be 16 byte aligned - mostly because I don't expect to see one any time soon and because it makes the docs simpler. > > > If we have a bug that already made that true then we might be stuck > > with it, but I'm fairly sure we don't. > >> > >> I think my suggestion above may yield undesirable effects should the > >> scan elements be greater than 8 bytes. (Don't know if this is supported > >> though) > > > > It is supported in theory, in practice not seen one yet. > > So, whether to unconditionally use largest scan element sized alignment > - or largest scan element up to 8 bytes - is a question we haven't hit > yet :) > > Actually, more I stare at the alignment code here, less sure I am it is > correct - but maybe I don't understand how the data should be aligned. > > I think it works if allowed data sizes are 1, 2, 4, and 8. However, I > suspect it breaks for other sizes. Indeed - it's meant to be power of 2 only. More than possible we don't check that rigorously enough or have it clearly documented though. The aim is for the data to be padded for efficient accesses + because it is a pain to deal with arbitrary padding so we restrict it to power of 2 naturally aligned only. One relaxation we've talked about in the past is packing multiple channels per byte (for logic analyser cases). Not done it yet though. > > For non power of2 sizes, the alignment code will result strange > alignments. For example, scan consisting of two 6-byte elements would be > packed - meaning the second element would probably break the alignment > rules by starting from address '6'. I think that on most architectures > the proper access would require 2 padding bytes to be added at the end > of the first sample. Current code wouldn't do that. > > If we allow only power of 2 sizes - I would expect a scan consisting of > a 8 byte element followed by a 16 byte element to be tightly packed. I'd > assume that for the 16 byte data, it'd be enough to ensure 8 byte > alignment. Current code would however add 8 bytes of padding at the end > of the first 8 byte element to make the 16 byte scan element to be > aligned at 16 byte address. To my uneducated mind this is not needed - > but maybe I just don't know what I am writing about :) 16 byte alignement is probably not needed - but who knows for future architecture. Note this has been really non obvious in the past and is why we force alignment for timestamp elements in lots of drivers. Most architectures align an s64 in a c structure to an 8 byte boundary but x86 32 bit doesn't. Hence we have to force it all over the place. Fixing that (because userspace ABI data placement should not vary across architectures) was a pain. I don't want to do it again! > > In any case, the patch here should fix things when allowed scan element > sizes are 1, 2, 4 and 8 and we have to add padding after last scan > element. It won't work for other sizes, but as I wrote, I suspect the > whole alignment code here may be broken for other sizes so things > shouldn't at least get worse with this patch... I think this should be > revised if we see samples of other sizes - and in any case, this might > at least warrant a comment here :) (I reserve a right to be wrong. > Haven't been sleeping too well lately and my head is humming...) Might be worth a power of 2 only comment. J