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]
Message-ID: <20200820100440.2d30dc02@coco.lan>
Date:   Thu, 20 Aug 2020 10:04:40 +0200
From:   Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To:     John Stultz <john.stultz@...aro.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linuxarm@...wei.com, mauro.chehab@...wei.com,
        Manivannan Sadhasivam <mani@...nel.org>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Bogdan Togorean <bogdan.togorean@...log.com>,
        Liwei Cai <cailiwei@...ilicon.com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Rob Herring <robh+dt@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Xinliang Liu <xinliang.liu@...aro.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Wanchun Zheng <zhengwanchun@...ilicon.com>,
        driverdevel <devel@...verdev.osuosl.org>,
        BPF Mailing List <bpf@...r.kernel.org>,
        Xiubin Zhang <zhangxiubin1@...wei.com>,
        linux-media <linux-media@...r.kernel.org>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Xinwei Kong <kong.kongxinwei@...ilicon.com>,
        Alexei Starovoitov <ast@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Rob Clark <robdclark@...omium.org>,
        Laurentiu Palcu <laurentiu.palcu@....com>,
        Andrzej Hajda <a.hajda@...sung.com>,
        John Fastabend <john.fastabend@...il.com>,
        Liuyao An <anliuyao@...wei.com>,
        "moderated list:DMA BUFFER SHARING FRAMEWORK" 
        <linaro-mm-sig@...ts.linaro.org>, Wei Xu <xuwei5@...ilicon.com>,
        Rongrong Zou <zourongrong@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Sam Ravnborg <sam@...nborg.org>,
        Network Development <netdev@...r.kernel.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        David Airlie <airlied@...ux.ie>,
        Chen Feng <puck.chen@...ilicon.com>
Subject: Re: [PATCH 00/49] DRM driver for Hikey 970

Em Wed, 19 Aug 2020 14:36:52 -0700
John Stultz <john.stultz@...aro.org> escreveu:

> On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
> <mchehab+huawei@...nel.org> wrote:
> > So, IMO, the best is to keep it on staging for a while, until those
> > remaining bugs gets solved.
> >
> > I added this series, together with the regulator driver and
> > a few other patches (including a hack to fix a Kernel 5.8
> > regression at WiFi ) at:
> >
> >         https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master  
> 
> Sorry, one more small request: Could you create a branch that only has
> the DRM driver changes in it?
> 
> The reason I ask, is that since the HiKey960 isn't affected by the
> majority of the problems you listed as motivation for going through
> staging. So if we can validate that your tree works fine on HiKey960,
> the series can be cleaned up and submitted properly upstream to enable
> that SoC, and the outstanding 970 issues can be worked out afterwards
> against mainline.

Well, if support for HiKey 960 is OK, I guess what we can do is to not 
push the patch with DT bindings for hikey970. We should probably fix
the color swap thing at the driver first.

From my side, provided that the history is preserved, I don't mind
if this is merged:

- via staging tree;
- at dri-devel tree;
- or having a the historic patchsets merged at /staging, with
  a follow up patch moving it from staging/ into /gpu/drm/.

Thanks,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