I am planning to wrap all registers call into some macro to keep compatibility with out of the tree boards and stuff.
I'll introduce this wrapper later this week.
However, there is one thing which is still unclear to me -> how should we manage the bit name changes inside a register.
For instance, on the current Microchip vendor files we have like:
FOO_BAR
FOO_BAR_Pos
FOO_BAR_Msk (Only if there is more than 1 bit otherwise this macro is not created)

However, on the new Microchip vendor files, we have:
FOO_BAR_Msk (even if there is only 1 bit) which is a drop-in replacement for old FOO_BAR
FOO_BAR_Pos (same as the old one)
FOO_BAR(value) (a new macro)

Maintaining compatibility with these changes will be tricky. We could go with only using FOO_BAR_Pos everywhere as this is the only thing in common between both generation of vendor files. But this will be a bit ugly so I am not sure yet.

Regarding the wrapper I was thinking about something like this:

#if USE_MCHP_VENDOR_NG
  #define iomem(per, re) ((per)->per##_##re)
#else
  #define iomem(per, re) ((per)->re.reg)
#endif

As long as USE_MCHP_VENDOR_NG is not defined, old headers will be use. A warning should also be printed during build to warn users about a migration ongoing. Then move gradually to use USE_MCHP_VENDOR_NG at board level only so we don't break out of the tree users.
Obviously, the whole process will take a few releases before completion.

Murdock results

✔️ PASSED

bc188c5 cpu/saml21: avoid the use of bitfield

Artifacts

• Documentation preview

Do you have a plan how to switch to the new vendor files? AFAIK they not only drop the bitfield access, but also change register names.

@benpicco I've add more details in #20457 about what I have in mind for the migration. Comments and ideas are welcome :)