- 03 Dec, 2020 40 commits
-
-
Jeremy Cline authored
Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI device. Normally we would handle this by letting the special drivers/platform/x86/i2c-multi-instantiate.c driver handle the BOSC0200 ACPI id and let it instantiate 2 bmc150_accel type i2c_client-s for us. But doing so changes the modalias for the first accelerometer (which is already supported and used on many devices) from acpi:BOSC0200 to i2c:bmc150_accel. The modalias is not only used to load the driver, but is also used by hwdb matches in /lib/udev/hwdb.d/60-sensor.hwdb which provide a mountmatrix to userspace by setting the ACCEL_MOUNT_MATRIX udev property. Switching the handling of the BOSC0200 over to i2c-multi-instantiate.c will break the hwdb matches causing the ACCEL_MOUNT_MATRIX udev prop to no longer be set. So switching over to i2c-multi-instantiate.c is not an option. Changes by Hans de Goede: -Add explanation to the commit message why i2c-multi-instantiate.c cannot be used -Also set the dev_name, fwnode and irq i2c_board_info struct members for the 2nd client Signed-off-by:
Jeremy Cline <jeremy@jcline.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201130141954.339805-2-hdegoede@redhat.com BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198671Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Hans de Goede authored
The bmc150_accel_dat struct irq member is only ever used inside bmc150_accel_core_probe, drop it and just use the function argument directly. Signed-off-by:
-
Jonathan Cameron authored
Inspired by Andy Shevchenko's proposal to use get_unaligned_leXX(). The whole one time programable memory is treated as a single 64bit little endian value. Thus we can avoid a lot of messy handling of fields overlapping byte boundaries by just loading and manipulating it as an __le64 converted to a u64. That lets us just use FIELD_GET() and GENMASK() to extract the values desired. Note only build tested. We need to use GENMASK_ULL and %llX formatters to account for the larger types used in computing the various fields. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
Jonathan Cameron authored
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings. In this driver the timestamp can end up in various different locations depending on what other channels are enabled. As a result, we don't use a structure to specify it's position as that would be misleading. Fixes: e717f8c6 ("iio: adc: Add the TI ads124s08 ADC code") Reported-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Dan Murphy <dmurphy@ti.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-9-jic23@kernel.org
-
Jonathan Cameron authored
The buffer is expressed as a u32 array, yet the extra space for the s64 timestamp was expressed as sizeof(s64)/sizeof(u16). This will result in 2 extra u32 elements. Fix by dividing by sizeof(u32). Fixes: e717f8c6 ("iio: adc: Add the TI ads124s08 ADC code") Signed-off-by: Jonathan Cameron<Jonathan.Cameron@huawei.com> Reviewed-by:
-
Jonathan Cameron authored
Whilst this is another case of the issue Lars reported with an array of elements of smaller than 8 bytes being passed to iio_push_to_buffers_with_timestamp(), the solution here is a bit different from the other cases and relies on __aligned working on the stack (true since 4.6?) This one is unusual. We have to do an explicit memset() each time as we are reading 3 bytes into a potential 4 byte channel which may sometimes be a 2 byte channel depending on what is enabled. As such, moving the buffer to the heap in the iio_priv structure doesn't save us much. We can't use a nice explicit structure on the stack either as the data channels have different storage sizes and are all separately controlled. Fixes: cc26ad45 ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver") Reported-by:
-
Jonathan Cameron authored
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable array in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings. In this driver, depending on which channels are enabled, the timestamp can be in a number of locations. Hence we cannot use a structure to specify the data layout without it being misleading. Fixes: 77c4ad2d ("iio: imu: Add initial support for Bosch BMI160") Reported-by:
-
Jonathan Cameron authored
The comment implies this device has 3 sensor types, but it only has an accelerometer and a gyroscope (both 3D). As such the buffer does not need to be as long as stated. Note I've separated this from the following patch which fixes the alignment for passing to iio_push_to_buffers_with_timestamp() as they are different issues even if they affect the same line of code. Signed-off-by:
-
Jonathan Cameron authored
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc() so no data can leak apart from previous readings. The explicit alignment of ts is not necessary in this case but does make the code slightly less fragile so I have included it. Fixes: 39631b5f ("iio: Add Freescale mag3110 magnetometer driver") Reported-by:
-
Jonathan Cameron authored
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() This data is allocated with kzalloc() so no data can leak apart from previous readings. A local unsigned int variable is used for the regmap call so it is clear there is no potential issue with writing into the padding of the structure. Fixes: 3025c868 ("iio: light: add support for UVIS25 sensor") Reported-by:
Lorenzo Bianconi <lorenzo@kernel.org> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-3-jic23@kernel.org
-
Jonathan Cameron authored
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc() so no data can leak apart from previous readings and in this case the status byte from the device. The forced alignment of ts is not necessary in this case but it potentially makes the code less fragile. >From personal communications with Mikko: We could probably split the reading of the int register, but it would mean a significant performance cost of 20 i2c clock cycles. Fixes: e12ffd24 ("iio: light: rpr0521 triggered buffer") Signed-off-by:
-
Jonathan Cameron authored
By adding a few local variables and avoiding a void * for a parameter we can easily make all the endian types explicit and get rid of the warnings from sparse: CHECK drivers/iio/adc/ti-adc084s021.c drivers/iio/adc/ti-adc084s021.c:84:26: warning: incorrect type in assignment (different base types) drivers/iio/adc/ti-adc084s021.c:84:26: expected unsigned short [usertype] drivers/iio/adc/ti-adc084s021.c:84:26: got restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 Signed-off-by:
-
Jonathan Cameron authored
As we no longer support a try again if we cannot reenable the trigger rename the function to reflect this. Also we don't do anything with the value returned so stop it returning anything. For the few drivers that didn't already print an error message in this patch, add such a print. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Christian Oder <me@myself5.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Nishant Malpani <nish.malpani25@gmail.com> Cc: Daniel Baluta <daniel.baluta@oss.nxp.com> Link: https://lore.kernel.org/r/20200920132548.196452-3-jic23@kernel.org
-
Jonathan Cameron authored
The original reason for this behaviour is long gone and no current drivers are making use of this function correctly. Note however, that you would be very unlucky to actually hit the problem as it would require a bus comms failure in the callback. This dates back a long way. The original board on which I did a lot of early IIO development only supported edge interrupts, but some of the sensors were level interrupt based. As such, the lis3l02dq driver did a dance with checking a GPIO to identify if it should retrigger. That was an unsustainable hack so we later just stopped supporting interrupts for that particular combination. There are a number of drivers where a fault on a bus read in the try_reenable() callback will result in them returning non 0 and incorrectly then causing iio_trigger_poll() to be called. Anyhow, this handling is unused and causing issues so let us rip it out. Link: https://lore.kernel.org/linux-iio/20200813075358.13310-1-lars@metafoo.de/ After this the try_reenable() naming makes no sense, so as a follow up patch I'll rename it to simply reenable(). I haven't done that here as it will add noise to the fix for backporting. Signed-off-by:
-
Lino Sanfilippo authored
In function iio_map_array_register() properly rewind in case of error. Signed-off-by:
Lino Sanfilippo <LinoSanfilippo@gmx.de> Reviewed-by:
-
Lino Sanfilippo authored
Introduce an unlocked version of iio_map_array_unregister(). This function can help to unwind in case of error while the iio_map_list_lock mutex is held. Signed-off-by:
-
Lorenzo Bianconi authored
Signed-off-by:
-
Lorenzo Bianconi authored
Add support to STM LSM6DSOP (acc + gyro) Mems sensor https://www.st.com/resource/en/datasheet/lsm6dsop.pdfSigned-off-by:
-
Lorenzo Bianconi authored
Shrink st_lsm6dsx_sensor_settings table size moving wai address info in id array and remove duplicated code Signed-off-by:
-
Alexandre Belloni authored
at91_adc_probe_dt is now small enough to be merged back in at91_adc_probe. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20201128222818.1910764-8-alexandre.belloni@bootlin.comSigned-off-by:
-
Alexandre Belloni authored
The trigger child nodes are not necessary anymore as they are defined directly by the driver, depending on the compatible string. Signed-off-by:
-
Alexandre Belloni authored
Move the available trigger definition back in the driver to stop cluttering the device tree. There is no functional change except that it actually fixes the available triggers for at91sam9rl as it inherited the list from at91sam9260 but actually has the triggers from at91sam9x5. Signed-off-by:
-
Jonathan Cameron authored
There are a few things we would do differently in an ADC binding if we were starting from scratch but we are stuck with what we have (which made sense back when this was written!) We may be able to tighten up some elements of this binding in the future by careful checking of what values properties can actually take. Note the unusual sign off chain is representative of the path this patch took. Jonathan wrote the patch, which was then included in a series by Alexandre and ultimately applied by Jonathan. [Alexandre Belloni: add sama5d3, remove atmel,adc-res and atmel,adc-res-names] Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Alexandre Belloni authored
Remove atmel,adc-res and atmel,adc-res-names as they are not necessary and are handled by the driver. Also add sama5d3 to the list of possible chips. Signed-off-by:
-
Alexandre Belloni authored
Move the possible resolution values back to the driver. This removes the atmel,adc-res and atmel,adc-res-names properties, leaving only atmel,adc-use-res. As atmel,adc-res-names had to contain "lowres" and "highres", those where already the only allowed values for atmel,adc-use-res. Also introduce a new compatible string for the sama5d3 as this is the only one with a different resolution. Also it doesn't even have the LOWRES bit. Signed-off-by:
-
Alexandre Belloni authored
The driver is DT only since commit ead1c9f3 ("iio: adc: at91_adc: remove platform data and move defs in driver file"). Remove the leftover platform_device_id array. Signed-off-by:
-
Jonathan Cameron authored
There were a few parts of the example that did not conform to the binding description and would not have worked with the Linux driver as a result. Fixed them whilst doing this conversion. Signed-off-by:
Matt Ranostay <matt.ranostay@konsulko.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Link: https://lore.kernel.org/r/20201031181242.742301-11-jic23@kernel.org
-
Jonathan Cameron authored
Simple conversion using the new iio-consumers.yaml binding in the dt-schema. Signed-off-by:
-
Jonathan Cameron authored
Simple binding so straight forward conversion, though did require adding a separate binding document for the max1027 to reflect its abilities to provide channels to consumers. Signed-off-by:
-
Jonathan Cameron authored
The afe/voltage-divider.yaml example uses this device with 2 properties not provided by trivial-devices.yaml (spi-max-frequency and #io-channel-cells) Solve that by creating a more specific binding doc. Signed-off-by:
-
Jonathan Cameron authored
Very simple binding. As such straight forward conversion. Signed-off-by:
-
Jonathan Cameron authored
Note this includes a fix in the example where we had *-mul instead of *-mult. The binding doc and driver agree that it should be *-mult Signed-off-by:
-
Jonathan Cameron authored
Straight forward format conversion. The example in here is fun in that it has 2 separate provider / consumer pairs. Signed-off-by:
-
Jonathan Cameron authored
We use this part in an example for the envelope detector. That showed that we need to allow for the #io-channel-cells property which trivial-devices.yaml does not. It doesn't make sense to add that property to trivial-devices as it only applies for those devices that can provide some sort of DAC or ADC service to another device driver. Hence solution will be to pull some IIO devices out to have their own file on a case by case basis. Signed-off-by:
-
Jonathan Cameron authored
Txt to yaml format conversion. I dropped the example section describing the measurement ADC, as that isn't strictly part of this binding. Uses the new dt-schema/schema/iio/iio-consumer.yaml schema. Signed-off-by:
-
Jonathan Cameron authored
File contained generic IIO wide bindings. Now part of the external dt-schema repository. Signed-off-by:
-
Jonathan Cameron authored
Also add additionalProperties: false for the child nodes. Signed-off-by:
-
Jonathan Cameron authored
This both ensures this binding is compliant with the generic properties and reduces the amount we need to specify in this separate binding. Whilst here mark the child node as additionalProperties: false Signed-off-by:
-
Jonathan Cameron authored
Each driver that uses this will need to use a $ref We can't always enable it like most of the generic bindings due to channel@X matching far more widely than IIO. Signed-off-by:
-
Jonathan Cameron authored
This basically has same questions as for the afe4403. We could combine the two bindings, but as the drivers are separate and it would be a little fiddly due to different buses let's keep the separating. To repeat questions from the ti,afe4403 binding. A few questions came up whilst converting this one. 1) What is actually required? - Checking Linux driver, interrupt is not, and the tx-supply could be supplied by a stub regulator as long as it's always on. As such I have reduced the required list to just compatible and reg. 2) What is the regulator called? - It's tx-supply in the binding doc, but the driver request tx_sup I will shortly send out a fix for the driver to match the binding doc which is the better choice of naming. As Andrew's email is bouncing, I've put myself as temporary maintainer for this binding until someone else steps up. Signed-off-by:
-
