Re: [Intel-gfx] [RFC v2 1/4] drm: Add support to find drm_panel by name

Re: [Intel-gfx] [RFC v2 1/4] drm: Add support to find drm_panel by name

[Daniel Vetter]

On Fri, Jan 9, 2015 at 1:50 PM, Jani Nikula <jani.nikula@intel.com> wrote:
> I have a slightly uneasy feeling about handing out drm_panel pointers
> (both from here and of_drm_find_panel) without refcounting. If the panel
> driver gets removed, whoever called the find functions will have a
> dangling pointer. I supposed this will be discussed on drm-devel.

There's been some discussion already about exactly this problem (but
with drm bridges) with Thierry and some other people. Cc'ed them all
hopefully. Especially when the panel/bridge is a separate driver
there's imo indeed an issue.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC v2 1/4] drm: Add support to find drm_panel by name

[Andrzej Hajda]

On 01/13/2015 12:08 AM, Daniel Vetter wrote:
> On Fri, Jan 9, 2015 at 1:50 PM, Jani Nikula <jani.nikula@intel.com> wrote:
>> I have a slightly uneasy feeling about handing out drm_panel pointers
>> (both from here and of_drm_find_panel) without refcounting. If the panel
>> driver gets removed, whoever called the find functions will have a
>> dangling pointer. I supposed this will be discussed on drm-devel.

refcounting does not seems to me a good solution, drm_panel is
exposed by device driver and device driver can be unbound unconditionally
at any time. This problem affects many frameworks not only drm_panel.

I work on resource tracking framework which tries to solve the problem
in a generic way[1].

[1]: https://lkml.org/lkml/2014/12/10/342

Regards
Andrzej


> There's been some discussion already about exactly this problem (but
> with drm bridges) with Thierry and some other people. Cc'ed them all
> hopefully. Especially when the panel/bridge is a separate driver
> there's imo indeed an issue.
> -Daniel

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

Re: [Intel-gfx] [RFC v2 1/4] drm: Add support to find drm_panel by name

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1417 bytes --]

On Tue, Jan 13, 2015 at 12:08:11AM +0100, Daniel Vetter wrote:
> On Fri, Jan 9, 2015 at 1:50 PM, Jani Nikula <jani.nikula@intel.com> wrote:
> > I have a slightly uneasy feeling about handing out drm_panel pointers
> > (both from here and of_drm_find_panel) without refcounting. If the panel
> > driver gets removed, whoever called the find functions will have a
> > dangling pointer. I supposed this will be discussed on drm-devel.
> 
> There's been some discussion already about exactly this problem (but
> with drm bridges) with Thierry and some other people. Cc'ed them all
> hopefully. Especially when the panel/bridge is a separate driver
> there's imo indeed an issue.

I posted patches some time ago to create a generic registry to do the
actual ref-counting[0]. It didn't seem to be very well received by Greg
for the core, so perhaps we could test-drive it in DRM first for panels
and bridges and once it's matured a bit it could still be promoted to
the driver core, or maybe lib/.

The difficult part about it is that while reference counting gives you
the benefit of keeping a valid pointer around, you may still want to
have a method of getting notified of the panel going away. I've thought
a bit about that and I think we could probably integrate that into the
registry, since that will notice anyway.

Thierry

[0]: http://www.spinics.net/linux/lists/kernel/msg1859333.html

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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