linux-kernel - Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 9 Nov 2016 16:59:31 +0000
From:   Eric Engestrom <eric.engestrom@...tec.com>
To:     Daniel Vetter <daniel@...ll.ch>
CC:     Eric Engestrom <eric@...estrom.ch>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        David Airlie <airlied@...ux.ie>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Wei Yongjun <yongjun_wei@...ndmicro.com.cn>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Flora Cui <Flora.Cui@....com>,
        Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
        Tom St Denis <tom.stdenis@....com>,
        Chunming Zhou <David1.Zhou@....com>,
        Thomas Hellstrom <thellstrom@...are.com>,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
        Sinclair Yeh <syeh@...are.com>,
        Xinliang Liu <z.liuxinliang@...ilicon.com>,
        Xinwei Kong <kong.kongxinwei@...ilicon.com>,
        VMware Graphics <linux-graphics-maintainer@...are.com>,
        Vitaly Prosyak <vitaly.prosyak@....com>,
        Alexandre Demers <alexandre.f.demers@...il.com>,
        Jani Nikula <jani.nikula@...el.com>,
        intel-gfx <intel-gfx@...ts.freedesktop.org>,
        Emily Deng <Emily.Deng@....com>,
        Colin Ian King <colin.king@...onical.com>,
        Junwei Zhang <Jerry.Zhang@....com>,
        Michel Dänzer <michel.daenzer@....com>,
        Alex Deucher <alexander.deucher@....com>,
        Christian König <christian.koenig@....com>
Subject: Re: [Intel-gfx] [PATCH v3] drm: move allocation out of
 drm_get_format_name()

On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote:
> On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom
> <eric.engestrom@...tec.com> wrote:
> >> Well, had to drop it again since it didn't compile:
> >>
> >>
> >>   CC [M]  drivers/gpu/drm/drm_blend.o
> >> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’:
> >> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function ‘drm_get_format_name’
> >>      drm_get_format_name(fb->pixel_format));
> >>      ^~~~~~~~~~~~~~~~~~~
> >> In file included from ./include/drm/drmP.h:71:0,
> >>                  from drivers/gpu/drm/drm_atomic.c:29:
> >> ./include/drm/drm_fourcc.h:65:7: note: declared here
> >>  char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
> >>        ^~~~~~~~~~~~~~~~~~~
> >>
> >> Can you pls rebase onto drm-misc or linux-next or something?
> >
> > That was based on airlied/drm-next (last fetched on Sunday I think),
> > I can rebase it on drm-misc if it helps, but it seems older than
> > drm-next.
> > Should I just rebase on top of current head of drm-next?
> 
> It needs to be drm-misc (linux-next doesn't have it yet) due to the
> new atomic debug work that we just landed. I'm working on drm-tip as a
> drm local integration tree to ease pains like these a bit, but that
> doesn't really exist yet.

I'm confused as to how the different trees and branches merge back to
Torvalds' tree (I'm interested in particular in drm), and I'm not sure
which branch you want me to rebase on in the drm-misc tree [1],
especially since all of them are older than drm-next [2].

I'll try to rebase on drm-misc-fixes (currently at 4da5caa6a6f82cda3193)
as it sounds about right, but it doesn't apply at all, so it'll take
a little while.

Could you give me a quick explanation or point me to a doc/page that
explains how the various trees and branches get merged?
I googled a bit and found this doc [4] by Jani, but it doesn't mention
drm-misc for instance, so I'm not sure how up-to-date and
non-intel-specific it is.

Looking at this page, something just occurred to me: did you mean
drm-fixes [3], instead of one of the branches on drm-misc?

Cheers,
  Eric

[1] git://anongit.freedesktop.org/drm/drm-misc
[2] git://people.freedesktop.org/~airlied/linux drm-next
[2] git://people.freedesktop.org/~airlied/linux drm-fixes
[3] https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html