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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.