linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dan Malek <dan@embeddededge.com>
To: Vitaly Bordug <vbordug@ru.mvista.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
	Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
Date: Thu, 30 Mar 2006 08:09:01 -0500	[thread overview]
Message-ID: <0f0e0fbbf56f73879a70f785c497756c@embeddededge.com> (raw)
In-Reply-To: <20060330142626.1a9d22f5@vitb.ru.mvista.com>


On Mar 30, 2006, at 5:26 AM, Vitaly Bordug wrote:

> - 	the new way, all that will not follow it will be obsoleted sooner 
> or later

The problem I see is the "new way" is done for the sake of doing 
something
new, without adding any value.  If you want to make the drivers 
dynamically
configurable, which I'll continue to argue is silly in an embedded 
environment
of the type with CPMs, all you need to know is personality of the 
device.
The reason it's silly is the wiring on the particular board dictates 
how a
CPM peripheral will be used.  The SCC1 can't be a serial uart one
moment and an Ethernet the next time you boot up.  Since you have 
already
done a "board port", you may as well wire this as part of the 
configuration
and eliminate potential mistakes.  If you insist on making this dynamic
(and as a port maintainer I would reject such patches), the only thing
you need to describe is the device type.  For example, the SCC1 can be
an Ethernet or uart.  We only support FCCs as Ethernets, and unless
someone submits some other kind of driver, like ATM/UTOPIA, there
isn't anything variable to configure.

All of the truly configurable options, like NMSI vs. TSA, are so complex
the device tree would not be helpful, as that would be built into the
custom driver to configure as necessary.

The offsets into the internal register maps are not so variable that 
adding
the information into the device tree is useful.  There is CPM1 and CPM2,
some common code shared between them that already solves the
problems, and the real difference between the two different CPM2 maps
on 82xx isn't reflected here (but again is already solved in the 
existing
software).  As I said in the past message, this seems more likely to 
cause
errors than be helpful.  To me it just seems new for the sake of being
new, rather than providing any real value.

I'd rather we spend our time adding the xmon and kgdb over serial port
features back into the driver that were lost during the "great driver 
clean up"
than pursing stuff like this.

Thanks.

	-- Dan

  reply	other threads:[~2006-03-30 13:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-28 16:14 [PATCH] powerpc: Add FSL CPM2 device tree node documentation Vitaly Bordug
2006-03-28 16:37 ` Kumar Gala
2006-03-28 16:42   ` Vitaly Bordug
2006-03-28 16:55 ` Paul Nasrat
2006-04-12 23:19   ` Andy Fleming
2006-04-13  5:14     ` Paul Nasrat
2006-04-13 15:15       ` Jon Loeliger
2006-04-21 11:17     ` Paul Mackerras
2006-03-30  5:05 ` Dan Malek
2006-03-30  6:10   ` Paul Mackerras
2006-03-30 10:37     ` Vitaly Bordug
2006-03-30 10:26   ` Vitaly Bordug
2006-03-30 13:09     ` Dan Malek [this message]
2006-03-30 14:37       ` Kumar Gala
2006-03-30 15:14         ` Dan Malek
2006-03-30 15:02           ` Vitaly Bordug
2006-03-30 15:43           ` Kumar Gala
2006-03-30 15:10             ` Vitaly Bordug

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=0f0e0fbbf56f73879a70f785c497756c@embeddededge.com \
    --to=dan@embeddededge.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    --cc=vbordug@ru.mvista.com \
    /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).