> -----Original Message----- > From: Alexander Graf [mailto:agraf@xxxxxxx] > Sent: Monday, October 24, 2016 9:34 AM > To: Stuart Yoder <stuart.yoder@xxxxxxx>; gregkh@xxxxxxxxxxxxxxxxxxx > Cc: German Rivera <german.rivera@xxxxxxx>; devel@xxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > arnd@xxxxxxxx; Leo Li <leoyang.li@xxxxxxx> > 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
