linux-kernel - Re: [PATCH 15/20] drm/radeon/r600d: Move 'rc600

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: <20201110210224.GJ2063125@dell>
Date:   Tue, 10 Nov 2020 21:02:24 +0000
From:   Lee Jones <lee.jones@...aro.org>
To:     Alex Deucher <alexdeucher@...il.com>
Cc:     Sam Ravnborg <sam@...nborg.org>, David Airlie <airlied@...ux.ie>,
        LKML <linux-kernel@...r.kernel.org>,
        Maling list - DRI developers 
        <dri-devel@...ts.freedesktop.org>,
        amd-gfx list <amd-gfx@...ts.freedesktop.org>,
        Alex Deucher <alexander.deucher@....com>,
        Christian König <christian.koenig@....com>
Subject: Re: [PATCH 15/20] drm/radeon/r600d: Move 'rc600_*' prototypes into
 shared header

On Tue, 10 Nov 2020, Alex Deucher wrote:

> On Tue, Nov 10, 2020 at 4:41 AM Lee Jones <lee.jones@...aro.org> wrote:
> >
> > On Tue, 10 Nov 2020, Sam Ravnborg wrote:
> >
> > > Hi Lee,
> > >
> > > > > the *d.h headers are supposed to just be hardware definitions.  I'd
> > > > > prefer to keep driver stuff out of them.
> > > >
> > > > That's fine (I did wonder if that were the case).
> > > >
> > > > I need an answer from you and Sam whether I can create new headers.
> > > >
> > > > For me, it is the right thing to do.
> > >
> > > Please follow the advice of Alex for the radeon driver.
> >
> > Great.  Thanks for resolving this Sam.
> >
> > Will fix all occurrences.
> 
> I'm not really following these patch sets you are sending out.  They
> all seem completely independent.  I was expecting updated versions
> with feedback integrated, but they seem to be just different fixes.
> Are you planning to send out updated versions based on feedback from
> these series?  Also, some of the patches have subtle errors in them
> (e.g., wrong descriptions of variables, wrong copyright headers on new
> files, etc.), do you mind if I fix them up locally when applying or
> would you rather I point out the changes and you can integrate them
> and resend?

Apologies for any confusion.  Let me try to shed some light.

All 4 sets sent thus far have been independent.  There are 5000 issues
to solve in drivers/gpu - I'm trying my best to whittle them down.
We're down to 2200 right now, so it seems to be going well.

I'm aware that some of the patches have been accepted already, so the
plan is to wait a few days, let them settle into -next, then start;
rebasing sets, applying fix-ups and sending out v2s.

FYI: There are also outstanding rebases due for; wireless, net, input
and SCSI, as well as the 4 DRM sets.  I'm getting to all of them.

With regards to how you deal with incorrectness, that's entirely up to
you.  Feel free to either fix-up any issues you see or to provide
review comments and let me deal with it.  Whatever works for you.

A note on copyrights on new files; the new files are copied directly
from old, previously accepted/currently residing ones in order to keep
in-line with what's expected of the subsystem.  If the format has been
updated and/or you would like them modernised, please either fix them
up at your leisure or let me know what's required and I'll rework and
resubmit them.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog