linux-kernel - Re: [PATCH 00/22] Intel Vision Processing Unit base enabling part 1

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20201201175313.GC56560@mtg-dev.jf.intel.com>
Date:   Tue, 1 Dec 2020 09:53:13 -0800
From:   mark gross <mgross@...ux.intel.com>
To:     Greg KH <greg@...ah.com>
Cc:     mgross@...ux.intel.com, linux-kernel@...r.kernel.org,
        markgross@...nel.org, adam.r.gretzinger@...el.com
Subject: Re: [PATCH 00/22] Intel Vision Processing Unit base enabling part 1

On Tue, Dec 01, 2020 at 11:14:12AM +0100, Greg KH wrote:
> On Mon, Nov 30, 2020 at 03:06:45PM -0800, mgross@...ux.intel.com wrote:
> > From: mark gross <mgross@...ux.intel.com>
> > 
> > The Intel Vision Processing Unit (VPU) is an IP block that is showing up for
> > the first time as part of the Keem Bay SOC.  Keem Bay is a quad core A53 Arm
> > SOC.  It is designed to be used as a stand alone SOC as well as in an PCIe
> > Vision Processing accelerator add in card.
> > 
> > This part 1 of the patches make up the base or core of the stack needed to
> > enable both use cases for the VPU.
> > 
> > Part 2 includes 11 more patches that depend on part 1.  Those should be ready
> > in a couple of weeks or less.
> > 
> > I am trying something a bit new with this sequence where I've been working with
> > the driver developers as a "pre-maintainer" reviewing and enforcing the kernel
> > expectations as I understand them.  Its taken a couple of months to get this
> > code to the point I feel its ready for public posting.  My goal is to make sure
> > it meets expectations for quality and compliance with kernel expectations and
> > there will be mostly technical / design issues to talk about.
> > 
> > Thanks for looking at these and providing feedback.
> > 
> > --mark
> > p.s. I have had a problem my MTA configuration between mutt and git send-email
> > where I was using msmpt to send from mutt (because 15+ years ago its the first
> > way I got to work and never changed) while my worstation MTA that git
> > send-email uses was un-configured resulting in my return-path naming my
> > workstion withing the firewall.  I suck at email administration.
> > 
> > I appologies for the multiple copies.
> 
> Ah, here's the full set of patches...
> 
> But, you didn't cc: everyone on them, some of us just got a partial set
> of patches, why?
Because I thought ccing everyone on all the changes was not what was expected.
Does the DT guy want to see all the non-DT changes?

this is my first time sending a big patch set that crosses subsystems like
this.  I'm not sure what the preferd way to do things so I used
get_maintainer.pl on each patch to add thime in the cc: tags just above the
signed off's.

Should I have simply concatinated the list of mainttainers and CC them all on
all the patches?

> 
> still confused,
its my fault.  

--mark