[Bug] Realign and size check EECONFIG structures

[drashna]

Description

RGB/LED matrix eeconfig is overwriting addresses pass 34, which is not good.

Technically, it only takes up 6 bytes, but there is no uint48_t. So for correctness, extends the config to uint64_t to properly fit everything, which requires extending the EECONFIG blocks too.

Types of Changes

• Core
• Bugfix

Issues Fixed or Closed by This PR

• drashna found a bug: https://discord.com/channels/440868230475677696/1099913824024416339

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[fauxpark]

How does this affect the Input Club boards, if at all? Their EEPROM becomes locked to 32 bytes after flashing QMK for the first time due to misconfiguration in the driver.

[drashna]

How does this affect the Input Club boards, if at all? Their EEPROM becomes locked to 32 bytes after flashing QMK for the first time due to misconfiguration in the driver.

A quick look at it would seem to indicate that the val, speed, and flags would get truncated. Would it be worth moving the reserved block? It would mean that the led and rgb matrix would not be as parity like it is now, but it could fit in 32bit structure and would be fully under the 32byte limit, I think.

[zvecr]

You could always reorder and bump haptic to the end, far less users on that feature.

[drashna]

You could always reorder and bump haptic to the end, far less users on that feature.

Haptic isn't used on their boards, as far as I'm aware. So sounds "safe"

[drashna]

Apparently, because of how the struct was set up for haptic config, the size of the config was actually larger than 32 bits. Seems like AVR-GCC was okay with this, but arm-gcc did not like this.

https://github.com/drashna/qmk_firmware/actions/runs/4793553713/jobs/8526110742#step:4:494

Rearranging struct seems to fix this, and since we're already decrementing the Magic number...

[sigprof]

I'm still not completely convinced that we should waste 4 bytes of EEPROM to store the data that the RGBLIGHT subsystem does not actually use in any way. But if we choose to do it that way, at least we should clean up the misleading comments from that code.

[drashna]

I'm still not completely convinced that we should waste 4 bytes of EEPROM to store the data that the RGBLIGHT subsystem does not actually use in any way. But if we choose to do it that way, at least we should clean up the misleading comments from that code.

Can definitely understand that.

And part of that was me wanting to avoid with bitwise stuff.

Reverted some of the reorganization, and split off a block for rgblight speed. Can decide to nuke it or whatnot later.