On Fri, Sep 01, 2017 at 08:14:16AM +0000, Horia Geantă wrote: > On 8/31/2017 7:20 PM, Greg Kroah-Hartman wrote: > > On Wed, Aug 30, 2017 at 01:41:58PM +0300, Horia Geantă wrote: > >> This patch set adds support for functionalities needed by the upcoming > >> dpseci (Data Path SEC Interface) object device driver: > >> -Frame List Entries (FLEs) > >> -Congestion State Change Notifications (CSCNs) > >> -Order Preservation > >> > >> An RFC has been previously submitted: > >> https://www.mail-archive.com/linux-crypto@xxxxxxxxxxxxxxx/msg27290.html > >> and crypto-specific (dpseci) patches have been ack-ed. > >> > >> I am resending the dpio dependencies separately (patches 1-4 in the RFC) > >> for inclusion in the staging tree. > > > > I'd rather see some users of the new code before I add the logic to the > > kernel. We don't add code that isn't used... > > > The user is the DPAA2 crypto engine - RFC patches 5-9 (link above), RFC patches mean that the submitter doesn't think they should be merged, so why should I? :) > I've split the RFC patch set, since: > -crypto-specific patches (5-9) received the ack from maintainer (Herbert Xu) > -DPIO dependencies (staging tree), i.e. patches 1-4, received no > attention -> hence sending them separately > > I am open to suggestions on how to go with a patch set that is touching > the staging and crypto trees. If they have an ack already, and are dependant on these patches, then send them all at once. But again, I really want to see this code out of staging before adding new functionality, like this. Please work on that first. And yes, I have said I need to review the code to get it out of staging, but if you could do that as well, and give your ack/reviewed by to the patch that does the move, that would help... thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
