Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: a3bSB7z6aFBZwWxEcJEeDZl3C2tT0o7WtTPzPHb3NGxK0xDx8g/jtSKcngBR5MgutDbv6LnEuK
 B8XR7UqIX59A==
IronPort-SDR: igHf0N6xZuNH0SjT8YI/hy5zRhwWLyy+64oCU0jf+FV6OI7OKrgISTgwa8nD2NkAaMLwNKWQ+j
 hGhiP784KX/g==
From:   "Gross, Mark" <mark.gross@intel.com>
To:     Greg KH <gregkh@linuxfoundation.org>,
        mark gross <mgross@linux.intel.com>
CC:     "markgross@kernel.org" <markgross@kernel.org>,
        "arnd@arndb.de" <arnd@arndb.de>, "bp@suse.de" <bp@suse.de>,
        "damien.lemoal@wdc.com" <damien.lemoal@wdc.com>,
        "dragan.cvetic@xilinx.com" <dragan.cvetic@xilinx.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "leonard.crestez@nxp.com" <leonard.crestez@nxp.com>,
        "palmerdabbelt@google.com" <palmerdabbelt@google.com>,
        "paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
        "peng.fan@nxp.com" <peng.fan@nxp.com>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Alessandrelli, Daniele" <daniele.alessandrelli@intel.com>,
        "Iyer, Sundar" <sundar.iyer@intel.com>
Subject: RE: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
Thread-Topic: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
Thread-Index: AQHWyDJR6ibfO+n2Z0iYweamtROKuKnjVOgAgAC/kwCAABYoAIADtESAgABVJ4CAAIUUMA==
Date:   Sat, 5 Dec 2020 16:37:25 +0000
Message-ID: <MWHPR11MB16793B6D480A452273A60C5C8EF00@MWHPR11MB1679.namprd11.prod.outlook.com>
References: <20201201223511.65542-1-mgross@linux.intel.com>
 <20201201223511.65542-4-mgross@linux.intel.com> <X8cxNA3GTi/LrTt/@kroah.com>
 <20201202174200.GG63356@mtg-dev.jf.intel.com> <X8fkflUXwSTGAoyQ@kroah.com>
 <20201205033517.GA49179@linux.intel.com> <X8tHY5W/ueQYEaN6@kroah.com>
In-Reply-To: <X8tHY5W/ueQYEaN6@kroah.com>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.5.1.3
dlp-product: dlpe-windows
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b2a5516d-57a8-4106-6612-08d8993c0c91
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2020 16:37:25.9188
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bA+GwF0BQcuqS5gCOn3O0bFIVDqlpJWlxz/px3nGLOfpzI3iMeRohjBmd8RL+KM/M3XHppM8X9aFeQtqEw1XNw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB2029
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> -----Original Message-----
> From: Greg KH <gregkh@linuxfoundation.org>
> Sent: Saturday, December 5, 2020 12:40 AM
> To: mark gross <mgross@linux.intel.com>
> Cc: markgross@kernel.org; arnd@arndb.de; bp@suse.de;
> damien.lemoal@wdc.com; dragan.cvetic@xilinx.com; corbet@lwn.net;
> leonard.crestez@nxp.com; palmerdabbelt@google.com;
> paul.walmsley@sifive.com; peng.fan@nxp.com; robh+dt@kernel.org;
> shawnguo@kernel.org; linux-kernel@vger.kernel.org; Alessandrelli, Daniele
> <daniele.alessandrelli@intel.com>; Iyer, Sundar <sundar.iyer@intel.com>
> Subject: Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
>=20
> On Fri, Dec 04, 2020 at 07:35:17PM -0800, mark gross wrote:
> > On Wed, Dec 02, 2020 at 08:01:18PM +0100, Greg KH wrote:
> > > On Wed, Dec 02, 2020 at 09:42:00AM -0800, mark gross wrote:
> > > > On Wed, Dec 02, 2020 at 07:16:20AM +0100, Greg KH wrote:
> > > > > On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgross@linux.intel.com =
wrote:
> > > > > > --- a/MAINTAINERS
> > > > > > +++ b/MAINTAINERS
> > > > > > @@ -8955,6 +8955,14 @@ M:	Deepak Saxena <dsaxena@plexity.net>
> > > > > >  S:	Maintained
> > > > > >  F:	drivers/char/hw_random/ixp4xx-rng.c
> > > > > >
> > > > > > +INTEL KEEM BAY IPC DRIVER
> > > > > > +M:	Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> > > > > > +M:	Mark Gross <mgross@linux.intel.com>
> > > > > > +S:	Maintained
> > > > > > +F:	Documentation/devicetree/bindings/soc/intel/intel,keembay-
> ipc.yaml
> > > > > > +F:	drivers/soc/intel/keembay-ipc.c
> > > > > > +F:	include/linux/soc/intel/keembay-ipc.h
> > > > >
> > > > > Sad that Intel is not going to actually pay you all to do this
> > > > > maintenance work for a brand new subsystem you are wanting to
> > > > > add to the tree :(
> > > > I thought adding my name to these maintainer items would help with
> > > > continuity as the individual engineers tend to move on to other thi=
ngs over
> time.
> > > >
> > > > While I'm paid for a number of things at intel this is one of
> > > > them.  My role is as stable as I choose it to be at the point I'm
> > > > at in my Intel career and the business unit I'm now part of.  We
> > > > can leave my name off if that would be better.
> > > >
> > > > Even if I'm not a VPU IP domain expert like Daniele is I can still
> > > > chase down the experts as needed after Daniele grows into other thi=
ngs over
> time.
> > >
> > > I'm not objecting to your, or anyone else's name on this at all.
> > > I'm just asking about Intel's support for this new codebase being add=
ed.
> > > Having a new subsystem from a major company and not have someone
> > > paid to actually maintain it seems really odd to me.
> > >
> > > That's all.  If that's Intel's stance, that's fine, just wanted to
> > > clarify it is correct as I know some people at Intel have been
> > > confused recently about just what the S: field means.
> > I've been following up on whether the status field should be
> > "Supported" or "Maintained" at this time.  For this current
> > instantiation of the VPU enabling under review here I think Maintained
> > most appropriate.  There are a good number of people who look after it.
> >
> > However; I have learned that the instantiations of the VPU after keem
> > bay and its follow on SoC will include an evolution of this stack and
> > between now and when those get close to landing that evolved version wi=
ll
> become "Supported".
> >
> > Given this, would it be more appropriate to put this stack into
> > staging for a while?
>=20
> drivers/staging/ is for code that for some reason is not good enough to b=
e merged
> to the "right" place in the kernel tree, and you need community help to g=
et it
> cleaned up because you can not do it yourself.
>=20
> Is that the case here?  If not, then no, it should not go into drivers/st=
aging/.
That is not the case here.  Lets proceed as we are on this then.

Thanks!

--mark