linux-kernel - RE: [EXT] Re: [PATCH net-next v4 2/4] octeon

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]

Message-ID: <PH0PR18MB4734A12CE7AE14C9969DEC31C78CA@PH0PR18MB4734.namprd18.prod.outlook.com>
Date:   Thu, 14 Dec 2023 16:16:00 +0000
From:   Shinas Rasheed <srasheed@...vell.com>
To:     "shenjian (K)" <shenjian15@...wei.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     Haseeb Gani <hgani@...vell.com>,
        Vimlesh Kumar <vimleshk@...vell.com>,
        "egallen@...hat.com" <egallen@...hat.com>,
        "mschmidt@...hat.com" <mschmidt@...hat.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "horms@...nel.org" <horms@...nel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "wizhao@...hat.com" <wizhao@...hat.com>,
        "kheib@...hat.com" <kheib@...hat.com>,
        "konguyen@...hat.com" <konguyen@...hat.com>,
        Veerasenareddy Burru <vburru@...vell.com>,
        Sathesh B Edara <sedara@...vell.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: RE: [EXT] Re: [PATCH net-next v4 2/4] octeon_ep: PF-VF mailbox
 version support

Hi Shenijan

> > +#define OCTEP_PFVF_MBOX_VERSION_CURRENT
> 	OCTEP_PFVF_MBOX_VERSION_V1
> > +
> >   enum octep_pfvf_mbox_opcode {
> >   	OCTEP_PFVF_MBOX_CMD_VERSION,
> >   	OCTEP_PFVF_MBOX_CMD_SET_MTU,
> > @@ -30,7 +34,7 @@ enum octep_pfvf_mbox_opcode {
> >   	OCTEP_PFVF_MBOX_CMD_GET_LINK_STATUS,
> >   	OCTEP_PFVF_MBOX_CMD_GET_MTU,
> >   	OCTEP_PFVF_MBOX_CMD_DEV_REMOVE,
> > -	OCTEP_PFVF_MBOX_CMD_LAST,
> > +	OCTEP_PFVF_MBOX_CMD_MAX,
> >   };
> This change is unrelative with
> this enum is introduced in the first patch, why not directly rename it
> in the first one?

That is correct. These changes were ported from our original development release internal repos in order
to also reflect the development history, but I think this particular detail can be avoided by fixing it
in the original patch as it doesn't seem too relevant. I can do that in the next patchset.

> >
> >   enum octep_pfvf_mbox_word_type {
> > @@ -79,7 +83,6 @@ enum octep_pfvf_link_autoneg {
> >
> >   #define OCTEP_PFVF_MBOX_TIMEOUT_MS     500
> >   #define OCTEP_PFVF_MBOX_MAX_RETRIES    2
> > -#define OCTEP_PFVF_MBOX_VERSION        0
> Similar here,  you introduce it in first patch, and no place used, then
> remove it int the second one.
> Maybe you can reorganize this patchset ?
> 
> >   #define OCTEP_PFVF_MBOX_MAX_DATA_SIZE  6
> >   #define OCTEP_PFVF_MBOX_MORE_FRAG_FLAG 1
> >   #define OCTEP_PFVF_MBOX_WRITE_WAIT_TIME msecs_to_jiffies(1)