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

[Mario Limonciello <mario.limonciello@amd.com>]

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.