Subject: Re: [PATCH v2 net-next 3/7] octeontx2-vf: Virtual function driver support

From: Leon Romanovsky <[email-masked]>
Date: Sat, 14 Mar 2020 19:59:13 +0200

On Sat, Mar 14, 2020 at 09:10:28PM +0530, Sunil Kovvuri wrote:
> On Fri, Mar 13, 2020 at 11:41 PM Leon Romanovsky <[email-masked]> wrote:
>  > diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c
> b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c
> > > new file mode 100644
> > > index 0000000..cf366dc
> > > --- /dev/null
> > > +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c
> > > @@ -0,0 +1,659 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/* Marvell OcteonTx2 RVU Virtual Function ethernet driver
> > > + *
> > > + * Copyright (C) 2020 Marvell International Ltd.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> >
> > Please don't add license text, the SPDX line is enough.
> >
>
> Can you please point me to where this is written.

It is in nutshell of SPDX tags. They already include proper LICENSE text.
https://elixir.bootlin.com/linux/latest/source/Documentation/process/howto.rst#L59
https://elixir.bootlin.com/linux/latest/source/Documentation/process/license-rules.rst

> It would be great if these are made rules and written somewhere so
> that everyone can go through and follow.
> I see that there are so many patches being submitted with copyright text.
> So this is very confusing.

This is a mistake, new files should carry SPDX tags only.

>
> > > +
> > > +static int otx2vf_process_mbox_msg_up(struct otx2_nic *vf,
> > > +                                   struct mbox_msghdr *req)
> > > +{
> > > +     /* Check if valid, if not reply with a invalid msg */
> > > +     if (req->sig != OTX2_MBOX_REQ_SIG) {
> > > +             otx2_reply_invalid_msg(&vf->mbox.mbox_up, 0, 0, req->id);
> > > +             return -ENODEV;
> > > +     }
> > > +
> > > +     switch (req->id) {
> > > +#define M(_name, _id, _fn_name, _req_type, _rsp_type)                        \
> > > +     case _id: {                                                     \
> > > +             struct _rsp_type *rsp;                                  \
> > > +             int err;                                                \
> > > +                                                                     \
> > > +             rsp = (struct _rsp_type *)otx2_mbox_alloc_msg(          \
> > > +                     &vf->mbox.mbox_up, 0,                           \
> > > +                     sizeof(struct _rsp_type));                      \
> > > +             if (!rsp)                                               \
> > > +                     return -ENOMEM;                                 \
> > > +                                                                     \
> > > +             rsp->hdr.id = _id;                                      \
> > > +             rsp->hdr.sig = OTX2_MBOX_RSP_SIG;                       \
> > > +             rsp->hdr.pcifunc = 0;                                   \
> > > +             rsp->hdr.rc = 0;                                        \
> > > +                                                                     \
> > > +             err = otx2_mbox_up_handler_ ## _fn_name(                \
> > > +                     vf, (struct _req_type *)req, rsp);              \
> > > +             return err;                                             \
> > > +     }
> > > +MBOX_UP_CGX_MESSAGES
> > > +#undef M
> >
> > "return ..." inside macro which is called by another macro is highly
> > discouraged by the Linux kernel coding style.
> >
>
> There are many mailbox messages to handle and adding each one of them
> to switch case would be a
> lot of duplicate code. Hence we choose to with these macros.

Somehow other drivers succeeded to do it without such macros, I'm
confident that you will success too. Please try your best to rewrite it.

Section 12.1 talks exactly about this case and why it is **bad** idea.
https://elixir.bootlin.com/linux/latest/source/Documentation/process/coding-style.rst#L752

Thanks

> Thanks,
> Sunil.