From: Vitaly Bordug <vbordug@ru.mvista.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Olof Johansson <olof@lixom.net>, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
Date: Thu, 5 Oct 2006 04:16:22 +0400 [thread overview]
Message-ID: <20061005041622.58c9ada2@vitb-lp.dev.rtsoft.ru> (raw)
In-Reply-To: <17700.19414.724178.711359@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
On Thu, 5 Oct 2006 10:03:34 +1000
Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > > It's the 'or not' part that I am worried about. Things like
> > > you mention above make sense. I'm starting to worry about
> > > some of this other stuff, and the bscr example is what
> > > woke me up :-) I think that's an example of things that
> > > should be considered not necessary.
> >
> > I haven't looked at this specific example. I'll try to have a look
> > later. I jumped into the discussion pointed by somebody else :)
>
> That one was interesting - the bcsr was being referenced from an
> ethernet driver that looked to me like it would be useful on any board
> based on an 836x chip (I think). Yet it was claimed that the bcsr was
> so specific and unique to each board that there was no point putting
> it in the device tree - which implies that we would have to have a
> separate lump of code in the tree to drive it for every single
> board. :P I asked why the ethernet driver was accessing it directly
> if that was the case, but didn't get an answer (well, only an indirect
> answer in that the bcsr access code got removed from the ethernet
> driver).
>
Well that's because accessing bcsr in generic code is just odd. Yes, there are some places with
such a stuff still. bcsr is something like a sw jumper to enable/disable stuff, configure things, etc.
which may vary up to the hw design even if it's following the reference closely.
It's unique across the boards, and should be touched in BSP code only to keep the base sane.
Such a thing in the eth driver directly was sort of "nice" because takes care of enabling network "physically"
on board. For the same aim, I used to have board-specific callback to set up some bits if needed(speaking about
fs_enet/ppc). IOW, upon network driver init, it triggers callback function (passed in there via platform data) that's intended to do the bsp setup (or may be unset if nothing needed). In powerpc, only sane solution seems to be Dan's proposed
feature_call thing. I wish I'd have some time for that ...
Thanks,
-Vitaly
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-10-05 0:16 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-21 12:20 [PATCH 10/11] Add MPC8360EMDS board support Li Yang
2006-09-27 6:39 ` Paul Mackerras
2006-09-27 11:56 ` Vitaly Bordug
2006-09-27 12:02 ` Li Yang-r58472
2006-09-27 12:55 ` Vitaly Bordug
2006-09-27 13:09 ` Ben Warren
2006-09-27 13:20 ` Li Yang-r58472
2006-09-27 13:33 ` Kumar Gala
2006-09-28 6:12 ` Li Yang-r58472
2006-09-30 0:49 ` Paul Mackerras
2006-09-27 14:14 ` Jon Loeliger
2006-09-28 6:38 ` Li Yang-r58472
2006-09-27 14:42 ` Dan Malek
2006-09-27 16:22 ` Olof Johansson
2006-09-28 4:10 ` Dan Malek
2006-09-30 15:56 ` Li Yang
2006-10-04 0:40 ` Paul Mackerras
2006-10-04 13:53 ` Dan Malek
2006-10-04 17:28 ` Tim Bird
2006-10-05 0:27 ` Paul Mackerras
2006-10-05 6:29 ` Eugene Surovegin
2006-10-04 6:08 ` Benjamin Herrenschmidt
2006-10-04 14:48 ` Dan Malek
2006-10-04 23:36 ` Benjamin Herrenschmidt
2006-10-05 0:03 ` Paul Mackerras
2006-10-05 0:08 ` Benjamin Herrenschmidt
2006-10-05 0:16 ` Vitaly Bordug [this message]
2006-10-05 6:21 ` Eugene Surovegin
2006-10-05 6:26 ` Benjamin Herrenschmidt
2006-10-05 6:31 ` Eugene Surovegin
2006-10-05 6:33 ` Eugene Surovegin
2006-10-05 6:51 ` Benjamin Herrenschmidt
2006-10-04 5:52 ` Benjamin Herrenschmidt
2006-10-04 14:57 ` Dan Malek
2006-10-04 16:05 ` Jerry Van Baren
2006-09-27 14:57 ` Sergei Shtylyov
-- strict thread matches above, loose matches on Subject: below --
2006-09-27 13:54 Joakim Tjernlund
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=20061005041622.58c9ada2@vitb-lp.dev.rtsoft.ru \
--to=vbordug@ru.mvista.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=olof@lixom.net \
--cc=paulus@samba.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).