Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.
Add mod_devicetable.h include.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220531213922.72992-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use the ->probe_new() callback.
The driver does not use const struct i2c_device_id * argument,
so convert it to utilise the simplified I²C driver registration.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220531213922.72992-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.
Add mod_devicetable.h include.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220531142353.64925-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is nothing directly using of specific interfaces in this driver,
so lets not include the headers.
While at it, drop dependency to OF, which currently makes no sense.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220531212218.72189-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Nothing in this driver depends on OF so drop the dependency
to remove the false impression such a dependency exists.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220530181313.2789-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Nothing in this driver depends on OF so drop the dependency
to remove the false impression such a dependency exists.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220530181706.3045-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add supports for BMI090L, it's a high-performance Inertial
Measurement Unit, with an accelerometer and gyroscope.
The commit adds the accelerometer driver for the SPI interface.
The gyroscope part is already supported by the BMG160 driver.
Same as BMI088, BMI090L have the range of +/-3, 6, 12, and 24g.
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
Link: https://lore.kernel.org/r/20220526133359.2261928-6-Qing-wu.Li@leica-geosystems.com.cn
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add supports for BMI085, an Inertial Measurement Unit,
with an accelerometer and gyroscope.
The commit adds the accelerometer driver for the SPI interface.
The gyroscope part is already supported by the BMG160 driver.
Unlike BMI088, the BMI085 accelerometer ranges are +/-2, 4, 6,
and 8g, the scales are calculated as 9.8/32768*pow(2,reg41+1).
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
Link: https://lore.kernel.org/r/20220526133359.2261928-5-Qing-wu.Li@leica-geosystems.com.cn
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: accel: bmi088: modified the device name
It is possible to have multiple sensors connected on the same platform.
For support of different sensors, making it possible to obtain the
device name by reading the chip id. If the device was found in the
table but the device tree binding is different, the driver will carry
on with a warning. If no matching device was found, the driver load
the binding chip info.
Tested case, test with bmi085 and bmi090 patches applied:
connect 3 bmi090l to the system, and set device tree compatible:
spi2.0: compatible = "bosch,bmi090l-accel";
spi2.2: compatible = "bosch,bmi088-accel";
spi2.4: compatible = "bosch,bmi085-accel";
Get a warning for the mismatched devices:
bmi088_accel_spi spi2.2: unexpected chip id 0x1A
bmi088_accel_spi spi2.4: unexpected chip id 0x1A
Get the real present device name:
/sys/bus/iio/devices/iio:device1/name:bmi090l-accel
/sys/bus/iio/devices/iio:device3/name:bmi090l-accel
/sys/bus/iio/devices/iio:device5/name:bmi090l-accel
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
Link: https://lore.kernel.org/r/20220526133359.2261928-4-Qing-wu.Li@leica-geosystems.com.cn
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The sensor can set the scales by writing the range register 0x41,
The current driver has no interface to configure it.
The commit adds the interface for config the scales.
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
Link: https://lore.kernel.org/r/20220526133359.2261928-3-Qing-wu.Li@leica-geosystems.com.cn
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The units after application of scale are 100*m/s^2,
The scale calculation is only for the device
with the range of 3, 6, 12, and 24g,
but some other chips have a range of 2, 4, 6, and 8g.
Modified the scales from formula to a list, the scales in the list are
calculated as 9.8/32768*pow(2,reg41+1)*1.5, refer to datasheet 5.3.4.
The new units after the application of scale are m/s^2.
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
Link: https://lore.kernel.org/r/20220526133359.2261928-2-Qing-wu.Li@leica-geosystems.com.cn
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
On some boards interrupt type might be different than falling edge,
like hardcoded in driver. Leave interrupt flags as they were pre-configured
from the device-tree. If they're not provided, default to falling edge
interrupts.
Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
Link: https://lore.kernel.org/r/20220523175344.5845-3-markuss.broks@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the optional properties for the VL53L0X ToF sensor to the
device-tree binding.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
Link: https://lore.kernel.org/r/20220523175344.5845-2-markuss.broks@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
(!val) has been checked outside the loop, remove redundant (val &&)
from loop.
Signed-off-by: Li Zhengyu <lizhengyu3@huawei.com>
Acked-by: Andreas Klinger <ak@it-klinger.de>
Link: https://lore.kernel.org/r/20220523122755.90638-1-lizhengyu3@huawei.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
It works much the same as ti,dac7571, so it fits in the "family" even
if the name is a little bit different.
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/a230b7a8-4146-9483-48ee-0bebdd945731@axentia.se
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Currently, the driver updates the FIFO watermark inside both
update_scan_mode() and hwfifo_set_watermark(). Inside the IIO core,
hwfifo_set_watermark() is called immediately after update_scan_mode(),
making the first call to set_fifo_samples() redundant.
Remove the first call to set_fifo_samples(), and merge the
set_fifo_samples() function into the set_fifo_watermark()
function. Also, since fifo_set_size is always set inside of
update_scan_mode(), and it cannot be set to 0, remove the
zero check from set_fifo_samples().
Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20220514182010.152784-1-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
bmc150_magn_remove() always returns zero. Make it return no value which
makes it easier to see in the callers that there is no error to handle.
Also the return value of i2c driver remove callbacks is ignored anyway.
This prepares making i2c remove callbacks return void, too.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220514133250.307955-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-9-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-8-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-7-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-5-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-4-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't
make a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more
helpful message if a problem occurs and return 0 to suppress the generic
message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220515155929.338656-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Remove unnecessary channel check from rzg2l_adc_read_label(), as the
channel error handling is already done in probe(). Therefore no need to
validate at runtime.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20220515060337.16513-3-biju.das.jz@bp.renesas.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Document Renesas RZ/G2UL ADC bindings. RZ/G2UL ADC is almost identical
to RZ/G2L, but it has 2 analog input channels compared to 8 channels
on the RZ/G2L.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220515060337.16513-2-biju.das.jz@bp.renesas.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This driver doesn't need to access I/O ports directly via inb()/outb()
and friends. This patch abstracts such access by calling ioport_map()
to enable the use of more typical ioread8()/iowrite8() I/O memory
accessor calls.
Suggested-by: David Laight <David.Laight@ACULAB.COM>
Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/c973ce9a326131552caf762381edf8e90be43cc5.1652201921.git.william.gray@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This driver doesn't need to access I/O ports directly via inb()/outb()
and friends. This patch abstracts such access by calling ioport_map()
to enable the use of more typical ioread8()/iowrite8() I/O memory
accessor calls.
Suggested-by: David Laight <David.Laight@ACULAB.COM>
Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/64673797df382c52fc32fce24348b25a0b05e73a.1652201921.git.william.gray@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Returning an error value in an i2c remove callback results in an error
message being emitted by the i2c core, but otherwise it doesn't make a
difference.
As afe4404_remove() already emits an error message on failure and the
additional error message by the i2c core doesn't add any useful
information, change the return value to zero to suppress this message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220514130432.304674-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
When sensor location is known, populate iio sysfs "label" attribute:
* "accel-base" : the sensor is in the base of the convertible (2-1)
device.
* "accel-display" : the sensor is in the lid/display plane of the
device.
* "accel-camera" : the sensor is in the swivel camera subassembly.
The non-standard |location| attribute is removed, the field |loc| in
cros_ec_sensors_core_state is removed.
It apply to standalone accelerometer as well as IMU (accelerometer +
gyroscope) and sensors where the location is known (light).
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20220427190804.961697-3-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add "accel-camera" when an IMU is location near the camera in a swivel
sub-assembly. These IMU are used for AR applications.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20220427190804.961697-2-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for activity and inactivity events for all axis based on the
threshold, duration and hysteresis value set from the userspace. INT1 pin
is used to interrupt and event is pushed to userspace.
Signed-off-by: Jagath Jog J <jagathjog1996@gmail.com>
Link: https://lore.kernel.org/r/20220505133021.22362-9-jagathjog1996@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for activity recognition like STILL, WALKING, RUNNING
and these events are pushed to the userspace whenever the STEP
interrupt occurs.
Signed-off-by: Jagath Jog J <jagathjog1996@gmail.com>
Link: https://lore.kernel.org/r/20220505133021.22362-8-jagathjog1996@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Added support for event when there is a detection of step change.
INT1 pin is used to interrupt and event is pushed to userspace.
Signed-off-by: Jagath Jog J <jagathjog1996@gmail.com>
Link: https://lore.kernel.org/r/20220505133021.22362-7-jagathjog1996@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>