mmcreg.h: update and match values to spec

[mchoo]

Summary

This adds and fixes values defined in the latest SD and eMMC standard. This is a breaking change, but it has to happen because FreeBSD's mmc macro doesn't match the spec's field name, which could be painful for device driver developers.

This is part of effort to bring mmc support for linuxkpi. Linux doesn't follow standard field name in some cases like DEVICE_TYPE, but it could be fixed in linux/mmc/mmc.h

[mchoo]

Align comment

[mchoo]

This change could be controversial: both keeping old name and strictly following the spec's name makes sense. Even Linux doesn't strictly follow spec's field name such as PARTITION (PART) and DEVICE ('CARD`), so handling these cases in linuxkpi header is inevitable either way. I want to hear others' opinion on this.

[mchoo]

Partial build fix

[mchoo]

As this moves MMC 3.31 to eMMC 5.1, we need to discuss backward-compatibility issue.

[mchoo]

fix missing stuff

[mchoo]

stick with mmc for now

[marius]

In fact, the macros added as part of implementing eMMC support already
were based on v5.1 of the eMMC specification. However, some have been
shortened on purpose in order to make it easier for keeping resulting
code within 80 columns.
Apparently, Linux chose to do the same and as you say, still as of today
uses e. g. EXT_CSD_CARD_TYPE and EXT_CSD_PART_CONFIG. Thus,
it seems backwards to change such macros to something Linux doesn't
use either.
Moreover, with 49 chars EXT_CSD_NUMBER_OF_FW_SECTORS_CORRECTLY_PROGRAMMED
is ridiculously long and Linux apparently doesn't have a macro for that
register at all.
Thus, overall, I'd prefer to stick to the convention of shortening macro
names where it makes sense (also for additional ones being added), and to
just add alias macros to linuxkpi when needed.
Generally, your patch also mixes the addition of new macros for mostly
SPI mode with changing existing ones, which should be separate changes,
if at all.

The more controversial point is what SDIO support in linuxkpi will be
based on. Hopefully, that won't be the failed academic experiment known
as MMCCAM. Given that the successor technology (see ufshci(4)) is already
15 years old by now, I'd rather import the known-working Net/OpenBSD
SDIO code and be done with it instead of having to port lots of existing stuff
over to MMCCAM. Net/OpenBSD also already even have a driver for the
WiFi on Raspberry Pi.
As such, MMCCAM feels like reimplementing isa(4) on top of CAM. Now
there _might_ have been a point for going the CAM route iff MMCCAM
supported CQE right from the beginning. However, as it currently stands,
MMCCAM doesn't even have feature parity with mmc(4)/mmcsd(4).

[mchoo]

I'm abandoning this revision for the following reasons:

• I agree with @marius that we should keep the current conventions for (e)MMC constant names and the additions for SPI mode should be a separate patch.
• Currently there is a separate effort for sdio support on linuxkpi, so this change doesn't worth tracking anymore.

I will revisit this again in future if we need a specific (e)MMC issue to deal with.