prefixes for field enums appear to be inconsistently present

[wt]

I am looking at chiptool output. Is there a reason why some enums appear to be prefixed with the register name and some appear to be unprefixed?

On my LPC55S16 in the syscon peripheral, I have a couple registers called AhbClkCtrl0/1.

On 0, I have a field called "ROM" that generates an enum called AhbClkCtrl0Rom.

On 1, I have a field called "FC0" that generates an enum called Fc0.

I would have expected the enum for the 1 register to, AhbClkCtrl1Fc0 instead of the bare FC0.

It's not clear to me why one gets the prefix and the other does not.

There's no obvious difference in the SVD. The registers are defined within the same parent and seem to have the same attrs set.

AHBCLKCTRL0:

        <register>
          <name>AHBCLKCTRL0</name>
          <description>AHB Clock control 0</description>
          <alternateGroup>AHBCLKCTRL</alternateGroup>
          <addressOffset>0x200</addressOffset>
          <size>32</size>
          <access>read-write</access>
          <resetValue>0x180</resetValue>
          <resetMask>0xCFFE9FA</resetMask>
          <fields>
            <field>
              <name>ROM</name>
              <description>Enables the clock for the ROM.</description>
              <bitOffset>1</bitOffset>
              <bitWidth>1</bitWidth>
              <access>read-write</access>
              <enumeratedValues>
                <enumeratedValue>
                  <name>DISABLE</name>
                  <description>Disable Clock.</description>
                  <value>0</value>
                </enumeratedValue>
                <enumeratedValue>
                  <name>ENABLE</name>
                  <description>Enable Clock.</description>
                  <value>0x1</value>
                </enumeratedValue>
              </enumeratedValues>
            </field>
            ...more fields...
          </register>

AHBCLKCTRL1:

        <register>
          <name>AHBCLKCTRL1</name>
          <description>AHB Clock control 1</description>
          <alternateGroup>AHBCLKCTRL</alternateGroup>
          <addressOffset>0x204</addressOffset>
          <size>32</size>
          <access>read-write</access>
          <resetValue>0</resetValue>
          <resetMask>0xDE57FC47</resetMask>
          <fields>
            ...more fields...
            <field>
              <name>FC0</name>
              <description>Enables the clock for the FC0.</description>
              <bitOffset>11</bitOffset>
              <bitWidth>1</bitWidth>
              <access>read-write</access>
              <enumeratedValues>
                <enumeratedValue>
                  <name>DISABLE</name>
                  <description>Disable Clock.</description>
                  <value>0</value>
                </enumeratedValue>
                <enumeratedValue>
                  <name>ENABLE</name>
                  <description>Enable Clock.</description>
                  <value>0x1</value>
                </enumeratedValue>
              </enumeratedValues>
            </field>
            ...more fields...
          </fields>
        </register>

The values differ for the resetMask and the resetValue and the addressOffset. Identical otherwise.

See here for the original SVD I copied these from: https://raw.githubusercontent.com/nxp-mcuxpresso/mcux-soc-svd/refs/heads/release/25.06.00/LPC55S16/LPC55S16.xml

[Dirbaio]

There's a "make names unique" step. if there's name collisions it prepends register/block names. logic is here

[wt]

Is it possible to just always do the prefixing so that I can predict the names reliably?

[Dirbaio]

Not without changes to the code.

[wt]

Would this be a welcome change to the code? Like doing this as the default. The currently logic of only generating full names when conflicts exist seems like it should be an option.