Aside from the one nit, looks good.

The change looks fine. cr_cpuid != cr_hwref because cr_hwref is the "hardware logical" CPU ID (multithreaded CPUs count by N, not 1). So on e6500 cpu1 to FreeBSD is hwref 2. The "reg" property on e6500 CPUs (T2080, etc) is actually an array of IDs. Since we currently don't support multithreading on Book-E (and I have no plans at this time to add it, but may if I get bored) we only accept the first member in the array. Looking through the code, though, for this platform you're right, that hwref is not used. cr_hwref (and pc_hwref) look to only be used on the AIM platforms (particularly powernv). I had to make a lot of changes to this code when doing the e6500 bringup earlier this year, but it could likely be removed. The only reason this difference between cpuid and hwref is needed is for the openpic interface, but the PIC_AP_INIT() change I added makes that unnecessary, the pc_pic field now takes care of that.

This change is not necessary.

Add missing files linux_emul_md.{c,h}

Address all feedback. Since a lot of time has passed since, I also added more
features, primarily VMX/VSX and signal handling.

Will go a different route--move this functionality into fman_xmdio instead per @mmel.

@mmel this new driver is effectively the mii_fdt.c equivalent on the mdio side. From a physical perspective, my understanding is mdio is the low-level serial interface that can connect "anything", while MII is the higher level bus intended for PHYs, so MII "sits on top of" MDIO in reality, and they're separate entities in our driver architecture.

Helps if I add some reviewers.

Works for me! Resolves PR292006.