Re: [PATCH v4 3/3] arm64: dts: exynos7870-j6lte: add Sharp GP2AP070S proximity sensor

[email protected]
Newsgroups org.kernel.vger.linux-devicetree
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The devicetree node `i2c-proximity` uses the software bit-banged `i2c-gpio` driver, but its pinctrl node `i2c_proxm_bus` explicitly configures the pins to the hardware I2C controller's alternate function instead of GPIO mode.
--

--- Patch [3]: [PATCH v4 3/3] arm64: dts: exynos7870-j6lte: add Sharp GP2AP070S proximity sensor ---
commit c0b785824301e0a2b3734b066c904e45cdad7f77
Author: Kaustabh Chakraborty <[email protected]>

arm64: dts: exynos7870-j6lte: add Sharp GP2AP070S proximity sensor

The commit adds a Sharp GP2AP070S proximity sensor to the exynos7870-j6lte
device tree. It connects the sensor via a GPIO-driven I2C bus and provides
necessary regulator supplies.

> diff --git a/arch/arm64/boot/dts/exynos/exynos7870-j6lte.dts b/arch/arm64/boot/dts/exynos/exynos7870-j6lte.dts
> index de30d0970336f..dd493138fed6e 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7870-j6lte.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos7870-j6lte.dts
> @@ -73,6 +73,35 @@ key-volup {
>  		};
>  	};
>  
> +	i2c-proximity {
> +		compatible = "i2c-gpio";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&i2c_proxm_bus>;
> +
> +		sda-gpios = <&gpf4 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> +		scl-gpios = <&gpf4 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;

[ ... ]

> @@ -579,6 +624,12 @@ bt_enable: bt-enable-pins {
>  		samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
>  	};
>  
> +	i2c_proxm_bus: i2c-proxm-bus-pins {
> +		samsung,pins = "gpf4-3", "gpf4-2";
> +		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;

[Severity: Medium]
Is it intentional to configure these pins to the hardware I2C controller
alternate function (EXYNOS_PIN_FUNC_3) while using the software bit-banged
i2c-gpio driver?

During device probe, the pinctrl framework will route the pins to the hardware
I2C controller.

This contradicts the bit-banged I2C design and creates a window where the pins
are driven by the hardware controller before the GPIO framework eventually
overrides the pin multiplexing.

If the hardware controller isn't powered or properly initialized, could this
cause the pins to float or drive the bus incorrectly, leading to I2C bus
glitches?

> +		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
> +	};
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.