Message-ID: <VI1PR0401MB2638583008C2537897723ADB8DAB0@VI1PR0401MB2638.eurprd04.prod.outlook.com>
Date:   Wed, 26 Oct 2016 02:35:57 +0000
From:   Stuart Yoder <stuart.yoder@....com>
To:     Alexander Graf <agraf@...e.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:     German Rivera <german.rivera@....com>,
        "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "arnd@...db.de" <arnd@...db.de>, Leo Li <leoyang.li@....com>
Subject: RE: [PATCH 0/9] staging: fsl-mc: move bus driver out of staging, add
 dpio



> -----Original Message-----
> From: Alexander Graf [mailto:agraf@...e.de]
> Sent: Monday, October 24, 2016 9:34 AM
> To: Stuart Yoder <stuart.yoder@....com>; gregkh@...uxfoundation.org
> Cc: German Rivera <german.rivera@....com>; devel@...verdev.osuosl.org; linux-kernel@...r.kernel.org;
> arnd@...db.de; Leo Li <leoyang.li@....com>
> Subject: Re: [PATCH 0/9] staging: fsl-mc: move bus driver out of staging, add dpio
> 
> Hi Stuart,
> 
> On 10/21/2016 04:01 PM, Stuart Yoder wrote:
> > This patch series: A) addresses the final item in the staging
> > TODO list for the fsl-mc bus driver-- adding a functional driver
> > on top of the bus driver, and B) requests that the fsl-mc bus driver
> > be moved out of staging.
> 
> Awesome, it's great to see progress again! :)
> 
> > The proposed destination for the bus driver is drivers/bus.
> > Proposed location for global header files for fsl-mc and dpaa2
> > is include/linux/fsl.
> >
> > The functional driver added is for the DPIO object which provides
> > queuing services for other DPAA2 drivers.  An overview of the
> 
> I thought the idea of the TODO item was to have a full-fledged user of
> the bus, like a full network driver. The TODO item reads:
> 
> > -* Add at least one device driver for a DPAA2 object (child device of the
> > -  fsl-mc bus).  Most likely candidate for this is adding DPAA2 Ethernet
> > -  driver support, which depends on drivers for several objects: DPNI,
> > -  DPIO, DPMAC.  Other pre-requisites include:

DPIO is a "full fleged user" of the bus.  But, yes, it does provide
infrastructure services and so does not have a standalone I/O function.

> which to me indicates that DPIO is only part of that goal. Of course I'm
> the last person blocking progress to move the driver out of staging. But
> are we at the right point yet?

I thought the goal was to demonstrate a driver on top of the fsl-mc
bus driver because without that it would have been difficult to validate/review
that the bus infrastructure was correct.

The DPIO driver demonstrates full use of the bus driver infrastructure--
getting probed, discovering and mapping mmio regions, initializing the
device, initializing interrupts.

> To me the topmost important bit of having this outside of staging is
> actually missing in the TODO list (probably since it's obvious): Have
> stable, reliable, responsible maintainership for the code.
> 
> So far I've seen German do the initial push upstream, then there was
> silence for a while. Now some time passed and you push a few bits here
> and there again. All of the efforts are great and very appreciated, but
> I'm missing the "maintainer" figure. Some peer to German and you who
> oversees the whole thing, reviews your patches and devotes at least 2-3
> days a week to only upstream fsl-mc work. Someone like York for U-Boot
> or Scott for general Linux work.
> 
> Without that, there's too much of a chance that the code will stay
> incomplete, bitrot, etc. And that'd be bad for everyone involved. I
> think the concept behind fsl-mc is great and exactly what people need,
> so we should make sure it succeeds.

I agree we need that.  We are actively working on getting an additional
maintainer (or two), and until we can get the right person(s) I'm willing
to fill that role.  We're not going to let this code bitrot.

I actually think getting the bus driver out of staging will help spur
broader involvment by NXP engineers in the fsl-mc bus support.  There
are enhancements like a resource management interface for user space,
an interface to see the MC log buffer, SMMU-related hooks for the fsl-mc
bus, and vfio for the fsl-mc bus.  All that stuff is on hold until we
get the bus driver out of staging. The directive we have is to add no
new features until the bus driver is out.

For example, the ARM SMMU driver has an include of <linux/pci.h>,
but I don't see the SMMU maintainers accepting the following in
arm-smmu.c:
   #include <../drivers/staging/fsl-mc/include/mc.h>

Given that the fsl-mc bus TODO list is done, there is not a whole lot
for a new maintainer to do to the bus driver itself until we get the
driver out of staging (aside from reviewing another DPAA2 object driver
that would also go into staging).

Once the bus driver + dpio is out staging it also opens up the door
for other DPAA2 drivers-- network, crypto, DMA, L2 switch,
decompression/compression, and others to be upstreamed.  I didn't think
we wanted all of those to go into staging, but we were waiting until
some 1 driver was accepted first, proving the bus infrastructure is 
sound.  I was hoping DPI could be that proof of concept.

So, in short, I think getting the bus driver and DPIO out of staging
will open some parallel development and will also provide more 
opportunities for some new maintainers to get involved, because there
will be more to review and do.

However, if you want things to stay in staging for now, I will resubmit
and put DPIO there.

Thanks,
Stuart

Powered by blists - more mailing lists