linux-kernel - Re: [PATCH 0/9] staging: fsl-mc: move bus driver out of staging, add dpio

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <580E1BDE.6050302@suse.de>
Date:   Mon, 24 Oct 2016 16:34:06 +0200
From:   Alexander Graf <agraf@...e.de>
To:     Stuart Yoder <stuart.yoder@....com>, gregkh@...uxfoundation.org
Cc:     german.rivera@....com, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org, arnd@...db.de, 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:

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?

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.

Alex