Re: [PATCH] SSB: make it depend on PCI

Previous thread: [PATCH v6] Add Dallas DS1390/93/94 RTC chips by Mark Jackson on Thursday, November 6, 2008 - 2:09 am. (3 messages)

Next thread: 2.6.28-rc2-mm1: multiple BUG: scheduling while atomic: swapper, first in acpi_idle_enter_simple, then fbcon has problems by Pavel Machek on Thursday, November 6, 2008 - 3:23 am. (4 messages)
From: Mike Frysinger
Date: Thursday, November 6, 2008 - 2:51 am

Since the SSB code requires PCI, set the Kconfig dependencies accordingly.
Also tweak the menu display so that the menu does not show up at all if
SSB is not possible.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 drivers/ssb/Kconfig |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index 307b1f6..f0a176a 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -1,10 +1,11 @@
-menu "Sonics Silicon Backplane"
-
 config SSB_POSSIBLE
 	bool
-	depends on HAS_IOMEM && HAS_DMA
+	depends on HAS_IOMEM && HAS_DMA && PCI
 	default y
 
+menu "Sonics Silicon Backplane"
+	depends on SSB_POSSIBLE
+
 config SSB
 	tristate "Sonics Silicon Backplane support"
 	depends on SSB_POSSIBLE
-- 
1.6.0.3

--

From: Johannes Berg
Date: Thursday, November 6, 2008 - 4:07 am

This is incorrect. SSB is also used on embedded systems that do not use
PCI at all.

johannes
From: Mike Frysinger
Date: Thursday, November 6, 2008 - 4:15 am

while that may be the intent, it doesnt work today.

drivers/ssb/main.c always includes linux/ssb/ssb.h

linux/ssb/ssb.h always calls pci_dma_* functions

arches that do not support PCI fail to build:
  CC      drivers/ssb/main.o
In file included from drivers/ssb/ssb_private.h:5,
                 from drivers/ssb/main.c:12:
include/linux/ssb/ssb.h: In function 'ssb_dma_mapping_error':
include/linux/ssb/ssb.h:430: error: implicit declaration of function
'pci_dma_mapping_error'
include/linux/ssb/ssb.h: In function 'ssb_dma_sync_single_for_cpu':
include/linux/ssb/ssb.h:475: error: implicit declaration of function
'pci_dma_sync_single_for_cpu'
include/linux/ssb/ssb.h: In function 'ssb_dma_sync_single_for_device':
include/linux/ssb/ssb.h:493: error: implicit declaration of function
'pci_dma_sync_single_for_device'
include/linux/ssb/ssb.h: In function 'ssb_dma_sync_single_range_for_cpu':
include/linux/ssb/ssb.h:517: error: implicit declaration of function
'dma_sync_single_range_for_cpu'
include/linux/ssb/ssb.h: In function 'ssb_dma_sync_single_range_for_device':
include/linux/ssb/ssb.h:538: error: implicit declaration of function
'dma_sync_single_range_for_device'
drivers/ssb/main.c: In function 'ssb_dma_set_mask':
drivers/ssb/main.c:1183: error: implicit declaration of function 'dma_set_mask'
make[1]: *** [drivers/ssb/main.o] Error 1
make: *** [drivers/ssb/main.o] Error 2
-mike
--

From: Johannes Berg
Date: Thursday, November 6, 2008 - 4:22 am

_mask'


That seems odd, shouldn't at least the dma_sync_* functions and
dma_set_mask be supported?

There probably need to be ifdefs, if you look at those functions then
you'll see that it depends on the bustype the device is on.

johannes
From: Mike Frysinger
Date: Thursday, November 6, 2008 - 4:26 am

i'm highlighting the pci-specific functions.  the common dma functions
missing are not a ssb problem, so ignore those ;).
-mike
--

From: Johannes Berg
Date: Thursday, November 6, 2008 - 4:29 am

Alright, but even then you'll fail build if you enable SSB ;) I guess we
need ifdefs or mandate that non-PCI architectures have dummy stubs (like
other architectures have in the !CONFIG_PCI case), but Michael's the SSB
expert.

johannes
From: Mike Frysinger
Date: Thursday, November 6, 2008 - 4:32 am

OK.  regarding the patch, if we drop the "&& PCI" part, i think the
rest should get merged ... having empty menus in kconfig is annoying.
agreed ?  i can send out another one ...
-mike
--

From: Johannes Berg
Date: Thursday, November 6, 2008 - 4:35 am

Yeah that part looks fine to me.

johannes
From: Michael Buesch
Date: Thursday, November 6, 2008 - 9:59 am

We have these all over the place.
SSB_POSSIBLE is false for virtually nobody (only for some weird architectures).
The the menu will be there in almost any case.

-- 
Greetings Michael.
--

From: Mike Frysinger
Date: Thursday, November 6, 2008 - 2:14 pm

that's a weak argument.  empty menus should go away, not remain
"because other people are doing it too".  with that mentality, there's
many issues we wouldnt be able to address.
-mike
--

From: Michael Buesch
Date: Thursday, November 6, 2008 - 2:24 pm

Well, I don't see this as an issue, as 99.9% of the people don't hit that
case and if they do it doesn't matter anyway.
But hey, if you want to apply this, feel free to do so.

-- 
Greetings Michael.
--

From: Michael Buesch
Date: Thursday, November 6, 2008 - 9:56 am

No it doesn't. Read the code.
pci_dma_xxx functions should probably declared to no-op inlines in
the pci.h header.
However, we can also ifdef them in ssb.h.

-- 
Greetings Michael.
--

From: Geert Uytterhoeven
Date: Sunday, November 9, 2008 - 3:51 am

I had the same issue on m68k, not only with SSB but also with other legacy
drivers (hp100 Ethernet, AIC7xxx SCSI). It was fixed in commit
998aaf01c6f6f3dffc1ea9e7b20b131e38fdbc78 ("m68k: <asm/pci.h> needs
<asm-generic/pci-dma-compat.h>").

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
--

From: Michael Buesch
Date: Sunday, November 9, 2008 - 4:49 am

Ok, nice.
I'd suggest we additionally fix the architectures this way.

My patch already is on its way upstream and I think that's OK.
The codepaths that it #ifdefs out are dead code on non-PCI, so I think
it's OK to #ifdef them.

-- 
Greetings Michael.
--

From: Michael Buesch
Date: Thursday, November 6, 2008 - 9:55 am

Ehm, no. it doesn't.

-- 
Greetings Michael.
--

Previous thread: [PATCH v6] Add Dallas DS1390/93/94 RTC chips by Mark Jackson on Thursday, November 6, 2008 - 2:09 am. (3 messages)

Next thread: 2.6.28-rc2-mm1: multiple BUG: scheduling while atomic: swapper, first in acpi_idle_enter_simple, then fbcon has problems by Pavel Machek on Thursday, November 6, 2008 - 3:23 am. (4 messages)