From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> To: Stephen Boyd <swboyd@chromium.org>, Vinod Polimera <quic_vpolimer@quicinc.com>, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org Cc: quic_kalyant@quicinc.com, linux-kernel@vger.kernel.org, dianders@chromium.org Subject: Re: [PATCH] drm/msm/disp/dpu1: avoid clearing hw interrupts if hw_intr is null during drm uninit Date: Wed, 27 Apr 2022 13:53:01 +0300 [thread overview] Message-ID: <e20d94d7-a865-21f7-0514-706992294614@linaro.org> (raw) In-Reply-To: <CAE-0n52cSR_xCxF+_UeK8CaHqsu=4HOtfWQ3BMmx2Tx3kmk-ZA@mail.gmail.com> On 27/04/2022 00:50, Stephen Boyd wrote: > Quoting Vinod Polimera (2022-04-25 23:02:11) >> Avoid clearing irqs and derefernce hw_intr when hw_intr is null. > > Presumably this is only the case when the display driver doesn't fully > probe and something probe defers? Can you clarify how this situation > happens? > >> >> BUG: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 >> >> Call trace: >> dpu_core_irq_uninstall+0x50/0xb0 >> dpu_irq_uninstall+0x18/0x24 >> msm_drm_uninit+0xd8/0x16c >> msm_drm_bind+0x580/0x5fc >> try_to_bring_up_master+0x168/0x1c0 >> __component_add+0xb4/0x178 >> component_add+0x1c/0x28 >> dp_display_probe+0x38c/0x400 >> platform_probe+0xb0/0xd0 >> really_probe+0xcc/0x2c8 >> __driver_probe_device+0xbc/0xe8 >> driver_probe_device+0x48/0xf0 >> __device_attach_driver+0xa0/0xc8 >> bus_for_each_drv+0x8c/0xd8 >> __device_attach+0xc4/0x150 >> device_initial_probe+0x1c/0x28 >> >> Fixes: a73033619ea ("drm/msm/dpu: squash dpu_core_irq into dpu_hw_interrupts") > > The fixes tag looks odd. In dpu_core_irq_uninstall() at that commit it > is dealing with 'irq_obj' which isn't a pointer. After commit > f25f656608e3 ("drm/msm/dpu: merge struct dpu_irq into struct > dpu_hw_intr") dpu_core_irq_uninstall() starts using 'hw_intr' which is > allocated on the heap. If we backported this patch to a place that had > a73033619ea without f25f656608e3 it wouldn't make any sense. I'd agree here. The following tag would be correct: Fixes: f25f656608e3 ("drm/msm/dpu: merge struct dpu_irq into struct dpu_hw_intr") > >> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com> >> --- >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c >> index c515b7c..ab28577 100644 >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c >> @@ -599,6 +599,9 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms) >> { >> int i; >> >> + if (!dpu_kms->hw_intr) >> + return; >> + >> pm_runtime_get_sync(&dpu_kms->pdev->dev); >> for (i = 0; i < dpu_kms->hw_intr->total_irqs; i++) -- With best wishes Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> To: Stephen Boyd <swboyd@chromium.org>, Vinod Polimera <quic_vpolimer@quicinc.com>, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, robdclark@gmail.com, dianders@chromium.org, quic_kalyant@quicinc.com Subject: Re: [PATCH] drm/msm/disp/dpu1: avoid clearing hw interrupts if hw_intr is null during drm uninit Date: Wed, 27 Apr 2022 13:53:01 +0300 [thread overview] Message-ID: <e20d94d7-a865-21f7-0514-706992294614@linaro.org> (raw) In-Reply-To: <CAE-0n52cSR_xCxF+_UeK8CaHqsu=4HOtfWQ3BMmx2Tx3kmk-ZA@mail.gmail.com> On 27/04/2022 00:50, Stephen Boyd wrote: > Quoting Vinod Polimera (2022-04-25 23:02:11) >> Avoid clearing irqs and derefernce hw_intr when hw_intr is null. > > Presumably this is only the case when the display driver doesn't fully > probe and something probe defers? Can you clarify how this situation > happens? > >> >> BUG: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 >> >> Call trace: >> dpu_core_irq_uninstall+0x50/0xb0 >> dpu_irq_uninstall+0x18/0x24 >> msm_drm_uninit+0xd8/0x16c >> msm_drm_bind+0x580/0x5fc >> try_to_bring_up_master+0x168/0x1c0 >> __component_add+0xb4/0x178 >> component_add+0x1c/0x28 >> dp_display_probe+0x38c/0x400 >> platform_probe+0xb0/0xd0 >> really_probe+0xcc/0x2c8 >> __driver_probe_device+0xbc/0xe8 >> driver_probe_device+0x48/0xf0 >> __device_attach_driver+0xa0/0xc8 >> bus_for_each_drv+0x8c/0xd8 >> __device_attach+0xc4/0x150 >> device_initial_probe+0x1c/0x28 >> >> Fixes: a73033619ea ("drm/msm/dpu: squash dpu_core_irq into dpu_hw_interrupts") > > The fixes tag looks odd. In dpu_core_irq_uninstall() at that commit it > is dealing with 'irq_obj' which isn't a pointer. After commit > f25f656608e3 ("drm/msm/dpu: merge struct dpu_irq into struct > dpu_hw_intr") dpu_core_irq_uninstall() starts using 'hw_intr' which is > allocated on the heap. If we backported this patch to a place that had > a73033619ea without f25f656608e3 it wouldn't make any sense. I'd agree here. The following tag would be correct: Fixes: f25f656608e3 ("drm/msm/dpu: merge struct dpu_irq into struct dpu_hw_intr") > >> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com> >> --- >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c >> index c515b7c..ab28577 100644 >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c >> @@ -599,6 +599,9 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms) >> { >> int i; >> >> + if (!dpu_kms->hw_intr) >> + return; >> + >> pm_runtime_get_sync(&dpu_kms->pdev->dev); >> for (i = 0; i < dpu_kms->hw_intr->total_irqs; i++) -- With best wishes Dmitry
next prev parent reply other threads:[~2022-04-27 10:53 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-26 6:02 [PATCH] drm/msm/disp/dpu1: avoid clearing hw interrupts if hw_intr is null during drm uninit Vinod Polimera 2022-04-26 6:02 ` Vinod Polimera 2022-04-26 21:50 ` Stephen Boyd 2022-04-26 21:50 ` Stephen Boyd 2022-04-27 10:53 ` Dmitry Baryshkov [this message] 2022-04-27 10:53 ` Dmitry Baryshkov 2022-05-02 1:38 ` [Freedreno] " Abhinav Kumar 2022-05-02 1:38 ` Abhinav Kumar 2022-05-02 8:05 ` Dmitry Baryshkov 2022-05-02 8:05 ` Dmitry Baryshkov 2022-05-02 16:10 ` Abhinav Kumar 2022-05-02 16:10 ` Abhinav Kumar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=e20d94d7-a865-21f7-0514-706992294614@linaro.org \ --to=dmitry.baryshkov@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=dianders@chromium.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=quic_kalyant@quicinc.com \ --cc=quic_vpolimer@quicinc.com \ --cc=swboyd@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.