[PATCH v2] ibm_newemac: Add support for GPCS, SGMIIandM88E1112 PHY

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Oct 2 23:48:24 EST 2008


On Thu, 2008-10-02 at 06:40 -0700, Victor Gallardo wrote:
> > Victor, while at it, can you do a fixup patch on top of it that guards
> > the new feature with a Kconfig option like some of the other ones so
> > that the code for it doesn't get compiled in when building, for example.
> > for 405GP only ?
> >
> > The trick is to have the option not be part of the possible mask, so
> > that the compiler optimises out the feature tests as if (0) (gcc
> > nowadays is supposedly smart enough to rip off the code when it finds
> > such constructs).
> 
> Hi Ben, 
>  
> Can you give an example of what you are asking for? I am not sure if I understand your request.

Well, if you look at the way emac_has_feature is implemented:

static inline int emac_has_feature(struct emac_instance *dev,
				   unsigned long feature)
{
	return (EMAC_FTRS_ALWAYS & feature) ||
	       (EMAC_FTRS_POSSIBLE & dev->features & feature);
}

And now, if you look a few lines up, you see that various CONFIG_*
options define what is in EMAC_FTRS_POSSIBLE.

The trick is, you can thus make your new option only be part of
EMAC_FTRS_POSSIBLE if support for a 460EX based board has been enabled
or even better, one that uses a GPCS PHY. You do that by creating a new
Kconfig option such as CONFIG_EMAC_SUPPORTS_GPCS for example that gets
select'ed by the boards that need it.

That way, when compiling a kernel for a board that does -not- need it,
the feature bit will be absent from EMAC_FTRS_POSSIBLE. That will allow
the compiler to figure out that when emac_has_feature() is called for
that option, the result will always be 0. Thus the compiler gets to
optimize out all the code relative to that option.

Cheers,
Ben.





More information about the Linuxppc-dev mailing list