- 07 Jul, 2020 33 commits
-
-
Alexandru Ardelean authored
This change attaches the life-cycle of the kfifo buffer & IRQ to the parent-device. This in turn cleans up the exit & error paths, since we don't need to explicitly cleanup these resources. The main intent here is to remove the explicit cleanup of the 'indio_dev->buffer' via 'iio_kfifo_free(indio_dev->buffer);'. As we want to add support for multiple buffers per IIO device, having it exposed like this makes it tricky to consider a safe backwards compatible approach for it. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This change attaches the life-cycle of the channels array to the parent device object that is attached to the IIO device. This way we can remove from the cleanup code, the explicit tiadc_channels_remove() which simply does a kfree() on the channels array. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Jonathan Cameron authored
Whilst it's unlikely this device will ever be instantiated using ACPI, there is little advantage not assigning the of_device_id table in all cases and it avoids providing an example that might be coppied into new drivers. Also include mod_devicetable.h whilst here as of_device_id is defined in there so including the header is best practice. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Artur Rojek <contact@artur-rojek.eu> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
These stop us using ACPI PRP0001 to instantiate the device. I am slowly clearly out use of these in IIO to avoid this being coppied into new drivers. Here I also included mod_devicetable.h as we are using of_match_id which is defined in there and hence it is best practice to include it directly. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Phil Reid <preid@electromag.com.au> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
Dropping this allows use of ACPI PRP0001. I'm also looking to drop all of_match_ptr use in IIO in order to avoid it getting cut and paste into new drivers in the future. Also add a direct include of mod_devicetable.h to reflect the use of struct of_device_id. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Matt Ranostay <matt.ranostay@konsulko.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
Allows ACPI PRP0001 to be used with this driver. Also adds mod_devicetable.h header as the driver is directly using struct of_device_id which is defined in that file. I'm also trying to clear out of_match_ptr use in IIO to avoid it being cut and paste into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Mårten Lindahl <martenli@axis.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
These just prevent the driver being used with ACPI PRP0001. I am also trying to remove these from IIO in general to avoid them being coppied into new drivers. Also include the mod_devicetable.h header as we are using of_device_id which is defined in there. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
Whilst this driver already supports explicit ACPI bindings we might as well also allow for PRP0001 based binding. I'm also keen to remove of_match_ptr from IIO drivers to avoid this (now) anti-pattern getting coppied into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
Dropping of_match_ptr allows this driver to be used with ACPI. The header includes are adjusted to include platform_device.h and mod_devicetable.h instead of OF specific header as nothing from that header itself is actually used. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnaud Pouliquen <arnaud.pouliquen@st.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
They stop the driver being used with ACPI PRP0001 and are something I want to avoid being cut and paste into new drivers. Also switch the include from of.h to mod_devicetable.h as we struct of_device_id is defined in there and we don't use anything actually in of.h. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Angelo Compagnucci <angelo.compagnucci@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
These just prevent the driver being used with ACPI PRP0001. They also get cut and paste into new drivers and we want to discourage this from happening by cleaning it out in general. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Oskar Andero <oskar.andero@gmail.com> Cc: Søren Andersen <san@rosetechnology.dk> Cc: Lukas Wunner <lukas@wunner.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
These just stop the driver being used with ACPI PRP0001 and we are trying to clear them out of IIO to avoid them getting copied into new drivers. Also add the mod_devicetable.h include as we are using struct of_device_id which is defined in there. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
Allows use of driver with ACPI PRP0001 base binding. Mostly this is about trying to avoid cut and paste of this into new drivers (it is a frequent review comment) rather than any thought that this driver might get used on an ACPI platform. The mod_devicetable.h include is to encourage best practice of including any header directly used within the code (here for of_match_id) Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
This prevents the driver being used with ACPI PRP0001 based bindings. Also switch include to mod_devicetable.h which devices the used id structure. Note this is most about removing something I don't want want cut and paste into new driver rather than any thought that this particular driver will be used in an ACPI system (though it might!) Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
Part of a slow effort to avoid OF specific code in IIO. Whilst the main advantages of this are not likely to be seen in this particular driver (ACPI support via PRP0001) the change proposed does make things a bit more maintainable and also ensures that this particular (now) anti-patern is less likely to be cut and paste into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
The macro prevents use of driver with ACPI PRP0001 and the of_match_id structure is defined in mod_devicetable.h so include that directly rather than of.h. Note this is mostly about removing something I don't want cut and paste into new drivers rather than expectation that this particular driver will be used on an ACPI platform. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
These just prevent the driver being used with ACPI PRP0001 and provide no major benefits. Part of clearing these out in general in IIO to avoid cut and paste repetition in new drivers. Also include mod_devicetable.h as we directly make use of of_device_id which is defined in there. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Philippe Reynes <tremyfr@yahoo.fr> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
Allows driver to use ACPI PRP0001 binding and there was no particular advantage in having the protections in this driver. Mostly this part of an effort to remove as many OF specific bits of handling from IIO and use the generic forms where possible. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
Allows use of ACPI with PRP0001 and is generally something we are trying to avoid having people cut and paste into new drivers without thinking about it. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
I guess this is a left over from some earlier cleanup. Not used currently. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
Whilst is unlikely anyone will be using this part with an ACPI PRP0001 based binding any time soon, we are getting a lot of cut and pasting of this pattern so I am looking to remove it entirely from IIO. In this case CONFIG_OF protections also removed and mod_devicetable.h include added given direct use of struct of_device_id. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Krzysztof Kozlowski authored
The compatible for BMM150 should not have "_magn" suffix because, unlike two other Bosch devices, it is only a magnetometer. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Krzysztof Kozlowski authored
The driver supports also BMC156B and BMM150B. Add existing compatibles marking the BMM150B one as deprecated (due to redundant suffix "_magn" because the device unlike two others is a magnetometer only). Introduce a new, proper compatible for the deprecated one. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Nuno Sá authored
The value retrieved by `irqd_get_trigger_type()` is not an irq flag. While the values are the same, the meaning is different. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Randy Dunlap authored
Drop the doubled word "struct". Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: William Breathitt Gray <vilhelm.gray@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Randy Dunlap authored
Drop the doubled word "the". Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: linux-iio@vger.kernel.org Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
Same as with other private fields, this moves the event interface reference to the opaque IIO device object, to be invisible to drivers. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This change moves the 'buffer_list' away from the public IIO device object into the private part. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This change bit straightforward and simple, since the 'channel_attr_list' & 'chan_attr_group' fields are only used in 'industrialio-core.c'. This change moves to the private IIO device object Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This change moves all iio_dev debugfs fields to the iio_dev_priv object. It's not the biggest advantage yet (to the whole thing of abstractization) but it's a start. The iio_get_debugfs_dentry() function (which is moved in industrialio-core.c) needs to also be guarded against the CONFIG_DEBUG_FS symbol, when it isn't defined. We do want to keep the inline definition in the iio.h header, so that the compiler can better infer when to compile out debugfs code that is related to the IIO debugfs directory. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
There was a recent discussion about this code: https://lore.kernel.org/linux-iio/20200322165317.0b1f0674@archlinux/ This looks like a good time to removed this, since any issues about it should pop-up under testing, because the iio_dev is having a bit of an overhaul and stuff being moved to iio_dev_opaque. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
There are plenty of bad designs we want to discourage or not have to review manually usually about accessing private (marked as [INTERN]) fields of 'struct iio_dev'. Sometimes users copy drivers that are not always the best examples. A better idea is to hide those fields into the framework. For 'struct iio_dev' this is a 'struct iio_dev_opaque' which wraps a public 'struct iio_dev' object. In the next series, some fields will be moved to this new struct, each with it's own rework. This rework will not be complete-able for a while, as many fields need some drivers to be reworked in order to finalize them (e.g. 'indio_dev->mlock'). But some fields can already be moved, and in time, all of them may get there (in the 'struct iio_dev_opaque' object). Since a lot of drivers also call 'iio_priv()', in order to preserve fast-paths (where this matters), the public iio_dev object will have a 'priv' field that will have the pointer to the private information already computed. The reference returned by this field should be guaranteed to be cacheline aligned. The opaque parts will be moved into the 'include/linux/iio/iio-opaque.h' header. Should the hidden information be required for some debugging or some special needs, it can be made available via this header. Otherwise, only the IIO core files should include this file. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
We may want to get rid of the iio_priv_to_dev() helper. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. The iio_priv() helper won't be affected by the rework, as the iio_dev struct will keep a reference to the private information. For this driver, not using iio_priv_to_dev(), means reworking some paths to pass the iio device and using iio_priv() to access the private information, and also keeping a reference to the iio device for some quirky paths. One [quirky] path is the at91_adc_workq_handler() which requires the IIO device & the state struct to push to buffers. Since this requires the back-ref to the IIO device, the at91_adc_touch_pos() also uses it. This simplifies the patch a bit. The information required in this function is mostly for debugging purposes. Replacing it with a reference to the IIO device would have been a slightly bigger change, which may not be worth it (for just the debugging purpose and given that we need the back-ref to the IIO device anyway). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 27 Jun, 2020 7 commits
-
-
Tomasz Duszynski authored
Add SCD30 sensor binding file. Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Tomasz Duszynski authored
Add serial interface driver for the SCD30 sensor. Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Tomasz Duszynski authored
Add I2C interface driver for the SCD30 sensor. Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Tomasz Duszynski authored
Add Sensirion SCD30 carbon dioxide core driver. Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Jean-Baptiste Maneyrol authored
Add MAINTAINERS entry for InvenSense ICM-426xx IMU device. Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Jean-Baptiste Maneyrol authored
Document the ICM-426xxx devices devicetree bindings. Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Jean-Baptiste Maneyrol authored
Add a timestamping mechanism for buffer that provides accurate event timestamps when using watermark. This mechanism estimates device internal clock by comparing FIFO interrupts delta time and device elapsed time computed by parsing FIFO data. Take interrupt timestamp in hard irq handler and add IIO device specific timestamp structures in device private allocation. Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-