Thread (34 messages) 34 messages, 12 authors, 2006-10-05

Re: [PATCH 10/11] Add MPC8360EMDS board support

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2006-10-05 00:08:55

On Thu, 2006-10-05 at 10:03 +1000, Paul Mackerras wrote:
Benjamin Herrenschmidt writes:
quoted
quoted
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, feature calls might be the answer there... at least to move the
problem out of the driver to the platform code. They are after all just
a way to do random calls into the BSP from drivers, though they have
some issues too (you gotta hope you are running the right platform code
that understands your calls, in which case, why not just call an
exported function ...)

Ben.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help