diff options
| author | Salah Triki <salah.triki@gmail.com> | 2026-08-24 05:29:07 +0100 |
|---|---|---|
| committer | Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> | 2026-09-07 03:12:17 +0100 |
| commit | 7d38af8f20239a66e90de7632a79c9425256c574 (patch) | |
| tree | 5cea745f41713bb9f77e0943683eba8641ff637e /samples/rust | |
| parent | e24328974a88aa8541e94e8bb8dfa2ade1b3c45d (diff) | |
| download | linux-stable-7d38af8f20239a66e90de7632a79c9425256c574.tar.gz linux-stable-7d38af8f20239a66e90de7632a79c9425256c574.zip | |
iio: proximity: vcnl3020: fix ISR bitmask check in IRQ handler
The threaded IRQ handler contained multiple issues in handling interrupt
events and clearing status flags:
1. ISR bit check: The handler incorrectly checked the Interrupt Status
Register (VCNL_ISR) against VCNL_ICR_THRES_EN (BIT(1)), which is a
bitmask meant for the Control Register (VCNL_PS_ICR). In VCNL_ISR,
BIT(1) corresponds only to low-threshold interrupts. A high-threshold
interrupt (VCNL_INT_TH_HI, BIT(0)) on its own was completely ignored and
returned IRQ_NONE.
2. Event direction & channel index: The handler unconditionally pushed a
RISING event code on channel index 1. The driver only registers a single
proximity channel (index 0), and low-threshold interrupts should be
reported with IIO_EV_DIR_FALLING.
3. ISR clearing: The write-back to acknowledge the interrupt only preserved
BIT(1) instead of masking against both valid status bits.
Fix this by checking both VCNL_INT_TH_HI and VCNL_INT_TH_LOW bits in
VCNL_ISR, pushing separate IIO events with the correct direction and
channel index (0), and properly clearing handled status bits.
Fixes: 3363fbbe19e5 ("iio: proximity: vcnl3020: add periodic mode")
Signed-off-by: Salah Triki <salah.triki@gmail.com>
Reviewed-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Diffstat (limited to 'samples/rust')
0 files changed, 0 insertions, 0 deletions
