lkml.org 
[lkml]   [2020]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
    Date


    > -----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
    >
    > 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 things 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 things 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 added.
    > > > 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 will
    > become "Supported".
    > >
    > > Given this, would it be more appropriate to put this stack into
    > > staging for a while?
    >
    > drivers/staging/ is for code that for some reason is not good enough to be merged
    > to the "right" place in the kernel tree, and you need community help to get it
    > cleaned up because you can not do it yourself.
    >
    > Is that the case here? If not, then no, it should not go into drivers/staging/.
    That is not the case here. Lets proceed as we are on this then.

    Thanks!

    --mark

    \
     
     \ /
      Last update: 2020-12-05 18:37    [W:2.426 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site