| Message ID | 20250228100538.32029-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net,v1,1/1] bnx2: Fix unused data compilation warning | expand |
On Fri, 28 Feb 2025 12:05:37 +0200 Andy Shevchenko wrote: > In some configuration, compilation raises warnings related to unused > data. Indeed, depending on configuration, those data can be unused. > > Mark those data as __maybe_unused to avoid compilation warnings. Will making dma_unmap_addr access the first argument instead of pre-processing down to nothing not work?
On Mon, Mar 03, 2025 at 05:21:14PM -0800, Jakub Kicinski wrote: > On Fri, 28 Feb 2025 12:05:37 +0200 Andy Shevchenko wrote: > > In some configuration, compilation raises warnings related to unused > > data. Indeed, depending on configuration, those data can be unused. > > > > Mark those data as __maybe_unused to avoid compilation warnings. > > Will making dma_unmap_addr access the first argument instead of > pre-processing down to nothing not work? I looked at the implementation of those macros and I have no clue how to do that in a least intrusive way. Otherwise it sounds to me quite far from the scope of the small compilation error fix that I presented here.
On 3/4/25 11:56 AM, Andy Shevchenko wrote: > On Mon, Mar 03, 2025 at 05:21:14PM -0800, Jakub Kicinski wrote: >> On Fri, 28 Feb 2025 12:05:37 +0200 Andy Shevchenko wrote: >>> In some configuration, compilation raises warnings related to unused >>> data. Indeed, depending on configuration, those data can be unused. >>> >>> Mark those data as __maybe_unused to avoid compilation warnings. >> >> Will making dma_unmap_addr access the first argument instead of >> pre-processing down to nothing not work? > > I looked at the implementation of those macros and I have no clue > how to do that in a least intrusive way. Otherwise it sounds to me > quite far from the scope of the small compilation error fix that > I presented here. I *think* Jakub is suggesting something alike: --- diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index b79925b1c433..927884f10b0f 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -629,7 +629,7 @@ static inline int dma_mmap_wc(struct device *dev, #else #define DEFINE_DMA_UNMAP_ADDR(ADDR_NAME) #define DEFINE_DMA_UNMAP_LEN(LEN_NAME) -#define dma_unmap_addr(PTR, ADDR_NAME) (0) +#define dma_unmap_addr(PTR, ADDR_NAME) (((PTR)->ADDR_NAME), 0) #define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) #define dma_unmap_len(PTR, LEN_NAME) (0) #define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) --- Would that work? Thanks, Paolo
+ Marek/Christoph (for the clarification/commenting on the below) On Tue, Mar 04, 2025 at 12:39:40PM +0100, Paolo Abeni wrote: > On 3/4/25 11:56 AM, Andy Shevchenko wrote: > > On Mon, Mar 03, 2025 at 05:21:14PM -0800, Jakub Kicinski wrote: > >> On Fri, 28 Feb 2025 12:05:37 +0200 Andy Shevchenko wrote: > >>> In some configuration, compilation raises warnings related to unused > >>> data. Indeed, depending on configuration, those data can be unused. > >>> > >>> Mark those data as __maybe_unused to avoid compilation warnings. > >> > >> Will making dma_unmap_addr access the first argument instead of > >> pre-processing down to nothing not work? > > > > I looked at the implementation of those macros and I have no clue > > how to do that in a least intrusive way. Otherwise it sounds to me > > quite far from the scope of the small compilation error fix that > > I presented here. > I *think* Jakub is suggesting something alike: I see. Perhpas we need Marek's/Christoph's opinion on this... > --- > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index b79925b1c433..927884f10b0f 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -629,7 +629,7 @@ static inline int dma_mmap_wc(struct device *dev, > #else > #define DEFINE_DMA_UNMAP_ADDR(ADDR_NAME) > #define DEFINE_DMA_UNMAP_LEN(LEN_NAME) > -#define dma_unmap_addr(PTR, ADDR_NAME) (0) > +#define dma_unmap_addr(PTR, ADDR_NAME) (((PTR)->ADDR_NAME), 0) > #define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) > #define dma_unmap_len(PTR, LEN_NAME) (0) > #define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) > --- > > Would that work? I do not know. Not my area of expertise.
On Tue, Mar 04, 2025 at 01:58:33PM +0200, Andy Shevchenko wrote: > + Marek/Christoph (for the clarification/commenting on the below) > > On Tue, Mar 04, 2025 at 12:39:40PM +0100, Paolo Abeni wrote: > > On 3/4/25 11:56 AM, Andy Shevchenko wrote: > > > On Mon, Mar 03, 2025 at 05:21:14PM -0800, Jakub Kicinski wrote: > > >> On Fri, 28 Feb 2025 12:05:37 +0200 Andy Shevchenko wrote: > > >>> In some configuration, compilation raises warnings related to unused > > >>> data. Indeed, depending on configuration, those data can be unused. > > >>> > > >>> Mark those data as __maybe_unused to avoid compilation warnings. > > >> > > >> Will making dma_unmap_addr access the first argument instead of > > >> pre-processing down to nothing not work? > > > > > > I looked at the implementation of those macros and I have no clue > > > how to do that in a least intrusive way. Otherwise it sounds to me > > > quite far from the scope of the small compilation error fix that > > > I presented here. > > > I *think* Jakub is suggesting something alike: > > I see. Perhpas we need Marek's/Christoph's opinion on this... > > > --- > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > > index b79925b1c433..927884f10b0f 100644 > > --- a/include/linux/dma-mapping.h > > +++ b/include/linux/dma-mapping.h > > @@ -629,7 +629,7 @@ static inline int dma_mmap_wc(struct device *dev, > > #else > > #define DEFINE_DMA_UNMAP_ADDR(ADDR_NAME) > > #define DEFINE_DMA_UNMAP_LEN(LEN_NAME) > > -#define dma_unmap_addr(PTR, ADDR_NAME) (0) > > +#define dma_unmap_addr(PTR, ADDR_NAME) (((PTR)->ADDR_NAME), 0) > > #define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) > > #define dma_unmap_len(PTR, LEN_NAME) (0) > > #define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) > > --- > > > > Would that work? Actually it won't work because the variable is under the same ifdeffery. What will work is to spreading the ifdeffery to the users, but it doesn't any better than __maybe_unsused, which is compact hack (yes, I admit that it is not the nicest solution, but it's spread enough in the kernel). > I do not know. Not my area of expertise.
On Tue, 4 Mar 2025 15:41:19 +0200 Andy Shevchenko wrote: > > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > > > index b79925b1c433..927884f10b0f 100644 > > > --- a/include/linux/dma-mapping.h > > > +++ b/include/linux/dma-mapping.h > > > @@ -629,7 +629,7 @@ static inline int dma_mmap_wc(struct device *dev, > > > #else > > > #define DEFINE_DMA_UNMAP_ADDR(ADDR_NAME) > > > #define DEFINE_DMA_UNMAP_LEN(LEN_NAME) > > > -#define dma_unmap_addr(PTR, ADDR_NAME) (0) > > > +#define dma_unmap_addr(PTR, ADDR_NAME) (((PTR)->ADDR_NAME), 0) > > > #define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) > > > #define dma_unmap_len(PTR, LEN_NAME) (0) > > > #define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) > > > --- > > > > > > Would that work? > > Actually it won't work because the variable is under the same ifdeffery. > What will work is to spreading the ifdeffery to the users, but it doesn't any > better than __maybe_unsused, which is compact hack (yes, I admit that it is not > the nicest solution, but it's spread enough in the kernel). I meant something more like (untested): diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index b79925b1c433..a7ebcede43f6 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -629,10 +629,10 @@ static inline int dma_mmap_wc(struct device *dev, #else #define DEFINE_DMA_UNMAP_ADDR(ADDR_NAME) #define DEFINE_DMA_UNMAP_LEN(LEN_NAME) -#define dma_unmap_addr(PTR, ADDR_NAME) (0) -#define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) -#define dma_unmap_len(PTR, LEN_NAME) (0) -#define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) +#define dma_unmap_addr(PTR, ADDR_NAME) ({ typeof(PTR) __p __maybe_unused = PTR; 0; )} +#define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { typeof(PTR) __p __maybe_unused = PTR; } while (0) +#define dma_unmap_len(PTR, LEN_NAME) ({ typeof(PTR) __p __maybe_unused = PTR; 0; )} +#define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { typeof(PTR) __p __maybe_unused = PTR; } while (0) #endif #endif /* _LINUX_DMA_MAPPING_H */ I just don't know how much code out there depends on PTR not existing if !CONFIG_NEED_DMA_MAP_STATE
On Tue, Mar 04, 2025 at 08:35:24AM -0800, Jakub Kicinski wrote: > On Tue, 4 Mar 2025 15:41:19 +0200 Andy Shevchenko wrote: ... > > > > Would that work? > > > > Actually it won't work because the variable is under the same ifdeffery. > > What will work is to spreading the ifdeffery to the users, but it doesn't any > > better than __maybe_unsused, which is compact hack (yes, I admit that it is not > > the nicest solution, but it's spread enough in the kernel). > > I meant something more like (untested): We are starving for the comment from the DMA mapping people. > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index b79925b1c433..a7ebcede43f6 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -629,10 +629,10 @@ static inline int dma_mmap_wc(struct device *dev, > #else > #define DEFINE_DMA_UNMAP_ADDR(ADDR_NAME) > #define DEFINE_DMA_UNMAP_LEN(LEN_NAME) > -#define dma_unmap_addr(PTR, ADDR_NAME) (0) > -#define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) > -#define dma_unmap_len(PTR, LEN_NAME) (0) > -#define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) > +#define dma_unmap_addr(PTR, ADDR_NAME) ({ typeof(PTR) __p __maybe_unused = PTR; 0; )} > +#define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { typeof(PTR) __p __maybe_unused = PTR; } while (0) > +#define dma_unmap_len(PTR, LEN_NAME) ({ typeof(PTR) __p __maybe_unused = PTR; 0; )} > +#define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { typeof(PTR) __p __maybe_unused = PTR; } while (0) > #endif > > #endif /* _LINUX_DMA_MAPPING_H */ > > I just don't know how much code out there depends on PTR not > existing if !CONFIG_NEED_DMA_MAP_STATE Brief checking shows that only drivers/net/ethernet/chelsio/* comes with ifdeffery, the rest most likely will fail in the same way (note, overwhelming majority of the users is under the network realm): $ git grep -lw dma_unmap_[al][de].* drivers/infiniband/hw/cxgb4/cq.c drivers/infiniband/hw/cxgb4/qp.c drivers/infiniband/hw/mthca/mthca_allocator.c drivers/infiniband/hw/mthca/mthca_eq.c drivers/net/ethernet/alacritech/slicoss.c drivers/net/ethernet/alteon/acenic.c drivers/net/ethernet/amazon/ena/ena_netdev.c drivers/net/ethernet/arc/emac_main.c drivers/net/ethernet/atheros/alx/main.c drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c drivers/net/ethernet/broadcom/bcmsysport.c drivers/net/ethernet/broadcom/bnx2.c drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c drivers/net/ethernet/broadcom/bnxt/bnxt.c drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c drivers/net/ethernet/broadcom/genet/bcmgenet.c drivers/net/ethernet/broadcom/tg3.c drivers/net/ethernet/brocade/bna/bnad.c drivers/net/ethernet/chelsio/cxgb/sge.c drivers/net/ethernet/chelsio/cxgb3/sge.c drivers/net/ethernet/emulex/benet/be_main.c drivers/net/ethernet/engleder/tsnep_main.c drivers/net/ethernet/google/gve/gve_tx.c drivers/net/ethernet/google/gve/gve_tx_dqo.c drivers/net/ethernet/intel/fm10k/fm10k_main.c drivers/net/ethernet/intel/fm10k/fm10k_netdev.c drivers/net/ethernet/intel/i40e/i40e_main.c drivers/net/ethernet/intel/i40e/i40e_txrx.c drivers/net/ethernet/intel/i40e/i40e_xsk.c drivers/net/ethernet/intel/iavf/iavf_txrx.c drivers/net/ethernet/intel/ice/ice_txrx.c drivers/net/ethernet/intel/ice/ice_txrx_lib.c drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c drivers/net/ethernet/intel/idpf/idpf_txrx.c drivers/net/ethernet/intel/igb/igb_ethtool.c drivers/net/ethernet/intel/igb/igb_main.c drivers/net/ethernet/intel/igc/igc_dump.c drivers/net/ethernet/intel/igc/igc_main.c drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c drivers/net/ethernet/intel/ixgbe/ixgbe_main.c drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c drivers/net/ethernet/marvell/skge.c drivers/net/ethernet/marvell/sky2.c drivers/net/ethernet/mediatek/mtk_eth_soc.c drivers/net/ethernet/mscc/ocelot_fdma.c drivers/net/ethernet/myricom/myri10ge/myri10ge.c drivers/net/ethernet/qlogic/qla3xxx.c drivers/net/ethernet/rocker/rocker_main.c drivers/net/ethernet/wangxun/libwx/wx_lib.c drivers/net/wireless/intel/iwlegacy/3945-mac.c drivers/net/wireless/intel/iwlegacy/3945.c drivers/net/wireless/intel/iwlegacy/4965-mac.c drivers/net/wireless/intel/iwlegacy/common.c drivers/net/wireless/marvell/mwl8k.c include/net/libeth/tx.h
Hi Andy, On 05.03.2025 11:00, Andy Shevchenko wrote: > On Tue, Mar 04, 2025 at 08:35:24AM -0800, Jakub Kicinski wrote: >> On Tue, 4 Mar 2025 15:41:19 +0200 Andy Shevchenko wrote: > ... > >>>>> Would that work? >>> Actually it won't work because the variable is under the same ifdeffery. >>> What will work is to spreading the ifdeffery to the users, but it doesn't any >>> better than __maybe_unsused, which is compact hack (yes, I admit that it is not >>> the nicest solution, but it's spread enough in the kernel). >> I meant something more like (untested): > We are starving for the comment from the DMA mapping people. I'm really sorry for this delay. Just got back to the everyday stuff after spending a week in bed recovering from flu... >> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h >> index b79925b1c433..a7ebcede43f6 100644 >> --- a/include/linux/dma-mapping.h >> +++ b/include/linux/dma-mapping.h >> @@ -629,10 +629,10 @@ static inline int dma_mmap_wc(struct device *dev, >> #else >> #define DEFINE_DMA_UNMAP_ADDR(ADDR_NAME) >> #define DEFINE_DMA_UNMAP_LEN(LEN_NAME) >> -#define dma_unmap_addr(PTR, ADDR_NAME) (0) >> -#define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) >> -#define dma_unmap_len(PTR, LEN_NAME) (0) >> -#define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) >> +#define dma_unmap_addr(PTR, ADDR_NAME) ({ typeof(PTR) __p __maybe_unused = PTR; 0; )} >> +#define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { typeof(PTR) __p __maybe_unused = PTR; } while (0) >> +#define dma_unmap_len(PTR, LEN_NAME) ({ typeof(PTR) __p __maybe_unused = PTR; 0; )} >> +#define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { typeof(PTR) __p __maybe_unused = PTR; } while (0) >> #endif >> >> #endif /* _LINUX_DMA_MAPPING_H */ >> >> I just don't know how much code out there depends on PTR not >> existing if !CONFIG_NEED_DMA_MAP_STATE > Brief checking shows that only drivers/net/ethernet/chelsio/* comes > with ifdeffery, the rest most likely will fail in the same way > (note, overwhelming majority of the users is under the network realm): Frankly speaking I wasn't aware of this API till now. If got it right the above proposal should work fine. The addr/len names can be optimized out, but the pointer to the container should exist. > $ git grep -lw dma_unmap_[al][de].* > > drivers/infiniband/hw/cxgb4/cq.c > drivers/infiniband/hw/cxgb4/qp.c > drivers/infiniband/hw/mthca/mthca_allocator.c > drivers/infiniband/hw/mthca/mthca_eq.c > drivers/net/ethernet/alacritech/slicoss.c > drivers/net/ethernet/alteon/acenic.c > drivers/net/ethernet/amazon/ena/ena_netdev.c > drivers/net/ethernet/arc/emac_main.c > drivers/net/ethernet/atheros/alx/main.c > drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c > drivers/net/ethernet/broadcom/bcmsysport.c > drivers/net/ethernet/broadcom/bnx2.c > drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c > drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h > drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c > drivers/net/ethernet/broadcom/bnxt/bnxt.c > drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c > drivers/net/ethernet/broadcom/genet/bcmgenet.c > drivers/net/ethernet/broadcom/tg3.c > drivers/net/ethernet/brocade/bna/bnad.c > drivers/net/ethernet/chelsio/cxgb/sge.c > drivers/net/ethernet/chelsio/cxgb3/sge.c > drivers/net/ethernet/emulex/benet/be_main.c > drivers/net/ethernet/engleder/tsnep_main.c > drivers/net/ethernet/google/gve/gve_tx.c > drivers/net/ethernet/google/gve/gve_tx_dqo.c > drivers/net/ethernet/intel/fm10k/fm10k_main.c > drivers/net/ethernet/intel/fm10k/fm10k_netdev.c > drivers/net/ethernet/intel/i40e/i40e_main.c > drivers/net/ethernet/intel/i40e/i40e_txrx.c > drivers/net/ethernet/intel/i40e/i40e_xsk.c > drivers/net/ethernet/intel/iavf/iavf_txrx.c > drivers/net/ethernet/intel/ice/ice_txrx.c > drivers/net/ethernet/intel/ice/ice_txrx_lib.c > drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c > drivers/net/ethernet/intel/idpf/idpf_txrx.c > drivers/net/ethernet/intel/igb/igb_ethtool.c > drivers/net/ethernet/intel/igb/igb_main.c > drivers/net/ethernet/intel/igc/igc_dump.c > drivers/net/ethernet/intel/igc/igc_main.c > drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c > drivers/net/ethernet/marvell/skge.c > drivers/net/ethernet/marvell/sky2.c > drivers/net/ethernet/mediatek/mtk_eth_soc.c > drivers/net/ethernet/mscc/ocelot_fdma.c > drivers/net/ethernet/myricom/myri10ge/myri10ge.c > drivers/net/ethernet/qlogic/qla3xxx.c > drivers/net/ethernet/rocker/rocker_main.c > drivers/net/ethernet/wangxun/libwx/wx_lib.c > drivers/net/wireless/intel/iwlegacy/3945-mac.c > drivers/net/wireless/intel/iwlegacy/3945.c > drivers/net/wireless/intel/iwlegacy/4965-mac.c > drivers/net/wireless/intel/iwlegacy/common.c > drivers/net/wireless/marvell/mwl8k.c > > include/net/libeth/tx.h > Best regards
On Tue, Mar 11, 2025 at 01:51:21PM +0100, Marek Szyprowski wrote: > On 05.03.2025 11:00, Andy Shevchenko wrote: > > On Tue, Mar 04, 2025 at 08:35:24AM -0800, Jakub Kicinski wrote: > >> On Tue, 4 Mar 2025 15:41:19 +0200 Andy Shevchenko wrote: ... > >> I meant something more like (untested): > > We are starving for the comment from the DMA mapping people. > > I'm really sorry for this delay. Just got back to the everyday stuff > after spending a week in bed recovering from flu... Oh, I hope you feel much better now! ... > >> #define DEFINE_DMA_UNMAP_ADDR(ADDR_NAME) > >> #define DEFINE_DMA_UNMAP_LEN(LEN_NAME) > >> -#define dma_unmap_addr(PTR, ADDR_NAME) (0) > >> -#define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) > >> -#define dma_unmap_len(PTR, LEN_NAME) (0) > >> -#define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) > >> +#define dma_unmap_addr(PTR, ADDR_NAME) ({ typeof(PTR) __p __maybe_unused = PTR; 0; )} > >> +#define dma_unmap_addr_set(PTR, ADDR_NAME, VAL) do { typeof(PTR) __p __maybe_unused = PTR; } while (0) > >> +#define dma_unmap_len(PTR, LEN_NAME) ({ typeof(PTR) __p __maybe_unused = PTR; 0; )} > >> +#define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { typeof(PTR) __p __maybe_unused = PTR; } while (0) > >> I just don't know how much code out there depends on PTR not > >> existing if !CONFIG_NEED_DMA_MAP_STATE > > Brief checking shows that only drivers/net/ethernet/chelsio/* comes > > with ifdeffery, the rest most likely will fail in the same way > > (note, overwhelming majority of the users is under the network realm): > > Frankly speaking I wasn't aware of this API till now. > > If got it right the above proposal should work fine. The addr/len names > can be optimized out, but the pointer to the container should exist. Thanks for the reply, would you or Jakub will to send a formal patch? I can test it on my configuration and build.
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c index 6ec773e61182..a40ef3ec38b3 100644 --- a/drivers/net/ethernet/broadcom/bnx2.c +++ b/drivers/net/ethernet/broadcom/bnx2.c @@ -2887,7 +2887,7 @@ bnx2_tx_int(struct bnx2 *bp, struct bnx2_napi *bnapi, int budget) last = tx_buf->nr_frags; for (i = 0; i < last; i++) { - struct bnx2_sw_tx_bd *tx_buf; + struct bnx2_sw_tx_bd *tx_buf __maybe_unused; sw_cons = BNX2_NEXT_TX_BD(sw_cons); @@ -2994,7 +2994,7 @@ static inline void bnx2_reuse_rx_data(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u8 *data, u16 cons, u16 prod) { - struct bnx2_sw_bd *cons_rx_buf, *prod_rx_buf; + struct bnx2_sw_bd *cons_rx_buf __maybe_unused, *prod_rx_buf; struct bnx2_rx_bd *cons_bd, *prod_bd; cons_rx_buf = &rxr->rx_buf_ring[cons];
In some configuration, compilation raises warnings related to unused data. Indeed, depending on configuration, those data can be unused. Mark those data as __maybe_unused to avoid compilation warnings. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- drivers/net/ethernet/broadcom/bnx2.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)