Fix enum warnings in ath_hal's ar9300

[dim]

Summary

This fixes a number of clang 19 warnings:

sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:709:25: error: comparison of different enumeration types ('HAL_BOOL' and 'HAL_FREQ_BAND') [-Werror,-Wenum-compare]
  709 |         freq_array[i] = FBIN2FREQ(p_freq_bin[i], is_2ghz);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sys/contrib/dev/ath/ath_hal/ar9300/ar9300eep.h:148:11: note: expanded from macro 'FBIN2FREQ'
  148 |     (((y) == HAL_FREQ_BAND_2GHZ) ? (2300 + x) : (4800 + 5 * x))
      |       ~~~ ^  ~~~~~~~~~~~~~~~~~~
sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:745:25: error: comparison of different enumeration types ('HAL_BOOL' and 'HAL_FREQ_BAND') [-Werror,-Wenum-compare]
  745 |         freq_array[i] = FBIN2FREQ(p_freq_bin[i], is_2ghz);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sys/contrib/dev/ath/ath_hal/ar9300/ar9300eep.h:148:11: note: expanded from macro 'FBIN2FREQ'
  148 |     (((y) == HAL_FREQ_BAND_2GHZ) ? (2300 + x) : (4800 + 5 * x))
      |       ~~~ ^  ~~~~~~~~~~~~~~~~~~
sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:781:25: error: comparison of different enumeration types ('HAL_BOOL' and 'HAL_FREQ_BAND') [-Werror,-Wenum-compare]
  781 |         freq_array[i] = FBIN2FREQ(p_freq_bin[i], is_2ghz);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sys/contrib/dev/ath/ath_hal/ar9300/ar9300eep.h:148:11: note: expanded from macro 'FBIN2FREQ'
  148 |     (((y) == HAL_FREQ_BAND_2GHZ) ? (2300 + x) : (4800 + 5 * x))
      |       ~~~ ^  ~~~~~~~~~~~~~~~~~~

The FBIN2FREQ() and FREQ2FBIN() macros in ar9300eep.h are invoked
in most places around the ath_hal code with a (effectively) boolean
second argument, corresponding to "is this 2GHz?". But in the code that
is warned about, the value HAL_FREQ_BAND_2GHZ is of a different
non-boolean type, HAL_FREQ_BAND.

Either the FBIN2FREQ() and FREQ2FBIN() macros can be left to use a
HAL_FREQ_BAND as a second argument, which would necessitate updating
all the call sites, or the macros can be changed to interpret the second
argument as a zero/nonzero value instead. The latter seems preferable,
since the above three instances are the only place where the macros get
invoked incorrectly with a HAL_FREQ_BAND second argument.

MFC after: 3 days

[bz]

sys/dev/ath/ath_hal/ah_eeprom_v14.h has another copy of FREQ2FBIN which do not have the check but do treat the 2nd arg as boolean:
sys/dev/ath/ath_hal/ah_eeprom_v14.h:#define FREQ2FBIN(x,y) ((y) ? ((x) - 2300) : (((x) - 4800) / 5))

I do not care if we spell it as (y) or as (y != 0). Both work for me.

[adrian]

can you add a comment above each macro just saying that != 0 is a check that it's HAL_FREQ_BAND_2GHZ? other than that, go ahead!