[PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Andy Shevchenko]

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(-)

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];
-- 
2.47.2

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Jakub Kicinski]

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?

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Paolo Abeni]

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

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Andy Shevchenko]

+ 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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Jakub Kicinski]

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

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Andy Shevchenko]

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

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Marek Szyprowski]

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
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Andy Shevchenko]

On Wed, Mar 12, 2025 at 06:20:17PM +0200, Andy Shevchenko wrote:
> 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.

Any news here? The problem still persist AFAICT.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

[Andy Shevchenko]

On Mon, Apr 14, 2025 at 01:08:36PM +0300, Andy Shevchenko wrote:
> On Wed, Mar 12, 2025 at 06:20:17PM +0200, Andy Shevchenko wrote:
> > 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.
> 
> Any news here? The problem still persist AFAICT.

Thank you, Marek, for the patch, I just have tested it, and it works as
expected to me.

-- 
With Best Regards,
Andy Shevchenko