* [PATCH v2 1/3] dt-bindings: iio: light: Document Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 8:31 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, Svyatoslav Ryhel,
Randy Dunlap
Cc: linux-iio, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-1-clamor95@gmail.com>
Document Avago APDS-9900/9901 combined ALS/IR-LED/Proximity sensor.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
Documentation/devicetree/bindings/iio/light/tsl2772.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/light/tsl2772.yaml b/Documentation/devicetree/bindings/iio/light/tsl2772.yaml
index d81229857944..9921ccaa64a0 100644
--- a/Documentation/devicetree/bindings/iio/light/tsl2772.yaml
+++ b/Documentation/devicetree/bindings/iio/light/tsl2772.yaml
@@ -26,6 +26,8 @@ properties:
- amstaos,tmd2672
- amstaos,tsl2772
- amstaos,tmd2772
+ - avago,apds9900
+ - avago,apds9901
- avago,apds9930
reg:
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 8:31 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, Svyatoslav Ryhel,
Randy Dunlap
Cc: linux-iio, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-1-clamor95@gmail.com>
The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
just add the correct bindings and the appropriate LUX table derived from
the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
index c8f15ba95267..8dab34bf00ca 100644
--- a/drivers/iio/light/tsl2772.c
+++ b/drivers/iio/light/tsl2772.c
@@ -127,6 +127,7 @@ enum {
tmd2672,
tsl2772,
tmd2772,
+ apds990x,
apds9930,
};
@@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
{ 0, 0 },
};
+static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
+ { 52000, 115960 },
+ { 36400, 73840 },
+ { 0, 0 },
+};
+
static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
{ 52000, 96824 },
{ 38792, 67132 },
@@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
[tmd2672] = tmd2x72_lux_table,
[tsl2772] = tsl2x72_lux_table,
[tmd2772] = tmd2x72_lux_table,
+ [apds990x] = apds990x_lux_table,
[apds9930] = apds9930_lux_table,
};
@@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
[tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
[tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
[tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
+ [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
[apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
};
@@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
[tmd2672] = PRX2,
[tsl2772] = ALSPRX2,
[tmd2772] = ALSPRX2,
+ [apds990x] = ALSPRX,
[apds9930] = ALSPRX2,
};
@@ -530,6 +540,7 @@ static int tsl2772_get_prox(struct iio_dev *indio_dev)
case tmd2672:
case tsl2772:
case tmd2772:
+ case apds990x:
case apds9930:
if (!(ret & TSL2772_STA_PRX_VALID)) {
ret = -EINVAL;
@@ -1367,6 +1378,7 @@ static int tsl2772_device_id_verif(int id, int target)
return (id & 0xf0) == TRITON_ID;
case tmd2671:
case tmd2771:
+ case apds990x:
return (id & 0xf0) == HALIBUT_ID;
case tsl2572:
case tsl2672:
@@ -1898,6 +1910,8 @@ static const struct i2c_device_id tsl2772_idtable[] = {
{ "tmd2672", tmd2672 },
{ "tsl2772", tsl2772 },
{ "tmd2772", tmd2772 },
+ { "apds9900", apds990x },
+ { "apds9901", apds990x },
{ "apds9930", apds9930 },
{ }
};
@@ -1915,6 +1929,8 @@ static const struct of_device_id tsl2772_of_match[] = {
{ .compatible = "amstaos,tmd2672" },
{ .compatible = "amstaos,tsl2772" },
{ .compatible = "amstaos,tmd2772" },
+ { .compatible = "avago,apds9900" },
+ { .compatible = "avago,apds9901" },
{ .compatible = "avago,apds9930" },
{ }
};
--
2.51.0
^ permalink raw reply related
* [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Svyatoslav Ryhel @ 2026-04-19 8:31 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, Svyatoslav Ryhel,
Randy Dunlap
Cc: linux-iio, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-1-clamor95@gmail.com>
The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
IIO driver so there is no need to keep this old implementation. Remove it.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
Documentation/misc-devices/apds990x.rst | 128 ---
drivers/misc/Kconfig | 10 -
drivers/misc/Makefile | 1 -
drivers/misc/apds990x.c | 1284 -----------------------
include/linux/platform_data/apds990x.h | 65 --
5 files changed, 1488 deletions(-)
delete mode 100644 Documentation/misc-devices/apds990x.rst
delete mode 100644 drivers/misc/apds990x.c
delete mode 100644 include/linux/platform_data/apds990x.h
diff --git a/Documentation/misc-devices/apds990x.rst b/Documentation/misc-devices/apds990x.rst
deleted file mode 100644
index e2f75577f731..000000000000
--- a/Documentation/misc-devices/apds990x.rst
+++ /dev/null
@@ -1,128 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-======================
-Kernel driver apds990x
-======================
-
-Supported chips:
-Avago APDS990X
-
-Data sheet:
-Not freely available
-
-Author:
-Samu Onkalo <samu.p.onkalo@nokia.com>
-
-Description
------------
-
-APDS990x is a combined ambient light and proximity sensor. ALS and proximity
-functionality are highly connected. ALS measurement path must be running
-while the proximity functionality is enabled.
-
-ALS produces raw measurement values for two channels: Clear channel
-(infrared + visible light) and IR only. However, threshold comparisons happen
-using clear channel only. Lux value and the threshold level on the HW
-might vary quite much depending the spectrum of the light source.
-
-Driver makes necessary conversions to both directions so that user handles
-only lux values. Lux value is calculated using information from the both
-channels. HW threshold level is calculated from the given lux value to match
-with current type of the lightning. Sometimes inaccuracy of the estimations
-lead to false interrupt, but that doesn't harm.
-
-ALS contains 4 different gain steps. Driver automatically
-selects suitable gain step. After each measurement, reliability of the results
-is estimated and new measurement is triggered if necessary.
-
-Platform data can provide tuned values to the conversion formulas if
-values are known. Otherwise plain sensor default values are used.
-
-Proximity side is little bit simpler. There is no need for complex conversions.
-It produces directly usable values.
-
-Driver controls chip operational state using pm_runtime framework.
-Voltage regulators are controlled based on chip operational state.
-
-SYSFS
------
-
-
-chip_id
- RO - shows detected chip type and version
-
-power_state
- RW - enable / disable chip. Uses counting logic
-
- 1 enables the chip
- 0 disables the chip
-lux0_input
- RO - measured lux value
-
- sysfs_notify called when threshold interrupt occurs
-
-lux0_sensor_range
- RO - lux0_input max value.
-
- Actually never reaches since sensor tends
- to saturate much before that. Real max value varies depending
- on the light spectrum etc.
-
-lux0_rate
- RW - measurement rate in Hz
-
-lux0_rate_avail
- RO - supported measurement rates
-
-lux0_calibscale
- RW - calibration value.
-
- Set to neutral value by default.
- Output results are multiplied with calibscale / calibscale_default
- value.
-
-lux0_calibscale_default
- RO - neutral calibration value
-
-lux0_thresh_above_value
- RW - HI level threshold value.
-
- All results above the value
- trigs an interrupt. 65535 (i.e. sensor_range) disables the above
- interrupt.
-
-lux0_thresh_below_value
- RW - LO level threshold value.
-
- All results below the value
- trigs an interrupt. 0 disables the below interrupt.
-
-prox0_raw
- RO - measured proximity value
-
- sysfs_notify called when threshold interrupt occurs
-
-prox0_sensor_range
- RO - prox0_raw max value (1023)
-
-prox0_raw_en
- RW - enable / disable proximity - uses counting logic
-
- - 1 enables the proximity
- - 0 disables the proximity
-
-prox0_reporting_mode
- RW - trigger / periodic.
-
- In "trigger" mode the driver tells two possible
- values: 0 or prox0_sensor_range value. 0 means no proximity,
- 1023 means proximity. This causes minimal number of interrupts.
- In "periodic" mode the driver reports all values above
- prox0_thresh_above. This causes more interrupts, but it can give
- _rough_ estimate about the distance.
-
-prox0_reporting_mode_avail
- RO - accepted values to prox0_reporting_mode (trigger, periodic)
-
-prox0_thresh_above_value
- RW - threshold level which trigs proximity events.
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 8cbd71a0dc35..051cf2c44b90 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -392,16 +392,6 @@ config SENSORS_BH1770
To compile this driver as a module, choose M here: the
module will be called bh1770glc. If unsure, say N here.
-config SENSORS_APDS990X
- tristate "APDS990X combined als and proximity sensors"
- depends on I2C
- help
- Say Y here if you want to build a driver for Avago APDS990x
- combined ambient light and proximity sensor chip.
-
- To compile this driver as a module, choose M here: the
- module will be called apds990x. If unsure, say N here.
-
config HMC6352
tristate "Honeywell HMC6352 compass"
depends on I2C
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 62c3d03206e9..bfad6982591c 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -20,7 +20,6 @@ obj-$(CONFIG_RPMB) += rpmb-core.o
obj-$(CONFIG_QCOM_COINCELL) += qcom-coincell.o
obj-$(CONFIG_QCOM_FASTRPC) += fastrpc.o
obj-$(CONFIG_SENSORS_BH1770) += bh1770glc.o
-obj-$(CONFIG_SENSORS_APDS990X) += apds990x.o
obj-$(CONFIG_ENCLOSURE_SERVICES) += enclosure.o
obj-$(CONFIG_KGDB_TESTS) += kgdbts.o
obj-$(CONFIG_SGI_XP) += sgi-xp/
diff --git a/drivers/misc/apds990x.c b/drivers/misc/apds990x.c
deleted file mode 100644
index b69c3a1c94d1..000000000000
--- a/drivers/misc/apds990x.c
+++ /dev/null
@@ -1,1284 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * This file is part of the APDS990x sensor driver.
- * Chip is combined proximity and ambient light sensor.
- *
- * Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
- *
- * Contact: Samu Onkalo <samu.p.onkalo@nokia.com>
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/i2c.h>
-#include <linux/interrupt.h>
-#include <linux/mutex.h>
-#include <linux/regulator/consumer.h>
-#include <linux/pm_runtime.h>
-#include <linux/delay.h>
-#include <linux/wait.h>
-#include <linux/slab.h>
-#include <linux/platform_data/apds990x.h>
-
-/* Register map */
-#define APDS990X_ENABLE 0x00 /* Enable of states and interrupts */
-#define APDS990X_ATIME 0x01 /* ALS ADC time */
-#define APDS990X_PTIME 0x02 /* Proximity ADC time */
-#define APDS990X_WTIME 0x03 /* Wait time */
-#define APDS990X_AILTL 0x04 /* ALS interrupt low threshold low byte */
-#define APDS990X_AILTH 0x05 /* ALS interrupt low threshold hi byte */
-#define APDS990X_AIHTL 0x06 /* ALS interrupt hi threshold low byte */
-#define APDS990X_AIHTH 0x07 /* ALS interrupt hi threshold hi byte */
-#define APDS990X_PILTL 0x08 /* Proximity interrupt low threshold low byte */
-#define APDS990X_PILTH 0x09 /* Proximity interrupt low threshold hi byte */
-#define APDS990X_PIHTL 0x0a /* Proximity interrupt hi threshold low byte */
-#define APDS990X_PIHTH 0x0b /* Proximity interrupt hi threshold hi byte */
-#define APDS990X_PERS 0x0c /* Interrupt persistence filters */
-#define APDS990X_CONFIG 0x0d /* Configuration */
-#define APDS990X_PPCOUNT 0x0e /* Proximity pulse count */
-#define APDS990X_CONTROL 0x0f /* Gain control register */
-#define APDS990X_REV 0x11 /* Revision Number */
-#define APDS990X_ID 0x12 /* Device ID */
-#define APDS990X_STATUS 0x13 /* Device status */
-#define APDS990X_CDATAL 0x14 /* Clear ADC low data register */
-#define APDS990X_CDATAH 0x15 /* Clear ADC high data register */
-#define APDS990X_IRDATAL 0x16 /* IR ADC low data register */
-#define APDS990X_IRDATAH 0x17 /* IR ADC high data register */
-#define APDS990X_PDATAL 0x18 /* Proximity ADC low data register */
-#define APDS990X_PDATAH 0x19 /* Proximity ADC high data register */
-
-/* Control */
-#define APDS990X_MAX_AGAIN 3
-
-/* Enable register */
-#define APDS990X_EN_PIEN (0x1 << 5)
-#define APDS990X_EN_AIEN (0x1 << 4)
-#define APDS990X_EN_WEN (0x1 << 3)
-#define APDS990X_EN_PEN (0x1 << 2)
-#define APDS990X_EN_AEN (0x1 << 1)
-#define APDS990X_EN_PON (0x1 << 0)
-#define APDS990X_EN_DISABLE_ALL 0
-
-/* Status register */
-#define APDS990X_ST_PINT (0x1 << 5)
-#define APDS990X_ST_AINT (0x1 << 4)
-
-/* I2C access types */
-#define APDS990x_CMD_TYPE_MASK (0x03 << 5)
-#define APDS990x_CMD_TYPE_RB (0x00 << 5) /* Repeated byte */
-#define APDS990x_CMD_TYPE_INC (0x01 << 5) /* Auto increment */
-#define APDS990x_CMD_TYPE_SPE (0x03 << 5) /* Special function */
-
-#define APDS990x_ADDR_SHIFT 0
-#define APDS990x_CMD 0x80
-
-/* Interrupt ack commands */
-#define APDS990X_INT_ACK_ALS 0x6
-#define APDS990X_INT_ACK_PS 0x5
-#define APDS990X_INT_ACK_BOTH 0x7
-
-/* ptime */
-#define APDS990X_PTIME_DEFAULT 0xff /* Recommended conversion time 2.7ms*/
-
-/* wtime */
-#define APDS990X_WTIME_DEFAULT 0xee /* ~50ms wait time */
-
-#define APDS990X_TIME_TO_ADC 1024 /* One timetick as ADC count value */
-
-/* Persistence */
-#define APDS990X_APERS_SHIFT 0
-#define APDS990X_PPERS_SHIFT 4
-
-/* Supported ID:s */
-#define APDS990X_ID_0 0x0
-#define APDS990X_ID_4 0x4
-#define APDS990X_ID_29 0x29
-
-/* pgain and pdiode settings */
-#define APDS_PGAIN_1X 0x0
-#define APDS_PDIODE_IR 0x2
-
-#define APDS990X_LUX_OUTPUT_SCALE 10
-
-/* Reverse chip factors for threshold calculation */
-struct reverse_factors {
- u32 afactor;
- int cf1;
- int irf1;
- int cf2;
- int irf2;
-};
-
-struct apds990x_chip {
- struct apds990x_platform_data *pdata;
- struct i2c_client *client;
- struct mutex mutex; /* avoid parallel access */
- struct regulator_bulk_data regs[2];
- wait_queue_head_t wait;
-
- int prox_en;
- bool prox_continuous_mode;
- bool lux_wait_fresh_res;
-
- /* Chip parameters */
- struct apds990x_chip_factors cf;
- struct reverse_factors rcf;
- u16 atime; /* als integration time */
- u16 arate; /* als reporting rate */
- u16 a_max_result; /* Max possible ADC value with current atime */
- u8 again_meas; /* Gain used in last measurement */
- u8 again_next; /* Next calculated gain */
- u8 pgain;
- u8 pdiode;
- u8 pdrive;
- u8 lux_persistence;
- u8 prox_persistence;
-
- u32 lux_raw;
- u32 lux;
- u16 lux_clear;
- u16 lux_ir;
- u16 lux_calib;
- u32 lux_thres_hi;
- u32 lux_thres_lo;
-
- u32 prox_thres;
- u16 prox_data;
- u16 prox_calib;
-
- char chipname[10];
- u8 revision;
-};
-
-#define APDS_CALIB_SCALER 8192
-#define APDS_LUX_NEUTRAL_CALIB_VALUE (1 * APDS_CALIB_SCALER)
-#define APDS_PROX_NEUTRAL_CALIB_VALUE (1 * APDS_CALIB_SCALER)
-
-#define APDS_PROX_DEF_THRES 600
-#define APDS_PROX_HYSTERESIS 50
-#define APDS_LUX_DEF_THRES_HI 101
-#define APDS_LUX_DEF_THRES_LO 100
-#define APDS_DEFAULT_PROX_PERS 1
-
-#define APDS_TIMEOUT 2000
-#define APDS_STARTUP_DELAY 25000 /* us */
-#define APDS_RANGE 65535
-#define APDS_PROX_RANGE 1023
-#define APDS_LUX_GAIN_LO_LIMIT 100
-#define APDS_LUX_GAIN_LO_LIMIT_STRICT 25
-
-#define TIMESTEP 87 /* 2.7ms is about 87 / 32 */
-#define TIME_STEP_SCALER 32
-
-#define APDS_LUX_AVERAGING_TIME 50 /* tolerates 50/60Hz ripple */
-#define APDS_LUX_DEFAULT_RATE 200
-
-static const u8 again[] = {1, 8, 16, 120}; /* ALS gain steps */
-
-/* Following two tables must match i.e 10Hz rate means 1 as persistence value */
-static const u16 arates_hz[] = {10, 5, 2, 1};
-static const u8 apersis[] = {1, 2, 4, 5};
-
-/* Regulators */
-static const char reg_vcc[] = "Vdd";
-static const char reg_vled[] = "Vled";
-
-static int apds990x_read_byte(struct apds990x_chip *chip, u8 reg, u8 *data)
-{
- struct i2c_client *client = chip->client;
- s32 ret;
-
- reg &= ~APDS990x_CMD_TYPE_MASK;
- reg |= APDS990x_CMD | APDS990x_CMD_TYPE_RB;
-
- ret = i2c_smbus_read_byte_data(client, reg);
- *data = ret;
- return (int)ret;
-}
-
-static int apds990x_read_word(struct apds990x_chip *chip, u8 reg, u16 *data)
-{
- struct i2c_client *client = chip->client;
- s32 ret;
-
- reg &= ~APDS990x_CMD_TYPE_MASK;
- reg |= APDS990x_CMD | APDS990x_CMD_TYPE_INC;
-
- ret = i2c_smbus_read_word_data(client, reg);
- *data = ret;
- return (int)ret;
-}
-
-static int apds990x_write_byte(struct apds990x_chip *chip, u8 reg, u8 data)
-{
- struct i2c_client *client = chip->client;
- s32 ret;
-
- reg &= ~APDS990x_CMD_TYPE_MASK;
- reg |= APDS990x_CMD | APDS990x_CMD_TYPE_RB;
-
- ret = i2c_smbus_write_byte_data(client, reg, data);
- return (int)ret;
-}
-
-static int apds990x_write_word(struct apds990x_chip *chip, u8 reg, u16 data)
-{
- struct i2c_client *client = chip->client;
- s32 ret;
-
- reg &= ~APDS990x_CMD_TYPE_MASK;
- reg |= APDS990x_CMD | APDS990x_CMD_TYPE_INC;
-
- ret = i2c_smbus_write_word_data(client, reg, data);
- return (int)ret;
-}
-
-static int apds990x_mode_on(struct apds990x_chip *chip)
-{
- /* ALS is mandatory, proximity optional */
- u8 reg = APDS990X_EN_AIEN | APDS990X_EN_PON | APDS990X_EN_AEN |
- APDS990X_EN_WEN;
-
- if (chip->prox_en)
- reg |= APDS990X_EN_PIEN | APDS990X_EN_PEN;
-
- return apds990x_write_byte(chip, APDS990X_ENABLE, reg);
-}
-
-static u16 apds990x_lux_to_threshold(struct apds990x_chip *chip, u32 lux)
-{
- u32 thres;
- u32 cpl;
- u32 ir;
-
- if (lux == 0)
- return 0;
- else if (lux == APDS_RANGE)
- return APDS_RANGE;
-
- /*
- * Reported LUX value is a combination of the IR and CLEAR channel
- * values. However, interrupt threshold is only for clear channel.
- * This function approximates needed HW threshold value for a given
- * LUX value in the current lightning type.
- * IR level compared to visible light varies heavily depending on the
- * source of the light
- *
- * Calculate threshold value for the next measurement period.
- * Math: threshold = lux * cpl where
- * cpl = atime * again / (glass_attenuation * device_factor)
- * (count-per-lux)
- *
- * First remove calibration. Division by four is to avoid overflow
- */
- lux = lux * (APDS_CALIB_SCALER / 4) / (chip->lux_calib / 4);
-
- /* Multiplication by 64 is to increase accuracy */
- cpl = ((u32)chip->atime * (u32)again[chip->again_next] *
- APDS_PARAM_SCALE * 64) / (chip->cf.ga * chip->cf.df);
-
- thres = lux * cpl / 64;
- /*
- * Convert IR light from the latest result to match with
- * new gain step. This helps to adapt with the current
- * source of light.
- */
- ir = (u32)chip->lux_ir * (u32)again[chip->again_next] /
- (u32)again[chip->again_meas];
-
- /*
- * Compensate count with IR light impact
- * IAC1 > IAC2 (see apds990x_get_lux for formulas)
- */
- if (chip->lux_clear * APDS_PARAM_SCALE >=
- chip->rcf.afactor * chip->lux_ir)
- thres = (chip->rcf.cf1 * thres + chip->rcf.irf1 * ir) /
- APDS_PARAM_SCALE;
- else
- thres = (chip->rcf.cf2 * thres + chip->rcf.irf2 * ir) /
- APDS_PARAM_SCALE;
-
- if (thres >= chip->a_max_result)
- thres = chip->a_max_result - 1;
- return thres;
-}
-
-static inline int apds990x_set_atime(struct apds990x_chip *chip, u32 time_ms)
-{
- u8 reg_value;
-
- chip->atime = time_ms;
- /* Formula is specified in the data sheet */
- reg_value = 256 - ((time_ms * TIME_STEP_SCALER) / TIMESTEP);
- /* Calculate max ADC value for given integration time */
- chip->a_max_result = (u16)(256 - reg_value) * APDS990X_TIME_TO_ADC;
- return apds990x_write_byte(chip, APDS990X_ATIME, reg_value);
-}
-
-/* Called always with mutex locked */
-static int apds990x_refresh_pthres(struct apds990x_chip *chip, int data)
-{
- int ret, lo, hi;
-
- /* If the chip is not in use, don't try to access it */
- if (pm_runtime_suspended(&chip->client->dev))
- return 0;
-
- if (data < chip->prox_thres) {
- lo = 0;
- hi = chip->prox_thres;
- } else {
- lo = chip->prox_thres - APDS_PROX_HYSTERESIS;
- if (chip->prox_continuous_mode)
- hi = chip->prox_thres;
- else
- hi = APDS_RANGE;
- }
-
- ret = apds990x_write_word(chip, APDS990X_PILTL, lo);
- ret |= apds990x_write_word(chip, APDS990X_PIHTL, hi);
- return ret;
-}
-
-/* Called always with mutex locked */
-static int apds990x_refresh_athres(struct apds990x_chip *chip)
-{
- int ret;
- /* If the chip is not in use, don't try to access it */
- if (pm_runtime_suspended(&chip->client->dev))
- return 0;
-
- ret = apds990x_write_word(chip, APDS990X_AILTL,
- apds990x_lux_to_threshold(chip, chip->lux_thres_lo));
- ret |= apds990x_write_word(chip, APDS990X_AIHTL,
- apds990x_lux_to_threshold(chip, chip->lux_thres_hi));
-
- return ret;
-}
-
-/* Called always with mutex locked */
-static void apds990x_force_a_refresh(struct apds990x_chip *chip)
-{
- /* This will force ALS interrupt after the next measurement. */
- apds990x_write_word(chip, APDS990X_AILTL, APDS_LUX_DEF_THRES_LO);
- apds990x_write_word(chip, APDS990X_AIHTL, APDS_LUX_DEF_THRES_HI);
-}
-
-/* Called always with mutex locked */
-static void apds990x_force_p_refresh(struct apds990x_chip *chip)
-{
- /* This will force proximity interrupt after the next measurement. */
- apds990x_write_word(chip, APDS990X_PILTL, APDS_PROX_DEF_THRES - 1);
- apds990x_write_word(chip, APDS990X_PIHTL, APDS_PROX_DEF_THRES);
-}
-
-/* Called always with mutex locked */
-static int apds990x_calc_again(struct apds990x_chip *chip)
-{
- int curr_again = chip->again_meas;
- int next_again = chip->again_meas;
- int ret = 0;
-
- /* Calculate suitable als gain */
- if (chip->lux_clear == chip->a_max_result)
- next_again -= 2; /* ALS saturated. Decrease gain by 2 steps */
- else if (chip->lux_clear > chip->a_max_result / 2)
- next_again--;
- else if (chip->lux_clear < APDS_LUX_GAIN_LO_LIMIT_STRICT)
- next_again += 2; /* Too dark. Increase gain by 2 steps */
- else if (chip->lux_clear < APDS_LUX_GAIN_LO_LIMIT)
- next_again++;
-
- /* Limit gain to available range */
- if (next_again < 0)
- next_again = 0;
- else if (next_again > APDS990X_MAX_AGAIN)
- next_again = APDS990X_MAX_AGAIN;
-
- /* Let's check can we trust the measured result */
- if (chip->lux_clear == chip->a_max_result)
- /* Result can be totally garbage due to saturation */
- ret = -ERANGE;
- else if (next_again != curr_again &&
- chip->lux_clear < APDS_LUX_GAIN_LO_LIMIT_STRICT)
- /*
- * Gain is changed and measurement result is very small.
- * Result can be totally garbage due to underflow
- */
- ret = -ERANGE;
-
- chip->again_next = next_again;
- apds990x_write_byte(chip, APDS990X_CONTROL,
- (chip->pdrive << 6) |
- (chip->pdiode << 4) |
- (chip->pgain << 2) |
- (chip->again_next << 0));
-
- /*
- * Error means bad result -> re-measurement is needed. The forced
- * refresh uses fastest possible persistence setting to get result
- * as soon as possible.
- */
- if (ret < 0)
- apds990x_force_a_refresh(chip);
- else
- apds990x_refresh_athres(chip);
-
- return ret;
-}
-
-/* Called always with mutex locked */
-static int apds990x_get_lux(struct apds990x_chip *chip, int clear, int ir)
-{
- int iac, iac1, iac2; /* IR adjusted counts */
- u32 lpc; /* Lux per count */
-
- /* Formulas:
- * iac1 = CF1 * CLEAR_CH - IRF1 * IR_CH
- * iac2 = CF2 * CLEAR_CH - IRF2 * IR_CH
- */
- iac1 = (chip->cf.cf1 * clear - chip->cf.irf1 * ir) / APDS_PARAM_SCALE;
- iac2 = (chip->cf.cf2 * clear - chip->cf.irf2 * ir) / APDS_PARAM_SCALE;
-
- iac = max(iac1, iac2);
- iac = max(iac, 0);
-
- lpc = APDS990X_LUX_OUTPUT_SCALE * (chip->cf.df * chip->cf.ga) /
- (u32)(again[chip->again_meas] * (u32)chip->atime);
-
- return (iac * lpc) / APDS_PARAM_SCALE;
-}
-
-static int apds990x_ack_int(struct apds990x_chip *chip, u8 mode)
-{
- struct i2c_client *client = chip->client;
- s32 ret;
- u8 reg = APDS990x_CMD | APDS990x_CMD_TYPE_SPE;
-
- switch (mode & (APDS990X_ST_AINT | APDS990X_ST_PINT)) {
- case APDS990X_ST_AINT:
- reg |= APDS990X_INT_ACK_ALS;
- break;
- case APDS990X_ST_PINT:
- reg |= APDS990X_INT_ACK_PS;
- break;
- default:
- reg |= APDS990X_INT_ACK_BOTH;
- break;
- }
-
- ret = i2c_smbus_read_byte_data(client, reg);
- return (int)ret;
-}
-
-static irqreturn_t apds990x_irq(int irq, void *data)
-{
- struct apds990x_chip *chip = data;
- u8 status;
-
- apds990x_read_byte(chip, APDS990X_STATUS, &status);
- apds990x_ack_int(chip, status);
-
- mutex_lock(&chip->mutex);
- if (!pm_runtime_suspended(&chip->client->dev)) {
- if (status & APDS990X_ST_AINT) {
- apds990x_read_word(chip, APDS990X_CDATAL,
- &chip->lux_clear);
- apds990x_read_word(chip, APDS990X_IRDATAL,
- &chip->lux_ir);
- /* Store used gain for calculations */
- chip->again_meas = chip->again_next;
-
- chip->lux_raw = apds990x_get_lux(chip,
- chip->lux_clear,
- chip->lux_ir);
-
- if (apds990x_calc_again(chip) == 0) {
- /* Result is valid */
- chip->lux = chip->lux_raw;
- chip->lux_wait_fresh_res = false;
- wake_up(&chip->wait);
- sysfs_notify(&chip->client->dev.kobj,
- NULL, "lux0_input");
- }
- }
-
- if ((status & APDS990X_ST_PINT) && chip->prox_en) {
- u16 clr_ch;
-
- apds990x_read_word(chip, APDS990X_CDATAL, &clr_ch);
- /*
- * If ALS channel is saturated at min gain,
- * proximity gives false posivite values.
- * Just ignore them.
- */
- if (chip->again_meas == 0 &&
- clr_ch == chip->a_max_result)
- chip->prox_data = 0;
- else
- apds990x_read_word(chip,
- APDS990X_PDATAL,
- &chip->prox_data);
-
- apds990x_refresh_pthres(chip, chip->prox_data);
- if (chip->prox_data < chip->prox_thres)
- chip->prox_data = 0;
- else if (!chip->prox_continuous_mode)
- chip->prox_data = APDS_PROX_RANGE;
- sysfs_notify(&chip->client->dev.kobj,
- NULL, "prox0_raw");
- }
- }
- mutex_unlock(&chip->mutex);
- return IRQ_HANDLED;
-}
-
-static int apds990x_configure(struct apds990x_chip *chip)
-{
- /* It is recommended to use disabled mode during these operations */
- apds990x_write_byte(chip, APDS990X_ENABLE, APDS990X_EN_DISABLE_ALL);
-
- /* conversion and wait times for different state machince states */
- apds990x_write_byte(chip, APDS990X_PTIME, APDS990X_PTIME_DEFAULT);
- apds990x_write_byte(chip, APDS990X_WTIME, APDS990X_WTIME_DEFAULT);
- apds990x_set_atime(chip, APDS_LUX_AVERAGING_TIME);
-
- apds990x_write_byte(chip, APDS990X_CONFIG, 0);
-
- /* Persistence levels */
- apds990x_write_byte(chip, APDS990X_PERS,
- (chip->lux_persistence << APDS990X_APERS_SHIFT) |
- (chip->prox_persistence << APDS990X_PPERS_SHIFT));
-
- apds990x_write_byte(chip, APDS990X_PPCOUNT, chip->pdata->ppcount);
-
- /* Start with relatively small gain */
- chip->again_meas = 1;
- chip->again_next = 1;
- apds990x_write_byte(chip, APDS990X_CONTROL,
- (chip->pdrive << 6) |
- (chip->pdiode << 4) |
- (chip->pgain << 2) |
- (chip->again_next << 0));
- return 0;
-}
-
-static int apds990x_detect(struct apds990x_chip *chip)
-{
- struct i2c_client *client = chip->client;
- int ret;
- u8 id;
-
- ret = apds990x_read_byte(chip, APDS990X_ID, &id);
- if (ret < 0) {
- dev_err(&client->dev, "ID read failed\n");
- return ret;
- }
-
- ret = apds990x_read_byte(chip, APDS990X_REV, &chip->revision);
- if (ret < 0) {
- dev_err(&client->dev, "REV read failed\n");
- return ret;
- }
-
- switch (id) {
- case APDS990X_ID_0:
- case APDS990X_ID_4:
- case APDS990X_ID_29:
- snprintf(chip->chipname, sizeof(chip->chipname), "APDS-990x");
- break;
- default:
- ret = -ENODEV;
- break;
- }
- return ret;
-}
-
-#ifdef CONFIG_PM
-static int apds990x_chip_on(struct apds990x_chip *chip)
-{
- int err = regulator_bulk_enable(ARRAY_SIZE(chip->regs),
- chip->regs);
- if (err < 0)
- return err;
-
- usleep_range(APDS_STARTUP_DELAY, 2 * APDS_STARTUP_DELAY);
-
- /* Refresh all configs in case of regulators were off */
- chip->prox_data = 0;
- apds990x_configure(chip);
- apds990x_mode_on(chip);
- return 0;
-}
-#endif
-
-static int apds990x_chip_off(struct apds990x_chip *chip)
-{
- apds990x_write_byte(chip, APDS990X_ENABLE, APDS990X_EN_DISABLE_ALL);
- regulator_bulk_disable(ARRAY_SIZE(chip->regs), chip->regs);
- return 0;
-}
-
-static ssize_t apds990x_lux_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
- ssize_t ret;
- u32 result;
- long time_left;
-
- if (pm_runtime_suspended(dev))
- return -EIO;
-
- time_left = wait_event_interruptible_timeout(chip->wait,
- !chip->lux_wait_fresh_res,
- msecs_to_jiffies(APDS_TIMEOUT));
- if (!time_left)
- return -EIO;
-
- mutex_lock(&chip->mutex);
- result = (chip->lux * chip->lux_calib) / APDS_CALIB_SCALER;
- if (result > (APDS_RANGE * APDS990X_LUX_OUTPUT_SCALE))
- result = APDS_RANGE * APDS990X_LUX_OUTPUT_SCALE;
-
- ret = sprintf(buf, "%d.%d\n",
- result / APDS990X_LUX_OUTPUT_SCALE,
- result % APDS990X_LUX_OUTPUT_SCALE);
- mutex_unlock(&chip->mutex);
- return ret;
-}
-
-static DEVICE_ATTR(lux0_input, S_IRUGO, apds990x_lux_show, NULL);
-
-static ssize_t apds990x_lux_range_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- return sprintf(buf, "%u\n", APDS_RANGE);
-}
-
-static DEVICE_ATTR(lux0_sensor_range, S_IRUGO, apds990x_lux_range_show, NULL);
-
-static ssize_t apds990x_lux_calib_format_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- return sprintf(buf, "%u\n", APDS_CALIB_SCALER);
-}
-
-static DEVICE_ATTR(lux0_calibscale_default, S_IRUGO,
- apds990x_lux_calib_format_show, NULL);
-
-static ssize_t apds990x_lux_calib_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
-
- return sprintf(buf, "%u\n", chip->lux_calib);
-}
-
-static ssize_t apds990x_lux_calib_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
- unsigned long value;
- int ret;
-
- ret = kstrtoul(buf, 0, &value);
- if (ret)
- return ret;
-
- chip->lux_calib = value;
-
- return len;
-}
-
-static DEVICE_ATTR(lux0_calibscale, S_IRUGO | S_IWUSR, apds990x_lux_calib_show,
- apds990x_lux_calib_store);
-
-static ssize_t apds990x_rate_avail(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- int i;
- int pos = 0;
-
- for (i = 0; i < ARRAY_SIZE(arates_hz); i++)
- pos += sprintf(buf + pos, "%d ", arates_hz[i]);
- sprintf(buf + pos - 1, "\n");
- return pos;
-}
-
-static ssize_t apds990x_rate_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
-
- return sprintf(buf, "%d\n", chip->arate);
-}
-
-static int apds990x_set_arate(struct apds990x_chip *chip, int rate)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(arates_hz); i++)
- if (rate >= arates_hz[i])
- break;
-
- if (i == ARRAY_SIZE(arates_hz))
- return -EINVAL;
-
- /* Pick up corresponding persistence value */
- chip->lux_persistence = apersis[i];
- chip->arate = arates_hz[i];
-
- /* If the chip is not in use, don't try to access it */
- if (pm_runtime_suspended(&chip->client->dev))
- return 0;
-
- /* Persistence levels */
- return apds990x_write_byte(chip, APDS990X_PERS,
- (chip->lux_persistence << APDS990X_APERS_SHIFT) |
- (chip->prox_persistence << APDS990X_PPERS_SHIFT));
-}
-
-static ssize_t apds990x_rate_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
- unsigned long value;
- int ret;
-
- ret = kstrtoul(buf, 0, &value);
- if (ret)
- return ret;
-
- mutex_lock(&chip->mutex);
- ret = apds990x_set_arate(chip, value);
- mutex_unlock(&chip->mutex);
-
- if (ret < 0)
- return ret;
- return len;
-}
-
-static DEVICE_ATTR(lux0_rate_avail, S_IRUGO, apds990x_rate_avail, NULL);
-
-static DEVICE_ATTR(lux0_rate, S_IRUGO | S_IWUSR, apds990x_rate_show,
- apds990x_rate_store);
-
-static ssize_t apds990x_prox_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- ssize_t ret;
- struct apds990x_chip *chip = dev_get_drvdata(dev);
-
- if (pm_runtime_suspended(dev) || !chip->prox_en)
- return -EIO;
-
- mutex_lock(&chip->mutex);
- ret = sprintf(buf, "%d\n", chip->prox_data);
- mutex_unlock(&chip->mutex);
- return ret;
-}
-
-static DEVICE_ATTR(prox0_raw, S_IRUGO, apds990x_prox_show, NULL);
-
-static ssize_t apds990x_prox_range_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- return sprintf(buf, "%u\n", APDS_PROX_RANGE);
-}
-
-static DEVICE_ATTR(prox0_sensor_range, S_IRUGO, apds990x_prox_range_show, NULL);
-
-static ssize_t apds990x_prox_enable_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
-
- return sprintf(buf, "%d\n", chip->prox_en);
-}
-
-static ssize_t apds990x_prox_enable_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
- unsigned long value;
- int ret;
-
- ret = kstrtoul(buf, 0, &value);
- if (ret)
- return ret;
-
- mutex_lock(&chip->mutex);
-
- if (!chip->prox_en)
- chip->prox_data = 0;
-
- if (value)
- chip->prox_en++;
- else if (chip->prox_en > 0)
- chip->prox_en--;
-
- if (!pm_runtime_suspended(dev))
- apds990x_mode_on(chip);
- mutex_unlock(&chip->mutex);
- return len;
-}
-
-static DEVICE_ATTR(prox0_raw_en, S_IRUGO | S_IWUSR, apds990x_prox_enable_show,
- apds990x_prox_enable_store);
-
-static const char *reporting_modes[] = {"trigger", "periodic"};
-
-static ssize_t apds990x_prox_reporting_mode_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
-
- return sprintf(buf, "%s\n",
- reporting_modes[!!chip->prox_continuous_mode]);
-}
-
-static ssize_t apds990x_prox_reporting_mode_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
- int ret;
-
- ret = sysfs_match_string(reporting_modes, buf);
- if (ret < 0)
- return ret;
-
- chip->prox_continuous_mode = ret;
- return len;
-}
-
-static DEVICE_ATTR(prox0_reporting_mode, S_IRUGO | S_IWUSR,
- apds990x_prox_reporting_mode_show,
- apds990x_prox_reporting_mode_store);
-
-static ssize_t apds990x_prox_reporting_avail_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- return sprintf(buf, "%s %s\n", reporting_modes[0], reporting_modes[1]);
-}
-
-static DEVICE_ATTR(prox0_reporting_mode_avail, S_IRUGO | S_IWUSR,
- apds990x_prox_reporting_avail_show, NULL);
-
-
-static ssize_t apds990x_lux_thresh_above_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
-
- return sprintf(buf, "%d\n", chip->lux_thres_hi);
-}
-
-static ssize_t apds990x_lux_thresh_below_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
-
- return sprintf(buf, "%d\n", chip->lux_thres_lo);
-}
-
-static ssize_t apds990x_set_lux_thresh(struct apds990x_chip *chip, u32 *target,
- const char *buf)
-{
- unsigned long thresh;
- int ret;
-
- ret = kstrtoul(buf, 0, &thresh);
- if (ret)
- return ret;
-
- if (thresh > APDS_RANGE)
- return -EINVAL;
-
- mutex_lock(&chip->mutex);
- *target = thresh;
- /*
- * Don't update values in HW if we are still waiting for
- * first interrupt to come after device handle open call.
- */
- if (!chip->lux_wait_fresh_res)
- apds990x_refresh_athres(chip);
- mutex_unlock(&chip->mutex);
- return ret;
-
-}
-
-static ssize_t apds990x_lux_thresh_above_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
- int ret = apds990x_set_lux_thresh(chip, &chip->lux_thres_hi, buf);
-
- if (ret < 0)
- return ret;
- return len;
-}
-
-static ssize_t apds990x_lux_thresh_below_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
- int ret = apds990x_set_lux_thresh(chip, &chip->lux_thres_lo, buf);
-
- if (ret < 0)
- return ret;
- return len;
-}
-
-static DEVICE_ATTR(lux0_thresh_above_value, S_IRUGO | S_IWUSR,
- apds990x_lux_thresh_above_show,
- apds990x_lux_thresh_above_store);
-
-static DEVICE_ATTR(lux0_thresh_below_value, S_IRUGO | S_IWUSR,
- apds990x_lux_thresh_below_show,
- apds990x_lux_thresh_below_store);
-
-static ssize_t apds990x_prox_threshold_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
-
- return sprintf(buf, "%d\n", chip->prox_thres);
-}
-
-static ssize_t apds990x_prox_threshold_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
- unsigned long value;
- int ret;
-
- ret = kstrtoul(buf, 0, &value);
- if (ret)
- return ret;
-
- if ((value > APDS_RANGE) || (value == 0) ||
- (value < APDS_PROX_HYSTERESIS))
- return -EINVAL;
-
- mutex_lock(&chip->mutex);
- chip->prox_thres = value;
-
- apds990x_force_p_refresh(chip);
- mutex_unlock(&chip->mutex);
- return len;
-}
-
-static DEVICE_ATTR(prox0_thresh_above_value, S_IRUGO | S_IWUSR,
- apds990x_prox_threshold_show,
- apds990x_prox_threshold_store);
-
-static ssize_t apds990x_power_state_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- return sprintf(buf, "%d\n", !pm_runtime_suspended(dev));
-}
-
-static ssize_t apds990x_power_state_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
- unsigned long value;
- int ret;
-
- ret = kstrtoul(buf, 0, &value);
- if (ret)
- return ret;
-
- if (value) {
- pm_runtime_get_sync(dev);
- mutex_lock(&chip->mutex);
- chip->lux_wait_fresh_res = true;
- apds990x_force_a_refresh(chip);
- apds990x_force_p_refresh(chip);
- mutex_unlock(&chip->mutex);
- } else {
- if (!pm_runtime_suspended(dev))
- pm_runtime_put(dev);
- }
- return len;
-}
-
-static DEVICE_ATTR(power_state, S_IRUGO | S_IWUSR,
- apds990x_power_state_show,
- apds990x_power_state_store);
-
-static ssize_t apds990x_chip_id_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct apds990x_chip *chip = dev_get_drvdata(dev);
-
- return sprintf(buf, "%s %d\n", chip->chipname, chip->revision);
-}
-
-static DEVICE_ATTR(chip_id, S_IRUGO, apds990x_chip_id_show, NULL);
-
-static struct attribute *sysfs_attrs_ctrl[] = {
- &dev_attr_lux0_calibscale.attr,
- &dev_attr_lux0_calibscale_default.attr,
- &dev_attr_lux0_input.attr,
- &dev_attr_lux0_sensor_range.attr,
- &dev_attr_lux0_rate.attr,
- &dev_attr_lux0_rate_avail.attr,
- &dev_attr_lux0_thresh_above_value.attr,
- &dev_attr_lux0_thresh_below_value.attr,
- &dev_attr_prox0_raw_en.attr,
- &dev_attr_prox0_raw.attr,
- &dev_attr_prox0_sensor_range.attr,
- &dev_attr_prox0_thresh_above_value.attr,
- &dev_attr_prox0_reporting_mode.attr,
- &dev_attr_prox0_reporting_mode_avail.attr,
- &dev_attr_chip_id.attr,
- &dev_attr_power_state.attr,
- NULL
-};
-
-static const struct attribute_group apds990x_attribute_group[] = {
- {.attrs = sysfs_attrs_ctrl },
-};
-
-static int apds990x_probe(struct i2c_client *client)
-{
- struct apds990x_chip *chip;
- int err;
-
- chip = kzalloc_obj(*chip);
- if (!chip)
- return -ENOMEM;
-
- i2c_set_clientdata(client, chip);
- chip->client = client;
-
- init_waitqueue_head(&chip->wait);
- mutex_init(&chip->mutex);
- chip->pdata = client->dev.platform_data;
-
- if (chip->pdata == NULL) {
- dev_err(&client->dev, "platform data is mandatory\n");
- err = -EINVAL;
- goto fail1;
- }
-
- if (chip->pdata->cf.ga == 0) {
- /* set uncovered sensor default parameters */
- chip->cf.ga = 1966; /* 0.48 * APDS_PARAM_SCALE */
- chip->cf.cf1 = 4096; /* 1.00 * APDS_PARAM_SCALE */
- chip->cf.irf1 = 9134; /* 2.23 * APDS_PARAM_SCALE */
- chip->cf.cf2 = 2867; /* 0.70 * APDS_PARAM_SCALE */
- chip->cf.irf2 = 5816; /* 1.42 * APDS_PARAM_SCALE */
- chip->cf.df = 52;
- } else {
- chip->cf = chip->pdata->cf;
- }
-
- /* precalculate inverse chip factors for threshold control */
- chip->rcf.afactor =
- (chip->cf.irf1 - chip->cf.irf2) * APDS_PARAM_SCALE /
- (chip->cf.cf1 - chip->cf.cf2);
- chip->rcf.cf1 = APDS_PARAM_SCALE * APDS_PARAM_SCALE /
- chip->cf.cf1;
- chip->rcf.irf1 = chip->cf.irf1 * APDS_PARAM_SCALE /
- chip->cf.cf1;
- chip->rcf.cf2 = APDS_PARAM_SCALE * APDS_PARAM_SCALE /
- chip->cf.cf2;
- chip->rcf.irf2 = chip->cf.irf2 * APDS_PARAM_SCALE /
- chip->cf.cf2;
-
- /* Set something to start with */
- chip->lux_thres_hi = APDS_LUX_DEF_THRES_HI;
- chip->lux_thres_lo = APDS_LUX_DEF_THRES_LO;
- chip->lux_calib = APDS_LUX_NEUTRAL_CALIB_VALUE;
-
- chip->prox_thres = APDS_PROX_DEF_THRES;
- chip->pdrive = chip->pdata->pdrive;
- chip->pdiode = APDS_PDIODE_IR;
- chip->pgain = APDS_PGAIN_1X;
- chip->prox_calib = APDS_PROX_NEUTRAL_CALIB_VALUE;
- chip->prox_persistence = APDS_DEFAULT_PROX_PERS;
- chip->prox_continuous_mode = false;
-
- chip->regs[0].supply = reg_vcc;
- chip->regs[1].supply = reg_vled;
-
- err = regulator_bulk_get(&client->dev,
- ARRAY_SIZE(chip->regs), chip->regs);
- if (err < 0) {
- dev_err(&client->dev, "Cannot get regulators\n");
- goto fail1;
- }
-
- err = regulator_bulk_enable(ARRAY_SIZE(chip->regs), chip->regs);
- if (err < 0) {
- dev_err(&client->dev, "Cannot enable regulators\n");
- goto fail2;
- }
-
- usleep_range(APDS_STARTUP_DELAY, 2 * APDS_STARTUP_DELAY);
-
- err = apds990x_detect(chip);
- if (err < 0) {
- dev_err(&client->dev, "APDS990X not found\n");
- goto fail3;
- }
-
- pm_runtime_set_active(&client->dev);
-
- apds990x_configure(chip);
- apds990x_set_arate(chip, APDS_LUX_DEFAULT_RATE);
- apds990x_mode_on(chip);
-
- pm_runtime_enable(&client->dev);
-
- if (chip->pdata->setup_resources) {
- err = chip->pdata->setup_resources();
- if (err) {
- err = -EINVAL;
- goto fail4;
- }
- }
-
- err = sysfs_create_group(&chip->client->dev.kobj,
- apds990x_attribute_group);
- if (err < 0) {
- dev_err(&chip->client->dev, "Sysfs registration failed\n");
- goto fail5;
- }
-
- err = request_threaded_irq(client->irq, NULL,
- apds990x_irq,
- IRQF_TRIGGER_FALLING | IRQF_TRIGGER_LOW |
- IRQF_ONESHOT,
- "apds990x", chip);
- if (err) {
- dev_err(&client->dev, "could not get IRQ %d\n",
- client->irq);
- goto fail6;
- }
- return err;
-fail6:
- sysfs_remove_group(&chip->client->dev.kobj,
- &apds990x_attribute_group[0]);
-fail5:
- if (chip->pdata && chip->pdata->release_resources)
- chip->pdata->release_resources();
-fail4:
- pm_runtime_disable(&client->dev);
-fail3:
- regulator_bulk_disable(ARRAY_SIZE(chip->regs), chip->regs);
-fail2:
- regulator_bulk_free(ARRAY_SIZE(chip->regs), chip->regs);
-fail1:
- kfree(chip);
- return err;
-}
-
-static void apds990x_remove(struct i2c_client *client)
-{
- struct apds990x_chip *chip = i2c_get_clientdata(client);
-
- free_irq(client->irq, chip);
- sysfs_remove_group(&chip->client->dev.kobj,
- apds990x_attribute_group);
-
- if (chip->pdata && chip->pdata->release_resources)
- chip->pdata->release_resources();
-
- if (!pm_runtime_suspended(&client->dev))
- apds990x_chip_off(chip);
-
- pm_runtime_disable(&client->dev);
- pm_runtime_set_suspended(&client->dev);
-
- regulator_bulk_free(ARRAY_SIZE(chip->regs), chip->regs);
-
- kfree(chip);
-}
-
-#ifdef CONFIG_PM_SLEEP
-static int apds990x_suspend(struct device *dev)
-{
- struct i2c_client *client = to_i2c_client(dev);
- struct apds990x_chip *chip = i2c_get_clientdata(client);
-
- apds990x_chip_off(chip);
- return 0;
-}
-
-static int apds990x_resume(struct device *dev)
-{
- struct i2c_client *client = to_i2c_client(dev);
- struct apds990x_chip *chip = i2c_get_clientdata(client);
-
- /*
- * If we were enabled at suspend time, it is expected
- * everything works nice and smoothly. Chip_on is enough
- */
- apds990x_chip_on(chip);
-
- return 0;
-}
-#endif
-
-#ifdef CONFIG_PM
-static int apds990x_runtime_suspend(struct device *dev)
-{
- struct i2c_client *client = to_i2c_client(dev);
- struct apds990x_chip *chip = i2c_get_clientdata(client);
-
- apds990x_chip_off(chip);
- return 0;
-}
-
-static int apds990x_runtime_resume(struct device *dev)
-{
- struct i2c_client *client = to_i2c_client(dev);
- struct apds990x_chip *chip = i2c_get_clientdata(client);
-
- apds990x_chip_on(chip);
- return 0;
-}
-
-#endif
-
-static const struct i2c_device_id apds990x_id[] = {
- { "apds990x" },
- {}
-};
-
-MODULE_DEVICE_TABLE(i2c, apds990x_id);
-
-static const struct dev_pm_ops apds990x_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(apds990x_suspend, apds990x_resume)
- SET_RUNTIME_PM_OPS(apds990x_runtime_suspend,
- apds990x_runtime_resume,
- NULL)
-};
-
-static struct i2c_driver apds990x_driver = {
- .driver = {
- .name = "apds990x",
- .pm = &apds990x_pm_ops,
- },
- .probe = apds990x_probe,
- .remove = apds990x_remove,
- .id_table = apds990x_id,
-};
-
-module_i2c_driver(apds990x_driver);
-
-MODULE_DESCRIPTION("APDS990X combined ALS and proximity sensor");
-MODULE_AUTHOR("Samu Onkalo, Nokia Corporation");
-MODULE_LICENSE("GPL v2");
diff --git a/include/linux/platform_data/apds990x.h b/include/linux/platform_data/apds990x.h
deleted file mode 100644
index 37684f68c04f..000000000000
--- a/include/linux/platform_data/apds990x.h
+++ /dev/null
@@ -1,65 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * This file is part of the APDS990x sensor driver.
- * Chip is combined proximity and ambient light sensor.
- *
- * Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
- *
- * Contact: Samu Onkalo <samu.p.onkalo@nokia.com>
- */
-
-#ifndef __APDS990X_H__
-#define __APDS990X_H__
-
-
-#define APDS_IRLED_CURR_12mA 0x3
-#define APDS_IRLED_CURR_25mA 0x2
-#define APDS_IRLED_CURR_50mA 0x1
-#define APDS_IRLED_CURR_100mA 0x0
-
-/**
- * struct apds990x_chip_factors - defines effect of the cover window
- * @ga: Total glass attenuation
- * @cf1: clear channel factor 1 for raw to lux conversion
- * @irf1: IR channel factor 1 for raw to lux conversion
- * @cf2: clear channel factor 2 for raw to lux conversion
- * @irf2: IR channel factor 2 for raw to lux conversion
- * @df: device factor for conversion formulas
- *
- * Structure for tuning ALS calculation to match with environment.
- * Values depend on the material above the sensor and the sensor
- * itself. If the GA is zero, driver will use uncovered sensor default values
- * format: decimal value * APDS_PARAM_SCALE except df which is plain integer.
- */
-struct apds990x_chip_factors {
- int ga;
- int cf1;
- int irf1;
- int cf2;
- int irf2;
- int df;
-};
-#define APDS_PARAM_SCALE 4096
-
-/**
- * struct apds990x_platform_data - platform data for apsd990x.c driver
- * @cf: chip factor data
- * @pdrive: IR-led driving current
- * @ppcount: number of IR pulses used for proximity estimation
- * @setup_resources: interrupt line setup call back function
- * @release_resources: interrupt line release call back function
- *
- * Proximity detection result depends heavily on correct ppcount, pdrive
- * and cover window.
- *
- */
-
-struct apds990x_platform_data {
- struct apds990x_chip_factors cf;
- u8 pdrive;
- u8 ppcount;
- int (*setup_resources)(void);
- int (*release_resources)(void);
-};
-
-#endif
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] docs: Add overview and SLUB allocator sections to slab documentation
From: David Hildenbrand (Arm) @ 2026-04-19 8:35 UTC (permalink / raw)
To: Matthew Wilcox, Lorenzo Stoakes
Cc: Nick Huang, Vlastimil Babka, Harry Yoo, Andrew Morton,
Jonathan Corbet, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, linux-mm, linux-doc,
linux-kernel
In-Reply-To: <aeOuCH8ydw_yzdXZ@casper.infradead.org>
On 4/18/26 18:15, Matthew Wilcox wrote:
> On Sat, Apr 18, 2026 at 10:07:22AM +0100, Lorenzo Stoakes wrote:
>> On Sat, Apr 18, 2026 at 12:06:19AM +0000, Nick Huang wrote:
>>> - Add "Overview" section explaining the slab allocator's role and purpose
>>> - Document the three main slab allocator implementations (SLAB, SLUB, SLOB)
>>
>> The fact you're insanely wrong about the current state of slab only makes this
>> worse.
>
> This is actually a new low. We've always had to contend with people
> putting up outdated or just wrong information on web pages, and there's
> little we can do about it. Witness all the outdated information about
> THP that's based on code that's been deleted for over a decade.
>
> But now we've got AI trained on all this wrong/ out of date information,
> and, er, "enthusiasts" who are trying to change the correct information
> in the kernel to match what the deluded AI "thinks" should be true.
>
> Let that sink in.
>
I think we should make it very clear that we don't want doc updates from someone
that is not a renowned expert in that area or wants to become an expert in that
area (and already discussed working on the docs with maintainers/experts).
Otherwise we'll have this same discussion over and over again.
diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
index 7aa2a88869083..8c5721001c8bb 100644
--- a/Documentation/mm/index.rst
+++ b/Documentation/mm/index.rst
@@ -7,6 +7,11 @@ of Linux. If you are looking for advice on simply allocating
memory,
see the :ref:`memory_allocation`. For controlling and tuning guides,
see the :doc:`admin guide <../admin-guide/mm/index>`.
+A lot of documentation in this guide is still incomplete. If you are not
+a renowned expert in the specific area, but you want to contribute bigger
+chunks of documentation, talk to the respective MM experts first. LLM
+generated slop from non-experts will be rejected without further comments.
+
.. toctree::
:maxdepth: 1
LLMs are just the tip of the iceberg. It will all be developmend-by review with
inexperienced contributors. And we are only willing to put in the effort to
teach contributors if the contributors are not actually worth our time: i.e.,
LLM kiddies that will actually stick around and help the subsystem in the long run.
The whole doc update stuff is similar to people just grepping for TODOs in the
kernel and then using an LLM to produce code they have no idea about.
It's the evolution of typo fixes: review load without any benefit.
--
Cheers,
David
^ permalink raw reply related
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Greg Kroah-Hartman @ 2026-04-19 8:42 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Randy Dunlap, linux-iio, devicetree,
linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-4-clamor95@gmail.com>
On Sun, Apr 19, 2026 at 11:31:24AM +0300, Svyatoslav Ryhel wrote:
> The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> IIO driver so there is no need to keep this old implementation. Remove it.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> Documentation/misc-devices/apds990x.rst | 128 ---
> drivers/misc/Kconfig | 10 -
> drivers/misc/Makefile | 1 -
> drivers/misc/apds990x.c | 1284 -----------------------
> include/linux/platform_data/apds990x.h | 65 --
> 5 files changed, 1488 deletions(-)
> delete mode 100644 Documentation/misc-devices/apds990x.rst
> delete mode 100644 drivers/misc/apds990x.c
> delete mode 100644 include/linux/platform_data/apds990x.h
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
From: Jonathan Corbet @ 2026-04-19 10:29 UTC (permalink / raw)
To: Manuel Ebner, Shuah Khan, linux-doc
Cc: lrcu, linux-kernel, workflows, linux-sound, rcu, linux-media,
Manuel Ebner, Kees Cook
In-Reply-To: <20260419065824.165921-4-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> Update the documentation to reflect new type-aware kmalloc-family as
> suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and family")
>
> ptr = kmalloc(sizeof(*ptr), gfp);
> -> ptr = kmalloc_obj(*ptr, gfp);
> ptr = kmalloc(sizeof(struct some_obj_name), gfp);
> -> ptr = kmalloc_obj(*ptr, gfp);
> ptr = kzalloc(sizeof(*ptr), gfp);
> -> ptr = kzalloc_obj(*ptr, gfp);
> ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> -> ptr = kmalloc_objs(*ptr, count, gfp);
> ptr = kcalloc(count, sizeof(*ptr), gfp);
> -> ptr = kzalloc_objs(*ptr, count, gfp);
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Just to be sure, did you write this patch yourself, or did you use some
sort of coding assistant?
Adding Kees, who did this work and might have something to add here.
> ---
> .../RCU/Design/Requirements/Requirements.rst | 6 +++---
> Documentation/RCU/listRCU.rst | 2 +-
> Documentation/RCU/whatisRCU.rst | 4 ++--
This patch will surely need to be split up; the RCU folks, for example,
will want to evaluate the change separately.
> Documentation/core-api/kref.rst | 4 ++--
> Documentation/core-api/list.rst | 4 ++--
> Documentation/core-api/memory-allocation.rst | 4 ++--
> Documentation/driver-api/mailbox.rst | 4 ++--
> Documentation/driver-api/media/v4l2-fh.rst | 2 +-
> Documentation/kernel-hacking/locking.rst | 4 ++--
> Documentation/locking/locktypes.rst | 4 ++--
> Documentation/process/coding-style.rst | 8 ++++----
> .../sound/kernel-api/writing-an-alsa-driver.rst | 12 ++++++------
> Documentation/spi/spi-summary.rst | 4 ++--
> .../translations/it_IT/kernel-hacking/locking.rst | 4 ++--
> .../translations/it_IT/locking/locktypes.rst | 4 ++--
> .../translations/it_IT/process/coding-style.rst | 2 +-
> .../translations/sp_SP/process/coding-style.rst | 2 +-
> Documentation/translations/zh_CN/core-api/kref.rst | 4 ++--
> .../translations/zh_CN/process/coding-style.rst | 2 +-
> .../zh_CN/video4linux/v4l2-framework.txt | 2 +-
> .../translations/zh_TW/process/coding-style.rst | 2 +-
> 21 files changed, 42 insertions(+), 42 deletions(-)
>
> diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
> index b5cdbba3ec2e..faca5a9c8c12 100644
> --- a/Documentation/RCU/Design/Requirements/Requirements.rst
> +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
> @@ -206,7 +206,7 @@ non-\ ``NULL``, locklessly accessing the ``->a`` and ``->b`` fields.
>
> 1 bool add_gp_buggy(int a, int b)
> 2 {
> - 3 p = kmalloc(sizeof(*p), GFP_KERNEL);
> + 3 p = kmalloc_obj(*p, GFP_KERNEL);
So you have not gone with the "implicit GFP_KERNEL" approach that Linus
added. Given that, I assume, he wanted that to be the normal style, we
should probably go with it.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 11:29 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-3-clamor95@gmail.com>
On Sun, 19 Apr 2026 11:31:23 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> just add the correct bindings and the appropriate LUX table derived from
> the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Hi Svyatoslav,
Just one small thing.
Experience has given me a strong aversion to the use of wildcards
in naming within drivers. They go wrong too often because companies
can seem to resist using similar names for very different parts.
> ---
> drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> index c8f15ba95267..8dab34bf00ca 100644
> --- a/drivers/iio/light/tsl2772.c
> +++ b/drivers/iio/light/tsl2772.c
> @@ -127,6 +127,7 @@ enum {
> tmd2672,
> tsl2772,
> tmd2772,
> + apds990x,
As above, just name this after one of the supported parts. apds9900
That doesn't stop you using it for multiple compatible devices.
Same applies for all the uses of x as a wildcard.
thanks,
Jonathan
> apds9930,
> };
^ permalink raw reply
* Re: [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
From: Manuel Ebner @ 2026-04-19 11:33 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, linux-doc
Cc: lrcu, linux-kernel, workflows, linux-sound, rcu, linux-media,
Kees Cook
In-Reply-To: <87se8rw8df.fsf@trenco.lwn.net>
On Sun, 2026-04-19 at 04:29 -0600, Jonathan Corbet wrote:
> Manuel Ebner <manuelebner@mailbox.org> writes:
>
> > Update the documentation to reflect new type-aware kmalloc-family as
> > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and
> > family")
> >
> > ptr = kmalloc(sizeof(*ptr), gfp);
> > -> ptr = kmalloc_obj(*ptr, gfp);
> > ptr = kmalloc(sizeof(struct some_obj_name), gfp);
> > -> ptr = kmalloc_obj(*ptr, gfp);
> > ptr = kzalloc(sizeof(*ptr), gfp);
> > -> ptr = kzalloc_obj(*ptr, gfp);
> > ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> > -> ptr = kmalloc_objs(*ptr, count, gfp);
> > ptr = kcalloc(count, sizeof(*ptr), gfp);
> > -> ptr = kzalloc_objs(*ptr, count, gfp);
> >
> > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
>
> Just to be sure, did you write this patch yourself, or did you use some
> sort of coding assistant?
I wrote the patch myself.
> Adding Kees, who did this work and might have something to add here.
Thanks.
> > ---
> > .../RCU/Design/Requirements/Requirements.rst | 6 +++---
> > Documentation/RCU/listRCU.rst | 2 +-
> > Documentation/RCU/whatisRCU.rst | 4 ++--
>
> This patch will surely need to be split up; the RCU folks, for example,
> will want to evaluate the change separately.
will do that in [v2]
>
> > Documentation/core-api/kref.rst | 4 ++--
> > Documentation/core-api/list.rst | 4 ++--
> > Documentation/core-api/memory-allocation.rst | 4 ++--
> > Documentation/driver-api/mailbox.rst | 4 ++--
> > Documentation/driver-api/media/v4l2-fh.rst | 2 +-
> > Documentation/kernel-hacking/locking.rst | 4 ++--
> > Documentation/locking/locktypes.rst | 4 ++--
> > Documentation/process/coding-style.rst | 8 ++++----
> > .../sound/kernel-api/writing-an-alsa-driver.rst | 12 ++++++------
> > Documentation/spi/spi-summary.rst | 4 ++--
> > .../translations/it_IT/kernel-hacking/locking.rst | 4 ++--
> > .../translations/it_IT/locking/locktypes.rst | 4 ++--
> > .../translations/it_IT/process/coding-style.rst | 2 +-
> > .../translations/sp_SP/process/coding-style.rst | 2 +-
> > Documentation/translations/zh_CN/core-api/kref.rst | 4 ++--
> > .../translations/zh_CN/process/coding-style.rst | 2 +-
> > .../zh_CN/video4linux/v4l2-framework.txt | 2 +-
> > .../translations/zh_TW/process/coding-style.rst | 2 +-
> > 21 files changed, 42 insertions(+), 42 deletions(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst
> > b/Documentation/RCU/Design/Requirements/Requirements.rst
> > index b5cdbba3ec2e..faca5a9c8c12 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.rst
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
> > @@ -206,7 +206,7 @@ non-\ ``NULL``, locklessly accessing the ``->a`` and ``-
> > >b`` fields.
> >
> > 1 bool add_gp_buggy(int a, int b)
> > 2 {
> > - 3 p = kmalloc(sizeof(*p), GFP_KERNEL);
> > + 3 p = kmalloc_obj(*p, GFP_KERNEL);
>
> So you have not gone with the "implicit GFP_KERNEL" approach that Linus
> added. Given that, I assume, he wanted that to be the normal style, we
> should probably go with it.
I scanned those 8 replies by Linus, but i can't figure out what you mean with
implicit GFP_Kernel approach, can you give me a hint?
https://lore.kernel.org/all/?q=slab%3A+Introduce+kmalloc_obj%28%29+and+family+f%3Atorvalds
> Thanks,
>
> jon
Thanks,
manuel
^ permalink raw reply
* Re: [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
From: Jonathan Corbet @ 2026-04-19 11:43 UTC (permalink / raw)
To: Manuel Ebner, Shuah Khan, linux-doc
Cc: lrcu, linux-kernel, workflows, linux-sound, rcu, linux-media,
Kees Cook
In-Reply-To: <295490d9bd8b9d519dda5c4551e7dbaf36492a8a.camel@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
>> So you have not gone with the "implicit GFP_KERNEL" approach that Linus
>> added. Given that, I assume, he wanted that to be the normal style, we
>> should probably go with it.
>
> I scanned those 8 replies by Linus, but i can't figure out what you mean with
> implicit GFP_Kernel approach, can you give me a hint?
>
> https://lore.kernel.org/all/?q=slab%3A+Introduce+kmalloc_obj%28%29+and+family+f%3Atorvalds
See https://lwn.net/Articles/1062856/
jon
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 11:50 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419122950.67355f4c@jic23-huawei>
нд, 19 квіт. 2026 р. о 14:30 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 11:31:23 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> > just add the correct bindings and the appropriate LUX table derived from
> > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Hi Svyatoslav,
>
> Just one small thing.
>
> Experience has given me a strong aversion to the use of wildcards
> in naming within drivers. They go wrong too often because companies
> can seem to resist using similar names for very different parts.
>
Noted.
> > ---
> > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > index c8f15ba95267..8dab34bf00ca 100644
> > --- a/drivers/iio/light/tsl2772.c
> > +++ b/drivers/iio/light/tsl2772.c
> > @@ -127,6 +127,7 @@ enum {
> > tmd2672,
> > tsl2772,
> > tmd2772,
> > + apds990x,
>
> As above, just name this after one of the supported parts. apds9900
> That doesn't stop you using it for multiple compatible devices.
>
> Same applies for all the uses of x as a wildcard.
>
If this is the only thing keeping you from picking this patchset may I
resend with apds990x fixed right away?
> thanks,
>
> Jonathan
>
> > apds9930,
> > };
>
^ permalink raw reply
* htmldocs: Documentation/iio/ad9910.rst:451: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
From: kernel test robot @ 2026-04-19 12:24 UTC (permalink / raw)
To: Rodrigo Alencar; +Cc: oe-kbuild-all, 0day robot, linux-doc
tree: https://github.com/intel-lab-lkp/linux/commits/Rodrigo-Alencar-via-B4-Relay/dt-bindings-iio-frequency-add-ad9910/20260419-104913
head: 5ac9bfbe149f0815ff3156530d694c8c4a39dc75
commit: 5ac9bfbe149f0815ff3156530d694c8c4a39dc75 docs: iio: add documentation for ad9910 driver
date: 9 hours ago
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260419/202604191436.eNqraDV2-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604191436.eNqraDV2-lkp@intel.com/
All warnings (new ones prefixed by >>):
Runtime Survivability
===================== [docutils]
Documentation/iio/ad9910.rst:444: ERROR: Unexpected indentation. [docutils]
Documentation/iio/ad9910.rst:447: ERROR: Unexpected indentation. [docutils]
>> Documentation/iio/ad9910.rst:451: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/iio/ad9910.rst:452: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/iio/ad9910.rst:459: ERROR: Unexpected indentation. [docutils]
Documentation/mm/memfd_preservation:7: ./mm/memfd_luo.c:13: ERROR: Unexpected section title.
vim +451 Documentation/iio/ad9910.rst
440
441 - 72-byte header:
442 - 4-byte big-endian word count: number of 32-bit words to be loaded (0-1024)
443 - 4-byte big-endian CFR1 value: configuration for the CFR1 register. Only
444 bits relevant to RAM mode (data destination and internal profile control)
445 are considered. Other bits are ignored and have no effect.
446 - Bits [30:29]: RAM data destination:
447 - 00: frequency
448 - 01: phase
449 - 10: amplitude
450 - 11: polar
> 451 - Bits [20:17]: Internal profile control (see Table 14 of the datasheet).
452 - 8 sets of 8-byte big-endian profile data for profiles 0-7. Each set contains:
453 - Bits [55:40]: Address step rate value
454 - Bits [39:30]: End address for the profile
455 - Bits [23:14]: Start address for the profile
456 - Bit [5]: no-dwell high for ramp-up mode
457 - Bit [3]: zero-crossing for direct-switch mode
458 - Bits [2:0]: operating mode:
459 - 000: direct switch
460 - 001: ramp-up
461 - 010: bidirectional
462 - 011: bidirectional continuous
463 - 100: ramp-up continuous
464 - Followed by the specified number of 32-bit big-endian data words.
465
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] docs: Add overview and SLUB allocator sections to slab documentation
From: Lorenzo Stoakes @ 2026-04-19 13:17 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Matthew Wilcox, Nick Huang, Vlastimil Babka, Harry Yoo,
Andrew Morton, Jonathan Corbet, Hao Li, Christoph Lameter,
David Rientjes, Roman Gushchin, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, linux-mm, linux-doc,
linux-kernel
In-Reply-To: <c113f667-f897-42cc-a0e5-b8a0bbd91be3@kernel.org>
On Sun, Apr 19, 2026 at 10:35:44AM +0200, David Hildenbrand (Arm) wrote:
> On 4/18/26 18:15, Matthew Wilcox wrote:
> > On Sat, Apr 18, 2026 at 10:07:22AM +0100, Lorenzo Stoakes wrote:
> >> On Sat, Apr 18, 2026 at 12:06:19AM +0000, Nick Huang wrote:
> >>> - Add "Overview" section explaining the slab allocator's role and purpose
> >>> - Document the three main slab allocator implementations (SLAB, SLUB, SLOB)
> >>
> >> The fact you're insanely wrong about the current state of slab only makes this
> >> worse.
> >
> > This is actually a new low. We've always had to contend with people
> > putting up outdated or just wrong information on web pages, and there's
> > little we can do about it. Witness all the outdated information about
> > THP that's based on code that's been deleted for over a decade.
> >
> > But now we've got AI trained on all this wrong/ out of date information,
> > and, er, "enthusiasts" who are trying to change the correct information
> > in the kernel to match what the deluded AI "thinks" should be true.
> >
> > Let that sink in.
Ugh ye gawds. My attitude is nip this in the bud early.
I'm very harsh in response to these things for a reason - firstly, it's rude,
obnoxious + disrespectful, so a negative response is wholly appropriate.
But more importantly, I want to SET A PRECEDENT that if you send this crap
you'll get a VERY negative response.
Clueless but good faith or bad faith - it's straight up plagiarism and that's
totally unacceptable.
> >
>
> I think we should make it very clear that we don't want doc updates from someone
> that is not a renowned expert in that area or wants to become an expert in that
> area (and already discussed working on the docs with maintainers/experts).
>
> Otherwise we'll have this same discussion over and over again.
>
> diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
> index 7aa2a88869083..8c5721001c8bb 100644
> --- a/Documentation/mm/index.rst
> +++ b/Documentation/mm/index.rst
> @@ -7,6 +7,11 @@ of Linux. If you are looking for advice on simply allocating
> memory,
> see the :ref:`memory_allocation`. For controlling and tuning guides,
> see the :doc:`admin guide <../admin-guide/mm/index>`.
>
> +A lot of documentation in this guide is still incomplete. If you are not
> +a renowned expert in the specific area, but you want to contribute bigger
> +chunks of documentation, talk to the respective MM experts first. LLM
> +generated slop from non-experts will be rejected without further comments.
> +
> .. toctree::
> :maxdepth: 1
>
>
>
> LLMs are just the tip of the iceberg. It will all be developmend-by review with
> inexperienced contributors. And we are only willing to put in the effort to
> teach contributors if the contributors are not actually worth our time: i.e.,
> LLM kiddies that will actually stick around and help the subsystem in the long run.
>
>
> The whole doc update stuff is similar to people just grepping for TODOs in the
> kernel and then using an LLM to produce code they have no idea about.
>
> It's the evolution of typo fixes: review load without any benefit.
Agree with all of that!
Let's do that, happy to give tags on a patch for the above :)
>
> --
> Cheers,
>
> David
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] docs/zh_CN: polish how-to.rst
From: Alex Shi @ 2026-04-19 13:28 UTC (permalink / raw)
To: Dongliang Mu, Alex Shi, Yanteng Si, Jonathan Corbet, Shuah Khan
Cc: linux-doc, linux-kernel
In-Reply-To: <20260418091014.2064780-1-dzm91@hust.edu.cn>
Applied thanks!
On 2026/4/18 17:10, Dongliang Mu wrote:
> Editorial pass on the Chinese translation contributor guide.
>
> - Fix typos: 网络通常 → 通畅; remove trailing backticks on the
> checktransupdate.py command; mis-placed 。 → ， in the 紧急处理
> section; 您/你 and 的/地 inconsistencies in 进阶.
> - Correct "git email" to "git send-email", matching usage
> elsewhere in the document.
> - Replace an invalid <URL> inline form with a bare URL so Sphinx
> renders the lore.kernel.org link.
> - Tighten grammar and wording: 针对于 → 面向; drop redundant
> 最多 before 不超过 and tautological 即可; remove double 的 in
> 您的翻译的内容; resolve ambiguity around 继续 placement in the
> 把补丁提交到邮件列表 section; and similar small fixes.
>
> Assisted-by:Claude:claude-opus-4-6
> Signed-off-by: Dongliang Mu<dzm91@hust.edu.cn>
> ---
> Documentation/translations/zh_CN/how-to.rst | 46 ++++++++++-----------
> 1 file changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/translations/zh_CN/how-to.rst b/Documentation/translations/zh_CN/how-to.rst
> index 7ae5d8765888..a46d7395b11c 100644
> --- a/Documentation/translations/zh_CN/how-to.rst
> +++ b/Documentation/translations/zh_CN/how-to.rst
> @@ -13,20 +13,20 @@ Linux 内核中文文档翻译规范
> 过去几年，在广大社区爱好者的友好合作下，Linux 内核中文文档迎来了蓬勃的发
> 展。在翻译的早期，一切都是混乱的，社区对译稿只有一个准确翻译的要求，以鼓
> 励更多的开发者参与进来，这是从 0 到 1 的必然过程，所以早期的中文文档目录
> -更加具有多样性，不过好在文档不多，维护上并没有过大的压力。
> +呈现出较强的多样性，不过好在文档不多，维护上并没有过大的压力。
>
> 然而，世事变幻，不觉有年，现在内核中文文档在前进的道路上越走越远，很多潜
> 在的问题逐渐浮出水面，而且随着中文文档数量的增加，翻译更多的文档与提高中
> 文文档可维护性之间的矛盾愈发尖锐。由于文档翻译的特殊性，很多开发者并不会
> 一直更新文档，如果中文文档落后英文文档太多，文档更新的工作量会远大于重新
> 翻译。而且邮件列表中陆续有新的面孔出现，他们那股热情，就像燃烧的火焰，能
> -瞬间点燃整个空间，可是他们的补丁往往具有个性，这会给审阅带来了很大的困难，
> +瞬间点燃整个空间，可是他们的补丁往往具有个性，这给审阅带来了很大的困难，
> reviewer 们只能耐心地指导他们如何与社区更好地合作，但是这项工作具有重复
> 性，长此以往，会渐渐浇灭 reviewer 审阅的热情。
>
> -虽然内核文档中已经有了类似的贡献指南，但是缺乏专门针对于中文翻译的，尤其
> +虽然内核文档中已经有了类似的贡献指南，但是缺乏专门面向中文翻译的，尤其
> 是对于新手来说，浏览大量的文档反而更加迷惑，该文档就是为了缓解这一问题而
> -编写，目的是为提供给新手一个快速翻译指南。
> +编写，旨在为新手提供一份快速翻译指南。
>
> 详细的贡献指南：Documentation/translations/zh_CN/process/index.rst。
>
> @@ -145,8 +145,8 @@ Git 和邮箱配置
> sudo dnf install git-email
> vim ~/.gitconfig
>
> -这里是我的一个配置文件示范，请根据您的邮箱域名服务商提供的手册替换到对
> -应的字段。
> +这里是我的一个配置文件示范，请根据您的邮箱域名服务商提供的手册替换对应
> +的字段。
> ::
>
> [user]
> @@ -190,7 +190,7 @@ Git 和邮箱配置
> 译文格式要求
> ------------
>
> - - 每行长度最多不超过 40 个字符
> + - 每行长度不超过 40 个字符
> - 每行长度请保持一致
> - 标题的下划线长度请按照一个英文一个字符、一个中文两个字符与标题对齐
> - 其它的修饰符请与英文文档保持一致
> @@ -211,7 +211,7 @@ Git 和邮箱配置
> --------
>
> 中文文档有每行 40 字符限制，因为一个中文字符等于 2 个英文字符。但是社区并
> -没有那么严格，一个诀窍是将您的翻译的内容与英文原文的每行长度对齐即可，这样，
> +没有那么严格，一个诀窍是将您翻译的内容与英文原文的每行长度对齐，这样，
> 您也不必总是检查有没有超限。
>
> 如果您的英文阅读能力有限，可以考虑使用辅助翻译工具，例如 deepseek。但是您
> @@ -309,8 +309,8 @@ warning 不需要解决::
>
> 重新导出再次检测，重复这个过程，直到处理完所有的补丁。
>
> -最后，如果检测时没有 warning 和 error 需要被处理或者您只有一个补丁，请跳
> -过下面这个步骤，否则请重新导出补丁制作封面::
> +最后，如果检测时没有需要处理的 warning 和 error，或者您只有一个补丁，请
> +跳过下面这个步骤，否则请重新导出补丁制作封面::
>
> git format-patch -N --cover-letter --thread=shallow
> # N 要替换为补丁数量，一般 N 大于 1
> @@ -335,7 +335,7 @@ warning 不需要解决::
> docs/zh_CN: add xxxxx
> ...
>
> -如果您只有一个补丁，则可以不制作封面，即 0 号补丁，只需要执行::
> +如果您只有一个补丁，则无需制作封面（即 0 号补丁），只需执行::
>
> git format-patch -1
>
> @@ -361,13 +361,13 @@ warning 不需要解决::
> git send-email *.patch --to <maintainer email addr> --cc <others addr>
> # 一个 to 对应一个地址，一个 cc 对应一个地址，有几个就写几个
>
> -执行该命令时，请确保网络通常，邮件发送成功一般会返回 250。
> +执行该命令时，请确保网络通畅，邮件发送成功一般会返回 250。
>
> 您可以先发送给自己，尝试发出的 patch 是否可以用 'git am' 工具正常打上。
> 如果检查正常， 您就可以放心的发送到社区评审了。
>
> -如果该步骤被中断，您可以检查一下，继续用上条命令发送失败的补丁，一定不要再
> -次发送已经发送成功的补丁。
> +如果该步骤被中断，您可以检查一下，然后用上条命令继续发送失败的补丁，一定不
> +要再次发送已经发送成功的补丁。
>
> 积极参与审阅过程并迭代补丁
> ==========================
> @@ -380,7 +380,7 @@ reviewer 的评论，做到每条都有回复，每个回复都落实到位。
>
> - 请先将您的邮箱客户端信件回复修改为 **纯文本** 格式，并去除所有签名，尤其是
> 企业邮箱。
> - - 然后点击回复按钮，并将要回复的邮件带入，
> + - 然后点击回复按钮，并引用要回复的邮件，
> - 在第一条评论行尾换行，输入您的回复
> - 在第二条评论行尾换行，输入您的回复
> - 直到处理完最后一条评论，换行空两行输入问候语和署名
> @@ -425,10 +425,10 @@ reviewer 的评论，做到每条都有回复，每个回复都落实到位。
> 紧急处理
> --------
>
> -如果您发送到邮件列表之后。发现发错了补丁集，尤其是在多个版本迭代的过程中；
> +如果您发送到邮件列表之后，发现发错了补丁集，尤其是在多个版本迭代的过程中；
> 自己发现了一些不妥的翻译；发送错了邮件列表……
>
> -git email 默认会抄送给您一份，所以您可以切换为审阅者的角色审查自己的补丁，
> +git send-email 默认会抄送给您一份，所以您可以切换为审阅者的角色审查自己的补丁，
> 并留下评论，描述有何不妥，将在下个版本怎么改，并付诸行动，重新提交，但是
> 注意频率，每天提交的次数不要超过两次。
>
> @@ -437,7 +437,7 @@ git email 默认会抄送给您一份，所以您可以切换为审阅者的角
> 对于首次参与 Linux 内核中文文档翻译的新手，建议您在 linux 目录中运行以下命令：
> ::
>
> - tools/docs/checktransupdate.py -l zh_CN``
> + tools/docs/checktransupdate.py -l zh_CN
>
> 该命令会列出需要翻译或更新的英文文档，结果同时保存在 checktransupdate.log 中。
>
> @@ -446,9 +446,9 @@ git email 默认会抄送给您一份，所以您可以切换为审阅者的角
> 进阶
> ----
>
> -希望您不只是单纯的翻译内核文档，在熟悉了一起与社区工作之后，您可以审阅其他
> +希望您不只是单纯地翻译内核文档，在熟悉了与社区协作之后，您可以审阅其他
> 开发者的翻译，或者提出具有建设性的主张。与此同时，与文档对应的代码更加有趣，
> -而且需要完善的地方还有很多，勇敢地去探索，然后提交你的想法吧。
> +而且需要完善的地方还有很多，勇敢地去探索，然后提交您的想法吧。
>
> 常见的问题
> ==========
> @@ -467,7 +467,7 @@ Maintainer 回复补丁不能正常 apply
> ------------------
>
> 大部分情况下，是由于您发送了非纯文本格式的信件，请尽量避免使用 webmail，推荐
> -使用邮件客户端，比如 thunderbird，记得在设置中的回信配置那改为纯文本发送。
> +使用邮件客户端，比如 thunderbird，记得在设置的回信配置中改为纯文本发送。
>
> -如果超过了 24 小时，您依旧没有在<https://lore.kernel.org/linux-doc/>发现您的
> -邮件，请联系您的网络管理员帮忙解决。
> +如果超过了 24 小时，您依旧没有在https://lore.kernel.org/linux-doc/ 上找到您
> +的邮件，请联系您的网络管理员帮忙解决。
> -- 2.43.0
>
^ permalink raw reply
* Re: [PATCH] docs/zh_CN: add --no-merges to git log example in how-to.rst
From: Alex Shi @ 2026-04-19 13:32 UTC (permalink / raw)
To: Ben Guo, Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet
Cc: linux-doc, linux-kernel, hust-os-kernel-patches
In-Reply-To: <20260416042647.3646595-1-ben.guo@openatom.club>
Applied thanks!
On 2026/4/16 12:26, Ben Guo wrote:
> Add --no-merges flag to prevent referencing merge commits in the
> through-commit field of translation commit messages.
>
> Signed-off-by: Ben Guo<ben.guo@openatom.club>
> ---
> Documentation/translations/zh_CN/how-to.rst | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/translations/zh_CN/how-to.rst b/Documentation/translations/zh_CN/how-to.rst
> index 7ae5d876588..39ed7054fa3 100644
> --- a/Documentation/translations/zh_CN/how-to.rst
> +++ b/Documentation/translations/zh_CN/how-to.rst
> @@ -257,7 +257,9 @@ Git 和邮箱配置
>
> Update the translation through commit b080e52110ea
> ("docs: update self-protection __ro_after_init status")
> - # 请执行 git log --oneline <您翻译的英文文档路径>，并替换上述内容
> + # 请执行 git log --no-merges --oneline <您翻译的英文文档路径>
> + # 并替换上述内容。注意：应引用实际修改文件内容的 commit，
> + # 而非 merge commit
>
> Signed-off-by: Yanteng Si<si.yanteng@linux.dev>
> # 如果您前面的步骤正确执行，该行会自动显示，否则请检查 gitconfig 文件
> -- 2.53.0
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Jonathan Cameron @ 2026-04-19 13:33 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-4-clamor95@gmail.com>
On Sun, 19 Apr 2026 11:31:24 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> IIO driver so there is no need to keep this old implementation. Remove it.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> Documentation/misc-devices/apds990x.rst | 128 ---
Sashiko AI reviewing is now running on anything that hits linux-iio@vger.kernel.org
I'm slowly getting into the habit of checking out what it finds though
I'm 500+ emails behind so it might not be that thorough today :*
Anyhow, it caught an easy one here.
This file is referenced from Documentation/misc-devices/index.rst
so that needs an update as well.
There is the obvious point of ABI compatibility raised as well, but given
we don't seem to be getting much push back on that maybe that's not a significant
concern.
Jonathan
> drivers/misc/Kconfig | 10 -
> drivers/misc/Makefile | 1 -
> drivers/misc/apds990x.c | 1284 -----------------------
> include/linux/platform_data/apds990x.h | 65 --
> 5 files changed, 1488 deletions(-)
> delete mode 100644 Documentation/misc-devices/apds990x.rst
> delete mode 100644 drivers/misc/apds990x.c
> delete mode 100644 include/linux/platform_data/apds990x.h
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 13:37 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-3-clamor95@gmail.com>
On Sun, 19 Apr 2026 11:31:23 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
A Sashiko review comment makes me wonder about one thing below if the
register set does match. Maybe it's a bit more subtle than this
patch description suggests?
> just add the correct bindings and the appropriate LUX table derived from
> the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> index c8f15ba95267..8dab34bf00ca 100644
> --- a/drivers/iio/light/tsl2772.c
> +++ b/drivers/iio/light/tsl2772.c
> @@ -127,6 +127,7 @@ enum {
> tmd2672,
> tsl2772,
> tmd2772,
> + apds990x,
> apds9930,
> };
>
> @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> { 0, 0 },
> };
>
> +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> + { 52000, 115960 },
> + { 36400, 73840 },
> + { 0, 0 },
> +};
> +
> static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> { 52000, 96824 },
> { 38792, 67132 },
> @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> [tmd2672] = tmd2x72_lux_table,
> [tsl2772] = tsl2x72_lux_table,
> [tmd2772] = tmd2x72_lux_table,
> + [apds990x] = apds990x_lux_table,
> [apds9930] = apds9930_lux_table,
> };
>
> @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> };
>
> @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> [tmd2672] = PRX2,
> [tsl2772] = ALSPRX2,
> [tmd2772] = ALSPRX2,
> + [apds990x] = ALSPRX,
This is different from tsl2772?
> [apds9930] = ALSPRX2,
> };
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Svyatoslav Ryhel @ 2026-04-19 13:41 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419143346.45ed78c2@jic23-huawei>
нд, 19 квіт. 2026 р. о 16:33 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 11:31:24 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> > IIO driver so there is no need to keep this old implementation. Remove it.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > Documentation/misc-devices/apds990x.rst | 128 ---
> Sashiko AI reviewing is now running on anything that hits linux-iio@vger.kernel.org
>
> I'm slowly getting into the habit of checking out what it finds though
> I'm 500+ emails behind so it might not be that thorough today :*
>
> Anyhow, it caught an easy one here.
>
> This file is referenced from Documentation/misc-devices/index.rst
> so that needs an update as well.
>
Good catch, index was not updated, I will do so in v3.
> There is the obvious point of ABI compatibility raised as well, but given
> we don't seem to be getting much push back on that maybe that's not a significant
> concern.
I did not found any ABI in the Documentation/ABI regarding this sensor
using grep, maybe you are more familiar?
>
> Jonathan
>
> > drivers/misc/Kconfig | 10 -
> > drivers/misc/Makefile | 1 -
> > drivers/misc/apds990x.c | 1284 -----------------------
> > include/linux/platform_data/apds990x.h | 65 --
> > 5 files changed, 1488 deletions(-)
> > delete mode 100644 Documentation/misc-devices/apds990x.rst
> > delete mode 100644 drivers/misc/apds990x.c
> > delete mode 100644 include/linux/platform_data/apds990x.h
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 13:46 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419143751.11ec0b69@jic23-huawei>
нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 11:31:23 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
>
> A Sashiko review comment makes me wonder about one thing below if the
> register set does match. Maybe it's a bit more subtle than this
> patch description suggests?
>
> > just add the correct bindings and the appropriate LUX table derived from
> > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > index c8f15ba95267..8dab34bf00ca 100644
> > --- a/drivers/iio/light/tsl2772.c
> > +++ b/drivers/iio/light/tsl2772.c
> > @@ -127,6 +127,7 @@ enum {
> > tmd2672,
> > tsl2772,
> > tmd2772,
> > + apds990x,
> > apds9930,
> > };
> >
> > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 0, 0 },
> > };
> >
> > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > + { 52000, 115960 },
> > + { 36400, 73840 },
> > + { 0, 0 },
> > +};
> > +
> > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 52000, 96824 },
> > { 38792, 67132 },
> > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > [tmd2672] = tmd2x72_lux_table,
> > [tsl2772] = tsl2x72_lux_table,
> > [tmd2772] = tmd2x72_lux_table,
> > + [apds990x] = apds990x_lux_table,
> > [apds9930] = apds9930_lux_table,
> > };
> >
> > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > };
> >
> > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > [tmd2672] = PRX2,
> > [tsl2772] = ALSPRX2,
> > [tmd2772] = ALSPRX2,
> > + [apds990x] = ALSPRX,
>
> This is different from tsl2772?
yes, lux table is different and made according to datasheet,
tsl2772_int_time_avail differs, ALSPRX configuration assumes that
proximity sensor needs no calibration which is true for apds9900/1
while tsl2772 needs calibration, device ID is different 0x20/0x29 for
apds and 0x30 for tsl2772
>
> > [apds9930] = ALSPRX2,
> > };
>
^ permalink raw reply
* Re: [PATCH v7 1/4] KVM: arm64: PMU: Add kvm_pmu_enabled_counter_mask()
From: Marc Zyngier @ 2026-04-19 14:13 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
kvmarm, linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <20260418-hybrid-v7-1-2bf39ad009bf@rsg.ci.i.u-tokyo.ac.jp>
On Sat, 18 Apr 2026 09:14:23 +0100,
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>
> This function will be useful to enumerate enabled counters.
Consider expanding this commit message a bit. Something along the
lines of:
"Add kvm_pmu_enabled_counter_mask() as an accessor returning a 64bit
mask of the counters enabled on a given vcpu.
This will eventually be useful to iterate over the counters."
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [RFC, PATCH 00/12] userfaultfd: working set tracking for VM guest memory
From: Kiryl Shutsemau @ 2026-04-19 14:33 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Andrew Morton, Peter Xu, Lorenzo Stoakes, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Liam R . Howlett, Zi Yan,
Jonathan Corbet, Shuah Khan, Sean Christopherson, Paolo Bonzini,
linux-mm, linux-kernel, linux-doc, linux-kselftest, kvm
In-Reply-To: <aeImfRrrvr3UoKtL@thinkstation>
On Fri, Apr 17, 2026 at 01:26:34PM +0100, Kiryl Shutsemau wrote:
> > Leaving NUMA-balancing aside, a simple
> > mprotect(PROT_NONE)+mprotect(PROT_READ) would already be problematic to
> > distinguish both cases.
>
> Hm. I didn't consider this case (miss some uffd lore). Will rework to
> reuse existing PTE bit.
See https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git uffd/rfc-v3
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v7 2/4] KVM: arm64: PMU: Protect the list of PMUs with RCU
From: Marc Zyngier @ 2026-04-19 14:34 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
kvmarm, linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <20260418-hybrid-v7-2-2bf39ad009bf@rsg.ci.i.u-tokyo.ac.jp>
On Sat, 18 Apr 2026 09:14:24 +0100,
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>
> Convert the list of PMUs to a RCU-protected list that has primitives to
> avoid read-side contention.
>
> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> ---
> arch/arm64/kvm/pmu-emul.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> index 59ec96e09321..ef5140bbfe28 100644
> --- a/arch/arm64/kvm/pmu-emul.c
> +++ b/arch/arm64/kvm/pmu-emul.c
> @@ -7,9 +7,9 @@
> #include <linux/cpu.h>
> #include <linux/kvm.h>
> #include <linux/kvm_host.h>
> -#include <linux/list.h>
> #include <linux/perf_event.h>
> #include <linux/perf/arm_pmu.h>
> +#include <linux/rculist.h>
> #include <linux/uaccess.h>
> #include <asm/kvm_emulate.h>
> #include <kvm/arm_pmu.h>
> @@ -26,7 +26,6 @@ static bool kvm_pmu_counter_is_enabled(struct kvm_pmc *pmc);
>
> bool kvm_supports_guest_pmuv3(void)
> {
> - guard(mutex)(&arm_pmus_lock);
> return !list_empty(&arm_pmus);
Please read include/linux/rculist.h and the discussion about the
interaction of list_empty() with RCU-protected lists. How about using
list_first_or_null_rcu() for peace of mind?
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Jonathan Cameron @ 2026-04-19 16:22 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n1qrSYr16zSSqRHuTWVkRfdC+c9w+mxAhtzgfHzL41XFw@mail.gmail.com>
On Sun, 19 Apr 2026 16:41:24 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 16:33 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:24 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> > > IIO driver so there is no need to keep this old implementation. Remove it.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > Documentation/misc-devices/apds990x.rst | 128 ---
> > Sashiko AI reviewing is now running on anything that hits linux-iio@vger.kernel.org
> >
> > I'm slowly getting into the habit of checking out what it finds though
> > I'm 500+ emails behind so it might not be that thorough today :*
> >
> > Anyhow, it caught an easy one here.
> >
> > This file is referenced from Documentation/misc-devices/index.rst
> > so that needs an update as well.
> >
>
> Good catch, index was not updated, I will do so in v3.
>
> > There is the obvious point of ABI compatibility raised as well, but given
> > we don't seem to be getting much push back on that maybe that's not a significant
> > concern.
>
> I did not found any ABI in the Documentation/ABI regarding this sensor
> using grep, maybe you are more familiar?
Doesn't matter if it's documented explicitly (many older drivers are not).
The question is whether anyone has supported parts and userspace code that
makes use of the sysfs files this driver provides.
Their userspace will be broken by dropping it. The lack of upstream users
makes this less critical but it can be argued it's still a possible regression.
Jonathan
>
> >
> > Jonathan
> >
> > > drivers/misc/Kconfig | 10 -
> > > drivers/misc/Makefile | 1 -
> > > drivers/misc/apds990x.c | 1284 -----------------------
> > > include/linux/platform_data/apds990x.h | 65 --
> > > 5 files changed, 1488 deletions(-)
> > > delete mode 100644 Documentation/misc-devices/apds990x.rst
> > > delete mode 100644 drivers/misc/apds990x.c
> > > delete mode 100644 include/linux/platform_data/apds990x.h
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 16:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n1iB9iC+TFrGK5ajXjdk8-g8vzr4ZbXdvW5=F8iukanaA@mail.gmail.com>
On Sun, 19 Apr 2026 14:50:55 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 14:30 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:23 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> > > just add the correct bindings and the appropriate LUX table derived from
> > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Hi Svyatoslav,
> >
> > Just one small thing.
> >
> > Experience has given me a strong aversion to the use of wildcards
> > in naming within drivers. They go wrong too often because companies
> > can seem to resist using similar names for very different parts.
> >
>
> Noted.
>
> > > ---
> > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > index c8f15ba95267..8dab34bf00ca 100644
> > > --- a/drivers/iio/light/tsl2772.c
> > > +++ b/drivers/iio/light/tsl2772.c
> > > @@ -127,6 +127,7 @@ enum {
> > > tmd2672,
> > > tsl2772,
> > > tmd2772,
> > > + apds990x,
> >
> > As above, just name this after one of the supported parts. apds9900
> > That doesn't stop you using it for multiple compatible devices.
> >
> > Same applies for all the uses of x as a wildcard.
> >
>
> If this is the only thing keeping you from picking this patchset may I
> resend with apds990x fixed right away?
No. I'm just one reviewer - others may need more time. You should wait
at least a few days before sending a new version unless I've specifically
requested a rushed version.
I only do that if I'm trying to get something in at the end of a kernel
cycle or there are dependencies on a patch from others. In this case, neither
applies so please take your time. I'd normally suggest approximately a week.
Thanks,
Jonathan
>
> > thanks,
> >
> > Jonathan
> >
> > > apds9930,
> > > };
> >
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 16:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n048kPMAnGQpOk0_SPtQ+hz=-p6jdyRYPB5d+CD9i7_Cw@mail.gmail.com>
On Sun, 19 Apr 2026 16:46:25 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:23 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> >
> > A Sashiko review comment makes me wonder about one thing below if the
> > register set does match. Maybe it's a bit more subtle than this
> > patch description suggests?
> >
> > > just add the correct bindings and the appropriate LUX table derived from
> > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > index c8f15ba95267..8dab34bf00ca 100644
> > > --- a/drivers/iio/light/tsl2772.c
> > > +++ b/drivers/iio/light/tsl2772.c
> > > @@ -127,6 +127,7 @@ enum {
> > > tmd2672,
> > > tsl2772,
> > > tmd2772,
> > > + apds990x,
> > > apds9930,
> > > };
> > >
> > > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > { 0, 0 },
> > > };
> > >
> > > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > + { 52000, 115960 },
> > > + { 36400, 73840 },
> > > + { 0, 0 },
> > > +};
> > > +
> > > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > { 52000, 96824 },
> > > { 38792, 67132 },
> > > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > > [tmd2672] = tmd2x72_lux_table,
> > > [tsl2772] = tsl2x72_lux_table,
> > > [tmd2772] = tmd2x72_lux_table,
> > > + [apds990x] = apds990x_lux_table,
> > > [apds9930] = apds9930_lux_table,
> > > };
> > >
> > > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > > };
> > >
> > > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > > [tmd2672] = PRX2,
> > > [tsl2772] = ALSPRX2,
> > > [tmd2772] = ALSPRX2,
> > > + [apds990x] = ALSPRX,
> >
> > This is different from tsl2772?
>
> yes, lux table is different and made according to datasheet,
> tsl2772_int_time_avail differs, ALSPRX configuration assumes that
> proximity sensor needs no calibration which is true for apds9900/1
> while tsl2772 needs calibration, device ID is different 0x20/0x29 for
> apds and 0x30 for tsl2772
All makes sense but that means the patch description needs to be
more precise about what elements are compatible, or use vaguer wording
like 'similar to'.
Jonathan
>
> >
> > > [apds9930] = ALSPRX2,
> > > };
> >
>
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 16:28 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419172458.375e7897@jic23-huawei>
нд, 19 квіт. 2026 р. о 19:25 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 16:46:25 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
> > >
> > > On Sun, 19 Apr 2026 11:31:23 +0300
> > > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > >
> > > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> > >
> > > A Sashiko review comment makes me wonder about one thing below if the
> > > register set does match. Maybe it's a bit more subtle than this
> > > patch description suggests?
> > >
> > > > just add the correct bindings and the appropriate LUX table derived from
> > > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > > 1 file changed, 16 insertions(+)
> > > >
> > > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > > index c8f15ba95267..8dab34bf00ca 100644
> > > > --- a/drivers/iio/light/tsl2772.c
> > > > +++ b/drivers/iio/light/tsl2772.c
> > > > @@ -127,6 +127,7 @@ enum {
> > > > tmd2672,
> > > > tsl2772,
> > > > tmd2772,
> > > > + apds990x,
> > > > apds9930,
> > > > };
> > > >
> > > > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > { 0, 0 },
> > > > };
> > > >
> > > > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > + { 52000, 115960 },
> > > > + { 36400, 73840 },
> > > > + { 0, 0 },
> > > > +};
> > > > +
> > > > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > { 52000, 96824 },
> > > > { 38792, 67132 },
> > > > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > > > [tmd2672] = tmd2x72_lux_table,
> > > > [tsl2772] = tsl2x72_lux_table,
> > > > [tmd2772] = tmd2x72_lux_table,
> > > > + [apds990x] = apds990x_lux_table,
> > > > [apds9930] = apds9930_lux_table,
> > > > };
> > > >
> > > > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > > > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > > > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > };
> > > >
> > > > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > > > [tmd2672] = PRX2,
> > > > [tsl2772] = ALSPRX2,
> > > > [tmd2772] = ALSPRX2,
> > > > + [apds990x] = ALSPRX,
> > >
> > > This is different from tsl2772?
> >
> > yes, lux table is different and made according to datasheet,
> > tsl2772_int_time_avail differs, ALSPRX configuration assumes that
> > proximity sensor needs no calibration which is true for apds9900/1
> > while tsl2772 needs calibration, device ID is different 0x20/0x29 for
> > apds and 0x30 for tsl2772
>
> All makes sense but that means the patch description needs to be
> more precise about what elements are compatible, or use vaguer wording
> like 'similar to'.
>
Fair, noted.
> Jonathan
>
> >
> > >
> > > > [apds9930] = ALSPRX2,
> > > > };
> > >
> >
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox