Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Kumar Gala


On Jun 3, 2008, at 10:10 AM, Scott Wood wrote:


Kumar Gala wrote:

How is this as a fix.
- k
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/ 
platforms/85xx/Kconfig

index 7ff29d5..9e5c884 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -34,6 +34,7 @@ config MPC85xx_MDS
bool Freescale MPC85xx MDS
select DEFAULT_UIMAGE
select QUICC_ENGINE
+   select PHYLIB if GIANFAR=m
help
  This option enables support for the MPC85xx MDS board


I assume you'll also ifdef-protect the phy calls in the platform code?


yes this needs to get done.

I'd rather avoid adding another case where the kernel needs to know  
what modules are being built, though, especially if the result of  
changing the .config and building modules is a mysterious runtime  
failure (due to a missing platform fixup) rather than compile- or  
insertion-time.


I don't follow what you are getting at here.  Is this something more  
than #ifdef PHYLIB in the platform code?


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Scott Wood

Kumar Gala wrote:

On Jun 3, 2008, at 10:10 AM, Scott Wood wrote:
I'd rather avoid adding another case where the kernel needs to know 
what modules are being built, though, especially if the result of 
changing the .config and building modules is a mysterious runtime 
failure (due to a missing platform fixup) rather than compile- or 
insertion-time.


I don't follow what you are getting at here.  Is this something more 
than #ifdef PHYLIB in the platform code?


If you just #ifdef PHYLIB, then things will break if the user does this:
make config, GIANFAR=PHYLIB=n
make zImage
make config, GIANFAR=PHYLIB=m
make modules

And the cause of the failure will not be something that obviously points 
to a build problem, such as unresolved symbols.


I'd rather just unconditionally select PHYLIB on platforms that need to 
do fixups.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Kumar Gala


On Jun 3, 2008, at 10:18 AM, Scott Wood wrote:


Kumar Gala wrote:

On Jun 3, 2008, at 10:10 AM, Scott Wood wrote:
I'd rather avoid adding another case where the kernel needs to  
know what modules are being built, though, especially if the  
result of changing the .config and building modules is a  
mysterious runtime failure (due to a missing platform fixup)  
rather than compile- or insertion-time.
I don't follow what you are getting at here.  Is this something  
more than #ifdef PHYLIB in the platform code?


If you just #ifdef PHYLIB, then things will break if the user does  
this:

make config, GIANFAR=PHYLIB=n
make zImage
make config, GIANFAR=PHYLIB=m
make modules

And the cause of the failure will not be something that obviously  
points to a build problem, such as unresolved symbols.


what you are suggesting will not break with my patch.

The second case will for PHYLIB=y w/the select.

I'd rather just unconditionally select PHYLIB on platforms that need  
to do fixups.


But you don't need fix ups for the phy if you don't have the enet  
driver that the phy is connected to in your system.


(But I do understand the desire to be generous, but I think we can get  
this right).


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Scott Wood

Kumar Gala wrote:

On Jun 3, 2008, at 10:18 AM, Scott Wood wrote:

Kumar Gala wrote:

On Jun 3, 2008, at 10:10 AM, Scott Wood wrote:
I'd rather avoid adding another case where the kernel needs to know 
what modules are being built, though, especially if the result of 
changing the .config and building modules is a mysterious runtime 
failure (due to a missing platform fixup) rather than compile- or 
insertion-time.
I don't follow what you are getting at here.  Is this something more 
than #ifdef PHYLIB in the platform code?


If you just #ifdef PHYLIB, then things will break if the user does this:
make config, GIANFAR=PHYLIB=n
make zImage
make config, GIANFAR=PHYLIB=m
make modules

And the cause of the failure will not be something that obviously 
points to a build problem, such as unresolved symbols.


what you are suggesting will not break with my patch.


Yes, it will -- note the absence of a make zImage after the second 
make config.



The second case will for PHYLIB=y w/the select.


And that will only make a difference if you rebuild the kernel itself 
after enabling the module.


-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Kumar Gala


On Jun 3, 2008, at 10:36 AM, Scott Wood wrote:


Kumar Gala wrote:

On Jun 3, 2008, at 10:18 AM, Scott Wood wrote:

Kumar Gala wrote:

On Jun 3, 2008, at 10:10 AM, Scott Wood wrote:
I'd rather avoid adding another case where the kernel needs to  
know what modules are being built, though, especially if the  
result of changing the .config and building modules is a  
mysterious runtime failure (due to a missing platform fixup)  
rather than compile- or insertion-time.
I don't follow what you are getting at here.  Is this something  
more than #ifdef PHYLIB in the platform code?


If you just #ifdef PHYLIB, then things will break if the user does  
this:

make config, GIANFAR=PHYLIB=n
make zImage
make config, GIANFAR=PHYLIB=m
make modules

And the cause of the failure will not be something that obviously  
points to a build problem, such as unresolved symbols.

what you are suggesting will not break with my patch.


Yes, it will -- note the absence of a make zImage after the second  
make config.



The second case will for PHYLIB=y w/the select.


And that will only make a difference if you rebuild the kernel  
itself after enabling the module.


I see.  However, I don't like the idea I have to build in the PHYLIB  
if I don't need it at all.  It seems like the type of breakage you are  
talking about exists today all over the place.  I dont like it anymore  
than you do, but it seems to me the lesser of evils is to allow the  
user the ability to config things as they want.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[RFC] Make board force selection of PHYLIB

2008-06-03 Thread Kumar Gala
How is this as a fix.

- k

diff --git a/arch/powerpc/platforms/85xx/Kconfig 
b/arch/powerpc/platforms/85xx/Kconfig
index 7ff29d5..9e5c884 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -34,6 +34,7 @@ config MPC85xx_MDS
bool Freescale MPC85xx MDS
select DEFAULT_UIMAGE
select QUICC_ENGINE
+   select PHYLIB if GIANFAR=m
help
  This option enables support for the MPC85xx MDS board

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Scott Wood

Kumar Gala wrote:

How is this as a fix.

- k

diff --git a/arch/powerpc/platforms/85xx/Kconfig 
b/arch/powerpc/platforms/85xx/Kconfig
index 7ff29d5..9e5c884 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -34,6 +34,7 @@ config MPC85xx_MDS
bool Freescale MPC85xx MDS
select DEFAULT_UIMAGE
select QUICC_ENGINE
+   select PHYLIB if GIANFAR=m
help
  This option enables support for the MPC85xx MDS board


I assume you'll also ifdef-protect the phy calls in the platform code?

I'd rather avoid adding another case where the kernel needs to know what 
modules are being built, though, especially if the result of changing 
the .config and building modules is a mysterious runtime failure (due to 
a missing platform fixup) rather than compile- or insertion-time.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Scott Wood

Kumar Gala wrote:

I see.  However, I don't like the idea I have to build in the PHYLIB
if I don't need it at all.


Understood, but in practice I don't think the 10K or so matters that
much on a typical 85xx board, and if the user really needs to trim
things down, they always have the option of manually ripping the phy
stuff out.


It seems like the type of breakage you are talking about exists today
all over the place.


It exists in a few places, but it's not that common, and often it's 
obvious what went wrong when the module won't load because some kernel 
hook didn't get built.  It's not a huge deal, but I'd rather avoid 
introducing another instance.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Adrian Bunk
On Tue, Jun 03, 2008 at 09:47:19AM -0500, Kumar Gala wrote:
 How is this as a fix.
 
 - k
 
 diff --git a/arch/powerpc/platforms/85xx/Kconfig 
 b/arch/powerpc/platforms/85xx/Kconfig
 index 7ff29d5..9e5c884 100644
 --- a/arch/powerpc/platforms/85xx/Kconfig
 +++ b/arch/powerpc/platforms/85xx/Kconfig
 @@ -34,6 +34,7 @@ config MPC85xx_MDS
   bool Freescale MPC85xx MDS
   select DEFAULT_UIMAGE
   select QUICC_ENGINE
 + select PHYLIB if GIANFAR=m
   help
 This option enables support for the MPC85xx MDS board

