From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: linux-renesas-soc@vger.kernel.org,
intel-gfx@lists.freedesktop.org,
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 12/17] drm/rcar-du: Convert to using __drm_atomic_helper_crtc_reset() for reset.
Date: Fri, 1 Mar 2019 17:06:29 +0200 [thread overview]
Message-ID: <20190301150629.GE32244@pendragon.ideasonboard.com> (raw)
In-Reply-To: <cb8c2c5d-5c20-8e79-39e5-a520479c5358@linux.intel.com>
Hi Marteen,
On Fri, Mar 01, 2019 at 03:47:02PM +0100, Maarten Lankhorst wrote:
> Op 01-03-2019 om 15:36 schreef Laurent Pinchart:
> > On Fri, Mar 01, 2019 at 03:08:20PM +0100, Maarten Lankhorst wrote:
> >> Op 01-03-2019 om 14:13 schreef Laurent Pinchart:
> >>> On Fri, Mar 01, 2019 at 01:56:22PM +0100, Maarten Lankhorst wrote:
> >>>> Convert rcar-du to using __drm_atomic_helper_crtc_reset(), instead of
> >>>> writing its own version. Instead of open coding destroy_state(), call
> >>>> it directly for freeing the old state.
> >>> I don't think the second sentence applies to this patch.
> >>>
> >>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >>>> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> >>>> Cc: linux-renesas-soc@vger.kernel.org
> >>>> ---
> >>>> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 11 +++--------
> >>>> 1 file changed, 3 insertions(+), 8 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >>>> index 4cdea14d552f..7766551e67fc 100644
> >>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> >>>> @@ -891,22 +891,17 @@ static void rcar_du_crtc_cleanup(struct drm_crtc *crtc)
> >>>>
> >>>> static void rcar_du_crtc_reset(struct drm_crtc *crtc)
> >>>> {
> >>>> - struct rcar_du_crtc_state *state;
> >>>> + struct rcar_du_crtc_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
> >>>>
> >>>> - if (crtc->state) {
> >>>> + if (crtc->state)
> >>>> rcar_du_crtc_atomic_destroy_state(crtc, crtc->state);
> >>>> - crtc->state = NULL;
> >>>> - }
> >>>>
> >>>> - state = kzalloc(sizeof(*state), GFP_KERNEL);
> >>>> + __drm_atomic_helper_crtc_reset(crtc, &state->state);
> >>> state may be NULL here if the above kzalloc() failed. Let's keep the
> >>> original order of the function, and simply call
> >>> __drm_atomic_helper_crtc_reset() after the NULL check below.
> >> There were 10 different ways crtc was implemented, I felt it was good to settle on one.
> >>
> >> We don't handle during reset at all, would need to start propagating this first before we should handle errors, imho.
> > That's not the point. As state can be NULL, you could end up
> > dereferencing a NULL pointer. The fact that the base state is the first
> > field in the rcar_du_crtc_state structure is just luck, and shouldn't be
> > relied on.
>
> Would it be ok if I changed it to state ? &state->state : NULL and let
> the compiler deal with it?
What's wrong with a proper implementation ?
static void rcar_du_crtc_reset(struct drm_crtc *crtc)
{
struct rcar_du_crtc_state *state;
if (crtc->state) {
rcar_du_crtc_atomic_destroy_state(crtc, crtc->state);
crtc->state = NULL;
}
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (state == NULL)
return;
__drm_atomic_helper_crtc_reset(crtc, &state->state);
state->crc.source = VSP1_DU_CRC_NONE;
state->crc.index = 0;
}
> Will probably fix up all other patches as well before committing.
You won't commit this one before I ack it, right ? :-)
> >> Looking more closely, it's the same way that errors in
> >> rcar_du_plane_reset() are handled. :)
> > It's not, the return value of kzalloc() is checked explicitly in
> > rcar_du_plane_reset() before calling __drm_atomic_helper_plane_reset().
> > Please copy the code flow of rcar_du_plane_reset() to implement
> > rcar_du_crtc_reset().
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-03-01 15:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-01 12:56 [PATCH 00/17] drm: Start subclassing crtc_state Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 01/17] drm/vc4: Fix memory leak during gpu reset Maarten Lankhorst
2019-03-01 22:43 ` Eric Anholt
2019-03-01 12:56 ` [PATCH 02/17] drm/atomic: Create __drm_atomic_helper_crtc_reset() for subclassing crtc_state Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 03/17] drm/docs: Fix typo in __drm_atomic_helper_connector_reset Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 04/17] drm/amd: Convert to using __drm_atomic_helper_crtc_reset() for reset Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 05/17] drm/mali: " Maarten Lankhorst
2019-03-01 13:37 ` Liviu Dudau
2019-03-01 12:56 ` [PATCH 06/17] drm/atmel-hlcdc: " Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 07/17] drm/i915: Use the new __drm_atomic_helper_crtc_reset() helper Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 08/17] drm/imx: Convert to using __drm_atomic_helper_crtc_reset() for reset Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 09/17] drm/mediatek: " Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 10/17] drm/msm: " Maarten Lankhorst
2019-03-04 19:23 ` Sean Paul
2019-03-01 12:56 ` [PATCH 11/17] drm/omap: " Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 12/17] drm/rcar-du: " Maarten Lankhorst
2019-03-01 13:13 ` Laurent Pinchart
2019-03-01 14:08 ` Maarten Lankhorst
2019-03-01 14:36 ` Laurent Pinchart
2019-03-01 14:47 ` Maarten Lankhorst
2019-03-01 15:06 ` Laurent Pinchart [this message]
[not found] ` <20190301125627.7285-1-maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2019-03-01 12:56 ` [PATCH 13/17] drm/rockchip: " Maarten Lankhorst
2019-03-18 18:07 ` Heiko Stübner
2019-03-01 12:56 ` [PATCH 14/17] drm/tegra: " Maarten Lankhorst
2019-03-04 13:02 ` Thierry Reding
2019-03-01 12:56 ` [PATCH 15/17] drm/vc4: " Maarten Lankhorst
2019-03-01 22:47 ` Eric Anholt
2019-03-04 13:51 ` Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 16/17] drm/vkms: " Maarten Lankhorst
2019-03-06 22:43 ` Rodrigo Siqueira
2019-04-25 9:41 ` Maarten Lankhorst
2019-03-01 12:56 ` [PATCH 17/17] drm/vmwgfx: " Maarten Lankhorst
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=20190301150629.GE32244@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox