On Fri, Sep 01, 2017 at 01:02:32PM +0000, Horia Geantă wrote: > On 9/1/2017 11:30 AM, Greg Kroah-Hartman wrote: > > 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. > > > IIUC this would mean adding Herbert's ack to the crypto patches and > going with the whole patch set through the staging tree. > (Note that the crypto driver is targeting drivers/crypto, not > drivers/staging.) Yes, that is correct, and is what normally happens for cross-subsystem patch series. thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
