Move some register definitions to the per-device array of struct
st_lsm6dsx_sensor_settings in order to simplify adding new sensor
devices to the driver.
Also, remove completely unused register definitions.
Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Before moving greybus core out of staging and moving header files to
include/linux some greybus header files were missing the necessary
includes. This would trigger compilation faillures with some example
errors logged bellow for with CONFIG_KERNEL_HEADER_TEST=y.
So, add the necessary headers to compile clean before relocating the
header files.
./include/linux/greybus/hd.h:23:50: error: unknown type name 'u16'
int (*cport_disable)(struct gb_host_device *hd, u16 cport_id); ^~~
./include/linux/greybus/greybus_protocols.h:1314:2: error: unknown type name '__u8'
__u8 data[0];
^~~~
./include/linux/greybus/hd.h:24:52: error: unknown type name 'u16'
int (*cport_connected)(struct gb_host_device *hd, u16 cport_id); ^~~
./include/linux/greybus/hd.h:25:48: error: unknown type name 'u16'
int (*cport_flush)(struct gb_host_device *hd, u16 cport_id); ^~~
./include/linux/greybus/hd.h:26:51: error: unknown type name 'u16'
int (*cport_shutdown)(struct gb_host_device *hd, u16 cport_id, ^~~
./include/linux/greybus/hd.h:27:5: error: unknown type name 'u8'
u8 phase, unsigned int timeout);
^~
./include/linux/greybus/hd.h:28:50: error: unknown type name 'u16'
int (*cport_quiesce)(struct gb_host_device *hd, u16 cport_id, ^~~
./include/linux/greybus/hd.h:29:5: error: unknown type name 'size_t'
size_t peer_space, unsigned int timeout);
^~~~~~
./include/linux/greybus/hd.h:29:5: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
./include/linux/greybus/hd.h:1:1:
+#include <stddef.h>
/* SPDX-License-Identifier: GPL-2.0 */
./include/linux/greybus/hd.h:29:5:
size_t peer_space, unsigned int timeout);
^~~~~~
./include/linux/greybus/hd.h:30:48: error: unknown type name 'u16'
int (*cport_clear)(struct gb_host_device *hd, u16 cport_id); ^~~
./include/linux/greybus/hd.h:32:49: error: unknown type name 'u16'
int (*message_send)(struct gb_host_device *hd, u16 dest_cport_id, ^~~
./include/linux/greybus/hd.h:33:32: error: unknown type name 'gfp_t'
struct gb_message *message, gfp_t gfp_mask); ^~~~~
./include/linux/greybus/hd.h:35:55: error: unknown type name 'u16'
int (*latency_tag_enable)(struct gb_host_device *hd, u16 cport_id);
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Gao Xiang <hsiangkao@aol.com>
Signed-off-by: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Link: https://lore.kernel.org/r/20190827155302.25704-1-rui.silva@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As Stephon reported [1], many compile warnings are raised when
moving out include/trace/events/erofs.h:
In file included from include/trace/events/erofs.h:8,
from <command-line>:
include/trace/events/erofs.h:28:37: warning: 'struct dentry' declared inside parameter list will not be visible outside of this definition or declaration
TP_PROTO(struct inode *dir, struct dentry *dentry, unsigned int flags),
^~~~~~
include/linux/tracepoint.h:233:34: note: in definition of macro '__DECLARE_TRACE'
static inline void trace_##name(proto) \
^~~~~
include/linux/tracepoint.h:396:24: note: in expansion of macro 'PARAMS'
__DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
^~~~~~
include/linux/tracepoint.h:532:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^~~~~~~~~~~~~
include/linux/tracepoint.h:532:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^~~~~~
include/trace/events/erofs.h:26:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(erofs_lookup,
^~~~~~~~~~~
include/trace/events/erofs.h:28:2: note: in expansion of macro 'TP_PROTO'
TP_PROTO(struct inode *dir, struct dentry *dentry, unsigned int flags),
^~~~~~~~
That makes me very confused since most original EROFS tracepoint code
was taken from f2fs, and finally I found
commit 43c78d8803 ("kbuild: compile-test kernel headers to ensure they are self-contained")
It seems these warnings are generated from KERNEL_HEADER_TEST feature and
ext4/f2fs tracepoint files were in blacklist.
Anyway, let's fix these issues for KERNEL_HEADER_TEST feature instead
of adding to blacklist...
[1] https://lore.kernel.org/lkml/20190826162432.11100665@canb.auug.org.au/
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Link: https://lore.kernel.org/r/20190826132653.100731-1-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Introduce update_fifo routine pointer in st_lsm6dsx_fifo_ops data
structure since we will need a different update FIFO configuration
callback adding support for lsm6ds0/lsm9ds1 imu device
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Tested-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Rename the bindings documentation file for Renesas ISL29501 Time-of-flight
sensor from isl29501.txt to renesas,isl29501.txt.
This is part of an ongoing effort to name bindings documentation files for
Renesas IP blocks consistently, in line with the compat strings they
document.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
IIO_ST_SENSORS_CORE select IIO_ST_SENSORS_I2C
unconditionally, if REGMAP_I2C is not set, build fails
drivers/iio/common/st_sensors/st_sensors_i2c.o: In function `st_sensors_i2c_configure':
st_sensors_i2c.c:(.text+0x58): undefined reference to `__devm_regmap_init_i2c'
This patch selects REGMAP_I2C to fix it.
IIO_ST_SENSORS_SPI is similar to SPI issue.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 062809ef77 ("iio: make st_sensors drivers use regmap")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The AD7606B is a 16-bit ADC that supports simultaneous sampling of 8
channels. It is pin compatible to AD7606, but adds extra modes by
writing to the register map.
The AD7606B can be configured to work in software mode by setting all
oversampling pins to high. This mode is selected by default.
The oversampling ratio is configured from the OS_MODE register (address
0x08) with the addition of OS=128 and OS=256 that were not available in
hardware mode.
The device is configured to output data on a single spi channel, but this
configuration must be done right after restart. That is why the delay was
removed for devices which doesn't require it.
Moreover, in software mode, the range gpio has no longer its function.
Instead, the scale can be configured individually for each channel from
the RANGE_CH registers (address 0x03 to 0x06). Besides the already
supported ±10 V and ±5 V ranges, software mode can also accommodate the
±2.5 V range.
Signed-off-by: Stefan Popa <stefan.popa@analog.com>
Co-developed-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
EROFS filesystem has been merged into linux-staging for a year.
EROFS is designed to be a better solution of saving extra storage
space with guaranteed end-to-end performance for read-only files
with the help of reduced metadata, fixed-sized output compression
and decompression inplace technologies.
In the past year, EROFS was greatly improved by many people as
a staging driver, self-tested, betaed by a large number of our
internal users, successfully applied to almost all in-service
HUAWEI smartphones as the part of EMUI 9.1 and proven to be stable
enough to be moved out of staging.
EROFS is a self-contained filesystem driver. Although there are
still some TODOs to be more generic, we have a dedicated team
actively keeping on working on EROFS in order to make it better
with the evolution of Linux kernel as the other in-kernel filesystems.
As Pavel suggested, it's better to do as one commit since git
can do moves and all histories will be saved in this way.
Let's promote it from staging and enhance it more actively as
a "real" part of kernel for more wider scenarios!
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Pavel Machek <pavel@denx.de>
Cc: David Sterba <dsterba@suse.cz>
Cc: Amir Goldstein <amir73il@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Darrick J . Wong <darrick.wong@oracle.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Richard Weinberger <richard@nod.at>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chao Yu <yuchao0@huawei.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Li Guifu <bluce.liguifu@huawei.com>
Cc: Fang Wei <fangwei1@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Link: https://lore.kernel.org/r/20190822213659.5501-1-hsiangkao@aol.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes gcc '-Wunused-but-set-variable' warning:
In function '_rtl92e_dm_tx_power_tracking_callback_tssi':
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c:621:7:
warning: variable 'bHighpowerstate' set but not used [-Wunused-but-set-variable]
In function '_rtl92e_dm_rx_path_sel_byrssi':
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c:1904:32:
warning: variable 'cck_rx_ver2_min_index' set but not used [-Wunused-but-set-variable]
They are never used, so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190821122556.37636-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c:
In function ieee80211_ccmp_encrypt:
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c:162:6:
warning: variable data_len set but not used [-Wunused-but-set-variable]
It is not used since commit eb0e7bf3ca ("staging:
rtl8192u: ieee80211: ieee80211_crypt_ccmp.c: Use crypto API ccm(aes)")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190821122250.71404-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As reported by erofs-utils fuzzer, 2 conditions
can happen in corrupted images, which can cause
unexpected behaviors.
- access the same pcluster one more time;
- access the tail end pcluster again, e.g.
_ access again (will trigger tail merging)
|
1 2 3 1 2 -> 1 2 3 1
|_ tail end of the chain \___/ (unexpected behavior)
Let's detect and avoid them now.
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Link: https://lore.kernel.org/r/20190821030908.40282-1-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Brennan