[ Upstream commit 8c576f87ad ]
In order to later move this variable within the opaque structure, let's
create a helper for accessing it in read-only mode. This helper will be
exposed to device drivers and kept accessible for the few that could need
it. The write access to this variable however should be fully reserved to
the core so in a second step we will hide this variable into the opaque
structure.
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20220207143840.707510-11-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stable-dep-of: 7771c8c80d ("iio: cros_ec: fix an use-after-free in cros_ec_sensors_push_data()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 632fe0bb8c upstream.
The pm_runtime_enable will increase power disable depth.
If the probe fails, we should use pm_runtime_disable() to balance
pm_runtime_enable(). In the PM Runtime docs:
Drivers in ->remove() callback should undo the runtime PM changes done
in ->probe(). Usually this means calling pm_runtime_disable(),
pm_runtime_dont_use_autosuspend() etc.
We should do this in error handling.
Fix this problem for the following drivers: bmc150, bmg160, kmx61,
kxcj-1013, mma9551, mma9553.
Fixes: 7d0ead5c3f ("iio: Reconcile operation order between iio_register/unregister and pm functions")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220106112309.16879-1-linmq006@gmail.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
BMC156 is another accelerometer that works just fine with the bmc150-accel
driver. It's very similar to BMC150 (also a accelerometer + magnetometer
combo) but with only one accelerometer interrupt pin. It would make sense
if only INT1 was exposed but someone at Bosch decided to only have an
INT2 pin.
Try to deal with this by making use of the INT2 support introduced
in the previous commit and force using INT2 for BMC156. To detect
that we need to bring up a simplified version of the previous type IDs.
Note that unlike the type IDs removed in commit c06a6aba68
("iio: accel: bmc150: Drop misleading/duplicate chip identifiers")
here I only add one for the special case of BMC156. Everything else
still happens by reading the CHIP_ID register since the chip type
information often is not accurate in ACPI tables.
Tested-by: Nikita Travkin <nikita@trvn.ru> # BMC156
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210802155657.102766-5-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some Bosch accelerometers have two interrupt pins (INT1 and INT2).
At the moment, the driver uses only the first one, which is fine for
most situations. However, some boards might only have INT2 connected
for some reason.
Add the necessary bits and configuration to set up INT2. Then try
to detect this situation at least for device tree setups by checking
if the first interrupt (the one picked by the I2C/SPI core) is actually
named "INT2" using the interrupt-names property.
of_irq_get_byname() returns either 0 or some error code in case
the driver probed without device tree, so in all other cases we fall
back to configuring INT1 as before.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210802155657.102766-4-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
It is quite strange that BMA222 and BMA222E have very close, yet
subtly different values in their scale tables. Comparing the datasheets
this is simply because the "Resolution" for the different measurement
ranges are documented with different precision.
For example, for +-2g the BMA222 datasheet [1] suggests a resolution
of 15.6 mg/LSB, while the BMA222E datasheet [2] suggests 15.63 mg/LSB.
Actually, there is no need to rely on the resolution given by the Bosch
datasheets. The resolution and scale can be calculated more consistently
and accurately using the range (e.g. +-2g) and the channel size (e.g. 8 bits).
Distributing 4g (-2g to 2g) over 8 bits results in an exact resolution
of (4g / 2^8) = 15.625 mg/LSB which is the same value as in both datasheets,
just slightly more accurate. Multiplying g = 9.80665 m/s^2 we get a more
accurate value for the IIO scale table.
Generalizing this we can calculate the scale tables more accurately using
(range / 2^bits) * g * 10^6 (because of IIO_VAL_INT_PLUS_MICRO).
Document this and make the scale tables more consistent and accurate
for all the variants using that formula. Now the scale tables for
BMA222 and BMA222E are consistent and probably slightly more accurate.
[1]: https://media.digikey.com/pdf/Data%20Sheets/Bosch/BMA222.pdf
[2]: https://www.mouser.com/datasheet/2/783/BST-BMA222E-DS004-06-1021076.pdf
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gnail.com>
Link: https://lore.kernel.org/r/20210611182442.1971-1-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Commit c1d1c4a62d ("iio: accel: bma180: BMA254 support") added
BMA254 support to the bma180 driver and changed some naming to BMA25x
to make it easier to add support for BMA253 and BMA255.
Unfortunately, there is quite some overlap between the bma180 driver
and the bmc150-accel driver. Back when the commit was made, the
bmc150-accel driver actually already had support for BMA255, and
adding support for BMA254 would have been as simple as adding a new
compatible to bmc150-accel.
The bmc150-accel driver is a bit better for BMA254 since it also
supports the motion trigger/interrupt functionality. Fortunately,
moving BMA254 support over to bmc150-accel is fairly simple because
the drivers have compatible device tree bindings.
Revert most of the changes for BMA254 support in bma180 and move
BMA254 over to bmc150-accel. This has the following advantages:
- Support for motion trigger/interrupt
- Fix incorrect scale values (BMA254 currently uses the same as
BMA250 but actually they're different because of 10 vs 12 bits
data size)
- Less code than before :)
BMA250 could be potentially also moved but it's more complicated
because its chip_id conflicts with the one for BMA222 in bmc150-accel.
Perhaps there are also other register differences, I did not investigate
further yet (and I have no way to test it).
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210611080903.14384-11-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
BMA253 is mostly like BMA255 and has exactly the same register layout
as used by the bmc150-accel driver as far I can tell. Making it work
is as simple as adding new device IDs for it since it has the same
chip_id = 0xFA (250) as BMA255 and others.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210611080903.14384-8-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Right now all the device IDs are listed in seemingly random order,
make this consistent by ordering those alphabetically. Also, order
bmc150_accel_chip_info_tbl by chip ID for the same reason.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210611080903.14384-6-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The chips supported by the bmc150-accel driver are clearly documented
in Kconfig, in the bmc150_accel_chip_info_tbl as well as in all the
device ID tables in the I2C/SPI drivers. It's easy to forget to update
the lists in the file header. Drop those entirely to reduce the amount
of changes required to add new chip variants.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210611080903.14384-5-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Commit 0ad4bf3701 ("iio:accel:bmc150-accel: Use the chip ID to detect
sensor variant") stopped using the I2C/ACPI match data to look up the
bmc150_accel_chip_info. However, the bmc150_accel_chip_info_tbl remained
as-is, with multiple entries with the same chip_id (e.g. 0xFA for
BMC150/BMI055/BMA255). This is redundant now because actually the driver
will always select the first entry with a matching chip_id.
So even if a device probes e.g. with BMA0255 it will end up using the
chip_info for BMC150. And in general that's fine for now, the entries
for BMC150/BMI055/BMA255 were exactly the same anyway (except for the
name, which is replaced with the more accurate one later).
But in this case it's misleading because it suggests that one should
add even more entries with the same chip_id when adding support for
new variants. Let's make that more clear by removing the enum with
the chip identifiers entirely and instead have only one entry per
chip_id.
Note that we may need to bring back some mechanism to differentiate
between different chips with the same chip_id in the future.
For example, BMA250 (currently supported by the bma180 driver) has the
same chip_id = 0x03 as BMA222 even though they have different channel
sizes (8 bits vs 10 bits). But in any case, that mechanism would
need to look quite different from what we have right now.
Cc: Bastien Nocera <hadess@hadess.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210611080903.14384-4-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
According to sysfs-bus-iio documentation the unit for accelerometer
values after applying scale/offset should be m/s^2, not g, which explains
why the scale values for the other variants in bmc150-accel do not match
exactly the values given in the datasheet.
To get the correct values, we need to multiply the BMA222 scale values
by g = 9.80665 m/s^2.
Fixes: a1a210bf29 ("iio: accel: bmc150-accel: Add support for BMA222")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210611080903.14384-2-stephan@gerhold.net
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some Yoga laptops with 1 accelerometer in the display and 1 in the base,
use an ACPI HID of DUAL250E instead of BOSC0200.
Set the iio-device's label for DUAL250E devices to a value indicating which
sensor is which, mirroring how we do this for BOSC0200 dual sensor devices.
Note the DUAL250E fwnode unfortunately does not include a mount-matrix.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210523170103.176958-10-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Factor the BOSC0200 ACPI HID handling out into a new
bmc150_apply_bosc0200_acpi_orientation() function and make
bmc150_apply_acpi_orientation() call that when dealing with
a BOSC0200 ACPI device (and make it return false otherwise).
This is a preparation patch for adding special handling for other
ACPI HIDs (the "DUAL250E" HID).
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210523170103.176958-9-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some 360 degree hinges (yoga) style 2-in-1 devices use 2 bmc150 accels
to allow the OS to determine the angle between the display and the base
of the device, so that the OS can determine if the 2-in-1 is in laptop
or in tablet-mode.
On Windows both accelerometers are read (polled) by a special service
and this service calls the DSM (Device Specific Method), which in turn
translates the angles to one of laptop/tablet/tent/stand mode and then
notifies the EC about the new mode and the EC then enables or disables
the builtin keyboard and touchpad based in the mode.
When the 2-in-1 is powered-on or resumed folded in tablet mode the
EC senses this independent of the DSM by using a HALL effect sensor
which senses that the keyboard has been folded away behind the display.
At power-on or resume the EC disables the keyboard based on this and
the only way to get the keyboard to work after this is to call the
DSM to re-enable it.
Call the DSM on probe() and resume() to fix the keyboard not working
when powered-on / resumed in tablet-mode.
This patch was developed and tested on a Lenovo Yoga 300-IBR.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210523170103.176958-8-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Now that the definition of the bmc150_accel_data struct is no longer
private to bmc150-accel-core.c, bmc150-accel-i2c.c can simply directly
access the second_dev member and the accessor functions are no longer
necessary.
Note if the i2c_acpi_new_device() for the second-client now fails,
an ERR_PTR gets stored in data->second_dev this is fine since it is only
ever passed to i2c_unregister_device() which has an IS_ERR_OR_NULL() check.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210523170103.176958-7-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Further patches to bmc150-accel-i2c.c need to store some extra info
(on top of the second_dev pointer) in the bmc150_accel_data struct,
rather then adding yet more accessor functions for this lets just
move the struct bmc150_accel_data definition to bmc150-accel.h.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210523170103.176958-6-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
On machines with dual accelerometers described in a single ACPI fwnode,
the bmc150_accel_probe() instantiates a second i2c-client for the second
accelerometer.
A pointer to this manually instantiated second i2c-client is stored
inside the iio_dev's private-data through bmc150_set_second_device(),
so that the i2c-client can be unregistered from bmc150_accel_remove().
Before this commit bmc150_set_second_device() took only 1 argument so it
would store the pointer in private-data of the iio_dev belonging to the
manually instantiated i2c-client, leading to the bmc150_accel_remove()
call for the second_dev trying to unregister *itself* while it was
being removed, leading to a deadlock and rmmod hanging.
Change bmc150_set_second_device() to take 2 arguments: 1. The i2c-client
which is instantiating the second i2c-client for the 2nd accelerometer and
2. The second-device pointer itself (which also is an i2c-client).
This will store the second_device pointer in the private data of the
iio_dev belonging to the (ACPI instantiated) i2c-client for the first
accelerometer and will make bmc150_accel_remove() unregister the
second_device i2c-client when called for the first client,
avoiding the deadlock.
Fixes: 5bfb3a4bd8 ("iio: accel: bmc150: Check for a second ACPI device for BOSC0200")
Cc: Jeremy Cline <jeremy@jcline.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The drvdata for iio-parent devices points to the struct iio_dev for
the iio-device. So by directly casting the return from i2c_get_clientdata()
to struct bmc150_accel_data * the code was ending up storing the second_dev
pointer in (and retrieving it from) some semi-random offset inside
struct iio_dev, rather then storing it in the second_dev member of the
bmc150_accel_data struct.
Fix the code to get the struct bmc150_accel_data * pointer to call
iio_priv() on the struct iio_dev * returned by i2c_get_clientdata(),
so that the correct pointer gets dereferenced.
This fixes the following oops on rmmod, caused by trying to
dereference the wrong return of bmc150_get_second_device():
[ 238.980737] BUG: unable to handle page fault for address: 0000000000004710
[ 238.980755] #PF: supervisor read access in kernel mode
[ 238.980760] #PF: error_code(0x0000) - not-present page
...
[ 238.980841] i2c_unregister_device.part.0+0x19/0x60
[ 238.980856] 0xffffffffc0815016
[ 238.980863] i2c_device_remove+0x25/0xb0
[ 238.980869] __device_release_driver+0x180/0x240
[ 238.980876] driver_detach+0xd4/0x120
[ 238.980882] bus_remove_driver+0x5b/0xd0
[ 238.980888] i2c_del_driver+0x44/0x70
While at it also remove the now no longer sensible checks for data
being NULL, iio_priv never returns NULL for an iio_dev with non 0
sized private-data.
Fixes: 5bfb3a4bd8 ("iio: accel: bmc150: Check for a second ACPI device for BOSC0200")
Cc: Jeremy Cline <jeremy@jcline.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
All of the users of iio_read_mount_matrix() are using the very same
property name. Moreover, the property name is hard coded in the API
documentation.
Make this clear and avoid duplication now and in the future.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210518112546.44592-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
A call to pm_runtime_put_noidle() doesn't match any call that would
result in a get(). It is safe because runtime pm core protects against
the reference counter going 0, but it makes it harder to understand the
code.
Whilst here use pm_runtime_resume_and_get() to tidy things up.
The Coccinelle script didn't get this one due to more complex code
structure.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/20210509113354.660190-5-jic23@kernel.org
Continuing from Alexandru Ardelean's introduction of the split between
driver modifiable fields and those that should only be set by the core.
This could have been done in two steps to make the actual move after
introducing iio_device_id() but there seemed limited point to that
given how mechanical the majority of the patch is.
Includes fixup from Alex for missing mxs-lradc-adc conversion.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426174911.397061-2-jic23@kernel.org
Use cocci semantic patch:
@@
expression trigger, P;
@@
trigger = devm_iio_trigger_alloc(P, ...);
...
- trigger->dev.parent = P;
To remove trigger->dev.parent, since it is set by default.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210309193620.2176163-3-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some 2-in-1 laptops / convertibles with 360° (yoga-style) hinges,
use 2 bmc150 accelerometers, defined by a single BOSC0200 ACPI
device node (1 in their base and 1 in their display).
Since in this case we know the location of each accelerometer,
set the label for the accelerometers to the standardized
"accel-display" resp. "accel-base" labels. This way userspace
can use the labels to get the location.
This was tested on a Lenovo ThinkPad Yoga 11e 4th gen (N3450 CPU).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210207160901.110643-3-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
bmc150 accelerometers with an ACPI hardware-id of BOSC0200 have an ACPI
method providing their mount-matrix, add support for retrieving this.
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-3-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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=198671
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20201130141954.339805-1-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-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
These Bosch accelerometers have two supplies, VDD and VDDIO.
Add some rudimentary support to obtain and enable these
regulators during probe() and disable them during remove()
or on the errorpath.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201115205745.618455-3-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This adds support for the BMA222 version of this sensor,
found in for example the Samsung GT-I9070 mobile phone.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201115205745.618455-2-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change switches to the new iio_triggered_buffer_setup_ext()
function and removes the iio_buffer_set_attrs() call, for assigning the
HW FIFO attributes to the buffer.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-6-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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 a 16 byte 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
ensured by use of an explicit c structure. This data is allocated
with kzalloc so no data can leak appart from previous readings.
Fixes tag is beyond some major refactoring so likely manual backporting
would be needed to get that far back.
Whilst the force alignment of the ts is not strictly necessary, it
does make the code less fragile.
Fixes: 3bbec97733 ("iio: bmc150_accel: add support for hardware fifo")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
All devices using a triggered buffer need to attach and detach the trigger
to the device in order to properly work. Instead of doing this in each and
every driver by hand move this into the core.
At this point in time, all drivers should have been resolved to
attach/detach the poll-function in the same order.
This patch removes all explicit calls of iio_triggered_buffer_postenable()
& iio_triggered_buffer_predisable() in all drivers, since the core handles
now the pollfunc attach/detach.
The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's
not immediately obvious that removing the hooks doesn't break anything.
Eugen was able to test on at91-sama5d2-adc driver, sama5d2-xplained board.
All seems to be fine.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Tested-by: Eugen Hristev <eugen.hristev@microchip.com> #for at91-sama5d2-adc
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This patch applies the semantic patch:
@@
expression I, P, SP;
@@
I = devm_iio_device_alloc(P, SP);
...
- I->dev.parent = P;
It updates 302 files and does 307 deletions.
This semantic patch also removes some comments like
'/* Establish that the iio_dev is a child of the i2c device */'
But this is is only done in case where the block is left empty.
The patch does not seem to cover all cases. It looks like in some cases a
different variable is used in some cases to assign the parent, but it
points to the same reference.
In other cases, the block covered by ... may be just too big to be covered
by the semantic patch.
However, this looks pretty good as well, as it does cover a big bulk of the
drivers that should remove the parent assignment.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The center temperature of the supported devices stored in the constant
BMC150_ACCEL_TEMP_CENTER_VAL is not 24 degrees but 23 degrees.
It seems that some datasheets were inconsistent on this value leading
to the error. For most usecases will only make minor difference so
not queued for stable.
Signed-off-by: Pascal Bouwmann <bouwmann@tau-tec.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms and conditions of the gnu general public license
version 2 as published by the free software foundation this program
is distributed in the hope it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 263 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141901.208660670@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It fixes the following checkpatch.pl warning:
WARNING: Prefer using '"%s...", __func__' to using function's name, in a
string
Signed-off-by: Mohan Kumar <mohankumar718@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This patch allows to read a mount-matrix device tree
property and report to user-space or in-kernel iio
clients.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The regmap core now handles splitting up transactions according to
max_raw_read, so this code is no longer required in client drivers.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Dynamic debug has a run time knob to enable function name printing.
Remove this from dev_dbg() calls.
Furthermore, functional tracing when enabled can show what function is
called, therefore remove empty dev_dbg() calls.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
After probe we would put the device in normal mode, after a runtime
suspend-resume we would put it back in normal mode. But for a regular
suspend-resume we would only put it back in normal mode if triggers
or events have been requested. This is not consistent and breaks
reading raw values after a suspend-resume.
This commit changes the regular resume path to also unconditionally put
the device back in normal mode, fixing reading of raw values not working
after a regular suspend-resume cycle.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This is a necessary step in taking the buffer implementation
opaque.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
In at least one known setup, the chip comes up in a state where reading
the chip ID returns garbage unless it's been reset, due to noise on the
wires during system boot.
All supported chips have the same reset method, and based on the
datasheets they all need 1.3 or 1.8ms to recover after reset. So, do
the conservative thing here and always reset the chip.
Signed-off-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Adds a new per-device sysfs attribute "current_timestamp_clock" to allow
userspace to select a particular POSIX clock for buffered samples and
events timestamping.
Following clocks, as listed in clock_gettime(2), are supported:
CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW,
CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and
CLOCK_TAI.
Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
Acked-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Bit of a bumper set for new drivers but plenty of other stuff here as well!
New device support
* ad5592R ADC/DAC
- new driver supporting ad5592r and ad5593r combined ADC/DAC and gpio chips.
* Aosong am2315 relative humidity
- new driver with triggered buffer support in follow up patch.
* bmi160 imu
- new driver
* bmp280
- bmp180 support - note there is support in the misc/bmp085 driver. Intent
is to remove that driver long term.
* invensense mpu6050
- cleanup leading to explicit support of mpu9150 with a good few cleanups
along the way.
* Hope RF hp03 pressure and temperature sensor.
- new driver
* maxim DS1803 potentiometer
- new driver
* maxim max44000 light and proximity sensor
- new driver built in a series of steps to support pretty much everything.
* ROHM BH1780 light sensor
- new driver. There is an existing driver in misc that this is pretty much
intended to replace. The discussion on whether to support the non standard
interface of that driver is some way is continuing.
* st-gyro
- lsm9ds0-gyro. The accel/magn side of this will take a while longer as
extensions to the st library are needed for cases where two types of sensor
share a single i2c address.
* ti-adc081c
- support the adc101c and adc121c
* Vishay VEML6070 UV sensor
- new driver.
New features
* core
- devm_ APIs for channel_get and channel_get_all. The first user of these
is the generic ADC based thermal driver. As it is going through the
thermal tree these will be picked up as a patch to that next cycle as that
is how the author preferred to do it.
- mounting matrix support. This new core support allows devices to provide
to userspace (typically from the device tree) allowing compensation for how
the sensor is mounted on the device. First examples are on UAVs but it
has a more mundane use on typical phone where the chip may be on the front
or the back of the circuit board and soldered at any angle. Includes
support for this ABI in ak8975 (which has an older interface, now
deprecated) and mpu6050.
* tools
- add a -a option to enable all available channels in generic_buffer sample.
Makes it somewhat easier to use.
* adis library and drivers
- support manual self test flag clearing. This has technically been broken
for a very long time - result is an offset on readings as the applied field
is on all the time.
* ak8975
- triggered buffer support
* bmc150
- spi support (including splitting the driver into core and i2c parts)
* bmp280
- oversampling support.
* dht11
- improved logging - useful to debug timing issues on this quirky device.
* st-sensors
- read each channel invidivually as not all support the optimization of
reading in bulk. This is technically a fix, but will need to be backported
if desired.
- support open drain and shared interrupts.
* ti-adc081c
- triggered buffer support.
Cleanups
* inkern
- white space fix.
* ad7606
- use the iio_device_claim_direct_mode call rather than open coding equiv.
* ad799x
- white space fix.
* ad9523
- unsigned -> unsigned int
* apds9660
- brace location tidying up.
- silence an uninitialized variable warning.
* ak8975
- else and brace on same line fix.
* at91_adc
- white space fixes.
* bmc150
- use regmap stored copy of the device pointer rather than having an
additional copy.
* bmg160
- use regmap stored copy of the device pointer rather than having an
additional copy.
* hid-sensors
- white space fixes.
* mcp3422
- white space fix.
* mma7455
- use regmap to retrieve the device struct rather than carrying another copy
in the private data.
* ms_sensors
- white space fix.
* mxs-lradc
- move current bindings out of staging - some will be shortly deprecated but
the reality is that we have device trees out there using them so they will
need to be supported for some time. They accidentally got left behind
when the driver graduated from staging.
- white space cleanup.
- set INPUT_PROP_DIRECT.
- move ts config into a better function.
- move the STMP reset out of the ADC init.
* vf610_adc
- case label indenting fix.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXHnw8AAoJEFSFNJnE9BaIDsIP/jbvOSDgOyvh4iNqV3ppAfvL
yw/CWfKB5oMiqq/ENBNyMcD7kpGoh6ad/2JV1eXRnZsKArTwX6iN0Nu3yPxa+ySn
xYc/BoGFwnNei+FqnFEqvK9RFZ3okQEkTW+OJg6eDMGDdL9HojZnALX4BE66QF3E
W699vd3nA9SXqQ1UkQ+ozWdybBh2ksOfXknyN/S0sioIeG4MopCIyLMZzBGcDOCN
EjdBudZla8VGTWcrp1ofOap6gJ7wKpbtlTPXuAEXtAypnDvuRdH7loTxtzSovNYd
u6r9bujc1KUE4ilkYqODd5de4HvKm7aCR2ojlXeKlj+BNaF/uxQoYV/Al5e9CwR8
nnz7c0rVAWIGc2tCiejJOMXB0t4TjVdzXZG9G/maKk1PNFOdUPb9Ul9BsjM28q5s
yUneBuKlGFj2K/+E1AmTDRMhStMCMgrXZgyh0GSI07UZsVRnJR7ikUw7tly+J4ki
21qKvTgXMKU+Fzh1HeqVcocq2AHsjlnKWuaB4/YiQzG5V0oGM4rvt78ewSMkmVkR
IcIF9yI5XUfDAFdQUtvRlLP6p+qHylMH72aYq8pkMZ43Dq6hukyfx4vkc0Ztw7yS
A655/frXiGeU2MFVSM2PYVloLQ5sftL5jDSBiDunzXHAl2WoXppu5Rjc7QvLnzLr
vxvvN7MyGvi1GnKxcnYw
=zzV9
-----END PGP SIGNATURE-----
Merge tag 'iio-for-4.7b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-testing
Jonathan writes:
2nd set of new device support, features and cleanup for IIO in the 4.7 cycle.
Bit of a bumper set for new drivers but plenty of other stuff here as well!
New device support
* ad5592R ADC/DAC
- new driver supporting ad5592r and ad5593r combined ADC/DAC and gpio chips.
* Aosong am2315 relative humidity
- new driver with triggered buffer support in follow up patch.
* bmi160 imu
- new driver
* bmp280
- bmp180 support - note there is support in the misc/bmp085 driver. Intent
is to remove that driver long term.
* invensense mpu6050
- cleanup leading to explicit support of mpu9150 with a good few cleanups
along the way.
* Hope RF hp03 pressure and temperature sensor.
- new driver
* maxim DS1803 potentiometer
- new driver
* maxim max44000 light and proximity sensor
- new driver built in a series of steps to support pretty much everything.
* ROHM BH1780 light sensor
- new driver. There is an existing driver in misc that this is pretty much
intended to replace. The discussion on whether to support the non standard
interface of that driver is some way is continuing.
* st-gyro
- lsm9ds0-gyro. The accel/magn side of this will take a while longer as
extensions to the st library are needed for cases where two types of sensor
share a single i2c address.
* ti-adc081c
- support the adc101c and adc121c
* Vishay VEML6070 UV sensor
- new driver.
New features
* core
- devm_ APIs for channel_get and channel_get_all. The first user of these
is the generic ADC based thermal driver. As it is going through the
thermal tree these will be picked up as a patch to that next cycle as that
is how the author preferred to do it.
- mounting matrix support. This new core support allows devices to provide
to userspace (typically from the device tree) allowing compensation for how
the sensor is mounted on the device. First examples are on UAVs but it
has a more mundane use on typical phone where the chip may be on the front
or the back of the circuit board and soldered at any angle. Includes
support for this ABI in ak8975 (which has an older interface, now
deprecated) and mpu6050.
* tools
- add a -a option to enable all available channels in generic_buffer sample.
Makes it somewhat easier to use.
* adis library and drivers
- support manual self test flag clearing. This has technically been broken
for a very long time - result is an offset on readings as the applied field
is on all the time.
* ak8975
- triggered buffer support
* bmc150
- spi support (including splitting the driver into core and i2c parts)
* bmp280
- oversampling support.
* dht11
- improved logging - useful to debug timing issues on this quirky device.
* st-sensors
- read each channel invidivually as not all support the optimization of
reading in bulk. This is technically a fix, but will need to be backported
if desired.
- support open drain and shared interrupts.
* ti-adc081c
- triggered buffer support.
Cleanups
* inkern
- white space fix.
* ad7606
- use the iio_device_claim_direct_mode call rather than open coding equiv.
* ad799x
- white space fix.
* ad9523
- unsigned -> unsigned int
* apds9660
- brace location tidying up.
- silence an uninitialized variable warning.
* ak8975
- else and brace on same line fix.
* at91_adc
- white space fixes.
* bmc150
- use regmap stored copy of the device pointer rather than having an
additional copy.
* bmg160
- use regmap stored copy of the device pointer rather than having an
additional copy.
* hid-sensors
- white space fixes.
* mcp3422
- white space fix.
* mma7455
- use regmap to retrieve the device struct rather than carrying another copy
in the private data.
* ms_sensors
- white space fix.
* mxs-lradc
- move current bindings out of staging - some will be shortly deprecated but
the reality is that we have device trees out there using them so they will
need to be supported for some time. They accidentally got left behind
when the driver graduated from staging.
- white space cleanup.
- set INPUT_PROP_DIRECT.
- move ts config into a better function.
- move the STMP reset out of the ADC init.
* vf610_adc
- case label indenting fix.
Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.
Patch created using Coccinelle plus manual edits.
Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Reviewed-by: Irina Tirdea <irina.tirdea@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This resolves a lot of merge issues with PAGE_CACHE_* changes, and an
iio driver merge issue.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bmc150_i2c_regmap_conf is defined three times (in bmc150-accel-core.c,
bmc150-accel-i2c.c and and bmc150-accel-spi.c), although the
definition is the same.
Use one common definition for bmc150_i2c_regmap_conf in all
included files.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
For big endian platforms, reading the axes will return
invalid values.
The device stores each axis value in a 16 bit little
endian register. The driver uses regmap_read_bulk to get
the axis value, resulting in a 16 bit little endian value.
This needs to be converted to cpu endianness to work
on big endian platforms.
Fix endianness for big endian platforms by converting
the values for the axes read from little endian to
cpu.
This is also partially fixed in commit b6fb9b6d6552 ("iio:
accel: bmc150: optimize transfers in trigger handler").
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
GPIO handling code has been removed from the drivers (since
this is now handled by the ACPI core) in commit 0f0796509c ("iio:
remove gpio interrupt probing from drivers that use a single interrupt").
Remove the include for linux/gpio/consumer.h since it is no longer
used.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Miquel Raynal
Miaoqian Lin
Stephan Gerhold
Hans de Goede
Andy Shevchenko
Jonathan Cameron
Gwendal Grignou
Jeremy Cline
Linus Walleij
Alexandru Ardelean
Lars-Peter Clausen
Pascal Bouwmann
Thomas Gleixner
Mohan Kumar
H. Nikolaus Schaller
Charles Keepax
Jonathan Cameron
Olof Johansson
Gregor Boirie
Greg Kroah-Hartman
Alison Schofield
Irina Tirdea