tree-wide: correct the spelling Ghz -> GHz

This mispelling was present in the configuration, so I retained parsing
of the legacy BandModifier*Ghz options for compatibility. Without this
change anyone spelling GHz correctly in their configs would be very
confused.

TODO

@@ -286,7 +286,7 @@ Wireless daemon
 - Support OCE mutually non-overlapping channels optimization.
 
   OCE Section 3.10 mandates that the STA should scan channels 1, 6 and 11 in
-  the 2.4Ghz band first, unless it expects to find an AP on a different
+  the 2.4GHz band first, unless it expects to find an AP on a different
   channel.
 
   Priority: Low

monitor/nlmon.c

@@ -2761,7 +2761,7 @@ static void print_wsc_configuration_error(unsigned int level, const char *label,
 		"Message timeout",
 		"Registration session timeout",
 		"Device Password Auth Failure",
-		"60 Ghz channel not supported",
+		"60 GHz channel not supported",
 		"Public Key Hash Mismatch",
 	};
 

src/ap.c

@@ -1202,7 +1202,7 @@ static size_t ap_build_country_ie(struct ap_state *ap, uint8_t *out_buf,
 	 * and use the same TX power. Any deviation from this results in a new
 	 * channel group.
 	 *
-	 * TODO: 6Ghz requires operating triplets, not subband triplets.
+	 * TODO: 6GHz requires operating triplets, not subband triplets.
 	 */
 	for (i = 0; i < len; i++) {
 		const struct band_freq_attrs *attr = &list[i];
@@ -3564,7 +3564,7 @@ static bool ap_validate_band_channel(struct ap_state *ap)
 	freq = band_channel_to_freq(ap->channel, ap->band);
 	if (!freq) {
 		l_error("AP invalid band (%s) and channel (%u) combination",
-			(ap->band & BAND_FREQ_5_GHZ) ? "5Ghz" : "2.4GHz",
+			(ap->band & BAND_FREQ_5_GHZ) ? "5GHz" : "2.4GHz",
 			ap->channel);
 		return false;
 	}

src/iwd.config.rst

@@ -122,7 +122,7 @@ The group ``[General]`` contains general settings.
      - Value: rssi dBm value, from -100 to 1, default: **-70**
 
        This value can be used to control how aggressively **iwd** roams when
-       connected to a 2.4Ghz access point.
+       connected to a 2.4GHz access point.
 
    * - RoamThreshold5G
      - Value: rssi dBm value, from -100 to 1, default: **-76**
@@ -291,7 +291,7 @@ autoconnect purposes.
    :widths: 20 80
    :align: left
 
-   * - BandModifier2_4Ghz
+   * - BandModifier2_4GHz
      - Values: floating point value (default: **1.0**)
 
        Increase or decrease the preference for 2.4GHz access points by
@@ -300,19 +300,19 @@ autoconnect purposes.
        A value of 0.0 will disable the 2.4GHz band and prevent scanning or
        connecting on those frequencies.
 
-   * - BandModifier5Ghz
+   * - BandModifier5GHz
      - Values: floating point value (default: **1.0**)
 
        Increase or decrease the preference for 5GHz access points by increasing
        or decreasing the value of this modifier.  5GHz networks are already
        preferred due to their increase throughput / data rate.  However, 5GHz
        networks are highly RSSI sensitive, so it is still possible for IWD to
-       prefer 2.4Ghz APs in certain circumstances.
+       prefer 2.4GHz APs in certain circumstances.
 
        A value of 0.0 will disable the 5GHz band and prevent scanning or
        connecting on those frequencies.
 
-   * - BandModifier6Ghz
+   * - BandModifier6GHz
      - Values: floating point value (default: **1.0**)
 
        Increase or decrease the preference for 6GHz access points by increasing

src/scan.c

@@ -2333,24 +2333,28 @@ double scan_get_band_rank_modifier(enum band_freq band)
 {
 	const struct l_settings *config = iwd_get_config();
 	double modifier;
-	char *str;
+	char *str, *str_legacy;
 
 	switch (band) {
 	case BAND_FREQ_2_4_GHZ:
-		str = "BandModifier2_4Ghz";
+		str = "BandModifier2_4GHz";
+		str_legacy = "BandModifier2_4Ghz";
 		break;
 	case BAND_FREQ_5_GHZ:
-		str = "BandModifier5Ghz";
+		str = "BandModifier5GHz";
+		str_legacy = "BandModifier5Ghz";
 		break;
 	case BAND_FREQ_6_GHZ:
-		str = "BandModifier6Ghz";
+		str = "BandModifier6GHz";
+		str_legacy = "BandModifier6Ghz";
 		break;
 	default:
 		l_warn("Unhandled band %u", band);
 		return 0.0;
 	}
 
-	if (!l_settings_get_double(config, "Rank", str, &modifier))
+	if (!l_settings_get_double(config, "Rank", str, &modifier) &&
+		!l_settings_get_double(config, "Rank", str_legacy, &modifier))
 		modifier = 1.0;
 
 	return modifier;

src/station.c

@@ -4435,7 +4435,7 @@ static void station_wiphy_watch(struct wiphy *wiphy,
 	/*
 	 * The only state that requires special handling is for
 	 * quick scans since the previous quick scan was delayed until
-	 * the regulatory domain updated. Try again in case 6Ghz is now
+	 * the regulatory domain updated. Try again in case 6GHz is now
 	 * unlocked (unlikely), or advance to full autoconnect. Just in
 	 * case this update came during a quick scan, ignore it.
 	 */

src/wiphy.c

@@ -1262,10 +1262,10 @@ static void wiphy_print_basic_info(struct wiphy *wiphy)
 	l_info("\tPermanent Address: "MAC, MAC_STR(wiphy->permanent_addr));
 
 	if (wiphy->band_2g)
-		wiphy_print_band_info(wiphy->band_2g, "2.4Ghz Band");
+		wiphy_print_band_info(wiphy->band_2g, "2.4GHz Band");
 
 	if (wiphy->band_5g)
-		wiphy_print_band_info(wiphy->band_5g, "5Ghz Band");
+		wiphy_print_band_info(wiphy->band_5g, "5GHz Band");
 
 	if (wiphy->band_6g)
 		wiphy_print_band_info(wiphy->band_6g, "6GHz Band");

unit/test-band.c

@@ -654,8 +654,8 @@ static void test_conversions(const void *data)
 {
 	/*
 	 * Test a few invalid channels/frequencies that appear valid but are
-	 * not in the E-4 table. The checks in band.c seem to cover 2.4Ghz and
-	 * 6Ghz very well since there are no gaps, but the 5GHz band has some
+	 * not in the E-4 table. The checks in band.c seem to cover 2.4GHz and
+	 * 6GHz very well since there are no gaps, but the 5GHz band has some
 	 * segmentation.
 	 */