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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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