On Wednesday 05 June 2013, Alexandre Belloni wrote:
> However, it is becoming urgent for Atmel to get the fix in 3.10 so that
> they never get a kernel compilation that breaks.
I don't think it's urgent since this is only about rare configurations,
and not a regression. We can queue the patch
On 04/06/2013 18:09, Florian Fainelli wrote:
> 2013/6/4 Arnd Bergmann :
>> On Tuesday 04 June 2013 16:36:50 Florian Fainelli wrote:
>>> It seems to me that what David proposes is to have say an
>>> arch/arm/mach-foo/phy-fixups.c file which is only enabled when
>>> CONFIG_PHYLIB is set
On 04/06/2013 18:09, Florian Fainelli wrote:
2013/6/4 Arnd Bergmann a...@arndb.de:
On Tuesday 04 June 2013 16:36:50 Florian Fainelli wrote:
It seems to me that what David proposes is to have say an
arch/arm/mach-foo/phy-fixups.c file which is only enabled when
CONFIG_PHYLIB is set
On Wednesday 05 June 2013, Alexandre Belloni wrote:
However, it is becoming urgent for Atmel to get the fix in 3.10 so that
they never get a kernel compilation that breaks.
I don't think it's urgent since this is only about rare configurations,
and not a regression. We can queue the patch ARM:
On Tuesday 04 June 2013 17:09:26 Florian Fainelli wrote:
> You would just need to define a stub for your arch_foo_phy_fixup()
> which has a different definition depending on whether CONFIG_PHYLIB is
> defined or not.
Yes, same thing. For a function that is called in only one place,
I would always
2013/6/4 Arnd Bergmann :
> On Tuesday 04 June 2013 16:36:50 Florian Fainelli wrote:
>> It seems to me that what David proposes is to have say an
>> arch/arm/mach-foo/phy-fixups.c file which is only enabled when
>> CONFIG_PHYLIB is set (obj-$(CONFIG_PHYLIB) += phy-fixup.o), such that
>> it does not
On Tuesday 04 June 2013 16:36:50 Florian Fainelli wrote:
> It seems to me that what David proposes is to have say an
> arch/arm/mach-foo/phy-fixups.c file which is only enabled when
> CONFIG_PHYLIB is set (obj-$(CONFIG_PHYLIB) += phy-fixup.o), such that
> it does not need to have any conditionnals
2013/6/4 Arnd Bergmann :
>> Or you properly segregate the networking bits of the platform code so
>> that it can be built only when the necessary networking portions are
>> enabled.
>>
>> Sometimes having dummy stubs makes sense, but not in this situation.
>
> Currently most users of this function
On Thursday 30 May 2013 02:42:01 David Miller wrote:
> From: Alexandre Belloni
> > On 28/05/2013 22:09, David Miller wrote:
> > But that is making it impossible to compile a kernel without any network
> > stack for those platforms or we are going back to either enclosing the
> > calls to
On Thursday 30 May 2013 02:42:01 David Miller wrote:
From: Alexandre Belloni alexandre.bell...@free-electrons.com
On 28/05/2013 22:09, David Miller wrote:
But that is making it impossible to compile a kernel without any network
stack for those platforms or we are going back to either
2013/6/4 Arnd Bergmann a...@arndb.de:
Or you properly segregate the networking bits of the platform code so
that it can be built only when the necessary networking portions are
enabled.
Sometimes having dummy stubs makes sense, but not in this situation.
Currently most users of this
On Tuesday 04 June 2013 16:36:50 Florian Fainelli wrote:
It seems to me that what David proposes is to have say an
arch/arm/mach-foo/phy-fixups.c file which is only enabled when
CONFIG_PHYLIB is set (obj-$(CONFIG_PHYLIB) += phy-fixup.o), such that
it does not need to have any conditionnals
2013/6/4 Arnd Bergmann a...@arndb.de:
On Tuesday 04 June 2013 16:36:50 Florian Fainelli wrote:
It seems to me that what David proposes is to have say an
arch/arm/mach-foo/phy-fixups.c file which is only enabled when
CONFIG_PHYLIB is set (obj-$(CONFIG_PHYLIB) += phy-fixup.o), such that
it does
On Tuesday 04 June 2013 17:09:26 Florian Fainelli wrote:
You would just need to define a stub for your arch_foo_phy_fixup()
which has a different definition depending on whether CONFIG_PHYLIB is
defined or not.
Yes, same thing. For a function that is called in only one place,
I would always
From: Alexandre Belloni
Date: Wed, 29 May 2013 10:21:26 +0200
> On 28/05/2013 22:09, David Miller wrote:
>>
>> This is the wrong way to go about this.
>>
>> If the arch code absolutely requires CONFIG_PHYLIB=y then express that
>> dependency in the arch Kconfig. The arch code in question should
From: Alexandre Belloni alexandre.bell...@free-electrons.com
Date: Wed, 29 May 2013 10:21:26 +0200
On 28/05/2013 22:09, David Miller wrote:
This is the wrong way to go about this.
If the arch code absolutely requires CONFIG_PHYLIB=y then express that
dependency in the arch Kconfig. The
Hi,
On 28/05/2013 22:09, David Miller wrote:
>
> This is the wrong way to go about this.
>
> If the arch code absolutely requires CONFIG_PHYLIB=y then express that
> dependency in the arch Kconfig. The arch code in question should not
> be compiled at all if CONFIG_PHYLIB has an incompatible
Hi,
On 28/05/2013 22:09, David Miller wrote:
This is the wrong way to go about this.
If the arch code absolutely requires CONFIG_PHYLIB=y then express that
dependency in the arch Kconfig. The arch code in question should not
be compiled at all if CONFIG_PHYLIB has an incompatible setting.
From: Alexandre Belloni
Date: Tue, 28 May 2013 13:43:21 +0200
> phy_register_fixup{,_for_uid,_for_id} are called from arch/, quite
> often, there is no protection to check whether CONFIG_PHYLIB=y which is
> the only case where this would work. Having phylib as a module or not
> compiled at all
phy_register_fixup{,_for_uid,_for_id} are called from arch/, quite
often, there is no protection to check whether CONFIG_PHYLIB=y which is
the only case where this would work. Having phylib as a module or not
compiled at all will result in that kind of linking failure:
phy_register_fixup{,_for_uid,_for_id} are called from arch/, quite
often, there is no protection to check whether CONFIG_PHYLIB=y which is
the only case where this would work. Having phylib as a module or not
compiled at all will result in that kind of linking failure:
From: Alexandre Belloni alexandre.bell...@free-electrons.com
Date: Tue, 28 May 2013 13:43:21 +0200
phy_register_fixup{,_for_uid,_for_id} are called from arch/, quite
often, there is no protection to check whether CONFIG_PHYLIB=y which is
the only case where this would work. Having phylib as a
22 matches
Mail list logo
