Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> Use of this new data member will be rare, it might be worth redoing
> this as a separate/sub-type to keep the base case.
>
> Signed-off-by: Jim Cromie
> ---
> include/linux/moduleparam.h | 11 +--
> 1 file changed, 9 insertions(
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> +struct dyndbg_bitdesc {
> + /* bitpos is inferred from index in containing array */
> + char *prefix;
> + char *help;
AFAICT these two should also be constant, right?
> +int param_set_dyndbg(const char *instr, const s
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> DYNDBG_BITMAP_DESC(__gvt_debug, "dyndbg bitmap desc",
> { "gvt: cmd: ", "command processing" },
> { "gvt: core: ", "core help" },
> { "gvt: dpy: ", "display help" },
> { "gvt: el: ", "help" },
>
one says "if
it's set". Yet no drivers do "if (config->allow_fb_modifiers)".
Sadly, nothing comes to mind atm wrt alternative wording.
With the WARN_ON() added or s/must/should/ in the documentation, the series is:
Reviewed-by: Emil Velikov
HTH
-Emil
__
Hi James,
On Tue, 2 Feb 2021 at 08:27, James Park wrote:
>
> Hello,
>
> Is there something I can do to help move this patch along?
>
> Thanks,
> James Park
>
> On Thu, Dec 10, 2020 at 1:13 AM James Park wrote:
>>
>> Create drm_basic_types.h to define types previously defined by drm.h.
>>
>> Use
ince. So I
> think it's safe to retire those export types now.
>
I believe you're spot on - based on reading through git log and
checking the ML archives.
Shame I didn't get to finish a similar series I had locally. Patches
11-13 match what I have here so:
Reviewed-by: Emil Vel
c99
mode. One is welcome to ignore the warning, silence it or use c11. If neither
of the three is an option, then do _not_ set the new guard.
Cc: James Park
Cc: Pekka Paalanen
Cc: Simon Ser
Signed-off-by: Emil Velikov
---
As mentioned before - there's little point in having yet another h
Hi james,
On Tue, 2 Feb 2021 at 18:15, James Park wrote:
>
> I'm not sure what your suggestion is. Move which #ifdef block where?
>
Fair enough. Just sent out a patch which demonstrates what I have in mind.
Thanks
Emil
P.S. Please try to avoid top-posting and HTML emails in public discussions.
On Tue, 2 Feb 2021 at 23:25, James Park wrote:
>
> On Tue, Feb 2, 2021 at 2:47 PM Emil Velikov wrote:
> >
> > Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> > At the same time drm.h pulls a lot of unneeded symbols.
> >
> > Add ne
On Wed, 3 Feb 2021 at 09:27, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
> emil.l.veli...@gmail.com wrote:
>
> > As summed in the commit message the burden is only applicable when all
> > of the following are set:
>
On Wed, 3 Feb 2021 at 10:15, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 11:08 AM, Emil Velikov
> wrote:
>
> > On Wed, 3 Feb 2021 at 09:27, Simon Ser wrote:
> > >
> > > On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
On Wed, 3 Feb 2021 at 13:47, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 12:03 PM, Emil Velikov
> wrote:
>
> > No issue then, great. Let's merge this trivial solution and move on to
> > other things.
>
> Just because one compositor isn't affe
On Wed, 3 Feb 2021 at 17:58, Xiong, Jianxin wrote:
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: Wednesday, February 03, 2021 9:53 AM
> > To: Xiong, Jianxin
> > Cc: Leon Romanovsky ; Jason Gunthorpe ; Gal
> > Pressman ; Yishai Hadas
> > ; linux-rdma ; Edward
> > Srouji ; d
DRM_FOURCC_STANDALONE and compiles with C99 or earlier while
also using -pedantic _and_ the header lives outside of the standard
/usr/include (like BSDs normally do).
v2:
- Add corner-case handling, based on popular demand.
Cc: James Park
Cc: Pekka Paalanen
Cc: Simon Ser
Signed-off-by: Emil Velikov
On Wed, 3 Feb 2021 at 14:21, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 3:13 PM, Emil Velikov
> wrote:
>
> > As said before, there are multiple ways to handle this without
> > introducing yet another UAPI header. I don't see why you're dismissing
On Thu, 4 Feb 2021 at 18:17, James Park wrote:
>
> On Thu, Feb 4, 2021 at 9:37 AM James Park wrote:
> >
> > On Thu, Feb 4, 2021 at 3:37 AM Emil Velikov
> > wrote:
> > >
> > > Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
&
On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
>
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf)
As you rightfully
On Fri, 12 Feb 2021 at 13:14, Simon Ser wrote:
>
> On Friday, February 12th, 2021 at 1:57 PM, Emil Velikov
> wrote:
>
> > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> > >
> > > Userspace has discovered the functionality offered by SYS_kcmp and has
On Fri, 12 Feb 2021 at 14:01, Michel Dänzer wrote:
>
> On 2021-02-12 1:57 p.m., Emil Velikov wrote:
> > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> >>
> >> Userspace has discovered the functionality offered by SYS_kcmp and has
> >> started to d
Hi Chris,
On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote:
>
> Register with /proc/gpu to provide the client runtimes for generic
> top-like overview, e.g. gnome-system-monitor can use this information to
> show the per-process multi-GPU usage.
>
Exposing this information to userspace sounds grea
On Fri, 12 Feb 2021 at 15:16, Chris Wilson wrote:
>
> Quoting Emil Velikov (2021-02-12 14:57:56)
> > Hi Chris,
> >
> > On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote:
> > >
> > > Register with /proc/gpu to provide the client runtimes for generic
Greetings everyone,
On Mon, 15 Feb 2021 at 08:52, Lee Jones wrote:
>
> On Fri, 12 Feb 2021, Krzysztof Kozlowski wrote:
>
> > Milo Kim's email in TI bounces with permanent error (550: Invalid
> > recipient). Last email from him on LKML was in 2017. Move Milo Kim to
> > credits and remove the sep
small cleanups.
As you may have noticed, this is my first patches series to linux-media,
so any tips how to make this as smoother process are appreciated.
Looking forward to your feedback,
Emil
Emil Velikov (7):
media: hantro: use G1_REG_INTERRUPT directly for the mpeg2
media: hantro: imx
From: Emil Velikov
Use the register directly over the existing SWREG().
Ideally we'll port the driver away from the local registers, but for
now this is enough. For context - I was reading through the IRQ register
handling across the variants.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc:
From: Emil Velikov
Swap the hardcoded 16 with MB_DIM define.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov
---
drivers/staging/media/hantro/imx8m_vpu_hw.c | 4 ++--
1 file changed, 2 insertions(+), 2
From: Emil Velikov
The vpu->dec_base is already set by the hantro driver itself.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov
---
drivers/staging/media/hantro/imx8m_vpu_hw.c | 1 -
1 file changed
From: Emil Velikov
The current imx8 code does not use the jpeg encoder. Remove the
unnecessary include.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov
---
drivers/staging/media/hantro/imx8m_vpu_hw.c
From: Emil Velikov
While enabling an extra config, I've noticed that savedefconfig produced
a notable delta. Split out the no-op changes for clarity sake.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Ve
From: Emil Velikov
The SoC features a Hantro G1 compatible video decoder.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov
---
arch/arm/boot/dts/sama5d4.dtsi| 9 ++
arch/arm/configs
From: Emil Velikov
The Hantro G1 IRQ and reset handling it pretty standard. I was this
close to duplicating it, yet again, before reconsidering and refactoring
it to a separate file.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Seems like I messed up the to line and this ended in the wrong list.
Apologies for the noise o/
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, 8 Mar 2021 at 13:57, Philipp Zabel wrote:
>
> Hi Emil,
>
> On Fri, Mar 05, 2021 at 06:39:21PM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > The current imx8 code does not use the jpeg encoder. Remove the
> > unnecessary include.
> >
Hi Daniel,
Thanks for the extra clarification.
On Tue, 27 Apr 2021 at 13:22, Daniel Vetter wrote:
>
> On Tue, Apr 27, 2021 at 12:32:19PM +0100, Emil Velikov wrote:
> > Hi Daniel,
> >
> > On Tue, 27 Apr 2021 at 10:20, Daniel Vetter wrote:
> >
> &
On Tue, 4 May 2021 at 15:58, Simon Ser wrote:
>
> Continuing on that idea to push for enabling the cap in more cases: do
> we have a policy to require new drivers to always support modifiers?
>
> That would be nice, even if it's just about enabling LINEAR.
Sounds perfectly reasonable IMHO. I thin
ra
Signed-off-by: Emil Velikov
---
Greetings all,
This patch has been downstream for a while now yet it seems perfectly
reasonable thing to have in the Linux kernel.
https://github.com/ValveSoftware/steamos_kernel/commit/5431b5b1999c3d3b5efee817fb3373fbbd473063
drivers/gpu/drm/i915/display/i
Hi Ville,
On Mon, 17 May 2021 at 18:24, Ville Syrjälä
wrote:
>
> On Sun, May 16, 2021 at 06:14:32PM +0100, Emil Velikov wrote:
> > From: Vivek Das Mohapatra
> >
> > This patch is to do with seamless handover, eg when the sequence is
> > bootloader → plymouth → de
On Tue, 18 May 2021 at 12:17, Ville Syrjälä
wrote:
>
> On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote:
> > Hi Ville,
> >
> > On Mon, 17 May 2021 at 18:24, Ville Syrjälä
> > wrote:
> > >
> > > On Sun, May 16, 2021 at 06:14:32PM +0
Hi Desmond,
Couple of small suggestions, with those the series is:
Reviewed-by: Emil Velikov
On Tue, 29 Jun 2021 at 04:38, Desmond Cheong Zhi Xi
wrote:
> @@ -128,13 +137,20 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
> struct drm_master *master;
>
Greetings everyone,
Food for thought: Would it make sense to have the madvise ioctl as
generic DRM one?
Looking around - i915, msm & panfrost already have one and the virtio
implementation [below] seems as generic as it gets.
On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko
wrote:
> +#define VIRTG
timate fixes that we want regardless of the shrinker.
Please add the respective "Fixes" tag, so they find their way in the
stable trees. With that, them 3 are:
Reviewed-by: Emil Velikov
HTH
Emil
On Sun, 27 Mar 2022 at 08:39, Xiaomeng Tong wrote:
>
> The bug is here:
> return encoder;
>
> The list iterator value 'encoder' will *always* be set and non-NULL
> by drm_for_each_encoder_mask(), so it is incorrect to assume that the
> iterator value will be NULL if the list is empty or no
spec mention).
But that is for another day.
As-is the series is:
Reviewed-by: Emil Velikov
HTH
Emil
On Mon, 28 Mar 2022 at 03:09, Xiaomeng Tong wrote:
>
> on Sun, 27 Mar 2022 16:59:28 +0100, Emil Velikov wrote:
> > On Sun, 27 Mar 2022 at 08:39, Xiaomeng Tong wrote:
> > >
> > > The bug is here:
> > > return encoder;
> > >
> > > T
Hi Maxime,
On 25 April 2016 at 14:22, Maxime Ripard
wrote:
> Documentation/devicetree/bindings/clock/sunxi.txt | 2 +
> .../bindings/display/sunxi/sun4i-drm.txt | 258
> arch/arm/boot/dts/sun5i-a13.dtsi | 39 +-
> arch/arm/boot/dts/sun5i-r8-chip.dts
On 25 April 2016 at 15:19, Liviu Dudau wrote:
> Add MAINTAINERS entry for ARM Mali-DP driver and update the
> HDLCD file matching pattern to cover only HDLCD rather than
> the whole drivers/gpu/drm/arm directory.
>
> Signed-off-by: Liviu Dudau
> ---
> MAINTAINERS | 10 +-
> 1 file change
On 25 April 2016 at 18:08, Liviu Dudau wrote:
> On Mon, Apr 25, 2016 at 05:00:02PM +0100, Emil Velikov wrote:
>> On 25 April 2016 at 15:19, Liviu Dudau wrote:
>> > Add MAINTAINERS entry for ARM Mali-DP driver and update the
>> > HDLCD file matching pattern to c
On 27 April 2016 at 00:37, Dave Airlie wrote:
> On 22 April 2016 at 18:37, Daniel Vetter wrote:
>> On Thu, Apr 21, 2016 at 09:17:32PM +0100, Emil Velikov wrote:
>>> Signed-off-by: Emil Velikov
>>
>> If the extern C stuff falls through, maybe we want to pull t
On 27 April 2016 at 10:47, Russell King - ARM Linux
wrote:
> On Thu, Apr 21, 2016 at 09:17:13PM +0100, Emil Velikov wrote:
>> Dave Airlie pointed out that "polluting" the headers in a manner as seen
>> with this series might not be too wise. David H, can we hear
On 27 April 2016 at 22:57, Dave Airlie wrote:
> On 28 April 2016 at 07:45, Emil Velikov wrote:
>> On 27 April 2016 at 10:47, Russell King - ARM Linux
>> wrote:
>>> On Thu, Apr 21, 2016 at 09:17:13PM +0100, Emil Velikov wrote:
>>>> Dave Airlie pointed out that
On 3 August 2016 at 19:04, David Herrmann wrote:
> @@ -277,9 +276,9 @@ EXPORT_SYMBOL(drm_vma_offset_remove);
> /**
> * drm_vma_node_allow - Add open-file to list of allowed users
> * @node: Node to modify
> - * @filp: Open file to add
> + * @tag: Tag of file to remove
s/to remove/to add/
-E
On 3 August 2016 at 11:56, Shashank Sharma wrote:
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> +
> +/* Aspect ratio flag bitmask (4 bits 22:19) */
> +#define DRM_MODE_FLAG_PARMASK (0x0F<<19)
> +#define DRM_MODE_FLAG_PARNONE \
> +
On 4 August 2016 at 11:16, Sharma, Shashank
wrote:
> Hello Emil,
>
> Thanks for your time.
>
> I have got mixed opinion on this.
>
> IMHO we should expose them to userspace too, as UI agents like Hardware
> composer/X/Wayland must know what does these
>
> flags means, so that they can display the
On 4 August 2016 at 14:15, Sharma, Shashank
wrote:
> On 8/4/2016 5:04 PM, Emil Velikov wrote:
>>
>> On 4 August 2016 at 11:16, Sharma, Shashank
>> wrote:
>>>
>>> Hello Emil,
>>>
>>> Thanks for your time.
>>>
>>> I have
On 4 August 2016 at 17:09, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote:
>> On 4 August 2016 at 14:15, Sharma, Shashank
>> wrote:
>> > On 8/4/2016 5:04 PM, Emil Velikov wrote:
>> >>
>> >> On 4 Aug
Hi Daniel,
On 17 August 2016 at 21:56, Daniel Vetter wrote:
> --- /dev/null
> +++ b/include/drm/drm_property.h
> +#ifndef __DRM_PROPERTY_H__
> +#define __DRM_PROPERTY_H__
> +
> +#include
> +#include
> +#include
> +
Add the following fwd declaration since we use a pointer to the said
struct ?
On 19 August 2016 at 15:26, Christian König wrote:
> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>>
>> From: Marek Olšák
>>
>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>>
>> See the comment in the code. Basically, don't do cleanups in this header.
>>
>> Signed-off-by: Ma
On 20 August 2016 at 11:05, Marek Olšák wrote:
> On Sat, Aug 20, 2016 at 12:54 AM, Emil Velikov
> wrote:
>> On 19 August 2016 at 15:26, Christian König
>> wrote:
>>> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>>>>
>>>>
On 20 August 2016 at 12:47, Marek Olšák wrote:
> On Sat, Aug 20, 2016 at 1:08 PM, Emil Velikov
> wrote:
>> On 20 August 2016 at 11:05, Marek Olšák wrote:
>>> On Sat, Aug 20, 2016 at 12:54 AM, Emil Velikov >> gmail.com> wrote:
>>>> On 19 August 20
On 20 August 2016 at 16:08, Marek Olšák wrote:
> On Sat, Aug 20, 2016 at 2:20 PM, Emil Velikov
> wrote:
>> On 20 August 2016 at 12:47, Marek Olšák wrote:
>>> On Sat, Aug 20, 2016 at 1:08 PM, Emil Velikov
>>> wrote:
>>>> On 20 August 2016 at 11:0
On 20 August 2016 at 23:31, Rob Clark wrote:
> On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli wrote:
>> Cc'ing lkml too.
>>
>> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
>>> Story time:
>>> I was dreaming of a day were we can st
On 22 August 2016 at 15:38, Daniel Vetter wrote:
> On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark wrote:
>>> That said, _note_ that some applications are built with -C89 -pedantic
>>> [1] which means that using stdint.h may or may not work as expected.
>>> So we'll want a __STDC_VESION__ check + #er
On Thu, 2 May 2019 at 23:19, Rob Clark wrote:
>
> On Thu, May 2, 2019 at 2:57 PM Dan Willemsen wrote:
> >
> > On Thu, May 2, 2019 at 1:52 PM John Stultz wrote:
> > >
> > > We need solutions for the xgettext and the python-mako usage.
> >
> > Android doesn't support translations at this level, s
tio_gpu_alloc_fence()).
>
> Signed-off-by: Chia-I Wu
> Cc: Gerd Hoffmann
> Cc: Gustavo Padovan
> Cc: Robert Foss
Reviewed-by: Emil Velikov
Side:
Rob, should we follow-up on 9fdd90c0f and drop the
virtio_gpu_fence_emit() return type?
HTH
-Emil
__
k. Instead,
> we set seqno to 0 when a fence is created, and update it when the
> command is finally queued and the seqno is known.
>
> Signed-off-by: Chia-I Wu
The series looks great. For the lot:
Reviewed-by: Emil Velikov
-Emil
___
On Tue, 14 May 2019 at 11:48, Boris Brezillon
wrote:
>
> Add a way to dump perf counters through debugfs. The implementation is
> kept simple and has a number of limitations:
>
> * it's not designed for multi-user usage as the counter values are
> reset after each dump and there's no per-user co
From: Emil Velikov
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 6 --
drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
3 files changed, 1 insertion(+), 8 deletions
From: Emil Velikov
Cc: Tomi Valkeinen
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 1b9b6f5e48e1
From: Emil Velikov
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.org
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/tegra/drm.c | 28 ++--
1 file changed, 14 insertions(+
From: Emil Velikov
Should minimise the copy/paste mistakes, fixed with previous patches.
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
Daniel, not 100% sold on the idea. That plus listing you as a contact
point ;-)
What do you thing?
Emil
---
Documentation/gpu/todo.rst | 19
From: Emil Velikov
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 18 +-
1
From: Emil Velikov
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
Cc: intel-...@lists.freedesktop.org
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/driver
From: Emil Velikov
Core DRM is safe when the callback is NULL.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgf
From: Emil Velikov
Currently vmw_execbuf_ioctl() open-codes the permission checking, size
extending and copying that is already done in core drm.
Kill all the duplication, adding a few comments for clarity.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-of
From: Emil Velikov
According to the docs - prevents firstopen/lastclose races. Yet never
used in practise.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx
From: Emil Velikov
As of earlier commit the function is used only within drm core.
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_ioctl.c | 3 +--
include/drm/drm_ioctl.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm
From: Emil Velikov
Drop the custom ioctl io encoding check - core drm does it for us.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drive
:
> > > > Hi, Emil,
> > > >
> > > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> > > > > From: Emil Velikov
> > > > >
> > > > > Currently vmw_execbuf_ioctl() open-codes the permission checking,
> > &g
On 2019/05/23, Thomas Hellstrom wrote:
> Hi, Emil,
>
> On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Drop the custom ioctl io encoding check - core drm does it for us.
>
> I fail to see where the core does this, o
On 2019/05/23, Ben Skeggs wrote:
> On Thu, 23 May 2019 at 01:03, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > Cc: Ben Skeggs
> > Cc: nouv...@lists.freedesktop.org
> > Signed-off-by: Emil Velikov
> Thanks!
>
Forgot to mention, any objectio
On 2019/05/22, Daniel Vetter wrote:
> On Wed, May 22, 2019 at 04:47:02PM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Should minimise the copy/paste mistakes, fixed with previous patches.
> >
> > Cc: Daniel Vetter
> > Signed-off-by: Emil Vel
On 2019/05/23, Thierry Reding wrote:
> On Wed, May 22, 2019 at 04:46:59PM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
> >
> > Cc: Thierry Reding
> > Cc: linux
On 2019/05/24, Thomas Hellstrom wrote:
> On Fri, 2019-05-24 at 13:14 +0100, Emil Velikov wrote:
> > On 2019/05/23, Thomas Hellstrom wrote:
> > > Hi, Emil,
> > >
> > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> > > > From: Emil Ve
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instance is:
- legacy DRI1 ioctl, which is already neutered
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV htere is no distinction between primary and render
nodes, thus we can drop the token.
Note: authentication is required on a single ioctl, due to a bug in
userspace. The issue has
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Qiang Yu
Cc: l...@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
Signed-off
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: David Airlie
Cc
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instances are:
- legacy DRI1 ioctls, which are already
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Tobias Jakobi
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Rob Clark
Cc: Sean Paul
Cc: freedr...@lists.freedesktop.org
Cc: David Airlie
Cc
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instances are:
- legacy DRI1 ioctls, which are already
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa wh
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instance is:
- (badly coped) legacy DRI1 ioctl, which is a
From: Emil Velikov
Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
render node. A seemingly deliberate design decision.
Hence we can drop the DRM_AUTH all together (details in follow-up patch)
yet not all userspace checks if it's authenticated, but instead uses
unc
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vgem
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
Cc: David Airlie
On 2019/05/25, Thomas Hellstrom wrote:
> On Sat, 2019-05-25 at 00:39 +0200, Thomas Hellström wrote:
> > Hi, Emil
> >
> > On Fri, 2019-05-24 at 16:26 +0100, Emil Velikov wrote:
> > > On 2019/05/24, Thomas Hellstrom wrote:
> > > > On Fri, 2019-05-24 at 13:
On 2019/05/27, Jani Nikula wrote:
> On Mon, 27 May 2019, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > The authentication can be circumvented, by design, by using the render
> > node.
> >
> > From the driver POV there is no distinction between primary
On 2019/05/27, Koenig, Christian wrote:
> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> > render node. A seemingly deliberate design decision.
> >
> > Henc
On 2019/05/27, Christian König wrote:
> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
&g
Hi Thomas,
On 2019/05/27, Thomas Hellstrom wrote:
> > I think we might be talking past each other, let's take a step back:
> >
> > - as of previous patch, all of vmwgfx ioctls size is consistently
> > handled by the core
>
> I don't think I follow you here, AFAICT patch 3/5 only affects and
>
1 - 100 of 2172 matches
Mail list logo
