Observation: Every single piece of hardware that is, or could ever exist, could be represented generically as follows:
1) One or more "meta-registers", that is, hardware registers for the purpose of reading and writing all of the other hardware registers.
2) Some form of standard callback/interrupt from the hardware indicating that registers have changed and need to be re-read.
3) Once #1 and #2 are defined, then a "linux-memory-region as readable/writable hardware-device registers" (such as regmap), can be easily and generically implemented.
regmap, while it implements a generic device abstraction, is itself not generically implemented, and can't be, until hardware designers implement #1 and #2, which first requires the creation of a standard, and then requires a consensus to use that standard for their hardware devices...
(Of course, DMA, as it exists currently, is still part of the model... what we're looking at here is the non-generic nature of hardware registers, from one hardware device to a different hardware device... that's still OK, but there should be one (or more) "meta-register(s)" to read/write all of the others, and some interrupt-driven way of being notified of changes... you know, in J.R.R. Tolkien terms "one register to bind them"... but maybe two or more meta-registers, for this purpose, make sense... I'm not a hardware engineer, I wouldn't know the optimal configuration...)
It's not the kernel that's constantly moving, it's the hardware. The idea of regmaps is that when you get a device revision B, rather than having to sprinkle "if(revision == ...)" all over your code you just look it up in a table.
How do Linux Devs manage to not accidentally break device support constantly? I imagine this stuff is close to impossible to write automated tests for.
Generally/Ideally things break early in the release cycle, bug reports show up on the mailing lists, and fixes are applied. They are marked with a Fixes tag so as for stable releases to pick them up if relevant.
For basic stuff (as in checking if boards still boot) you have projects like kernelci.org that detect regressions on a huge variety of boards. That said, if you need to support a touchscreen, or say, an uncommon USB device, it's up to you to take care of keeping up with the releases.
Previously a register address was a hardcoded constant. Very small,very fast.
Now, looking up a register ina map involves string matching on the name across every possible register in the map till you find a match. That is much slower, but also makes the kernel quite a lot larger, because you're effectively shipping half the device datasheet in the form of names for every flag bit.
At runtime this is all just a couple of pointer indirections so the impact is minimal. There are also special functions for bulk transfer so regmap shouldn't be called in tight loops.
Looks like a string in the structure to me. And when you have an array of such structures, you end up scanning through them checking for the name you need.
Look at the usage example a couple of lines below; it's passing a pointer to that structure. There's no scanning necessary, it already knows where the structure is.
1) One or more "meta-registers", that is, hardware registers for the purpose of reading and writing all of the other hardware registers.
2) Some form of standard callback/interrupt from the hardware indicating that registers have changed and need to be re-read.
3) Once #1 and #2 are defined, then a "linux-memory-region as readable/writable hardware-device registers" (such as regmap), can be easily and generically implemented.
regmap, while it implements a generic device abstraction, is itself not generically implemented, and can't be, until hardware designers implement #1 and #2, which first requires the creation of a standard, and then requires a consensus to use that standard for their hardware devices...
(Of course, DMA, as it exists currently, is still part of the model... what we're looking at here is the non-generic nature of hardware registers, from one hardware device to a different hardware device... that's still OK, but there should be one (or more) "meta-register(s)" to read/write all of the others, and some interrupt-driven way of being notified of changes... you know, in J.R.R. Tolkien terms "one register to bind them"... but maybe two or more meta-registers, for this purpose, make sense... I'm not a hardware engineer, I wouldn't know the optimal configuration...)