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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 30 Aug 2017 11:09:43 +0200 From: Thomas Hellstrom <thellstrom@...are.com> To: Arvind Yadav <arvind.yadav.cs@...il.com>, airlied@...ux.ie, syeh@...are.com, linux-graphics-maintainer@...are.com, linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org Subject: Re: [PATCH] drm: vmwgfx: constify vmw_fence_ops On 08/30/2017 10:30 AM, Daniel Vetter wrote: > On Wed, Aug 30, 2017 at 08:21:46AM +0200, Thomas Hellstrom wrote: >> On 08/30/2017 07:47 AM, Arvind Yadav wrote: >>> vmw_fence_ops are not supposed to change at runtime. Functions >>> "dma_fence_init" working with const vmw_fence_ops provided >>> by <linux/dma-fence.h>. So mark the non-const structs as const. >>> >>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@...il.com> >>> --- >>> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c >>> index b8bc5bc..abc5f03 100644 >>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c >>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c >>> @@ -225,7 +225,7 @@ static long vmw_fence_wait(struct dma_fence *f, bool intr, signed long timeout) >>> return ret; >>> } >>> -static struct dma_fence_ops vmw_fence_ops = { >>> +static const struct dma_fence_ops vmw_fence_ops = { >>> .get_driver_name = vmw_fence_get_driver_name, >>> .get_timeline_name = vmw_fence_get_timeline_name, >>> .enable_signaling = vmw_fence_enable_signaling, >> Reviewed-by: Thomas Hellstrom <thellstrom@...are.com> > Does this mean you'll merge it, or does this mean you'll expect someone > else to merge this? > > I'm always confused when maintainers reply with an r-b/ack for a patch > only touching their driver, and no further information at all. > -Daniel For patches only touching our driver, I'd say we're always responsible for sorting out how it's going to be merged. Since Sinclair is maintaining the vmwgfx trees I thought I'd give him a chance to comment on how he wanted it merged. /Thomas
Powered by blists - more mailing lists