All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Sasha Levin <sashal@kernel.org>
Cc: linux-hyperv@vger.kernel.org, sthemmin@microsoft.com,
	tvrtko.ursulin@intel.com, haiyangz@microsoft.com,
	spronovo@microsoft.com, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	wei.liu@kernel.org, linux-fbdev@vger.kernel.org,
	iourit@microsoft.com, alexander.deucher@amd.com,
	kys@microsoft.com, Hawking.Zhang@amd.com
Subject: Re: [RFC PATCH 1/4] gpu: dxgkrnl: core code
Date: Tue, 19 May 2020 17:19:06 +0000	[thread overview]
Message-ID: <20200519171906.GA1101627@kroah.com> (raw)
In-Reply-To: <20200519163234.226513-2-sashal@kernel.org>

On Tue, May 19, 2020 at 12:32:31PM -0400, Sasha Levin wrote:
> +/*
> + * Dxgkrnl Graphics Port Driver ioctl definitions
> + *
> + */
> +
> +#define LX_IOCTL_DIR_WRITE 0x1
> +#define LX_IOCTL_DIR_READ  0x2
> +
> +#define LX_IOCTL_DIR(_ioctl)	(((_ioctl) >> 30) & 0x3)
> +#define LX_IOCTL_SIZE(_ioctl)	(((_ioctl) >> 16) & 0x3FFF)
> +#define LX_IOCTL_TYPE(_ioctl)	(((_ioctl) >> 8) & 0xFF)
> +#define LX_IOCTL_CODE(_ioctl)	(((_ioctl) >> 0) & 0xFF)

Why create new ioctl macros, can't the "normal" kernel macros work
properly?

> +#define LX_IOCTL(_dir, _size, _type, _code) (	\
> +	(((uint)(_dir) & 0x3) << 30) |		\
> +	(((uint)(_size) & 0x3FFF) << 16) |	\
> +	(((uint)(_type) & 0xFF) << 8) |		\
> +	(((uint)(_code) & 0xFF) << 0))
> +
> +#define LX_IO(_type, _code) LX_IOCTL(0, 0, (_type), (_code))
> +#define LX_IOR(_type, _code, _size)	\
> +	LX_IOCTL(LX_IOCTL_DIR_READ, (_size), (_type), (_code))
> +#define LX_IOW(_type, _code, _size)	\
> +	LX_IOCTL(LX_IOCTL_DIR_WRITE, (_size), (_type), (_code))
> +#define LX_IOWR(_type, _code, _size)	\
> +	LX_IOCTL(LX_IOCTL_DIR_WRITE |	\
> +	LX_IOCTL_DIR_READ, (_size), (_type), (_code))
> +
> +#define LX_DXOPENADAPTERFROMLUID	\
> +	LX_IOWR(0x47, 0x01, sizeof(struct d3dkmt_openadapterfromluid))

<snip>

These structures do not seem to be all using the correct types for a
"real" ioctl in the kernel, so you will have to fix them all up before
this will work properly.

> +void ioctl_desc_init(void);

Very odd global name you are using here :)

Anyway, neat stuff, glad to see it posted, great work!

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Sasha Levin <sashal@kernel.org>
Cc: alexander.deucher@amd.com, chris@chris-wilson.co.uk,
	ville.syrjala@linux.intel.com, Hawking.Zhang@amd.com,
	tvrtko.ursulin@intel.com, linux-kernel@vger.kernel.org,
	linux-hyperv@vger.kernel.org, kys@microsoft.com,
	haiyangz@microsoft.com, sthemmin@microsoft.com,
	wei.liu@kernel.org, spronovo@microsoft.com, iourit@microsoft.com,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] gpu: dxgkrnl: core code
Date: Tue, 19 May 2020 19:19:06 +0200	[thread overview]
Message-ID: <20200519171906.GA1101627@kroah.com> (raw)
In-Reply-To: <20200519163234.226513-2-sashal@kernel.org>

On Tue, May 19, 2020 at 12:32:31PM -0400, Sasha Levin wrote:
> +/*
> + * Dxgkrnl Graphics Port Driver ioctl definitions
> + *
> + */
> +
> +#define LX_IOCTL_DIR_WRITE 0x1
> +#define LX_IOCTL_DIR_READ  0x2
> +
> +#define LX_IOCTL_DIR(_ioctl)	(((_ioctl) >> 30) & 0x3)
> +#define LX_IOCTL_SIZE(_ioctl)	(((_ioctl) >> 16) & 0x3FFF)
> +#define LX_IOCTL_TYPE(_ioctl)	(((_ioctl) >> 8) & 0xFF)
> +#define LX_IOCTL_CODE(_ioctl)	(((_ioctl) >> 0) & 0xFF)

Why create new ioctl macros, can't the "normal" kernel macros work
properly?

