On Wed, 2013-11-06 at 12:34 +1100, Alistair Popple wrote:
> On Tue, 5 Nov 2013 23:11:50 Ben Hutchings wrote:
> > On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote:
>
> [snip]
>
> > > It's an SoC bit so there's little point making it generally
> > > selectable by the user.
> >
> > I think a better way to do this is:
> >
> > config IBM_EMAC_RGMII_WOL
> > bool "IBM EMAC RGMII wake-on-LAN support"
> > depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST
> > default y if MY_WONDERFUL_NEW_SOC
> >
> > Then anyone making an API change that affects this driver can check that
> > it still complies.
>
> The method used in this patch is the same as what is currently used by the
> other IBM EMAC PHY interfaces (eg. config IBM_EMAC_ZMII etc). I'm happy to
> send a patch to update all of those as well for consistency but that would
> mean adding what each platform requires into EMACS Kconfig as well.
>
> Personally I think it is nicer to keep the definitions of what each platform
> requires in one place (ie. arch/powerpc/platforms/44x/Kconfig) as it is
> consistent with what we do for other 44x drivers, however I am happy to use
> the above method if people think it's better.
Yes, I see your point.
> Alternatively we could do something like this:
>
> config IBM_EMAC_RGMII_WOL
> bool
> default y if COMPILE_TEST
> default n
>
> This would leave the platform dependencies as they are currently but still
> allow compile testing.
It still shouldn't default to y in that case. Instead you can make the
symbol conditionally configurable:
config IBM_EMAC_RGMII_WOL
bool "IBM EMAC RGMII wake-on-LAN support" if COMPILE_TEST
and then select this from your platform Kconfig as you intended.
(There is no need to put 'default n' as that's implicit for a
configurable symbol. But it doesn't hurt either.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