The .config you sent me as an example didn't have GIANFAR set, so it 
couldn't help there.

How early do the fixups have to run?

I see two possible solutions:
- let MPC85xx_MDS unconditionally select PHYLIB or
- move the fixups to the gianfar driver

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Andy Fleming


On Jun 3, 2008, at 10:31, Kumar Gala wrote:



On Jun 3, 2008, at 10:18 AM, Scott Wood wrote:


If you just #ifdef PHYLIB, then things will break if the user does  
this:

make config, GIANFAR=PHYLIB=n
make zImage
make config, GIANFAR=PHYLIB=m
make modules

And the cause of the failure will not be something that obviously  
points to a build problem, such as unresolved symbols.


what you are suggesting will not break with my patch.

The second case will for PHYLIB=y w/the select.

I'd rather just unconditionally select PHYLIB on platforms that  
need to do fixups.


But you don't need fix ups for the phy if you don't have the enet  
driver that the phy is connected to in your system.


(But I do understand the desire to be generous, but I think we can  
get this right).



Nonono.  You can't make that code depend on GIANFAR.  Remember, the  
8568 has eTSECs *and* UCCs.  I'm in favor of selecting the PHYLIB  
unconditionally.  But if you really hate that, then at least select it  
based on *either* of those drivers being enabled.



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Andy Fleming


On Jun 3, 2008, at 12:00, Adrian Bunk wrote:


On Tue, Jun 03, 2008 at 09:47:19AM -0500, Kumar Gala wrote:

How is this as a fix.

- k

diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/ 
platforms/85xx/Kconfig

index 7ff29d5..9e5c884 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -34,6 +34,7 @@ config MPC85xx_MDS
bool Freescale MPC85xx MDS
select DEFAULT_UIMAGE
select QUICC_ENGINE
+   select PHYLIB if GIANFAR=m
help
  This option enables support for the MPC85xx MDS board


The .config you sent me as an example didn't have GIANFAR set, so it
couldn't help there.

How early do the fixups have to run?

I see two possible solutions:
- let MPC85xx_MDS unconditionally select PHYLIB or
- move the fixups to the gianfar driver


Just to reiterate the point:  The fixups are not only not gianfar- 
specific, they may not involve gianfar at all.  The 8568 has *two*  
types of built-in ethernet controllers, which use 4 PHYs (of one  
type).  The fixups are purely PHY-specific for this board.


Andy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RFC] Make board force selection of PHYLIB

2008-06-03 Thread Kumar Gala


On Jun 3, 2008, at 12:00 PM, Adrian Bunk wrote:


On Tue, Jun 03, 2008 at 09:47:19AM -0500, Kumar Gala wrote:

How is this as a fix.

- k

diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/ 
platforms/85xx/Kconfig

index 7ff29d5..9e5c884 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -34,6 +34,7 @@ config MPC85xx_MDS
bool Freescale MPC85xx MDS
select DEFAULT_UIMAGE
select QUICC_ENGINE
+   select PHYLIB if GIANFAR=m
help
  This option enables support for the MPC85xx MDS board


The .config you sent me as an example didn't have GIANFAR set, so it
couldn't help there.

How early do the fixups have to run?

I see two possible solutions:
- let MPC85xx_MDS unconditionally select PHYLIB or
- move the fixups to the gianfar driver


I'm ok w/unconditionally selecting PHYLIB for MPC85xx_MDS as that  
seems to be the best solution at this point.


I'll workup a patch and send it via the powerpc.git tree.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev