[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46f54cb0-4019-8b40-5a0b-43ca100a4a78@tronnes.org>
Date: Wed, 8 Mar 2017 13:23:29 +0100
From: Noralf Trønnes <noralf@...nnes.org>
To: Daniel Vetter <daniel@...ll.ch>
Cc: dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
thomas.petazzoni@...e-electrons.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/7] drm: Add DRM support for tiny LCD displays
Den 07.03.2017 23.21, skrev Daniel Vetter:
> On Sat, Feb 11, 2017 at 07:48:52PM +0100, Noralf Trønnes wrote:
>> +const struct file_operations tinydrm_fops = {
>> + .owner = THIS_MODULE,
>> + .open = drm_open,
>> + .release = drm_release,
>> + .unlocked_ioctl = drm_ioctl,
>> +#ifdef CONFIG_COMPAT
>> + .compat_ioctl = drm_compat_ioctl,
>> +#endif
>> + .poll = drm_poll,
>> + .read = drm_read,
>> + .llseek = no_llseek,
>> + .mmap = drm_gem_cma_mmap,
>> +};
>> +EXPORT_SYMBOL(tinydrm_fops);
> Just spotted this while doing a drive-by refactoring, this doesn't really
> work. The THIS_MODULE must be in the source code for your driver, and
> can't be in some helper library module like tinydrm.ko.
Yeah, you're right.
> I'm working on a macro to make this easier, and I guess you could try to
> integrate that into your driver macro somehow (probably simplest to
> generate the entire structure and just pass name+desc to that macro,
> everything else is boilerplate anyway).
>
> I'll cc you on that patch.
Thanks.
Noralf.
Powered by blists - more mailing lists