On Sun, Feb 14, 2021 at 5:06 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > On Sun, 14 Feb 2021 16:33:08 +0200 > Alexandru Ardelean <alexandru.ardelean@xxxxxxxxxx> wrote: > > > This is a re-spin of an older set [1]: > > https://patchwork.kernel.org/project/linux-iio/patch/20200401125936.6398-1-alexandru.ardelean@xxxxxxxxxx/ > > > > Patch 'iio: adc: ti_am335x_adc: remove omitted iio_kfifo_free()' is > > already be present in a fixes-togreg path. It did not make it yet > > downstream in the iio-togreg path. > > > > Following [1], where there was a suggestion to name this > > 'devm_iio_device_attach_new_kfifo_buffer()', I took another look and > > devm_iio_kfifo_buffer_setup() made more sense, since there is already a > > '{devm_}iio_triggered_buffer_setup()' helper. > > > > This reduces the usage of the iio_device_attach_buffer() helper to a > > more manage-able state. > > This is related to comment: > > https://lore.kernel.org/linux-iio/CA+U=Dsp5hxd9=rNbigUMFALBpPVBqDZDRq_Pe69ggKak7p46=w@xxxxxxxxxxxxxx/T/#u > This definitely reduces where we need to handle errors from iio_device_attach_buffer() which > is good. I guess we need a rebase of one or the other series though to make > this all fit together. > > > > > This should have gone before the multibuffer patch-set, but I was still > > waiting on patch 'iio: adc: ti_am335x_adc: remove omitted iio_kfifo_free()' > > to make it downstream in iio-togreg. > > Oops. I've been a touch slow sending things onwards recently. > > > > > Regarding patch 'iio: kfifo: un-export devm_iio_kfifo_allocate() function' > > I would have also wanted to un-export iio_kfifo_allocate() & > > iio_kfifo_free(), but that still needs a bit of work to cleanup the IIO > > dummy buffer. > > Yup. The lack of having a parent is a bit of pain. We just need to fake one > I guess however silly that seems. I tried faking it, but it needs a rework of the drivers/iio/industrialio-sw-device.c logic. The whole IIO dummy driver is an IIO SW device, so maybe the sanest thing, is to create platform devices or just parent devices in there, and pass the parent to the IIO device. I tried making the IIO dummy a standalone platform driver, but then you end up having to probe() paths, 1 via platform_driver and one via iio-sw-device. > > Mind you, I'd also like to see this go over to the triggered_buffer stuff > if possible. > > > > Related to patchset: > > https://lore.kernel.org/linux-iio/20201203095005.72252-1-alexandru.ardelean@xxxxxxxxxx/ > > > > The IIO dummy driver seems to be one of those blockers in cleaning up > > some IIO API. > > > > Jonathan > > > Alexandru Ardelean (5): > > iio: adc: ti_am335x_adc: remove omitted iio_kfifo_free() > > iio: kfifo: add devm_iio_kfifo_buffer_setup() helper > > iio: make use of devm_iio_kfifo_buffer_setup() helper > > iio: accel: sca3000: use devm_iio_kfifo_buffer_setup() helper > > iio: kfifo: un-export devm_iio_kfifo_allocate() function > > > > .../driver-api/driver-model/devres.rst | 2 +- > > drivers/iio/accel/sca3000.c | 19 ++------- > > drivers/iio/accel/ssp_accel_sensor.c | 14 +++---- > > drivers/iio/adc/ina2xx-adc.c | 14 +++---- > > drivers/iio/adc/ti_am335x_adc.c | 24 +++-------- > > drivers/iio/buffer/kfifo_buf.c | 42 ++++++++++++++++++- > > .../cros_ec_sensors/cros_ec_sensors_core.c | 13 +++--- > > drivers/iio/gyro/ssp_gyro_sensor.c | 14 +++---- > > drivers/iio/health/max30100.c | 16 ++++--- > > drivers/iio/health/max30102.c | 16 ++++--- > > .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 14 +++---- > > .../iio/imu/inv_icm42600/inv_icm42600_gyro.c | 13 +++--- > > .../iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 15 +++---- > > drivers/iio/light/acpi-als.c | 12 +++--- > > drivers/iio/light/apds9960.c | 16 ++++--- > > .../staging/iio/impedance-analyzer/ad5933.c | 23 ++-------- > > include/linux/iio/kfifo_buf.h | 7 +++- > > 17 files changed, 125 insertions(+), 149 deletions(-) > > >
