[PATCH v5 10/10] gna: add open and close operations on GNA device

[Daniel Vetter]

On Fri, 21 Oct 2022 at 06:27, Greg Kroah-Hartman
<gregkh at linuxfoundation.org> wrote:
>
> On Thu, Oct 20, 2022 at 07:53:34PM +0200, Maciej Kwapulinski wrote:
> > From: Tomasz Jankowski <tomasz1.jankowski at intel.com>
> >
> > Signed-off-by: Tomasz Jankowski <tomasz1.jankowski at intel.com>
> > Tested-by: Mikolaj Grzybowski <mikolajx.grzybowski at intel.com>
> > Co-developed-by: Jianxun Zhang <jianxun.zhang at linux.intel.com>
> > Signed-off-by: Jianxun Zhang <jianxun.zhang at linux.intel.com>
> > Co-developed-by: Maciej Kwapulinski <maciej.kwapulinski at linux.intel.com>
> > Signed-off-by: Maciej Kwapulinski <maciej.kwapulinski at linux.intel.com>
>
> That's a lot of people who missed that there is nothing described here
> at all :(
>
> Please please please work with the Intel internal kernel developers and
> get this all reviewed properly first before sending anything out again.
> I want to see their signed-off-by or reviewed-by on them before anything
> is sent out again.

This is partially on me, because I'm asking everyone (including intel
folks) to ditch internal review for dri-devel patches and submit
directly.

Of course that means you can get stuff like this which isn't really reviewable.

This part here is for the gna folks, not for Greg.

Now the other side of dri-devel review is that generally subsystem
maintainers never ever look at the patches, and instead we fully rely
on peer review.

This means:
- you review other people's driver patches, ideally also in the
accel/render space and not so much display drm drivers (there's plenty
of everything)
- you ask these people to review your patches
- usually one of them has commit rights already and can push the
stuff, if not _then_ and only then ask maintainers to land things

Quick search on lore says that gna posts on dri-devel have been rather
one-way thus far. Someone has to pay for upstream/community review of
your gna patches, and tit-for-tat economy is about the best we've
figured out thus far. Also tit-for-tat will get rid of unreviewable
patches real fast in my opinion because suddenly it becomes very
important that you're not squandering the painfully acquired review
credits you have on pointless stuff.

If you need help in figuring out what other patches you can review
please show up on #dri-devel irc on oftc, there's tons of people there
usually and we have enormous piles of patches inflight at any moment.

Back to Greg: I much appreciate you reviewing all the various
(occasionally nonsense) patches dri-devel comes up with, but maybe
it's best if you set the gna (and vpu too I guess) driver efforts onto
your ignore lists? I assume you very much want to stay up to date on
the patches that come out of the accel bof discussion from Oded, and I
guess i915 folks having questions about driver/pm changes is also
good. But for the random oddball drivers intel's pushing I think it's
just net negative on your time here.

Plan B is that we also put stern limits into place for intel patches
to dri-devel, but looking at gna+vpu we already seem to have a one-way
dumping ground going on, so I really don't want to encourage intel to
be even more a silo and disappear behind the company firewall.

Cheers, Daniel

>
> thanks,
>
> greg k-h




--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch