drivers/i2c/busses/i2c-designware-amdisp.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
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")
Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
---
drivers/i2c/busses/i2c-designware-amdisp.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-designware-amdisp.c b/drivers/i2c/busses/i2c-designware-amdisp.c
index c48728ad9f6f2..cd7ee55fbe1ee 100644
--- a/drivers/i2c/busses/i2c-designware-amdisp.c
+++ b/drivers/i2c/busses/i2c-designware-amdisp.c
@@ -153,7 +153,10 @@ static int amd_isp_dw_i2c_plat_runtime_resume(struct device *dev)
return -ENODEV;
i2c_dw_prepare_clk(i_dev, true);
- i2c_dw_init(i_dev);
+
+ /* Skip i2c_dw_init if regmap not yet created by i2c_dw_probe */
+ if (i_dev->map)
+ i2c_dw_init(i_dev);
return 0;
}
--
2.43.0On Mon, Mar 09, 2026 at 06:00:01PM -0400, 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>
Please, read Submitting Patches on the tags, especially how to correctly use
Co-developed-by.
> Fixes: 02c057ddefef ("ACPI: video: Convert the driver to a platform one")
> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
...
> i2c_dw_prepare_clk(i_dev, true);
> - i2c_dw_init(i_dev);
> +
> + /* Skip i2c_dw_init if regmap not yet created by i2c_dw_probe */
Use same style for references to the functions: func().
> + if (i_dev->map)
> + i2c_dw_init(i_dev);
TBH, Looks like papering over the problem. Why the resume is called on
uninitialised regmap to begin with?
--
With Best Regards,
Andy Shevchenko
Hi Andy,
On 3/10/2026 7:21 AM, Andy Shevchenko wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Mon, Mar 09, 2026 at 06:00:01PM -0400, 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>
>
> Please, read Submitting Patches on the tags, especially how to correctly use
> Co-developed-by.
>
sure, will fix the incorrect usage of tags in the next version.
>> Fixes: 02c057ddefef ("ACPI: video: Convert the driver to a platform one")
>> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
>
> ...
>
>> i2c_dw_prepare_clk(i_dev, true);
>> - i2c_dw_init(i_dev);
>> +
>> + /* Skip i2c_dw_init if regmap not yet created by i2c_dw_probe */
>
> Use same style for references to the functions: func().
>
sure, will fix it in the next version.
>> + if (i_dev->map)
>> + i2c_dw_init(i_dev);
>
> TBH, Looks like papering over the problem. Why the resume is called on
> uninitialised regmap to begin with?
>
yes, I agree, this change avoids the issue rather than fixing the root
cause of the race condition. I investigated further and shared the
details in response to Mario’s comments. Could you please review the
latest response[1] and share your feedback?
[1]
https://lore.kernel.org/all/61dbe8a1-6578-4690-8571-6b00c1850d34@amd.com/
Thanks,
Pratap
> --
> With Best Regards,
> Andy Shevchenko
>
>
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?
> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
> ---
> drivers/i2c/busses/i2c-designware-amdisp.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-amdisp.c b/drivers/i2c/busses/i2c-designware-amdisp.c
> index c48728ad9f6f2..cd7ee55fbe1ee 100644
> --- a/drivers/i2c/busses/i2c-designware-amdisp.c
> +++ b/drivers/i2c/busses/i2c-designware-amdisp.c
> @@ -153,7 +153,10 @@ static int amd_isp_dw_i2c_plat_runtime_resume(struct device *dev)
> return -ENODEV;
>
> i2c_dw_prepare_clk(i_dev, true);
> - i2c_dw_init(i_dev);
> +
> + /* Skip i2c_dw_init if regmap not yet created by i2c_dw_probe */
> + if (i_dev->map)
> + i2c_dw_init(i_dev);
>
> return 0;
> }
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;
}
Thanks,
Pratap
>> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
>> ---
>> drivers/i2c/busses/i2c-designware-amdisp.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-designware-amdisp.c b/drivers/i2c/
>> busses/i2c-designware-amdisp.c
>> index c48728ad9f6f2..cd7ee55fbe1ee 100644
>> --- a/drivers/i2c/busses/i2c-designware-amdisp.c
>> +++ b/drivers/i2c/busses/i2c-designware-amdisp.c
>> @@ -153,7 +153,10 @@ static int
>> amd_isp_dw_i2c_plat_runtime_resume(struct device *dev)
>> return -ENODEV;
>> i2c_dw_prepare_clk(i_dev, true);
>> - i2c_dw_init(i_dev);
>> +
>> + /* Skip i2c_dw_init if regmap not yet created by i2c_dw_probe */
>> + if (i_dev->map)
>> + i2c_dw_init(i_dev);
>> return 0;
>> }
>
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.
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
On Thu, Mar 19, 2026 at 05:09:55PM -0400, Nirujogi, Pratap wrote:
> On 3/9/2026 9:29 PM, Mario Limonciello wrote:
> > On 3/9/2026 5:00 PM, Pratap Nirujogi wrote:
...
> > > 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
Still it might be not a culprit as at that point the device should be in power
on state.
> 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.
That's what the initial cause, the AMD ISP driver initially relies on
the broken (racy) behaviour. So, the original patch d6263c468a761 does not
explain that bit. You need to go deeper and understand why the heck that
condition is present there.
> Here is some background and context on this change:
Exactly, the below seems that you have nailed it down.
> 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.
I don't know the scope of dev_pm_genpd_*() usage, but the description of
the proposed change sounds sane. And definitely it's much much better than
previous attempt.
--
With Best Regards,
Andy Shevchenko
On 3/20/2026 3:59 AM, Andy Shevchenko wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Thu, Mar 19, 2026 at 05:09:55PM -0400, Nirujogi, Pratap wrote:
>> On 3/9/2026 9:29 PM, Mario Limonciello wrote:
>>> On 3/9/2026 5:00 PM, Pratap Nirujogi wrote:
>
> ...
>
>>>> 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
>
> Still it might be not a culprit as at that point the device should be in power
> on state.
>
>> 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.
>
> That's what the initial cause, the AMD ISP driver initially relies on
> the broken (racy) behaviour. So, the original patch d6263c468a761 does not
> explain that bit. You need to go deeper and understand why the heck that
> condition is present there.
>
>> Here is some background and context on this change:
>
> Exactly, the below seems that you have nailed it down.
>
>> 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.
>
> I don't know the scope of dev_pm_genpd_*() usage, but the description of
> the proposed change sounds sane. And definitely it's much much better than
> previous attempt.
>
Thanks, Andy, for the feedback and comments. I’ll send out v2 with the
proposed changes.
Thanks,
Pratap
> --
> With Best Regards,
> Andy Shevchenko
>
>
© 2016 - 2026 Red Hat, Inc.