linux-kernel - RE: [PATCH 7/9] bus: fsl-mc: dpio: add the DPAA2 DPIO service interface

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] [day] [month] [year] [list]

Date:   Sat, 12 Nov 2016 00:10:31 +0000
From:   Stuart Yoder <stuart.yoder@....com>
To:     Ruxandra Ioana Radulescu <ruxandra.radulescu@....com>,
        "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>,
        "agraf@...e.de" <agraf@...e.de>, "arnd@...db.de" <arnd@...db.de>,
        Leo Li <leoyang.li@....com>, Roy Pledge <roy.pledge@....com>,
        Haiying Wang <haiying.wang@....com>
Subject: RE: [PATCH 7/9] bus: fsl-mc: dpio: add the DPAA2 DPIO service
 interface

> > +/**
> > + * dpaa2_io_service_rearm() - Rearm the notification for the given DPIO
> > service.
> > + * @service: the given DPIO service.
> > + * @ctx: the notification context.
> > + *
> > + * Once a FQDAN/CDAN has been produced, the corresponding FQ/channel
> > is
> > + * considered "disarmed". Ie. the user can issue pull dequeue operations on
> > that
> > + * traffic source for as long as it likes. Eventually it may wish to "rearm"
> > + * that source to allow it to produce another FQDAN/CDAN, that's what this
> > + * function achieves.
> > + *
> > + * Return 0 for success.
> > + */
> > +int dpaa2_io_service_rearm(struct dpaa2_io *d,
> > +			   struct dpaa2_io_notification_ctx *ctx)
> > +{
> > +	unsigned long irqflags;
> > +	int err;
> > +
> > +	d = service_select(d);
> 
> Why not select the DPIO based on ctx->desired_cpu, like in the initial
> notification register?

Sounds like a reasonable idea, I am going to confirm with Roy.

Stuart