On Tue, 2008-06-03 at 15:49 -0500, Nathan Lynch wrote:

Hannes Hering wrote:

quoted

On Wednesday 28 May 2008 18:44:05 Nathan Lynch wrote:

quoted

Hannes Hering wrote:

quoted

The new ehea memory hot plug implementation depends on MEMORY_HOTPLUG.

Signed-off-by: Hannes Hering <redacted>
---

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f90a86b..181cd86 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig

@@ -2440,7 +2440,7 @@ config CHELSIO_T3
 
 config EHEA
 	tristate "eHEA Ethernet support"
-	depends on IBMEBUS && INET && SPARSEMEM
+	depends on IBMEBUS && INET && SPARSEMEM && MEMORY_HOTPLUG
 	select INET_LRO
 	---help---
 	  This driver supports the IBM pSeries eHEA ethernet adapter.

I disagree with this change.

It makes it impossible to build the ehea driver without memory hotplug
enabled.  Presumably, this commit was intended to work around a build
break of this sort (with EHEA=m and MEMORY_HOTPLUG=n):

drivers/net/ehea/ehea_qmr.c: In function 'ehea_create_busmap':
drivers/net/ehea/ehea_qmr.c:635: error: implicit declaration of function 'walk_memory_resource'

(some indication of this should have been in the commit message, btw)

I think this was the wrong way to fix the issue.  EHEA=m and
MEMORY_HOTPLUG=n is a valid configuration for machines I test.

Any thoughts on the following, which makes walk_memory_resource()
available regardless of MEMORY_HOTPLUG's setting?  I've tested it on a
JS22 (Power6 blade).

I agree that the ehea cannot be built without MEMORY_HOTPLUG. The
problem is the fact that the ppc walk_memory_resource declaration is
in the scope of MEMORY_HOTPLUG. At the moment I don't have complete
overview if the move of the code as you propose in your patch has
any side effects. We probably need to talk to Badari who provided
the walk_memory_resource code. We can also just throw it onto one of
our boxes to see what happens. ;)

I would certainly appreciate any additional testing.

I think we can make walk_memory_resource() for ppc64 available
outside of MEMORY_HOTPLUG. It doesn't require any MEMORY_HOTPLUG
functionality to work correctly. Its a generic enough interface.
Only reason I placed it under MEMORY_HOTPLUG is to have parity
with the arch-independent version + we needed for eHEA driver whic
needs MEMORY_HOTPLUG.

You wrote the ehea code that uses walk_memory_resource, so I was
hoping you could speak to whether ehea needs that interface when
CONFIG_MEMORY_HOTPLUG=n.  Or maybe there should be a no-op version of
walk_memory_resource for that case?  And what about the
arch-independent version in kernel/resource.c?  Badari?

I would leave the arch-independent version alone - since its not
exported and there are no users for it.

It would be nice to get this resolved for 2.6.26 -- this new
dependency causes working 2.6.25 configs to effectively fail (by
deselecting CONFIG_EHEA during make oldconfig).

Thanks,
Badari