Message-ID: <067bd072-eb3f-451a-b1c4-59eae777cf00@samsung.com>
Date: Tue, 11 Mar 2025 13:51:21 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Jakub Kicinski
	<kuba@...nel.org>
Cc: Paolo Abeni <pabeni@...hat.com>, Christoph Hellwig <hch@....de>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Rasesh Mody
	<rmody@...vell.com>, GR-Linux-NIC-Dev@...vell.com, Andrew Lunn
	<andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
	Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net v1 1/1] bnx2: Fix unused data compilation warning

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

Powered by blists - more mailing lists