From a09de592f4fadb1dd45ef57359f1eab67698b87c Mon Sep 17 00:00:00 2001
From: Nav <nav@navnav.me>
Date: Thu, 15 Feb 2024 21:25:32 +0000
Subject: [PATCH] Tidying

---
 src/Targets/Microchip/AVR/AVR8/Avr8.cpp                | 10 ----------
 .../TargetDescription/TargetDescriptionFile.cpp        |  2 +-
 .../TargetDescription/TargetDescriptionFile.hpp        |  2 +-
 3 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/src/Targets/Microchip/AVR/AVR8/Avr8.cpp b/src/Targets/Microchip/AVR/AVR8/Avr8.cpp
index 76a279c5..4fbd90d4 100644
--- a/src/Targets/Microchip/AVR/AVR8/Avr8.cpp
+++ b/src/Targets/Microchip/AVR/AVR8/Avr8.cpp
@@ -786,20 +786,10 @@ namespace Targets::Microchip::Avr::Avr8Bit
         this->avrIspInterface->activate();
 
         /*
-         * It is crucial that we understand the potential consequences of this operation.
-         *
          * AVR fuses are used to control certain functions within the AVR (including the debugWire interface). Care
          * must be taken when updating these fuse bytes, as an incorrect value could render the AVR inaccessible to
          * standard programmers.
          *
-         * For example, consider the SPI enable (SPIEN) fuse bit. This fuse bit is used to enable/disable the SPI for
-         * serial programming. If the SPIEN fuse bit is cleared, most programming tools will not be able to gain access
-         * to the target via the SPI. This isn't too bad, if there is some other way for the programming tool to gain
-         * access (such as the debugWire interface). But now consider the DWEN fuse bit (which is used to enable/disable
-         * the debugWire interface). What if both the SPIEN *and* the DWEN fuse bits are cleared? Both interfaces will
-         * be disabled. Effectively, the AVR will be bricked, and the only course for recovery would be to use
-         * high-voltage programming.
-         *
          * When updating the DWEN fuse, Bloom relies on data from the target description file (TDF). But there is no
          * guarantee that this data is correct. For this reason, we perform additional checks in an attempt to reduce
          * the likelihood of bricking the target:
diff --git a/src/Targets/TargetDescription/TargetDescriptionFile.cpp b/src/Targets/TargetDescription/TargetDescriptionFile.cpp
index afdbd77d..fa3e09b4 100644
--- a/src/Targets/TargetDescription/TargetDescriptionFile.cpp
+++ b/src/Targets/TargetDescription/TargetDescriptionFile.cpp
@@ -85,7 +85,7 @@ namespace Targets::TargetDescription
             : std::nullopt;
     }
 
-    const AddressSpace & TargetDescriptionFile::getAddressSpace(std::string_view key) const {
+    const AddressSpace& TargetDescriptionFile::getAddressSpace(std::string_view key) const {
         const auto addressSpace = this->tryGetAddressSpace(key);
 
         if (!addressSpace.has_value()) {
diff --git a/src/Targets/TargetDescription/TargetDescriptionFile.hpp b/src/Targets/TargetDescription/TargetDescriptionFile.hpp
index ef998f23..67aa995f 100644
--- a/src/Targets/TargetDescription/TargetDescriptionFile.hpp
+++ b/src/Targets/TargetDescription/TargetDescriptionFile.hpp
@@ -104,8 +104,8 @@ namespace Targets::TargetDescription
 
     protected:
         std::map<std::string, std::string> deviceAttributesByName;
-        std::map<std::string, AddressSpace, std::less<void>> addressSpacesByKey;
         std::map<std::string, PropertyGroup, std::less<void>> propertyGroupsByKey;
+        std::map<std::string, AddressSpace, std::less<void>> addressSpacesByKey;
         std::vector<PhysicalInterface> physicalInterfaces;
         std::map<std::string, Module> modulesMappedByName;
         std::map<std::string, Module> peripheralModulesMappedByName;