Re: [PATCH v1] i2c: designware: amdisp: Fix null pointer dereference in runtime resume

["Nirujogi, Pratap" <pnirujog@amd.com>]

On 3/20/2026 9:56 AM, Mario Limonciello wrote:
> 
> 
> On 3/19/2026 4:09 PM, Nirujogi, Pratap wrote:
>> Hi Mario,
>>
>> On 3/9/2026 9:29 PM, Mario Limonciello wrote:
>>>
>>>
>>> On 3/9/2026 5:00 PM, Pratap Nirujogi wrote:
>>>> Add NULL check for i_dev->map before calling i2c_dw_init() in the
>>>> runtime resume path. The regmap may not be initialized yet when
>>>> runtime PM tries to resume the device early in the probe sequence,
>>>> leading to a NULL pointer dereference. Skip the i2c_dw_init() call
>>>> if regmap is not yet created.
>>>>
>>>> This race condition occurs when runtime PM resume is triggered before
>>>> i2c_dw_probe() completes the regmap initialization and was observed in
>>>> kernel v7.0 where the order of device enumeration has changed because
>>>> of the changes in registering the device sources in the device 
>>>> hierarchy.
>>>>
>>>> Co-developed-by: Bin Du <Bin.Du@amd.com>
>>>> Fixes: 02c057ddefef ("ACPI: video: Convert the driver to a platform 
>>>> one")
>>>
>>> Is this the right commit that introduced the race?  Did it change the 
>>> timing?
>>>
>>> Or was the race always there and we just got lucky until that commit 
>>> went in?
>>>
>> My apologies for mixing up this change along with other changes that 
>> were needed to fix the AMD ISP driver regressions in v7.0.
>>
>> I investigated further and found that this issue was exposed by the 
>> below commit.
>>
>> https://github.com/torvalds/linux/ 
>> commit/38fa29b01a6a295aedb69d1bbdad70acd7d204c6
>>
>> However, the resume‑probe race condition existed even earlier and had 
>> not surfaced because device initialization in resume is done only when 
>> init handle is valid.
>>
>> Here is some background and context on this change:
>>
>> The amdisp i2c device requires ISP to be in power on state for probe 
>> to succeed. To meet this requirement, we added this device, which is a 
>> amdgpu MFD child to the genpd, to control isp power using runtime PM. 
>> The pm_runtime_get_sync() call before probe triggers a PM resume, 
>> which powers on the ISP and also invokes the amdisp i2c runtime resume 
>> before the probe completes resulting in this race condition.
>>
>> To fix this issue properly, I’m considering this change. Please review 
>> and share your feedback on whether this makes sense.
>>
>> - Call dev_pm_genpd_resume() to Power ON ISP before probe
>> - Call dev_pm_genpd_suspend() to Power OFF ISP after probe
>> - Call pm_runtime_enable() after probe is successful to take care of 
>> system suspend/resume.
>>
>> diff --git a/drivers/i2c/busses/i2c-designware-amdisp.c b/drivers/i2c/ 
>> busses/i2c-designware-amdisp.c
>> index 19de518be30a4..9ce58522951cd 100644
>> --- a/drivers/i2c/busses/i2c-designware-amdisp.c
>> +++ b/drivers/i2c/busses/i2c-designware-amdisp.c
>> @@ -7,6 +7,7 @@
>>
>>   #include <linux/module.h>
>>   #include <linux/platform_device.h>
>> +#include <linux/pm_domain.h>
>>   #include <linux/pm_runtime.h>
>>   #include <linux/soc/amd/isp4_misc.h>
>>
>> @@ -76,9 +77,7 @@ static int amd_isp_dw_i2c_plat_probe(struct 
>> platform_device *pdev)
>>
>>          device_enable_async_suspend(&pdev->dev);
>>
>> -       pm_runtime_enable(&pdev->dev);
>> -       pm_runtime_get_sync(&pdev->dev);
>> -
>> +       dev_pm_genpd_resume(&pdev->dev);
>>          ret = i2c_dw_probe(isp_i2c_dev);
>>          if (ret) {
>> @@ -86,14 +85,14 @@ static int amd_isp_dw_i2c_plat_probe(struct 
>> platform_device *pdev)
>>                  goto error_release_rpm;
>>          }
>> -
>> -       pm_runtime_put_sync(&pdev->dev);
>> +       dev_pm_genpd_suspend(&pdev->dev);
>> +       pm_runtime_set_suspended(&pdev->dev);
>> +       pm_runtime_enable(&pdev->dev);
>>
>>          return 0;
>>
>>   error_release_rpm:
>>          amd_isp_dw_i2c_plat_pm_cleanup(isp_i2c_dev);
>> -       pm_runtime_put_sync(&pdev->dev);
>>          return ret;
>>   }
>>
> Good investigation.  Since this was around all the time and just got 
> worse I would say you should add a fixes tag for the first commit that 
> introduced this driver rather than 
> 38fa29b01a6a295aedb69d1bbdad70acd7d204c6 and just note in the commit 
> message that 38fa29b01a6a295aedb69d1bbdad70acd7d204c6 made it worse.

Thanks, Mario. Your feedback on the Fixes tag and commit message is very 
helpful, I will take care of these while submitting v2.

Thanks,
Pratap