linux-kernel - Re: [PATCH v2 7/7] drm: Document how to register devices without struct drm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANq1E4TnVLORZyqsrtgXk04rR_s+9xFwdzdDS3cMk6hVf07-0Q@mail.gmail.com>
Date:	Tue, 13 May 2014 17:55:54 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Russell King <rmk+kernel@....linux.org.uk>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Daniel Vetter <daniel@...ll.ch>,
	Rob Clark <robdclark@...il.com>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	linux-tegra@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 7/7] drm: Document how to register devices without
 struct drm_bus

Hi

On Tue, May 13, 2014 at 5:30 PM, Thierry Reding
<thierry.reding@...il.com> wrote:
> From: Thierry Reding <treding@...dia.com>
>
> With the recent addition of the drm_set_unique() function, devices can
> now be registered without requiring a drm_bus. Add a brief description
> to the DRM docbook to show how that can be achieved.
>
> Signed-off-by: Thierry Reding <treding@...dia.com>
> ---
>  Documentation/DocBook/drm.tmpl | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index f26a8e4fbe47..f48227caf41a 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -142,6 +142,12 @@
>        to register it with the DRM subsystem.
>      </para>
>      <para>
> +      Newer drivers that no longer require a <structname>drm_bus</structname>
> +      structure can alternatively use the low-level device initialization and
> +      registration functions such as <function>drm_dev_alloc()</function> and
> +      <function>drm_dev_register()</function> directly.
> +    </para>
> +    <para>
>        The <structname>drm_driver</structname> structure contains static
>        information that describes the driver and features it supports, and
>        pointers to methods that the DRM core will call to implement the DRM API.
> @@ -290,6 +296,29 @@ char *date;</synopsis>
>  !Fdrivers/gpu/drm/drm_pci.c drm_pci_init drm_pci_exit
>  !Fdrivers/gpu/drm/drm_usb.c drm_usb_init drm_usb_exit
>  !Fdrivers/gpu/drm/drm_platform.c drm_platform_init
> +      <para>
> +        New drivers that no longer rely on the services provided by the
> +        <structname>drm_bus</structname> structure can call the low-level
> +        device registration functions directly. The
> +        <function>drm_dev_alloc()</function> function can be used to allocate
> +        and initialize a new <structname>drm_device</structname> structure.
> +        Drivers will typically want to perform some additional setup on this
> +        structure, such as allocating driver-specific data and storing a
> +        pointer to it in the DRM device's <structfield>dev_private</structfield>
> +        field. Drivers should also set the device's unique name using the
> +        <function>drm_set_unique()</function> function. After it has been set up
> +        a device can be registered with the DRM subsystem by calling
> +        <function>drm_dev_register()</function>. This will cause the device to
> +        be exposed to userspace and will call the driver's
> +        <structfield>.load()</structfield> implementation. When a device is
> +        removed, the DRM device can safely be unregistered and freed using a

That's not true. drm_put_dev() is anything but safe.. but that's an
implementation bug and I'm working on it. Not that easy, though.
Furthermore, please use drm_dev_unregister() and drm_dev_unref()
directly. No reason to use drm_put_dev() in new drivers. Once I fixed
the runtime issues, a call to drm_dev_unregister() will _immediately_
remove a device and detach all active user-space connections.

> +        call to <function>drm_put_dev()</function>.
> +      </para>
> +!Fdrivers/gpu/drm/drm_stub.c drm_dev_alloc

Please change this to:

+!Fdrivers/gpu/drm/drm_stub.c drm_dev_alloc
+!Fdrivers/gpu/drm/drm_stub.c drm_dev_ref
+!Fdrivers/gpu/drm/drm_stub.c drm_dev_unref
+!Fdrivers/gpu/drm/drm_stub.c drm_dev_register
+!Fdrivers/gpu/drm/drm_stub.c drm_dev_unregister
+!Fdrivers/gpu/drm/drm_stub.c drm_dev_set_unique

All these helpers are needed and exported to drivers.

Otherwise, looks all good! Thanks!
David

> +    </sect2>
>      <sect2>
>        <title>Driver Load</title>
>        <para>
> --
> 1.9.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/