Thread (6 messages) flat view 6 messages, 2 authors, 2000-05-05

Better board support (was Re: [PATCH] Adding support for LXT971/2 PHYs)

From: Graham Stoney <hidden>
Date: 2000-05-05 05:19:36

Hi again,

Dan Malek writes:
There is lots of stuff that comes straight to me for merging into
sources.......
I know it's beyond your control; My plea was for other developers reading this
to cc the mailing list when they send you patches, so we all know what's going
on.
quoted
.......... My ideal solution to the problem of supporting multiple board
types is to move the magic numbers like the PHY interrupt pin and the
PxPAR/PxDIR/etc values into each board-specific header file,
I understand your point, but the other side of the argument is when you
don't keep things like this together, people don't realize how many
examples of how to do it exist.  They also don't realize how their
change may affect someone else.
Not sure I'm with you here, but I think we need to have a simple single
solution to multiple board support, and to use it universally. If we replace
all the board-specific #ifdefs with feature-specific ones defined in the board
specific header files, everything related to a specific board is all kept
together. I don't think I'm proposing anything new here, just a more complete
use of the current scheme where each board type has its own header defining
the features present on that board. This is also the approach 8xxROM/PPCBOOT
uses, and it would be nice to keep them all consistent.

Another example under the scheme would be to replace most of the usages of
"#ifdef CONFIG_RPXCLASSIC" in fec.c with "#ifdef PHY_QS6612", and put
"#define PHY_QS6612" in rpxclassic.h. At present, anyone adding a board which
uses the QS6612 has to edit fec.c, even though it already supports their PHY.
quoted
We took this approach with our new custom board, and haven't had to add a
single #ifdef CONFIG_ourboardname outside the one which chooses our
board-specific header in mpc8xx.h.
I do that with lots of custom boards.  Most are simple derivative of
what is already there.  In fact, some have even choose the same I/O
pins for Ethernet (there aren't many options, and most have been used :-),
so we don't even need to add anything but another conditional on an
#ifdef.
I'd much prefer the conditionals to test for board features rather than
specific boards. That way you _don't_ have to add another conditional on an
#ifdef every time you add a new board with existing features. In cases like
register names and bit definitions, we can even avoid the conditionals
altogether by using definitions like:

/* Ethernet : PHY controls - connected to port X
 *
 * Field        Value   Explanation
 * -----        -----   -----------
 * PHYPAUSE[x]      0   We don't support pause
 * PHYPWRDWN[x]     0   We don't support power down
 * PHYSLEEP[x]      0   We don't support sleep
 */
#define PHY_PAUSE               ((ushort) 0x0800)
#define PHY_PWRDWN              ((ushort) 0x0200)
#define PHY_SLEEP               ((ushort) 0x0040)

#define PHY_PAUSE_PORT          im_ioport.iop_pXdat
#define PHY_PWRDWN_PORT         im_ioport.iop_pXdat
#define PHY_SLEEP_PORT          im_ioport.iop_pXdat
It's just not as easy as getting a patch and checking it in.
I appreciate your efforts co-ordinating all this. One of the reasons for
posting a patch is to stimulate discussion, and I'm interested in comments
from other people too.

Thanks,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help