sam0: Name all anonymous bit-fields with qualifiers

[wag-thom]

Names all anonymous bit-fields with qualifiers to Reserved1, Reserved2, ...

This conforms to CWG2229 and enables compilation with clang++.

(See Zephyr Issue zephyrproject-rtos/zephyr#84242)

[wag-thom]

@nandojve: Would you mind taking a look before I do the rest?

[nandojve]

@nandojve: Would you mind taking a look before I do the rest?

Hi @wag-thom ,
This is perfect, let's finish and approve.

[wag-thom]

@nandojve should be ready now.

[nandojve]

Hi @wag-thom ,

You need to create a zephyr PR that will fetch this changes, see process-for-submitting-changes-to-existing-modules. Search by hal_atmel and replace the revision hash by pull/45/head. Once CI is green I can merge this side : )

Note, don't forget to add the Fixes #84242 as expected by pull-request-guidelines.

[wag-thom]

Hi @nandojve

My original Issue zephyrproject-rtos/zephyr#84242 also noted, that some SOCs here also have bit-fields which are named EMPTY (in dac.h) which collides with the zephyr utility macro. This results in some more unnamed bit-field errors.
This should also be fixed somehow before the Issue can be resolved.

One option to fix that would be to #undef and re-define the EMPTY macro in zephyr same51/soc.h .
Or is there a preferred way to handle such cases?

[nandojve]

Hi @nandojve

My original Issue zephyrproject-rtos/zephyr#84242 also noted, that some SOCs here also have bit-fields which are named EMPTY (in dac.h) which collides with the zephyr utility macro. This results in some more unnamed bit-field errors. This should also be fixed somehow before the Issue can be resolved.

One option to fix that would be to #undef and re-define the EMPTY macro in zephyr same51/soc.h . Or is there a preferred way to handle such cases?

The correct solution would be rename the EMPTY here and solve once for all.

[wag-thom]

@nandojve I created a PR in zephyr and the CI looks good.

The correct solution would be rename the EMPTY here and solve once for all.

Ok, I guess that should be done in a separate PR.
I can create one, once this is merged. (Maybe the Zephyr PR should then point to that new one, which would then actually fix the original issue.)