On Sun, 29 Jun 2008 01:37:12 +0200 Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> > I'm really don't like "fsl,sec1.0" or any of the variants as a > > compatible property either because it can easily be abused (it's not > > anchored to a specific physical part so the meaning can shift over > > time); but that is another argument and it is well documented in other > > email threads > > (http://thread.gmane.org/gmane.linux.ports.ppc64.devel/38977/ > > focus=39147) > > Also, these made-up names make you do more work: you'll need to who said they were made up? > 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. Plus, as I mentioned before, a lot of the differences between the SEC versions are miniscule feature bits scattered across the programming model. > 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. The SEC is on par with the TSEC ethernet controller as far as this goes. Kim _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
