From e24328974a88aa8541e94e8bb8dfa2ade1b3c45d Mon Sep 17 00:00:00 2001 From: Donggeun Yoo Date: Wed, 2 Sep 2026 00:21:26 +0900 Subject: iio: proximity: vl53l0x-i2c: claim direct mode for raw reads vl53l0x_read_raw() starts a single-shot ranging measurement and reads back the result. Once the triggered buffer is enabled the sensor runs in continuous mode and its data-ready interrupt is routed to the trigger, so a concurrent in_distance_raw read disturbs the streaming setup and never gets its completion, returning -ETIMEDOUT. The original submission claimed direct mode here, but it was dropped during review because the driver had no buffer support at the time [1]. Continuous (buffered) mode was later added without restoring the claim [2], reintroducing the conflict. Reject direct reads while buffered capture is active by claiming direct mode around the measurement, as the vl53l1x sibling already does. Fixes: 762186c6e7b1 ("iio: proximity: vl53l0x-i2c: Added continuous mode support") Link: https://lore.kernel.org/linux-iio/20180911160300.GA9212@himanshu-Vostro-3559/ [1] Link: https://lore.kernel.org/linux-iio/20240909101508.263085-3-abhashkumarjha123@gmail.com/ [2] Signed-off-by: Donggeun Yoo Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron --- Documentation/i2c/old-module-parameters.rst | 55 +++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/i2c/old-module-parameters.rst (limited to 'Documentation/i2c/old-module-parameters.rst') diff --git a/Documentation/i2c/old-module-parameters.rst b/Documentation/i2c/old-module-parameters.rst new file mode 100644 index 000000000..b08b6daab --- /dev/null +++ b/Documentation/i2c/old-module-parameters.rst @@ -0,0 +1,55 @@ +================================================================ +I2C device driver binding control from user-space in old kernels +================================================================ + +.. NOTE:: + Note: this section is only relevant if you are handling some old code + found in kernel 2.6. If you work with more recent kernels, you can + safely skip this section. + +Up to kernel 2.6.32, many I2C drivers used helper macros provided by + which created standard module parameters to let the user +control how the driver would probe I2C buses and attach to devices. These +parameters were known as ``probe`` (to let the driver probe for an extra +address), ``force`` (to forcibly attach the driver to a given device) and +``ignore`` (to prevent a driver from probing a given address). + +With the conversion of the I2C subsystem to the standard device driver +binding model, it became clear that these per-module parameters were no +longer needed, and that a centralized implementation was possible. The new, +sysfs-based interface is described in +Documentation/i2c/instantiating-devices.rst, section +"Method 4: Instantiate from user-space". + +Below is a mapping from the old module parameters to the new interface. + +Attaching a driver to an I2C device +----------------------------------- + +Old method (module parameters):: + + # modprobe probe=1,0x2d + # modprobe force=1,0x2d + # modprobe force_=1,0x2d + +New method (sysfs interface):: + + # echo 0x2d > /sys/bus/i2c/devices/i2c-1/new_device + +Preventing a driver from attaching to an I2C device +--------------------------------------------------- + +Old method (module parameters):: + + # modprobe ignore=1,0x2f + +New method (sysfs interface):: + + # echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device + # modprobe + +Of course, it is important to instantiate the ``dummy`` device before loading +the driver. The dummy device will be handled by i2c-core itself, preventing +other drivers from binding to it later on. If there is a real device at the +problematic address, and you want another driver to bind to it, then simply +pass the name of the device in question instead of ``dummy``. -- cgit v1.3.1