Hi Tom,
> -----Original Message-----
> From: Tom Rix <[email protected]>
> Sent: Sunday, May 8, 2022 6:07 AM
> To: Chautru, Nicolas <[email protected]>; [email protected];
> [email protected]
> Cc: [email protected]; Kinsella, Ray <[email protected]>; Richardson,
> Bruce <[email protected]>; [email protected]; Zhang,
> Mingshan <[email protected]>; [email protected]
> Subject: Re: [PATCH v2 2/5] baseband/acc100: modify validation code for
> ACC101
>
>
> On 4/27/22 11:17 AM, Nicolas Chautru wrote:
> > The validation requirement is different for the two devices.
> >
> > Signed-off-by: Nicolas Chautru <[email protected]>
> > ---
> > drivers/baseband/acc100/rte_acc100_pmd.c | 40
> ++++++++++++++++++++++----------
> > 1 file changed, 28 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> > b/drivers/baseband/acc100/rte_acc100_pmd.c
> > index fca27ef..daf2ce0 100644
> > --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> > @@ -1293,6 +1293,14 @@
> > return (q->d->device_variant == ACC100_VARIANT);
> > }
> >
> > +#ifdef RTE_LIBRTE_BBDEV_DEBUG
> > +static inline bool
> > +validate_op_required(struct acc100_queue *q)
>
> There isn't an #else case so this will fail to build.
There is no else required I believe, since that function is not used when the
RTE_LIBRTE_BBDEV_DEBUG is not set. It should build on both (I believe this is
tested by CICD).
>
> This i believe could be another function in private data fops i suggested in
> the
> first patch.
In that case we do not expect to validate the input on ACC100, there is not
such function.
>
> Tom
>
> > +{
> > + return is_acc100(q);
> > +}
> > +#endif
> > +