> +#define LX_IOCTL(_dir, _size, _type, _code) (	\
> +	(((uint)(_dir) & 0x3) << 30) |		\
> +	(((uint)(_size) & 0x3FFF) << 16) |	\
> +	(((uint)(_type) & 0xFF) << 8) |		\
> +	(((uint)(_code) & 0xFF) << 0))
> +
> +#define LX_IO(_type, _code) LX_IOCTL(0, 0, (_type), (_code))
> +#define LX_IOR(_type, _code, _size)	\
> +	LX_IOCTL(LX_IOCTL_DIR_READ, (_size), (_type), (_code))
> +#define LX_IOW(_type, _code, _size)	\
> +	LX_IOCTL(LX_IOCTL_DIR_WRITE, (_size), (_type), (_code))
> +#define LX_IOWR(_type, _code, _size)	\
> +	LX_IOCTL(LX_IOCTL_DIR_WRITE |	\
> +	LX_IOCTL_DIR_READ, (_size), (_type), (_code))
> +
> +#define LX_DXOPENADAPTERFROMLUID	\
> +	LX_IOWR(0x47, 0x01, sizeof(struct d3dkmt_openadapterfromluid))

<snip>

These structures do not seem to be all using the correct types for a
"real" ioctl in the kernel, so you will have to fix them all up before
this will work properly.

> +void ioctl_desc_init(void);

Very odd global name you are using here :)

Anyway, neat stuff, glad to see it posted, great work!

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Sasha Levin <sashal@kernel.org>
Cc: linux-hyperv@vger.kernel.org, sthemmin@microsoft.com,
	tvrtko.ursulin@intel.com, haiyangz@microsoft.com,
	spronovo@microsoft.com, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	wei.liu@kernel.org, linux-fbdev@vger.kernel.org,
	iourit@microsoft.com, alexander.deucher@amd.com,
	kys@microsoft.com, Hawking.Zhang@amd.com
Subject: Re: [RFC PATCH 1/4] gpu: dxgkrnl: core code
Date: Tue, 19 May 2020 19:19:06 +0200	[thread overview]
Message-ID: <20200519171906.GA1101627@kroah.com> (raw)
In-Reply-To: <20200519163234.226513-2-sashal@kernel.org>

On Tue, May 19, 2020 at 12:32:31PM -0400, Sasha Levin wrote:
> +/*
> + * Dxgkrnl Graphics Port Driver ioctl definitions
> + *
> + */
> +
> +#define LX_IOCTL_DIR_WRITE 0x1
> +#define LX_IOCTL_DIR_READ  0x2
> +
> +#define LX_IOCTL_DIR(_ioctl)	(((_ioctl) >> 30) & 0x3)
> +#define LX_IOCTL_SIZE(_ioctl)	(((_ioctl) >> 16) & 0x3FFF)
> +#define LX_IOCTL_TYPE(_ioctl)	(((_ioctl) >> 8) & 0xFF)
> +#define LX_IOCTL_CODE(_ioctl)	(((_ioctl) >> 0) & 0xFF)

Why create new ioctl macros, can't the "normal" kernel macros work
properly?

> +#define LX_IOCTL(_dir, _size, _type, _code) (	\
> +	(((uint)(_dir) & 0x3) << 30) |		\
> +	(((uint)(_size) & 0x3FFF) << 16) |	\
> +	(((uint)(_type) & 0xFF) << 8) |		\
> +	(((uint)(_code) & 0xFF) << 0))
> +
> +#define LX_IO(_type, _code) LX_IOCTL(0, 0, (_type), (_code))
> +#define LX_IOR(_type, _code, _size)	\
> +	LX_IOCTL(LX_IOCTL_DIR_READ, (_size), (_type), (_code))
> +#define LX_IOW(_type, _code, _size)	\
> +	LX_IOCTL(LX_IOCTL_DIR_WRITE, (_size), (_type), (_code))
> +#define LX_IOWR(_type, _code, _size)	\
> +	LX_IOCTL(LX_IOCTL_DIR_WRITE |	\
> +	LX_IOCTL_DIR_READ, (_size), (_type), (_code))
> +
> +#define LX_DXOPENADAPTERFROMLUID	\
> +	LX_IOWR(0x47, 0x01, sizeof(struct d3dkmt_openadapterfromluid))

<snip>

These structures do not seem to be all using the correct types for a
"real" ioctl in the kernel, so you will have to fix them all up before
this will work properly.

> +void ioctl_desc_init(void);

Very odd global name you are using here :)

