[efm32_probe] Fix detection of DI v2

[mmmspatz]

Detailed description

#402 introduced a bug with silabs devices (efm32/efr32) related to the parsing of the DI (Device Info) page. An example is efr32xg13, which I believe would currently be broken. I do not have any of the relevant devices and cannot test this, but I noticed it while playing with adding support for the newer "series 2" parts (eg. EFRMG24).

The driver currently knows about two versions (it calls them "version 1" and "version 2") of the DI page with completely different layouts. It decides which version to use by:

1. Reading the EUI64 from the location specified by DI layout version 1
2. checking if the 24 bit OUI therein is equal to EFM32_V1_DI_EUI_SILABS, in which case layout version 1 is used
3. If not, checking if that same OUI is instead equal to EFM32_V2_DI_EUI_ENERGYMICRO, in which case version 2 is used
4. Defaulting to version 1 if neither OUI is matched

The problem with this if EFM32_V2_DI_EUI_ENERGYMICRO were to appear in the DI page, it woud be in the location specified by DI layout version 2, and so we need to perform another read from there. There's no way for the current code to ever detect v2.

So, that is the change this PR makes: Also try reading the OUI per layout version 2 (from the EUI48, because there is no EUI64 in v2). This is the behavior originally introduced in #372.

As #402 discusses, this strategy of relying on the OUI to differentiate parts versions is bad in the first place because there are over 100 OUIs assigned to Silicon Labs, and it's not actually known which devices use which OUI. A better idea might be to use the PARTNO value from the IDCODE register. It is mentioned in AN1303 that all series 2 parts (so, not what this driver supports) have IDCODE == 0x6BA02477, perhaps there is similar simple rule for the older parts supported by this driver?

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

[dragonmux]

We can see just one issue remaining which is to do with types/const, but otherwise this looks great. Please note your commit message needs to conform with the contribution guidelines for the repo. efm32: as the prefix not that square bracket expression.

With that taken care of, we'll be happy to approve this and merge as a fix for v2.0 as this looks like a regression as you noted.

[dragonmux]

A better idea might be to use the PARTNO value from the IDCODE register. It is mentioned in AN1303 that all series 2 parts (so, not what this driver supports) have IDCODE == 0x6BA02477, perhaps there is similar simple rule for the older parts supported by this driver?

This is an ARM part number, so is not unique or identifying to these devices in any way. This only tells us that we're talking with a ADIv5 DPv2 part. Every ADIv5 DPv2 part shares this ID code (modulo the first nibble (6) which is a version number). 477 -> 43b when decoded, which is ARM's JEP-106. ba02 is the partno for a DP w/ the last nibble (2) indicating version. ba00 -> DPv0, ba01 -> DPv1, ba02 -> DPv2, and ba03 -> DPv3 (ADIv6).

If any unique identifiers are available in that way, it would be from the ROM tables or TARGETID register, which can contain a Vendor part ID.

[dragonmux]

LGTM, merging. Thank you for the contribution!