netdev - Re: [PATCH net v2] bnxt_en: Cap the size of HWRM_PORT_PHY

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

Date: Tue, 11 Jun 2024 13:09:47 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Michael Chan <michael.chan@...adcom.com>
CC: <netdev@...r.kernel.org>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<pabeni@...hat.com>, <andrew.gospodarek@...adcom.com>, <horms@...nel.org>,
	Somnath Kotur <somnath.kotur@...adcom.com>, Pavan Chebbi
	<pavan.chebbi@...adcom.com>, <davem@...emloft.net>
Subject: Re: [PATCH net v2] bnxt_en: Cap the size of HWRM_PORT_PHY_QCFG
 forwarded response

On 6/11/24 01:52, Michael Chan wrote:
> On Mon, Jun 10, 2024 at 7:00 AM Michael Chan <michael.chan@...adcom.com> wrote:
>>
>> On Mon, Jun 10, 2024 at 4:38 AM Przemek Kitszel
>> <przemyslaw.kitszel@...el.com> wrote:
>>>
>>> I assume that the first 96 bytes of the current
>>> struct hwrm_port_phy_qcfg are the same as here; with that you could wrap
>>> those there by struct_group_tagged, giving the very same name as here,
>>> but without replicating all the content.
>>
>> Except for the valid bit at the end of the struct.  Let me see if I
>> can define the struct_group thing for 95 bytes and add the valid bit
>> here.  Thanks.
>>
> 
> The struct_group_tagged() idea works in general.  However, the
> hwrm_port_phy_qcfg_output struct is generated from yaml and it
> contains a lot of #define within the structure.  So it looks like this
> with struct_group_tagged added:
> 
> struct hwrm_port_phy_qcfg_output {
>          struct_group_tagged(hwrm_port_phy_qcfg_output_legacy, legacy,
>                  __le16  error_code;
>                  __le16  req_type;
>                  __le16  seq_id;
>                  __le16  resp_len;
>                  u8      link;
>          #define PORT_PHY_QCFG_RESP_LINK_NO_LINK 0x0UL
>          #define PORT_PHY_QCFG_RESP_LINK_SIGNAL  0x1UL
>          #define PORT_PHY_QCFG_RESP_LINK_LINK    0x2UL
> ....
>          );
> ....
> };
> 
> The #define within the struct_group generates a lot of warnings with make C=1:
> 
>    CC [M]  drivers/net/ethernet/broadcom/bnxt/bnxt.o
>    CHECK   drivers/net/ethernet/broadcom/bnxt/bnxt.c
> drivers/net/ethernet/broadcom/bnxt/bnxt.c: note: in included file:
> drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h:4211:9: warning:
> directive in macro's argument list
> 
> Because it's a generated file, it's hard to make the drastic change to

is this generated as part of upstream build process or just manually?

> move all the #define macros.  Maybe in the future when we restructure
> these generated structs, we can do it in a better way.

You could also just split struct into two and combine them (packed)
into hwrm_port_phy_qcfg_output and add compat one as combination of
hwrm_port_phy_qcfg_output + valid bit

If you don't want to do so, please at least document in code that only 
the first 95 bytes match and the last one is different