Anyway, neat stuff, glad to see it posted, great work!

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

  reply	other threads:[~2020-05-19 17:19 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 16:32 [RFC PATCH 0/4] DirectX on Linux Sasha Levin
2020-05-19 16:32 ` Sasha Levin
2020-05-19 16:32 ` Sasha Levin
2020-05-19 16:32 ` [RFC PATCH 1/4] gpu: dxgkrnl: core code Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 17:19   ` Greg KH [this message]
2020-05-19 17:19     ` Greg KH
2020-05-19 17:19     ` Greg KH
2020-05-19 17:21   ` Greg KH
2020-05-19 17:21     ` Greg KH
2020-05-19 17:21     ` Greg KH
2020-05-19 17:45     ` Sasha Levin
2020-05-19 17:45       ` Sasha Levin
2020-05-19 17:45       ` Sasha Levin
2020-05-20  6:13       ` Greg KH
2020-05-20  6:13         ` Greg KH
2020-05-20  6:13         ` Greg KH
2020-05-19 17:27   ` Greg KH
2020-05-19 17:27     ` Greg KH
2020-05-19 17:27     ` Greg KH
2020-05-19 16:32 ` [RFC PATCH 2/4] gpu: dxgkrnl: hook up dxgkrnl Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 23:27   ` kbuild test robot
2020-05-19 23:27   ` kbuild test robot
2020-05-20  7:05   ` kbuild test robot
2020-05-22  8:10   ` Dan Carpenter
2020-05-22  8:10     ` [kbuild] " Dan Carpenter
2020-05-30 13:48   ` kbuild test robot
2020-05-19 16:32 ` [RFC PATCH 3/4] Drivers: hv: vmbus: " Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 16:32 ` [RFC PATCH 4/4] gpu: dxgkrnl: create a MAINTAINERS entry Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 19:21 ` [RFC PATCH 0/4] DirectX on Linux Daniel Vetter
2020-05-19 19:21   ` Daniel Vetter
2020-05-19 19:21   ` Daniel Vetter
2020-05-19 20:36   ` Sasha Levin
2020-05-19 20:36     ` Sasha Levin
2020-05-19 20:36     ` Sasha Levin
2020-05-20 10:37     ` Jan Engelhardt
2020-05-20 10:37       ` Jan Engelhardt
2020-05-20 10:37       ` Jan Engelhardt
2020-06-28 23:39     ` James Hilliard
2020-06-28 23:39       ` James Hilliard
2020-06-28 23:39       ` James Hilliard
2020-05-19 22:42 ` Dave Airlie
2020-05-19 22:42   ` Dave Airlie
2020-05-19 22:42   ` Dave Airlie
2020-05-19 23:01   ` Daniel Vetter
2020-05-19 23:01     ` Daniel Vetter
2020-05-19 23:01     ` Daniel Vetter
2020-05-20  3:47     ` [EXTERNAL] " Steve Pronovost
2020-05-20  3:47       ` Steve Pronovost
2020-05-20  3:47       ` Steve Pronovost
2020-05-20  7:40       ` Daniel Vetter
2020-05-20  8:19         ` Steve Pronovost
2020-05-20 15:34           ` Steve Pronovost
2020-05-20 15:34             ` Steve Pronovost
2020-05-20 15:34             ` Steve Pronovost
2020-06-16 10:51       ` Pavel Machek
2020-06-16 10:51         ` Pavel Machek
2020-06-16 10:51         ` Pavel Machek
2020-05-19 23:12   ` Dave Airlie
2020-05-19 23:12     ` Dave Airlie
2020-05-19 23:12     ` Dave Airlie
2020-06-16 10:51     ` Pavel Machek
2020-06-16 10:51       ` Pavel Machek
2020-06-16 10:51       ` Pavel Machek
2020-06-16 13:21       ` Sasha Levin
2020-06-16 13:21         ` Sasha Levin
2020-06-16 13:21         ` Sasha Levin
2020-05-20  7:10 ` Thomas Zimmermann
2020-05-20  7:10   ` Thomas Zimmermann
2020-05-20  7:10   ` Thomas Zimmermann
2020-05-20  7:42   ` [EXTERNAL] " Steve Pronovost
2020-05-20  7:42     ` Steve Pronovost
2020-05-20  7:42     ` Steve Pronovost
2020-05-20 11:06     ` Thomas Zimmermann
2020-05-20 11:06       ` Thomas Zimmermann
2020-05-20 11:06       ` Thomas Zimmermann
2020-06-16 10:51   ` Pavel Machek
2020-06-16 10:51     ` Pavel Machek
2020-06-16 10:51     ` Pavel Machek
2020-06-16 13:28     ` Sasha Levin
2020-06-16 13:28       ` Sasha Levin
2020-06-16 13:28       ` Sasha Levin
2020-06-16 14:41       ` Pavel Machek
2020-06-16 14:41         ` Pavel Machek
2020-06-16 14:41         ` Pavel Machek
2020-06-16 16:00         ` Sasha Levin
2020-06-16 16:00           ` Sasha Levin
2020-06-16 16:00           ` Sasha Levin

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=20200519171906.GA1101627@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Hawking.Zhang@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=haiyangz@microsoft.com \
    --cc=iourit@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=spronovo@microsoft.com \
    --cc=sthemmin@microsoft.com \
    --cc=tvrtko.ursulin@intel.com \
    --cc=wei.liu@kernel.org \
    /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.