On Wed, 2008-10-01 at 23:37 -0700, Victor Gallardo wrote:
> Signed-off-by: Victor Gallardo <vgallardo@amcc.com>> ---> v2:> - update to sync up with latest ibm_newemac driver
Ack.
Is this on top of Josh work ?
Ben.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

>> Signed-off-by: Victor Gallardo <vgallardo@amcc.com>>> --->> v2:>> - update to sync up with latest ibm_newemac driver>>Ack.>>Is this on top of Josh work ?>>Ben.
Yes, this based on Josh's git repository. Should I sync up with your git repository or is Josh's OK.
Regards,
Victor Gallardo

On Thu, 2008-10-02 at 00:30 -0700, Victor Gallardo wrote:
> > > Yes, this based on Josh's git repository. Should I sync up with your> git repository or is Josh's OK.
Josh is fine.
Jeff, can we merge all those EMAC patches via the powerpc git ? need an
ack from you I suppose ...
Thanks,
Ben.

On Thu, 02 Oct 2008 17:32:39 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2008-10-02 at 00:30 -0700, Victor Gallardo wrote:> > > > > > Yes, this based on Josh's git repository. Should I sync up with your> > git repository or is Josh's OK.> > Josh is fine.> > Jeff, can we merge all those EMAC patches via the powerpc git ? need an> ack from you I suppose ...
I already have this in my tree. Jeff already acked it (twice now I
think).
http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=shortlog;h=next
josh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Thu, 02 Oct 2008 20:34:28 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2008-10-02 at 06:33 -0400, Josh Boyer wrote:> > On Thu, 02 Oct 2008 17:32:39 +1000> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:> > > > > On Thu, 2008-10-02 at 00:30 -0700, Victor Gallardo wrote:> > > > > > > > > > > > Yes, this based on Josh's git repository. Should I sync up with your> > > > git repository or is Josh's OK.> > > > > > Josh is fine.> > > > > > Jeff, can we merge all those EMAC patches via the powerpc git ? need an> > > ack from you I suppose ...> > > > I already have this in my tree. Jeff already acked it (twice now I> > think).> > > > http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=shortlog;h=next> > Ok so it will go in when I get your pull request then :-0
Yep. You could pull now if you'd like. I have a few more patches I'd
like to get in before the merge window, but if it helps things I can do
those in a separate pull request.
josh

On Thu, Oct 02, 2008 at 06:56:48AM -0400, Josh Boyer wrote:
>> > > Jeff, can we merge all those EMAC patches via the powerpc git ? need an>> > > ack from you I suppose ...>> > >> > I already have this in my tree. Jeff already acked it (twice now I>> > think).>> > >> > http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=shortlog;h=next>> >> Ok so it will go in when I get your pull request then :-0>>Yep. You could pull now if you'd like. I have a few more patches I'd>like to get in before the merge window, but if it helps things I can do>those in a separate pull request.
Actually, it seems not. I pulled in an older version of the patch. I'll
grab the new version today.
/me sighs.
josh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Thu, 2008-10-02 at 07:55 -0400, Josh Boyer wrote:
> >Yep. You could pull now if you'd like. I have a few more patches I'd> >like to get in before the merge window, but if it helps things I can do> >those in a separate pull request.> > Actually, it seems not. I pulled in an older version of the patch. I'll> grab the new version today.
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).
Thanks !
Cheers,
Ben.

> 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.
Thanks,
Victor Gallardo

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.