Also, these made-up names make you do more work: you'll need to
who said they were made up?
I did. These names do not refer to some physical part you can buy.
write up a binding for them, explaining exactly what a 1.0 device
etc. is (or at least point to documentation for it). If you use
a name that refers to some device that people can easily google
for documentation, you can skip this (well, you might need to
write a binding anyway; but at least you won't have to explain
what the device _is_).
documentation is available in the usual places, and it specifically
points out which SEC version it references.
I can't find a manual online for "freescale sec"; googling
for "freescale sec-1.0" finds a manual for the PowerQUICC I;
is that the right one? I don't know, so the binding needs
to explain it to me.
Going from SoC name -> SEC version is easy, but the other way around
not so.
Anyway, minor stuff.
Plus, as I mentioned
before, a lot of the differences between the SEC versions are miniscule
feature bits scattered across the programming model.
I don't see how this is relevant, sorry.
Using actual model names also reduces the namespace pollution
(hopefully Freescale will not create some other MPC8272 device
ever, so "fsl,mpc8272-whatever" will never be a nice name to
use for any other device; OTOH, it's likely that Freescale will
create some other device called "SEC" (there are only so many
TLAs, after all), so "fsl,sec-n.m" isn't as future-proof.
I doubt that; the SEC has been around for about a decade now and that
hasn't happened.
You'll have to admit a three-letter acronym is a bigger namespace
squatter than a nice long name is. But it's your namespace, I don't
care.
i tried googling for "freescale sec" to find any other devices called
SEC, but that didn't work out. What is "insider trading"? ;-)
Segher
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
