Re: [PATCH v2 3/4] arm64: dts: qcom: monaco-pmics: Add ADC support for PMM8620AU

[Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>]

On 6/14/2026 1:45 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] The ADC interrupt handler `adc5_gen3_isr()` may dereference a NULL pointer `adc->handler` if an interrupt fires before the thermal auxiliary driver has registered its event notifier.
> --
> 
> commit 2afa9a558734cf9fc6ad1120da9026df8390137c
> Author: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com>
> 
> arm64: dts: qcom: monaco-pmics: Add ADC support for PMM8620AU
>     
> This commit adds ADC nodes for PMM8620AU PMIC instances on the Monaco
> platform. It exposes the DIE_TEMP and VPH_PWR channels.
> 
>> diff --git a/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi b/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
>> index e990d7367719b..232bcb942b54c 100644
>> --- a/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
> [ ... ]
>> @@ -20,6 +21,27 @@ pmm8620au_0_rtc: rtc@6100 {
>>  			interrupts = <0x0 0x62 0x1 IRQ_TYPE_EDGE_RISING>;
>>  		};
>>  
>> +		pmm8620au_0_adc: adc@8000 {
>> +			compatible = "qcom,spmi-adc5-gen3";
>> +			reg = <0x8000>;
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			interrupts = <0x0 0x80 0x1 IRQ_TYPE_EDGE_RISING>;
> 
> [Severity: High]
> This is a pre-existing issue, but by enabling the qcom,spmi-adc5-gen3
> interrupts here, does this expose a NULL pointer dereference in the
> ADC driver's interrupt handler?
> 
> In drivers/iio/adc/qcom-spmi-adc5-gen3.c:adc5_gen3_isr(), the handler
> checks the device driver state rather than the function pointer:
> 
> 		adev = adc->tm_aux;
> 		if (!adev || !adev->dev.driver) {
> 			dev_err(dev, "adc_tm auxiliary device not initialized\n");
> 			return IRQ_HANDLED;
> 		}
> 
> 		adc->handler(adev);
> 

At present, the auxiliary ADC_TM driver is not present in the code.

The above code block lies within this if check:

    if (tm_status[0] || tm_status[1])

This requires some channels to be configured for TM measurements
and a threshold violation to have happened, which is not possible
if the driver is absent.

Even if the interrupt is somehow triggered for TM violation, since
the driver does not exist, adev->dev.driver will always be NULL,
so execution will enter the error condition and return without reaching
adc->handler.

In the latest patch series for adding the auxiliary ADC_TM driver,
https://lore.kernel.org/all/20260705-gen3_adc_tm-v3-0-ac62f387dbce@oss.qualcomm.com/,
the above logic is removed from adc5_gen3_isr(), so this issue
won't happen.

Thanks,
Jishnu

> If an interrupt fires after the driver core sets adev->dev.driver but
> before the thermal driver calls adc5_gen3_register_tm_event_notifier()
> to set adc->handler, will this result in a kernel panic by dereferencing
> a NULL adc->handler?
>