linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Grant Likely" <grant.likely@secretlab.ca>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH v2] update crypto node definition and device tree instances
Date: Sun, 29 Jun 2008 01:37:12 +0200	[thread overview]
Message-ID: <2b97f7566925ed86b78b364ff5724644@kernel.crashing.org> (raw)
In-Reply-To: <fa686aa40806272229s795067d5he962c8a1750a260@mail.gmail.com>

> 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
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_).

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.


Segher

  reply	other threads:[~2008-06-28 23:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-27 16:52 [PATCH v2] update crypto node definition and device tree instances Kim Phillips
2008-06-28  5:29 ` Grant Likely
2008-06-28 23:37   ` Segher Boessenkool [this message]
2008-06-30 16:04     ` Kim Phillips
2008-06-30 16:55       ` Segher Boessenkool
2008-06-30 18:14         ` Kim Phillips
2008-06-30 21:19           ` Segher Boessenkool
2008-06-30 22:30             ` Kim Phillips
2008-06-30 23:27               ` Segher Boessenkool
2008-07-01  0:38                 ` Kim Phillips
2008-06-30 15:56   ` Kim Phillips

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b97f7566925ed86b78b364ff5724644@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).