All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jyri Sarha <jsarha@ti.com>
Cc: tomi.valkeinen@ti.com, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/drm_bridge: adjust bridge module's refcount
Date: Wed, 30 Nov 2016 11:30:12 +0200	[thread overview]
Message-ID: <9141562.dZ90ZYOVl1@avalon> (raw)
In-Reply-To: <4a502ab4-1f89-15b3-fbd9-5f582999faac@ti.com>

Hi Jyri,

On Wednesday 30 Nov 2016 11:13:41 Jyri Sarha wrote:
> On 11/30/16 11:03, Laurent Pinchart wrote:
> >>> This would require combining lookup and attach in all cases. I'm not
> >>> sure
> >>> 
> >>>>> that would be very convenient for drivers. Keeping the two
> >>>>> operations separate would be more flexible.
> >>> 
> >>> That could be avoided if of_drm_find_bridge() would copy the content of
> >>> bridge object, in stead of providing a pointer.
> > 
> > /me shivers
> > 
> >>> The attach call could then search for the bridge object again before
> >>> continuing. But still in the end the impact to individual drivers would
> >>> be equal to adding a simple drm_bridge_put() call. Probably better to go
> >>> forward with your suggestion.
> > 
> > Please :-)
> 
> Ok :). But first I'll make a pull request of all accumulated tilcdc
> patches, as all problems I have found in them are to be fixed outside
> tilcdc.

Sure.

> >>> Even adding the drm_bridge_put() would not be necessary in most cases
> >>> if we would add a devm version of getting the bridge object. In 99% of
> >>> cases the device probe will fail if the bridge attach fails, and bridge
> >>> object refcount would return to zero automatically.
> > 
> > devm_* is evil in most cases, especially the devm_kzalloc() function as it
> > ties object lifetime to devices, releasing memory at unbind time when the
> > object can still be referenced elsewhere. Regarding bridges, a
> > devm_of_drm_find_bridge() might make sense as the bridge seems at first
> > glance to (nearly) always be a resource that can be released at DRM
> > unbind time.
>
> But the devm is not at all as evil when the object is refcounted,
> because every piece of code that wants to keep a reference to the object
> can keep it.

devm_* is fine when allocating a resources that is release at device unbind 
time. I/O regions, IRQ, and most probably bridges (I'd have to sleep over that 
last one) should fall in that category, at least most of the time. 
devm_kzalloc() is evil in the sense that many driver authors use it as a 
solution to world hunger without thinking twice, while memory allocated by 
drivers for objects that are registered and must outlive the lifetime of the 
device binding is not a resource consumed by the driver that can be released 
at unbind time.

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-11-30  9:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20161129211315epcas3p2a805abe8449509312f481ab7dcea96ef@epcas3p2.samsung.com>
2016-11-29 21:12 ` [PATCH] drm/drm_bridge: adjust bridge module's refcount Jyri Sarha
2016-11-29 21:30   ` Jyri Sarha
2016-11-29 22:06   ` Laurent Pinchart
2016-11-30  8:13     ` Daniel Vetter
2016-11-30  8:25       ` Laurent Pinchart
2016-11-30  9:12         ` Daniel Vetter
2016-11-30  9:56           ` Laurent Pinchart
2016-11-30 10:55             ` Daniel Vetter
2016-11-30 11:03               ` Laurent Pinchart
2016-11-30 13:09                 ` Daniel Vetter
2016-12-01  7:07                   ` Andrzej Hajda
2016-12-01  7:18                     ` Daniel Vetter
2016-12-01 13:22                       ` Andrzej Hajda
2016-12-01 15:12                         ` Daniel Vetter
2016-12-02  6:49                           ` Andrzej Hajda
2016-11-30  8:32     ` Jyri Sarha
2016-11-30  8:37       ` Laurent Pinchart
2016-11-30  8:55         ` Jyri Sarha
2016-11-30  9:03           ` Laurent Pinchart
2016-11-30  9:13             ` Jyri Sarha
2016-11-30  9:30               ` Laurent Pinchart [this message]
2016-11-30  8:11   ` Andrzej Hajda
2016-11-30  8:16     ` Laurent Pinchart
2016-11-30  9:26       ` Andrzej Hajda
2016-11-30  9:39         ` Laurent Pinchart
2016-12-01  6:50           ` Andrzej Hajda

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=9141562.dZ90ZYOVl1@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=tomi.valkeinen@ti.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 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.