From 735b9ffada0563afa52d0879cf6d630819ee68ad Mon Sep 17 00:00:00 2001 From: Damien Lespiau Date: Mon, 9 Jun 2014 14:39:50 +0100 Subject: drm: Driver-specific ioctls range from 0x40 to 0x9f DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99. Signed-off-by: Damien Lespiau Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter --- include/uapi/drm/drm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include/uapi') diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 9abbeb924cbb..b0b855613641 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -780,7 +780,7 @@ struct drm_prime_handle { /** * Device specific ioctls should only be in their respective headers - * The device specific ioctl range is from 0x40 to 0x99. + * The device specific ioctl range is from 0x40 to 0x9f. * Generic IOCTLS restart at 0xA0. * * \sa drmCommandNone(), drmCommandRead(), drmCommandWrite(), and -- cgit v1.2.3 From d15156138dad40205c9fdd9abe85c9e1479ae272 Mon Sep 17 00:00:00 2001 From: Douglas Gilbert Date: Tue, 1 Jul 2014 10:48:05 -0600 Subject: block SG_IO: add SG_FLAG_Q_AT_HEAD flag After the SG_IO ioctl was copied into the block layer and later into the bsg driver, subtle differences emerged. One difference is the way injected commands are queued through the block layer (i.e. this is not SCSI device queueing nor SATA NCQ). Summarizing: - SG_IO on block layer device: blk_exec*(at_head=false) - sg device SG_IO: at_head=true - bsg device SG_IO: at_head=true Some time ago Boaz Harrosh introduced a sg v4 flag called BSG_FLAG_Q_AT_TAIL to override the bsg driver default. A recent patch titled: "sg: add SG_FLAG_Q_AT_TAIL flag" allowed the sg driver default to be overridden. This patch allows a SG_IO ioctl sent to a block layer device to have its default overridden. ChangeLog: - introduce SG_FLAG_Q_AT_HEAD flag in sg.h to cause commands that are injected via a block layer device SG_IO ioctl to set at_head=true - make comments clearer about queueing in sg.h since the header is used both by the sg device and block layer device implementations of the SG_IO ioctl. - introduce BSG_FLAG_Q_AT_HEAD in bsg.h for compatibility (it does nothing) and update comments. Signed-off-by: Douglas Gilbert Reviewed-by: Christoph Hellwig Reviewed-by: Mike Christie Signed-off-by: Jens Axboe --- include/uapi/linux/bsg.h | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'include/uapi') diff --git a/include/uapi/linux/bsg.h b/include/uapi/linux/bsg.h index 7a12e1c0f371..02986cf8b6f1 100644 --- a/include/uapi/linux/bsg.h +++ b/include/uapi/linux/bsg.h @@ -10,12 +10,13 @@ #define BSG_SUB_PROTOCOL_SCSI_TRANSPORT 2 /* - * For flags member below - * sg.h sg_io_hdr also has bits defined for it's flags member. However - * none of these bits are implemented/used by bsg. The bits below are - * allocated to not conflict with sg.h ones anyway. + * For flag constants below: + * sg.h sg_io_hdr also has bits defined for it's flags member. These + * two flag values (0x10 and 0x20) have the same meaning in sg.h . For + * bsg the BSG_FLAG_Q_AT_HEAD flag is ignored since it is the deafult. */ -#define BSG_FLAG_Q_AT_TAIL 0x10 /* default, == 0 at this bit, is Q_AT_HEAD */ +#define BSG_FLAG_Q_AT_TAIL 0x10 /* default is Q_AT_HEAD */ +#define BSG_FLAG_Q_AT_HEAD 0x20 struct sg_io_v4 { __s32 guard; /* [i] 'Q' to differentiate from v3 */ -- cgit v1.2.3 From cb553215d5d277d4838d7d6b7722e964bcf5ca1f Mon Sep 17 00:00:00 2001 From: Ming Lei Date: Thu, 26 Jun 2014 17:41:47 +0800 Subject: include/uapi/linux/virtio_blk.h: introduce feature of VIRTIO_BLK_F_MQ Current virtio-blk spec only supports one virtual queue for transfering data between VM and host, and inside VM all kinds of operations on the virtual queue needs to hold one lock, so cause below problems: - bad scalability - bad throughput This patch requests to introduce feature of VIRTIO_BLK_F_MQ so that more than one virtual queues can be used to virtio-blk device, then above problems can be solved or eased. Signed-off-by: Ming Lei Acked-by: Michael S. Tsirkin Signed-off-by: Jens Axboe --- include/uapi/linux/virtio_blk.h | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h index 6d8e61c48563..9ad67b267584 100644 --- a/include/uapi/linux/virtio_blk.h +++ b/include/uapi/linux/virtio_blk.h @@ -40,6 +40,7 @@ #define VIRTIO_BLK_F_WCE 9 /* Writeback mode enabled after reset */ #define VIRTIO_BLK_F_TOPOLOGY 10 /* Topology information is available */ #define VIRTIO_BLK_F_CONFIG_WCE 11 /* Writeback mode available in config */ +#define VIRTIO_BLK_F_MQ 12 /* support more than one vq */ #ifndef __KERNEL__ /* Old (deprecated) name for VIRTIO_BLK_F_WCE. */ @@ -77,6 +78,10 @@ struct virtio_blk_config { /* writeback mode (if VIRTIO_BLK_F_CONFIG_WCE) */ __u8 wce; + __u8 unused; + + /* number of vqs, only available when VIRTIO_BLK_F_MQ is set */ + __u16 num_queues; } __attribute__((packed)); /* -- cgit v1.2.3 From b4e05923f9c5bb65ac82988d7b53cfd7425e6f36 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Sun, 20 Jul 2014 13:35:44 -0700 Subject: Input: add support for Wacom protocol 4 serial tablets Recent version of xf86-input-wacom no longer support directly accessing serial tablets. Instead xf86-input-wacom now expects all wacom tablets to be driven by the kernel and to show up as evdev devices. This has caused old serial Wacom tablets to stop working for people who still have such tablets. Julian Squires has written a serio input driver to fix this: https://github.com/tokenrove/wacom-serial-iv This is a cleaned up version of this driver with improved Graphire support (I own an old Graphire myself). Signed-off-by: Julian Squires Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov --- include/uapi/linux/serio.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/serio.h b/include/uapi/linux/serio.h index 9f53fa7fc132..becdd78295cc 100644 --- a/include/uapi/linux/serio.h +++ b/include/uapi/linux/serio.h @@ -76,5 +76,6 @@ #define SERIO_HAMPSHIRE 0x3b #define SERIO_PS2MULT 0x3c #define SERIO_TSC40 0x3d +#define SERIO_WACOM_IV 0x3e #endif /* _UAPI_SERIO_H */ -- cgit v1.2.3 From ba4e9a61ad54c438d4c7b655e94e31f23a6fe13f Mon Sep 17 00:00:00 2001 From: David Herrmann Date: Sun, 20 Jul 2014 17:27:09 -0700 Subject: Input: uinput - add UI_GET_VERSION ioctl This ioctl is the counterpart to EVIOCGVERSION and returns the uinput-version the kernel was compiled with. Reviewed-by: Peter Hutterer Signed-off-by: David Herrmann Signed-off-by: Dmitry Torokhov --- include/uapi/linux/uinput.h | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/uinput.h b/include/uapi/linux/uinput.h index 0389b489bbba..baeab83deb64 100644 --- a/include/uapi/linux/uinput.h +++ b/include/uapi/linux/uinput.h @@ -84,6 +84,15 @@ struct uinput_ff_erase { */ #define UI_GET_SYSNAME(len) _IOC(_IOC_READ, UINPUT_IOCTL_BASE, 300, len) +/** + * UI_GET_VERSION - Return version of uinput protocol + * + * This writes uinput protocol version implemented by the kernel into + * the integer pointed to by the ioctl argument. The protocol version + * is hard-coded in the kernel and is independent of the uinput device. + */ +#define UI_GET_VERSION _IOR(UINPUT_IOCTL_BASE, 301, unsigned int) + /* * To write a force-feedback-capable driver, the upload_effect * and erase_effect callbacks in input_dev must be implemented. -- cgit v1.2.3 From ff587e45a1a1690f5cd713a2782672c579460365 Mon Sep 17 00:00:00 2001 From: Vandana Kannan Date: Wed, 11 Jun 2014 10:46:48 +0530 Subject: drm/crtc: Add property for aspect ratio Added a property to enable user space to set aspect ratio. This patch contains declaration of the property and code to create the property. v2: Thierry's review comments. - Made aspect ratio enum generic instead of HDMI/CEA specfic - Removed usage of temporary aspect_ratio variable v3: Thierry's review comments. - Fixed indentation v4: Thierry's review comments. - Return ENOMEM when property creation fails Signed-off-by: Vandana Kannan Cc: Thierry Reding Reviewed-by: Thierry Reding Acked-by: Dave Airlie Signed-off-by: Daniel Vetter --- include/uapi/drm/drm_mode.h | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index def54f9e07ca..a0db2d4aa5f0 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -88,6 +88,11 @@ #define DRM_MODE_SCALE_CENTER 2 /* Centered, no scaling */ #define DRM_MODE_SCALE_ASPECT 3 /* Full screen, preserve aspect */ +/* Picture aspect ratio options */ +#define DRM_MODE_PICTURE_ASPECT_NONE 0 +#define DRM_MODE_PICTURE_ASPECT_4_3 1 +#define DRM_MODE_PICTURE_ASPECT_16_9 2 + /* Dithering mode options */ #define DRM_MODE_DITHERING_OFF 0 #define DRM_MODE_DITHERING_ON 1 -- cgit v1.2.3 From 699a0ea0823d32030b0666b28ff8633960f7ffa7 Mon Sep 17 00:00:00 2001 From: Paul Mackerras Date: Mon, 2 Jun 2014 11:02:59 +1000 Subject: KVM: PPC: Book3S: Controls for in-kernel sPAPR hypercall handling This provides a way for userspace controls which sPAPR hcalls get handled in the kernel. Each hcall can be individually enabled or disabled for in-kernel handling, except for H_RTAS. The exception for H_RTAS is because userspace can already control whether individual RTAS functions are handled in-kernel or not via the KVM_PPC_RTAS_DEFINE_TOKEN ioctl, and because the numeric value for H_RTAS is out of the normal sequence of hcall numbers. Hcalls are enabled or disabled using the KVM_ENABLE_CAP ioctl for the KVM_CAP_PPC_ENABLE_HCALL capability on the file descriptor for the VM. The args field of the struct kvm_enable_cap specifies the hcall number in args[0] and the enable/disable flag in args[1]; 0 means disable in-kernel handling (so that the hcall will always cause an exit to userspace) and 1 means enable. Enabling or disabling in-kernel handling of an hcall is effective across the whole VM. The ability for KVM_ENABLE_CAP to be used on a VM file descriptor on PowerPC is new, added by this commit. The KVM_CAP_ENABLE_CAP_VM capability advertises that this ability exists. When a VM is created, an initial set of hcalls are enabled for in-kernel handling. The set that is enabled is the set that have an in-kernel implementation at this point. Any new hcall implementations from this point onwards should not be added to the default set without a good reason. No distinction is made between real-mode and virtual-mode hcall implementations; the one setting controls them both. Signed-off-by: Paul Mackerras Signed-off-by: Alexander Graf --- include/uapi/linux/kvm.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index e11d8f170a62..0418b746cb68 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -758,6 +758,7 @@ struct kvm_ppc_smmu_info { #define KVM_CAP_VM_ATTRIBUTES 101 #define KVM_CAP_ARM_PSCI_0_2 102 #define KVM_CAP_PPC_FIXUP_HCALL 103 +#define KVM_CAP_PPC_ENABLE_HCALL 104 #ifdef KVM_CAP_IRQ_ROUTING -- cgit v1.2.3 From 92b591a4c46b103ebd3fc0d03a084e1efd331253 Mon Sep 17 00:00:00 2001 From: Alexander Graf Date: Mon, 14 Jul 2014 18:33:08 +0200 Subject: KVM: Allow KVM_CHECK_EXTENSION on the vm fd The KVM_CHECK_EXTENSION is only available on the kvm fd today. Unfortunately on PPC some of the capabilities change depending on the way a VM was created. So instead we need a way to expose capabilities as VM ioctl, so that we can see which VM type we're using (HV or PR). To enable this, add the KVM_CHECK_EXTENSION ioctl to our vm ioctl portfolio. Signed-off-by: Alexander Graf Acked-by: Paolo Bonzini --- include/uapi/linux/kvm.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 0418b746cb68..51776cac6a9b 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -759,6 +759,7 @@ struct kvm_ppc_smmu_info { #define KVM_CAP_ARM_PSCI_0_2 102 #define KVM_CAP_PPC_FIXUP_HCALL 103 #define KVM_CAP_PPC_ENABLE_HCALL 104 +#define KVM_CAP_CHECK_EXTENSION_VM 105 #ifdef KVM_CAP_IRQ_ROUTING -- cgit v1.2.3 From ce91ddc471b77ec75e5b2a43c803efac605f37b3 Mon Sep 17 00:00:00 2001 From: Alexander Graf Date: Mon, 28 Jul 2014 19:29:13 +0200 Subject: KVM: PPC: Remove DCR handling DCR handling was only needed for 440 KVM. Since we removed it, we can also remove handling of DCR accesses. Signed-off-by: Alexander Graf --- include/uapi/linux/kvm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'include/uapi') diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 51776cac6a9b..f6f24aeb9e1a 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -162,7 +162,7 @@ struct kvm_pit_config { #define KVM_EXIT_TPR_ACCESS 12 #define KVM_EXIT_S390_SIEIC 13 #define KVM_EXIT_S390_RESET 14 -#define KVM_EXIT_DCR 15 +#define KVM_EXIT_DCR 15 /* deprecated */ #define KVM_EXIT_NMI 16 #define KVM_EXIT_INTERNAL_ERROR 17 #define KVM_EXIT_OSI 18 @@ -268,7 +268,7 @@ struct kvm_run { __u64 trans_exc_code; __u32 pgm_code; } s390_ucontrol; - /* KVM_EXIT_DCR */ + /* KVM_EXIT_DCR (deprecated) */ struct { __u32 dcrn; __u32 data; -- cgit v1.2.3 From 7e6edb9b2e0bcfb2a588db390c44d120213c57ae Mon Sep 17 00:00:00 2001 From: Matan Barak Date: Thu, 31 Jul 2014 11:01:28 +0300 Subject: IB/core: Add user MR re-registration support Memory re-registration is a feature that enables changing the attributes of a memory region registered by user-space, including PD, translation (address and length) and access flags. Add the required support in uverbs and the kernel verbs API. Signed-off-by: Matan Barak Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier --- include/uapi/rdma/ib_user_verbs.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/rdma/ib_user_verbs.h b/include/uapi/rdma/ib_user_verbs.h index cbfdd4ca9510..26daf55ff76e 100644 --- a/include/uapi/rdma/ib_user_verbs.h +++ b/include/uapi/rdma/ib_user_verbs.h @@ -276,6 +276,22 @@ struct ib_uverbs_reg_mr_resp { __u32 rkey; }; +struct ib_uverbs_rereg_mr { + __u64 response; + __u32 mr_handle; + __u32 flags; + __u64 start; + __u64 length; + __u64 hca_va; + __u32 pd_handle; + __u32 access_flags; +}; + +struct ib_uverbs_rereg_mr_resp { + __u32 lkey; + __u32 rkey; +}; + struct ib_uverbs_dereg_mr { __u32 mr_handle; }; -- cgit v1.2.3 From 7678d71fb4bd6abe6ccb46afe7d90b3ed01ee936 Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Tue, 3 Jun 2014 14:56:57 +0200 Subject: drm/tegra: Add SET/GET_TILING IOCTLs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently the tiling parameters of buffer objects can only be set at allocation time, and only a single tiled mode is supported. This new DRM_TEGRA_GEM_SET_TILING IOCTL allows more modes to be set and also allows the tiling mode to be changed after the allocation. This will enable the Tegra DRM driver to import buffers from a GPU and directly scan them out by configuring the display controller appropriately. To complement this, the DRM_TEGRA_GEM_GET_TILING IOCTL can query the current tiling mode of a buffer object. This is necessary when importing buffers via handle (as is done in Mesa for example) so that userspace can determine the proper parameters for the 2D or 3D engines. Reviewed-by: Stéphane Marchesin Tested-by: Alexandre Courbot Signed-off-by: Thierry Reding --- include/uapi/drm/tegra_drm.h | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h index b75482112428..0829f75eb986 100644 --- a/include/uapi/drm/tegra_drm.h +++ b/include/uapi/drm/tegra_drm.h @@ -129,6 +129,27 @@ struct drm_tegra_submit { __u32 reserved[5]; /* future expansion */ }; +#define DRM_TEGRA_GEM_TILING_MODE_PITCH 0 +#define DRM_TEGRA_GEM_TILING_MODE_TILED 1 +#define DRM_TEGRA_GEM_TILING_MODE_BLOCK 2 + +struct drm_tegra_gem_set_tiling { + /* input */ + __u32 handle; + __u32 mode; + __u32 value; + __u32 pad; +}; + +struct drm_tegra_gem_get_tiling { + /* input */ + __u32 handle; + /* output */ + __u32 mode; + __u32 value; + __u32 pad; +}; + #define DRM_TEGRA_GEM_CREATE 0x00 #define DRM_TEGRA_GEM_MMAP 0x01 #define DRM_TEGRA_SYNCPT_READ 0x02 @@ -139,6 +160,8 @@ struct drm_tegra_submit { #define DRM_TEGRA_GET_SYNCPT 0x07 #define DRM_TEGRA_SUBMIT 0x08 #define DRM_TEGRA_GET_SYNCPT_BASE 0x09 +#define DRM_TEGRA_GEM_SET_TILING 0x0a +#define DRM_TEGRA_GEM_GET_TILING 0x0b #define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create) #define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap) @@ -150,5 +173,7 @@ struct drm_tegra_submit { #define DRM_IOCTL_TEGRA_GET_SYNCPT DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GET_SYNCPT, struct drm_tegra_get_syncpt) #define DRM_IOCTL_TEGRA_SUBMIT DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_SUBMIT, struct drm_tegra_submit) #define DRM_IOCTL_TEGRA_GET_SYNCPT_BASE DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GET_SYNCPT_BASE, struct drm_tegra_get_syncpt_base) +#define DRM_IOCTL_TEGRA_GEM_SET_TILING DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GEM_SET_TILING, struct drm_tegra_gem_set_tiling) +#define DRM_IOCTL_TEGRA_GEM_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GEM_GET_TILING, struct drm_tegra_gem_get_tiling) #endif -- cgit v1.2.3 From 7b129087874b925901def7ae507f7d9fac406211 Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Tue, 10 Jun 2014 12:04:03 +0200 Subject: drm/tegra: Add SET/GET_FLAGS IOCTLs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The DRM_TEGRA_GEM_SET_FLAGS IOCTL can be used to set the flags of a buffer object after it has been allocated or imported. Flags associated with a buffer object can be queried using the DRM_TEGRA_GEM_GET_FLAGS IOCTL. Reviewed-by: Stéphane Marchesin Tested-by: Alexandre Courbot Signed-off-by: Thierry Reding --- include/uapi/drm/tegra_drm.h | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h index 0829f75eb986..c15d781ecc0f 100644 --- a/include/uapi/drm/tegra_drm.h +++ b/include/uapi/drm/tegra_drm.h @@ -150,6 +150,23 @@ struct drm_tegra_gem_get_tiling { __u32 pad; }; +#define DRM_TEGRA_GEM_BOTTOM_UP (1 << 0) +#define DRM_TEGRA_GEM_FLAGS (DRM_TEGRA_GEM_BOTTOM_UP) + +struct drm_tegra_gem_set_flags { + /* input */ + __u32 handle; + /* output */ + __u32 flags; +}; + +struct drm_tegra_gem_get_flags { + /* input */ + __u32 handle; + /* output */ + __u32 flags; +}; + #define DRM_TEGRA_GEM_CREATE 0x00 #define DRM_TEGRA_GEM_MMAP 0x01 #define DRM_TEGRA_SYNCPT_READ 0x02 @@ -162,6 +179,8 @@ struct drm_tegra_gem_get_tiling { #define DRM_TEGRA_GET_SYNCPT_BASE 0x09 #define DRM_TEGRA_GEM_SET_TILING 0x0a #define DRM_TEGRA_GEM_GET_TILING 0x0b +#define DRM_TEGRA_GEM_SET_FLAGS 0x0c +#define DRM_TEGRA_GEM_GET_FLAGS 0x0d #define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create) #define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap) @@ -175,5 +194,7 @@ struct drm_tegra_gem_get_tiling { #define DRM_IOCTL_TEGRA_GET_SYNCPT_BASE DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GET_SYNCPT_BASE, struct drm_tegra_get_syncpt_base) #define DRM_IOCTL_TEGRA_GEM_SET_TILING DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GEM_SET_TILING, struct drm_tegra_gem_set_tiling) #define DRM_IOCTL_TEGRA_GEM_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GEM_GET_TILING, struct drm_tegra_gem_get_tiling) +#define DRM_IOCTL_TEGRA_GEM_SET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GEM_SET_FLAGS, struct drm_tegra_gem_set_flags) +#define DRM_IOCTL_TEGRA_GEM_GET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_GEM_GET_FLAGS, struct drm_tegra_gem_get_flags) #endif -- cgit v1.2.3 From 1b69be5e8afc634f39ad695a6ab6aad0cf0975c7 Mon Sep 17 00:00:00 2001 From: Gavin Shan Date: Tue, 10 Jun 2014 11:41:57 +1000 Subject: drivers/vfio: EEH support for VFIO PCI device The patch adds new IOCTL commands for sPAPR VFIO container device to support EEH functionality for PCI devices, which have been passed through from host to somebody else via VFIO. Signed-off-by: Gavin Shan Acked-by: Alexander Graf Acked-by: Alex Williamson Signed-off-by: Benjamin Herrenschmidt --- include/uapi/linux/vfio.h | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index cb9023d4f063..6612974c64bf 100644 --- a/include/uapi/linux/vfio.h +++ b/include/uapi/linux/vfio.h @@ -30,6 +30,9 @@ */ #define VFIO_DMA_CC_IOMMU 4 +/* Check if EEH is supported */ +#define VFIO_EEH 5 + /* * The IOCTL interface is designed for extensibility by embedding the * structure length (argsz) and flags into structures passed between @@ -455,6 +458,37 @@ struct vfio_iommu_spapr_tce_info { #define VFIO_IOMMU_SPAPR_TCE_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12) +/* + * EEH PE operation struct provides ways to: + * - enable/disable EEH functionality; + * - unfreeze IO/DMA for frozen PE; + * - read PE state; + * - reset PE; + * - configure PE. + */ +struct vfio_eeh_pe_op { + __u32 argsz; + __u32 flags; + __u32 op; +}; + +#define VFIO_EEH_PE_DISABLE 0 /* Disable EEH functionality */ +#define VFIO_EEH_PE_ENABLE 1 /* Enable EEH functionality */ +#define VFIO_EEH_PE_UNFREEZE_IO 2 /* Enable IO for frozen PE */ +#define VFIO_EEH_PE_UNFREEZE_DMA 3 /* Enable DMA for frozen PE */ +#define VFIO_EEH_PE_GET_STATE 4 /* PE state retrieval */ +#define VFIO_EEH_PE_STATE_NORMAL 0 /* PE in functional state */ +#define VFIO_EEH_PE_STATE_RESET 1 /* PE reset in progress */ +#define VFIO_EEH_PE_STATE_STOPPED 2 /* Stopped DMA and IO */ +#define VFIO_EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA only */ +#define VFIO_EEH_PE_STATE_UNAVAIL 5 /* State unavailable */ +#define VFIO_EEH_PE_RESET_DEACTIVATE 5 /* Deassert PE reset */ +#define VFIO_EEH_PE_RESET_HOT 6 /* Assert hot reset */ +#define VFIO_EEH_PE_RESET_FUNDAMENTAL 7 /* Assert fundamental reset */ +#define VFIO_EEH_PE_CONFIGURE 8 /* PE configuration */ + +#define VFIO_EEH_PE_OP _IO(VFIO_TYPE, VFIO_BASE + 21) + /* ***************************************************************** */ #endif /* _UAPIVFIO_H */ -- cgit v1.2.3 From 77497f2735ad6e29c55475e15e9790dbfa2c2ef8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michel=20D=C3=A4nzer?= Date: Thu, 17 Jul 2014 19:01:07 +0900 Subject: drm/radeon: Pass GART page flags to radeon_gart_set_page() explicitly MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Michel Dänzer Reviewed-by: Christian König Signed-off-by: Alex Deucher --- include/uapi/drm/radeon_drm.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'include/uapi') diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h index 1cc0b610f162..509b2d7a41b7 100644 --- a/include/uapi/drm/radeon_drm.h +++ b/include/uapi/drm/radeon_drm.h @@ -796,7 +796,9 @@ struct drm_radeon_gem_info { uint64_t vram_visible; }; -#define RADEON_GEM_NO_BACKING_STORE 1 +#define RADEON_GEM_NO_BACKING_STORE (1 << 0) +#define RADEON_GEM_GTT_UC (1 << 1) +#define RADEON_GEM_GTT_WC (1 << 2) struct drm_radeon_gem_create { uint64_t size; -- cgit v1.2.3 From 753a2ad54ef45e3417a9d49537c2b42b04a2e1be Mon Sep 17 00:00:00 2001 From: Pablo Neira Date: Thu, 7 Aug 2014 00:17:09 +0200 Subject: net: reallocate new socket option number for IPV6_AUTOFLOWLABEL cb1ce2e ("ipv6: Implement automatic flow label generation on transmit") accidentally uses socket option 64, which is already used by ip6tables: IP6T_SO_SET_REPLACE / IP6T_SO_GET_INFO 64 IP6T_SO_SET_ADD_COUNTERS / IP6T_SO_GET_ENTRIES 65 There is comment include/uapi/linux/in6.h warning about that. Allocate 70 for this, which seems to be unused instead. Cc: Tom Herbert Signed-off-by: Pablo Neira Ayuso Signed-off-by: David S. Miller --- include/uapi/linux/in6.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include/uapi') diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h index 22b7a69619d8..74a2a1773494 100644 --- a/include/uapi/linux/in6.h +++ b/include/uapi/linux/in6.h @@ -233,7 +233,6 @@ struct in6_flowlabel_req { #if 0 /* not yet */ #define IPV6_USE_MIN_MTU 63 #endif -#define IPV6_AUTOFLOWLABEL 64 /* * Netfilter (1) @@ -262,6 +261,7 @@ struct in6_flowlabel_req { * IP6T_SO_ORIGINAL_DST 80 */ +#define IPV6_AUTOFLOWLABEL 70 /* RFC5014: Source address selection */ #define IPV6_ADDR_PREFERENCES 72 -- cgit v1.2.3 From 40e041a2c858b3caefc757e26cb85bfceae5062b Mon Sep 17 00:00:00 2001 From: David Herrmann Date: Fri, 8 Aug 2014 14:25:27 -0700 Subject: shm: add sealing API If two processes share a common memory region, they usually want some guarantees to allow safe access. This often includes: - one side cannot overwrite data while the other reads it - one side cannot shrink the buffer while the other accesses it - one side cannot grow the buffer beyond previously set boundaries If there is a trust-relationship between both parties, there is no need for policy enforcement. However, if there's no trust relationship (eg., for general-purpose IPC) sharing memory-regions is highly fragile and often not possible without local copies. Look at the following two use-cases: 1) A graphics client wants to share its rendering-buffer with a graphics-server. The memory-region is allocated by the client for read/write access and a second FD is passed to the server. While scanning out from the memory region, the server has no guarantee that the client doesn't shrink the buffer at any time, requiring rather cumbersome SIGBUS handling. 2) A process wants to perform an RPC on another process. To avoid huge bandwidth consumption, zero-copy is preferred. After a message is assembled in-memory and a FD is passed to the remote side, both sides want to be sure that neither modifies this shared copy, anymore. The source may have put sensible data into the message without a separate copy and the target may want to parse the message inline, to avoid a local copy. While SIGBUS handling, POSIX mandatory locking and MAP_DENYWRITE provide ways to achieve most of this, the first one is unproportionally ugly to use in libraries and the latter two are broken/racy or even disabled due to denial of service attacks. This patch introduces the concept of SEALING. If you seal a file, a specific set of operations is blocked on that file forever. Unlike locks, seals can only be set, never removed. Hence, once you verified a specific set of seals is set, you're guaranteed that no-one can perform the blocked operations on this file, anymore. An initial set of SEALS is introduced by this patch: - SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced in size. This affects ftruncate() and open(O_TRUNC). - GROW: If SEAL_GROW is set, the file in question cannot be increased in size. This affects ftruncate(), fallocate() and write(). - WRITE: If SEAL_WRITE is set, no write operations (besides resizing) are possible. This affects fallocate(PUNCH_HOLE), mmap() and write(). - SEAL: If SEAL_SEAL is set, no further seals can be added to a file. This basically prevents the F_ADD_SEAL operation on a file and can be set to prevent others from adding further seals that you don't want. The described use-cases can easily use these seals to provide safe use without any trust-relationship: 1) The graphics server can verify that a passed file-descriptor has SEAL_SHRINK set. This allows safe scanout, while the client is allowed to increase buffer size for window-resizing on-the-fly. Concurrent writes are explicitly allowed. 2) For general-purpose IPC, both processes can verify that SEAL_SHRINK, SEAL_GROW and SEAL_WRITE are set. This guarantees that neither process can modify the data while the other side parses it. Furthermore, it guarantees that even with writable FDs passed to the peer, it cannot increase the size to hit memory-limits of the source process (in case the file-storage is accounted to the source). The new API is an extension to fcntl(), adding two new commands: F_GET_SEALS: Return a bitset describing the seals on the file. This can be called on any FD if the underlying file supports sealing. F_ADD_SEALS: Change the seals of a given file. This requires WRITE access to the file and F_SEAL_SEAL may not already be set. Furthermore, the underlying file must support sealing and there may not be any existing shared mapping of that file. Otherwise, EBADF/EPERM is returned. The given seals are _added_ to the existing set of seals on the file. You cannot remove seals again. The fcntl() handler is currently specific to shmem and disabled on all files. A file needs to explicitly support sealing for this interface to work. A separate syscall is added in a follow-up, which creates files that support sealing. There is no intention to support this on other file-systems. Semantics are unclear for non-volatile files and we lack any use-case right now. Therefore, the implementation is specific to shmem. Signed-off-by: David Herrmann Acked-by: Hugh Dickins Cc: Michael Kerrisk Cc: Ryan Lortie Cc: Lennart Poettering Cc: Daniel Mack Cc: Andy Lutomirski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- include/uapi/linux/fcntl.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h index 074b886c6be0..beed138bd359 100644 --- a/include/uapi/linux/fcntl.h +++ b/include/uapi/linux/fcntl.h @@ -27,6 +27,21 @@ #define F_SETPIPE_SZ (F_LINUX_SPECIFIC_BASE + 7) #define F_GETPIPE_SZ (F_LINUX_SPECIFIC_BASE + 8) +/* + * Set/Get seals + */ +#define F_ADD_SEALS (F_LINUX_SPECIFIC_BASE + 9) +#define F_GET_SEALS (F_LINUX_SPECIFIC_BASE + 10) + +/* + * Types of seals + */ +#define F_SEAL_SEAL 0x0001 /* prevent further seals from being set */ +#define F_SEAL_SHRINK 0x0002 /* prevent file from shrinking */ +#define F_SEAL_GROW 0x0004 /* prevent file from growing */ +#define F_SEAL_WRITE 0x0008 /* prevent writes */ +/* (1U << 31) is reserved for signed error codes */ + /* * Types of directory notifications that may be requested. */ -- cgit v1.2.3 From 9183df25fe7b194563db3fec6dc3202a5855839c Mon Sep 17 00:00:00 2001 From: David Herrmann Date: Fri, 8 Aug 2014 14:25:29 -0700 Subject: shm: add memfd_create() syscall memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor that you can pass to mmap(). It can support sealing and avoids any connection to user-visible mount-points. Thus, it's not subject to quotas on mounted file-systems, but can be used like malloc()'ed memory, but with a file-descriptor to it. memfd_create() returns the raw shmem file, so calls like ftruncate() can be used to modify the underlying inode. Also calls like fstat() will return proper information and mark the file as regular file. If you want sealing, you can specify MFD_ALLOW_SEALING. Otherwise, sealing is not supported (like on all other regular files). Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not subject to a filesystem size limit. It is still properly accounted to memcg limits, though, and to the same overcommit or no-overcommit accounting as all user memory. Signed-off-by: David Herrmann Acked-by: Hugh Dickins Cc: Michael Kerrisk Cc: Ryan Lortie Cc: Lennart Poettering Cc: Daniel Mack Cc: Andy Lutomirski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- include/uapi/linux/memfd.h | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 include/uapi/linux/memfd.h (limited to 'include/uapi') diff --git a/include/uapi/linux/memfd.h b/include/uapi/linux/memfd.h new file mode 100644 index 000000000000..534e364bda92 --- /dev/null +++ b/include/uapi/linux/memfd.h @@ -0,0 +1,8 @@ +#ifndef _UAPI_LINUX_MEMFD_H +#define _UAPI_LINUX_MEMFD_H + +/* flags for memfd_create(2) (unsigned int) */ +#define MFD_CLOEXEC 0x0001U +#define MFD_ALLOW_SEALING 0x0002U + +#endif /* _UAPI_LINUX_MEMFD_H */ -- cgit v1.2.3 From cb1052581e2bddd6096544f3f944f4e7fdad4c7f Mon Sep 17 00:00:00 2001 From: Vivek Goyal Date: Fri, 8 Aug 2014 14:25:57 -0700 Subject: kexec: implementation of new syscall kexec_file_load Previous patch provided the interface definition and this patch prvides implementation of new syscall. Previously segment list was prepared in user space. Now user space just passes kernel fd, initrd fd and command line and kernel will create a segment list internally. This patch contains generic part of the code. Actual segment preparation and loading is done by arch and image specific loader. Which comes in next patch. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Vivek Goyal Cc: Borislav Petkov Cc: Michael Kerrisk Cc: Yinghai Lu Cc: Eric Biederman Cc: H. Peter Anvin Cc: Matthew Garrett Cc: Greg Kroah-Hartman Cc: Dave Young Cc: WANG Chao Cc: Baoquan He Cc: Andy Lutomirski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- include/uapi/linux/kexec.h | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h index d6629d49a243..6925f5b42f89 100644 --- a/include/uapi/linux/kexec.h +++ b/include/uapi/linux/kexec.h @@ -13,6 +13,17 @@ #define KEXEC_PRESERVE_CONTEXT 0x00000002 #define KEXEC_ARCH_MASK 0xffff0000 +/* + * Kexec file load interface flags. + * KEXEC_FILE_UNLOAD : Unload already loaded kexec/kdump image. + * KEXEC_FILE_ON_CRASH : Load/unload operation belongs to kdump image. + * KEXEC_FILE_NO_INITRAMFS : No initramfs is being loaded. Ignore the initrd + * fd field. + */ +#define KEXEC_FILE_UNLOAD 0x00000001 +#define KEXEC_FILE_ON_CRASH 0x00000002 +#define KEXEC_FILE_NO_INITRAMFS 0x00000004 + /* These values match the ELF architecture values. * Unless there is a good reason that should continue to be the case. */ -- cgit v1.2.3 From a4e610b5e655186f81f18f027d2b7a15e010cbef Mon Sep 17 00:00:00 2001 From: Ben Skeggs Date: Sun, 10 Aug 2014 04:10:23 +1000 Subject: drm/nouveau: use ioctl interface for abi16 grobj alloc Signed-off-by: Ben Skeggs --- include/uapi/drm/nouveau_drm.h | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h index 2a5769fdf8ba..ed0b7bd4b473 100644 --- a/include/uapi/drm/nouveau_drm.h +++ b/include/uapi/drm/nouveau_drm.h @@ -25,6 +25,14 @@ #ifndef __NOUVEAU_DRM_H__ #define __NOUVEAU_DRM_H__ +/* reserved object handles when using deprecated object APIs - these + * are here so that libdrm can allow interoperability with the new + * object APIs + */ +#define NOUVEAU_ABI16_CLIENT 0xffffffff +#define NOUVEAU_ABI16_DEVICE 0xdddddddd +#define NOUVEAU_ABI16_CHAN(n) (0xcccc0000 | (n)) + #define NOUVEAU_GEM_DOMAIN_CPU (1 << 0) #define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1) #define NOUVEAU_GEM_DOMAIN_GART (1 << 2) -- cgit v1.2.3 From 27111a23d01c1dba3180c998629004ab4c9ac985 Mon Sep 17 00:00:00 2001 From: Ben Skeggs Date: Sun, 10 Aug 2014 04:10:31 +1000 Subject: drm/nouveau: expose the full object/event interfaces to userspace Signed-off-by: Ben Skeggs --- include/uapi/drm/nouveau_drm.h | 3 +++ 1 file changed, 3 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h index ed0b7bd4b473..0d7608dc1a34 100644 --- a/include/uapi/drm/nouveau_drm.h +++ b/include/uapi/drm/nouveau_drm.h @@ -25,6 +25,8 @@ #ifndef __NOUVEAU_DRM_H__ #define __NOUVEAU_DRM_H__ +#define DRM_NOUVEAU_EVENT_NVIF 0x80000000 + /* reserved object handles when using deprecated object APIs - these * are here so that libdrm can allow interoperability with the new * object APIs @@ -131,6 +133,7 @@ struct drm_nouveau_gem_cpu_fini { #define DRM_NOUVEAU_GROBJ_ALLOC 0x04 /* deprecated */ #define DRM_NOUVEAU_NOTIFIEROBJ_ALLOC 0x05 /* deprecated */ #define DRM_NOUVEAU_GPUOBJ_FREE 0x06 /* deprecated */ +#define DRM_NOUVEAU_NVIF 0x07 #define DRM_NOUVEAU_GEM_NEW 0x40 #define DRM_NOUVEAU_GEM_PUSHBUF 0x41 #define DRM_NOUVEAU_GEM_CPU_PREP 0x42 -- cgit v1.2.3 From 0f29b46d49b0ca50536632c6a33986c3171f5ea1 Mon Sep 17 00:00:00 2001 From: Ira Weiny Date: Fri, 8 Aug 2014 19:00:55 -0400 Subject: IB/mad: add new ioctl to ABI to support new registration options Registrations options are specified through flags. Definitions of flags will be in subsequent patches. Signed-off-by: Ira Weiny Signed-off-by: Roland Dreier --- include/uapi/rdma/ib_user_mad.h | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/rdma/ib_user_mad.h b/include/uapi/rdma/ib_user_mad.h index d6fce1cbdb90..c00b081dc10e 100644 --- a/include/uapi/rdma/ib_user_mad.h +++ b/include/uapi/rdma/ib_user_mad.h @@ -191,6 +191,42 @@ struct ib_user_mad_reg_req { __u8 rmpp_version; }; +/** + * ib_user_mad_reg_req2 - MAD registration request + * + * @id - Set by the _kernel_; used by userspace to identify the + * registered agent in future requests. + * @qpn - Queue pair number; must be 0 or 1. + * @mgmt_class - Indicates which management class of MADs should be + * receive by the caller. This field is only required if + * the user wishes to receive unsolicited MADs, otherwise + * it should be 0. + * @mgmt_class_version - Indicates which version of MADs for the given + * management class to receive. + * @res - Ignored. + * @flags - additional registration flags; Must be in the set of + * flags defined in IB_USER_MAD_REG_FLAGS_CAP + * @method_mask - The caller wishes to receive unsolicited MADs for the + * methods whose bit(s) is(are) set. + * @oui - Indicates IEEE OUI to use when mgmt_class is a vendor + * class in the range from 0x30 to 0x4f. Otherwise not + * used. + * @rmpp_version - If set, indicates the RMPP version to use. + */ +#define IB_USER_MAD_REG_FLAGS_CAP (0) +struct ib_user_mad_reg_req2 { + __u32 id; + __u32 qpn; + __u8 mgmt_class; + __u8 mgmt_class_version; + __u16 res; + __u32 flags; + __u64 method_mask[2]; + __u32 oui; + __u8 rmpp_version; + __u8 reserved[3]; +}; + #define IB_IOCTL_MAGIC 0x1b #define IB_USER_MAD_REGISTER_AGENT _IOWR(IB_IOCTL_MAGIC, 1, \ @@ -200,4 +236,7 @@ struct ib_user_mad_reg_req { #define IB_USER_MAD_ENABLE_PKEY _IO(IB_IOCTL_MAGIC, 3) +#define IB_USER_MAD_REGISTER_AGENT2 _IOWR(IB_IOCTL_MAGIC, 4, \ + struct ib_user_mad_reg_req2) + #endif /* IB_USER_MAD_H */ -- cgit v1.2.3 From 1471cb6ca67990a306500e69e52ffb28c93ccbbc Mon Sep 17 00:00:00 2001 From: Ira Weiny Date: Fri, 8 Aug 2014 19:00:56 -0400 Subject: IB/mad: Add user space RMPP support Using the new registration mechanism, define a flag that indicates the user wishes to process RMPP messages in user space rather than have the kernel process them. Signed-off-by: Ira Weiny Signed-off-by: Roland Dreier --- include/uapi/rdma/ib_user_mad.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'include/uapi') diff --git a/include/uapi/rdma/ib_user_mad.h b/include/uapi/rdma/ib_user_mad.h index c00b081dc10e..09f809f323ea 100644 --- a/include/uapi/rdma/ib_user_mad.h +++ b/include/uapi/rdma/ib_user_mad.h @@ -213,7 +213,10 @@ struct ib_user_mad_reg_req { * used. * @rmpp_version - If set, indicates the RMPP version to use. */ -#define IB_USER_MAD_REG_FLAGS_CAP (0) +enum { + IB_USER_MAD_USER_RMPP = (1 << 0), +}; +#define IB_USER_MAD_REG_FLAGS_CAP (IB_USER_MAD_USER_RMPP) struct ib_user_mad_reg_req2 { __u32 id; __u32 qpn; -- cgit v1.2.3 From db1044d458a287c18c4d413adc4ad12e92e253b5 Mon Sep 17 00:00:00 2001 From: Doug Ledford Date: Tue, 12 Aug 2014 19:20:11 -0400 Subject: RDMA/uapi: Include socket.h in rdma_user_cm.h added struct sockaddr_storage to rdma_user_cm.h without also adding an include for linux/socket.h to make sure it is defined. Systemtap needs the header files to build standalone and cannot rely on other files to pre-include other headers, so add linux/socket.h to the list of includes in this file. Fixes: ee7aed4528f ("RDMA/ucma: Support querying for AF_IB addresses") Signed-off-by: Doug Ledford Signed-off-by: Roland Dreier --- include/uapi/rdma/rdma_user_cm.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/uapi') diff --git a/include/uapi/rdma/rdma_user_cm.h b/include/uapi/rdma/rdma_user_cm.h index 99b80abf360a..3066718eb120 100644 --- a/include/uapi/rdma/rdma_user_cm.h +++ b/include/uapi/rdma/rdma_user_cm.h @@ -34,6 +34,7 @@ #define RDMA_USER_CM_H #include +#include #include #include #include -- cgit v1.2.3 From 503e6636b6f96056210062be703356f4253b6db9 Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Mon, 11 Aug 2014 14:24:47 +0100 Subject: asm-generic: add memfd_create system call to unistd.h Commit 9183df25fe7b ("shm: add memfd_create() syscall") added a new system call (memfd_create) but didn't update the asm-generic unistd header. This patch adds the new system call to the asm-generic version of unistd.h so that it can be used by architectures such as arm64. Cc: Arnd Bergmann Reviewed-by: David Herrmann Signed-off-by: Will Deacon --- include/uapi/asm-generic/unistd.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'include/uapi') diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index f1afd607f043..11d11bc5c78f 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -703,9 +703,11 @@ __SYSCALL(__NR_renameat2, sys_renameat2) __SYSCALL(__NR_seccomp, sys_seccomp) #define __NR_getrandom 278 __SYSCALL(__NR_getrandom, sys_getrandom) +#define __NR_memfd_create 279 +__SYSCALL(__NR_memfd_create, sys_memfd_create) #undef __NR_syscalls -#define __NR_syscalls 279 +#define __NR_syscalls 280 /* * All syscalls below here should go away really, -- cgit v1.2.3 From 701e1e789142042144c8cc10b8f6d1554e960144 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= Date: Fri, 15 Aug 2014 11:52:53 +0200 Subject: drm/radeon: properly document reloc priority mask MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Instead of hard coding the value properly document that this is an userspace interface. No intended functional change. Signed-off-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org --- include/uapi/drm/radeon_drm.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/uapi') diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h index 509b2d7a41b7..fea6099608ef 100644 --- a/include/uapi/drm/radeon_drm.h +++ b/include/uapi/drm/radeon_drm.h @@ -944,6 +944,7 @@ struct drm_radeon_cs_chunk { }; /* drm_radeon_cs_reloc.flags */ +#define RADEON_RELOC_PRIO_MASK (0xf << 0) struct drm_radeon_cs_reloc { uint32_t handle; -- cgit v1.2.3 From fa71f32b5de2be1644ee671ddbe211d79be7847f Mon Sep 17 00:00:00 2001 From: David Herrmann Date: Tue, 29 Jul 2014 17:14:21 +0200 Subject: HID: uhid: add ABI compatible UHID_GET_REPORT replacing UHID_FEATURE The old hdev->hid_get_raw_report() was broken by design. It was never clear what kind of HW request it should trigger. Benjamin fixed that with the core HID cleanup, though we never really adjusted uhid. Unfortunately, our old UHID_FEATURE command was modelled around the broken hid_get_raw_report(). We converted it silently to the new GET_REPORT and nothing broke. Make this explicit by renaming UHID_FEATURE to UHID_GET_REPORT and UHID_FEATURE_ANSWER to UHID_GET_REPORT_REPLY. Note that this is 100% ABI compatible to UHID_FEATURE. This is just a rename. But we have to keep the old definitions around to not break API. >From now on, UHID_GET_REPORT must trigger a GET_REPORT request on the user-space hardware layer. All the ambiguity due to the weird "feature" name should be gone now. Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina --- include/uapi/linux/uhid.h | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) (limited to 'include/uapi') diff --git a/include/uapi/linux/uhid.h b/include/uapi/linux/uhid.h index 1e3b09c191cd..0a08f2bbe642 100644 --- a/include/uapi/linux/uhid.h +++ b/include/uapi/linux/uhid.h @@ -33,8 +33,10 @@ enum uhid_event_type { UHID_OUTPUT, UHID_OUTPUT_EV, /* obsolete! */ UHID_INPUT, - UHID_FEATURE, - UHID_FEATURE_ANSWER, + UHID_FEATURE, /* obsolete! use UHID_GET_REPORT */ + UHID_GET_REPORT = UHID_FEATURE, + UHID_FEATURE_ANSWER, /* obsolete! use UHID_GET_REPORT_REPLY */ + UHID_GET_REPORT_REPLY = UHID_FEATURE_ANSWER, UHID_CREATE2, UHID_INPUT2, }; @@ -98,12 +100,20 @@ struct uhid_output_ev_req { __s32 value; } __attribute__((__packed__)); +/* Obsolete! Kernel uses ABI compatible UHID_GET_REPORT. */ struct uhid_feature_req { __u32 id; __u8 rnum; __u8 rtype; } __attribute__((__packed__)); +struct uhid_get_report_req { + __u32 id; + __u8 rnum; + __u8 rtype; +} __attribute__((__packed__)); + +/* Obsolete! Use ABI compatible UHID_GET_REPORT_REPLY. */ struct uhid_feature_answer_req { __u32 id; __u16 err; @@ -111,6 +121,13 @@ struct uhid_feature_answer_req { __u8 data[UHID_DATA_MAX]; } __attribute__((__packed__)); +struct uhid_get_report_reply_req { + __u32 id; + __u16 err; + __u16 size; + __u8 data[UHID_DATA_MAX]; +} __attribute__((__packed__)); + struct uhid_event { __u32 type; @@ -120,7 +137,9 @@ struct uhid_event { struct uhid_output_req output; struct uhid_output_ev_req output_ev; struct uhid_feature_req feature; + struct uhid_get_report_req get_report; struct uhid_feature_answer_req feature_answer; + struct uhid_get_report_reply_req get_report_reply; struct uhid_create2_req create2; struct uhid_input2_req input2; } u; -- cgit v1.2.3 From 50598e7055d0d8610732e7eb2c84cbc3bc7db294 Mon Sep 17 00:00:00 2001 From: David Herrmann Date: Tue, 29 Jul 2014 17:14:22 +0200 Subject: HID: uhid: keep legacy definitions at the bottom of uhid.h Instead of inlining the legacy definitions into the main part of uhid.h, keep them at the bottom now. This way, the API is much easier to read and legacy requests can be looked up at a separate place. Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina --- include/uapi/linux/uhid.h | 101 ++++++++++++++++++++++++++++------------------ 1 file changed, 62 insertions(+), 39 deletions(-) (limited to 'include/uapi') diff --git a/include/uapi/linux/uhid.h b/include/uapi/linux/uhid.h index 0a08f2bbe642..116536eeae62 100644 --- a/include/uapi/linux/uhid.h +++ b/include/uapi/linux/uhid.h @@ -24,37 +24,21 @@ #include enum uhid_event_type { - UHID_CREATE, + __UHID_LEGACY_CREATE, UHID_DESTROY, UHID_START, UHID_STOP, UHID_OPEN, UHID_CLOSE, UHID_OUTPUT, - UHID_OUTPUT_EV, /* obsolete! */ - UHID_INPUT, - UHID_FEATURE, /* obsolete! use UHID_GET_REPORT */ - UHID_GET_REPORT = UHID_FEATURE, - UHID_FEATURE_ANSWER, /* obsolete! use UHID_GET_REPORT_REPLY */ - UHID_GET_REPORT_REPLY = UHID_FEATURE_ANSWER, + __UHID_LEGACY_OUTPUT_EV, + __UHID_LEGACY_INPUT, + UHID_GET_REPORT, + UHID_GET_REPORT_REPLY, UHID_CREATE2, UHID_INPUT2, }; -struct uhid_create_req { - __u8 name[128]; - __u8 phys[64]; - __u8 uniq[64]; - __u8 __user *rd_data; - __u16 rd_size; - - __u16 bus; - __u32 vendor; - __u32 product; - __u32 version; - __u32 country; -} __attribute__((__packed__)); - struct uhid_create2_req { __u8 name[128]; __u8 phys[64]; @@ -76,24 +60,67 @@ enum uhid_report_type { UHID_INPUT_REPORT, }; -struct uhid_input_req { +struct uhid_input2_req { + __u16 size; + __u8 data[UHID_DATA_MAX]; +} __attribute__((__packed__)); + +struct uhid_output_req { __u8 data[UHID_DATA_MAX]; __u16 size; + __u8 rtype; } __attribute__((__packed__)); -struct uhid_input2_req { +struct uhid_get_report_req { + __u32 id; + __u8 rnum; + __u8 rtype; +} __attribute__((__packed__)); + +struct uhid_get_report_reply_req { + __u32 id; + __u16 err; __u16 size; __u8 data[UHID_DATA_MAX]; } __attribute__((__packed__)); -struct uhid_output_req { +/* + * Compat Layer + * All these commands and requests are obsolete. You should avoid using them in + * new code. We support them for backwards-compatibility, but you might not get + * access to new feature in case you use them. + */ + +enum uhid_legacy_event_type { + UHID_CREATE = __UHID_LEGACY_CREATE, + UHID_OUTPUT_EV = __UHID_LEGACY_OUTPUT_EV, + UHID_INPUT = __UHID_LEGACY_INPUT, + UHID_FEATURE = UHID_GET_REPORT, + UHID_FEATURE_ANSWER = UHID_GET_REPORT_REPLY, +}; + +/* Obsolete! Use UHID_CREATE2. */ +struct uhid_create_req { + __u8 name[128]; + __u8 phys[64]; + __u8 uniq[64]; + __u8 __user *rd_data; + __u16 rd_size; + + __u16 bus; + __u32 vendor; + __u32 product; + __u32 version; + __u32 country; +} __attribute__((__packed__)); + +/* Obsolete! Use UHID_INPUT2. */ +struct uhid_input_req { __u8 data[UHID_DATA_MAX]; __u16 size; - __u8 rtype; } __attribute__((__packed__)); -/* Obsolete! Newer kernels will no longer send these events but instead convert - * it into raw output reports via UHID_OUTPUT. */ +/* Obsolete! Kernel uses UHID_OUTPUT exclusively now. */ struct uhid_output_ev_req { __u16 type; __u16 code; @@ -107,12 +134,6 @@ struct uhid_feature_req { __u8 rtype; } __attribute__((__packed__)); -struct uhid_get_report_req { - __u32 id; - __u8 rnum; - __u8 rtype; -} __attribute__((__packed__)); - /* Obsolete! Use ABI compatible UHID_GET_REPORT_REPLY. */ struct uhid_feature_answer_req { __u32 id; @@ -121,12 +142,14 @@ struct uhid_feature_answer_req { __u8 data[UHID_DATA_MAX]; } __attribute__((__packed__)); -struct uhid_get_report_reply_req { - __u32 id; - __u16 err; - __u16 size; - __u8 data[UHID_DATA_MAX]; -} __attribute__((__packed__)); +/* + * UHID Events + * All UHID events from and to the kernel are encoded as "struct uhid_event". + * The "type" field contains a UHID_* type identifier. All payload depends on + * that type and can be accessed via ev->u.XYZ accordingly. + * If user-space writes short events, they're extended with 0s by the kernel. If + * the kernel writes short events, user-space shall extend them with 0s. + */ struct uhid_event { __u32 type; -- cgit v1.2.3 From 11c221553080408b203a00b91ad5f647dfb218d1 Mon Sep 17 00:00:00 2001 From: David Herrmann Date: Tue, 29 Jul 2014 17:14:24 +0200 Subject: HID: uhid: implement SET_REPORT We so far lacked support for hid_hw_raw_request(..., HID_REQ_SET_REPORT); Add support for it and simply forward the request to user-space. Note that SET_REPORT is synchronous, just like GET_REPORT, even though it does not provide any data back besides an error code. If a transport layer does SET_REPORT asynchronously, they can just ACK it immediately by writing an uhid_set_report_reply to uhid. This patch re-uses the synchronous uhid-report infrastructure to query user-space. Note that this means you cannot run SET_REPORT and GET_REPORT in parallel. However, that has always been a restriction of HID and due to its blocking nature, this is just fine. Maybe some future transport layer supports parallel requests (very unlikely), however, until then lets not over-complicate things and avoid request-lookup-tables. Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina --- include/uapi/linux/uhid.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/uhid.h b/include/uapi/linux/uhid.h index 116536eeae62..62aac0e4edf3 100644 --- a/include/uapi/linux/uhid.h +++ b/include/uapi/linux/uhid.h @@ -37,6 +37,8 @@ enum uhid_event_type { UHID_GET_REPORT_REPLY, UHID_CREATE2, UHID_INPUT2, + UHID_SET_REPORT, + UHID_SET_REPORT_REPLY, }; struct uhid_create2_req { @@ -84,6 +86,19 @@ struct uhid_get_report_reply_req { __u8 data[UHID_DATA_MAX]; } __attribute__((__packed__)); +struct uhid_set_report_req { + __u32 id; + __u8 rnum; + __u8 rtype; + __u16 size; + __u8 data[UHID_DATA_MAX]; +} __attribute__((__packed__)); + +struct uhid_set_report_reply_req { + __u32 id; + __u16 err; +} __attribute__((__packed__)); + /* * Compat Layer * All these commands and requests are obsolete. You should avoid using them in @@ -165,6 +180,8 @@ struct uhid_event { struct uhid_get_report_reply_req get_report_reply; struct uhid_create2_req create2; struct uhid_input2_req input2; + struct uhid_set_report_req set_report; + struct uhid_set_report_reply_req set_report_reply; } u; } __attribute__((__packed__)); -- cgit v1.2.3 From c2b2f16c5c62583d4f8904e44c4b30c94a01eaf1 Mon Sep 17 00:00:00 2001 From: David Herrmann Date: Tue, 29 Jul 2014 17:14:25 +0200 Subject: HID: uhid: report to user-space whether reports are numbered This makes UHID_START include a "dev_flags" field that describes details of the hid-device in the kernel. The first flags we introduce describe whether a given report-type uses numbered reports. This is useful for transport layers that force report-numbers and therefore might have to prefix kernel-provided HID-messages with the report-number. Currently, only HoG needs this and the spec only talks about "global report numbers". That is, it's a global boolean not a per-type boolean. However, given the quirks we already have in kernel-space, a per-type value seems much more appropriate. Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina --- include/uapi/linux/uhid.h | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/uhid.h b/include/uapi/linux/uhid.h index 62aac0e4edf3..aaa86d6bd1dd 100644 --- a/include/uapi/linux/uhid.h +++ b/include/uapi/linux/uhid.h @@ -54,6 +54,16 @@ struct uhid_create2_req { __u8 rd_data[HID_MAX_DESCRIPTOR_SIZE]; } __attribute__((__packed__)); +enum uhid_dev_flag { + UHID_DEV_NUMBERED_FEATURE_REPORTS = (1ULL << 0), + UHID_DEV_NUMBERED_OUTPUT_REPORTS = (1ULL << 1), + UHID_DEV_NUMBERED_INPUT_REPORTS = (1ULL << 2), +}; + +struct uhid_start_req { + __u64 dev_flags; +}; + #define UHID_DATA_MAX 4096 enum uhid_report_type { @@ -182,6 +192,7 @@ struct uhid_event { struct uhid_input2_req input2; struct uhid_set_report_req set_report; struct uhid_set_report_reply_req set_report_reply; + struct uhid_start_req start; } u; } __attribute__((__packed__)); -- cgit v1.2.3