Some 2-in-1 laptops / convertibles with 360° (yoga-style) hinges,
use 2 KXCJ91008 accelerometers:
1 in their display using an ACPI HID of "KIOX010A"; and
1 in their base using an ACPI HID of "KIOX020A"
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 Medion Akoya E2228T MD60250.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210207160901.110643-4-hdegoede@redhat.com
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>
For non-DMA usage, we have an easy way to associate a timestamp with a
sample: iio_pollfunc_store_time stores a timestamp in the primary
trigger IRQ handler and stm32_adc_trigger_handler runs in the IRQ thread
to push out the buffer along with the timestamp.
For this to work, the driver needs to register an IIO_TIMESTAMP channel.
Do this.
For DMA, it's not as easy, because we don't push the buffers out of
stm32_adc_trigger, but out of stm32_adc_dma_buffer_done, which runs in
a tasklet scheduled after a DMA completion.
Preferably, the DMA controller would copy us the timestamp into that buffer
as well. Until this is implemented, restrict timestamping support to
only PIO. For low-frequency sampling, PIO is probably good enough.
Cc: Holger Assmann <has@pengutronix.de>
Acked-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.kernel.org/r/20210125194824.30549-1-a.fatoum@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Currently, the STM32 LP Timer counter driver registers into both IIO and
counter subsystems, which is redundant.
Remove the IIO counter ABI and IIO registration from the STM32 LP Timer
counter driver since it's been superseded by the Counter subsystem
as discussed in [1].
Keep only the counter subsystem related part.
Move a part of the ABI documentation into a driver comment.
This also removes a duplicate ABI warning
$ scripts/get_abi.pl validate
...
/sys/bus/iio/devices/iio:deviceX/in_count0_preset is defined 2 times:
./Documentation/ABI/testing/sysfs-bus-iio-timer-stm32:100
./Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32:0
[1] https://lkml.org/lkml/2021/1/19/347
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Link: https://lore.kernel.org/r/1611926542-2490-1-git-send-email-fabrice.gasnier@foss.st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Seems that there are config combinations in which this driver gets enabled
and hence selects the MFD, but with out HAS_IOMEM getting pulled in
via some other route. MFD is entirely contained in an
if HAS_IOMEM block, leading to the build issue in this bugzilla.
https://bugzilla.kernel.org/show_bug.cgi?id=209889
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This commit fixes the following checkpatch.pl warnings:
WARNING: do not add new typedefs
#24: FILE: hal/HalBtc8723b1Ant.h:24:
+typedef enum _BT_INFO_SRC_8723B_1ANT {
WARNING: do not add new typedefs
#31: FILE: hal/HalBtc8723b1Ant.h:31:
+typedef enum _BT_8723B_1ANT_BT_STATUS {
WARNING: do not add new typedefs
#41: FILE: hal/HalBtc8723b1Ant.h:41:
+typedef enum _BT_8723B_1ANT_WIFI_STATUS {
WARNING: do not add new typedefs
#51: FILE: hal/HalBtc8723b1Ant.h:51:
+typedef enum _BT_8723B_1ANT_COEX_ALGO {
WARNING: do not add new typedefs
#66: FILE: hal/HalBtc8723b1Ant.h:66:
+typedef struct _COEX_DM_8723B_1ANT {
WARNING: do not add new typedefs
#121: FILE: hal/HalBtc8723b1Ant.h:121:
+typedef struct _COEX_STA_8723B_1ANT {
Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210305100146.30687-1-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit fixes the following checkpatch.pl warnings:
WARNING: do not add new typedefs
#19: FILE: hal/HalBtc8723b2Ant.h:19:
+typedef enum _BT_INFO_SRC_8723B_2ANT {
WARNING: do not add new typedefs
#26: FILE: hal/HalBtc8723b2Ant.h:26:
+typedef enum _BT_8723B_2ANT_BT_STATUS {
WARNING: do not add new typedefs
#36: FILE: hal/HalBtc8723b2Ant.h:36:
+typedef enum _BT_8723B_2ANT_COEX_ALGO {
WARNING: do not add new typedefs
#51: FILE: hal/HalBtc8723b2Ant.h:51:
+typedef struct _COEX_DM_8723B_2ANT {
WARNING: do not add new typedefs
#104: FILE: hal/HalBtc8723b2Ant.h:104:
+typedef struct _COEX_STA_8723B_2ANT {
Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210305101151.13137-1-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit fixes the following checkpatch.pl warnings:
WARNING: do not add new typedefs
#11: FILE: hal/HalPhyRf.h:11:
+typedef enum _SPUR_CAL_METHOD {
WARNING: do not add new typedefs
#16: FILE: hal/HalPhyRf.h:16:
+typedef enum _PWRTRACK_CONTROL_METHOD {
WARNING: do not add new typedefs
#27: FILE: hal/HalPhyRf.h:27:
+typedef struct _TXPWRTRACK_CFG {
Signed-off-by: Marco Cesati <marco.cesati@gmail.com>
Link: https://lore.kernel.org/r/20210305144906.18850-1-marco.cesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix some "incorrect type in assignment" warnings reported by sparse in fw.c
sparse warnings:
wimax/i2400m/fw.c:266:27: warning: cast to restricted __le32
wimax/i2400m/fw.c:266:25: warning: incorrect type in assignment (different base types)
wimax/i2400m/fw.c:267:27: warning: cast to restricted __le32
wimax/i2400m/fw.c:267:25: warning: incorrect type in assignment (different base types)
wimax/i2400m/fw.c:268:27: warning: cast to restricted __le32
wimax/i2400m/fw.c:268:25: warning: incorrect type in assignment (different base types)
wimax/i2400m/fw.c:269:27: warning: cast to restricted __le32
wimax/i2400m/fw.c:269:25: warning: incorrect type in assignment (different base types)
Signed-off-by: Darryl T. Agostinelli <dagostinelli@gmail.com>
Link: https://lore.kernel.org/r/20210308144839.2364329-1-dagostinelli@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In function rtl92e_start_adapter() automatic variable 'i' referenced only
within certain loops, used as iteration counter. Control flow can't get
into such loop w/o 'i = 0' assignment.
It's redundant to shadow this variable by creating scope around loop.
This patch fixes the following sparse warning:
warning: symbol 'i' shadows an earlier one
Signed-off-by: Nikolay Kyx <knv418@gmail.com>
Link: https://lore.kernel.org/r/20210302133217.145994-1-knv418@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
