All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: linux-next@vger.kernel.org, Felipe Balbi <felipe.balbi@nokia.com>,
	Greg Kroah-Hartman <gregkh@suse.de>
Cc: linux-omap@vger.kernel.org
Subject: musb bogosity
Date: Fri, 8 Aug 2008 17:27:22 +0900	[thread overview]
Message-ID: <20080808082722.GA6580@linux-sh.org> (raw)

The musb code currently kills the SH randconfig build (and this will hose
any platform that also selects HAVE_CLK -- a PPC or AVR32 randconfig
would have also hit this eventually), as can be seen here:

http://kisskb.ellerman.id.au/kisskb/buildresult/41095/

This initial failure comes from the fact that musb handily uses "special"
I/O routines that it handily wraps, after having failed at grepping for
other users. Why this driver isn't using ioread/writeXX_rep() is beyond
me, as that's the portable interface we have for doing precisely this
sort of thing, without this bizarre PIO/MMIO wrapper munging that isn't
even going to work on most platforms.

With that ifdef in place, it's on to the next integral build failure:

drivers/usb/musb/musb_core.c: In function 'fifo_setup':
drivers/usb/musb/musb_core.c:1122: error: 'MUSB_C_RAM_BITS' undeclared (first use in this function)
drivers/usb/musb/musb_core.c:1122: error: (Each undeclared identifier is reported only once
drivers/usb/musb/musb_core.c:1122: error: for each function it appears in.)
drivers/usb/musb/musb_core.c: In function 'ep_config_from_table':
drivers/usb/musb/musb_core.c:1246: error: 'MUSB_C_RAM_BITS' undeclared (first use in this function)
drivers/usb/musb/musb_core.c: In function 'musb_remove':
drivers/usb/musb/musb_core.c:2131: warning: unused variable 'ctrl_base'
make[1]: *** [drivers/usb/musb/musb_core.o] Error 1
make: *** [drivers/usb/musb/musb_core.o] Error 2

...

$ git grep MUSB_C_RAM_BITS drivers/usb/musb
drivers/usb/musb/musb_core.c:#define DYN_FIFO_SIZE (1<<(MUSB_C_RAM_BITS+2))
drivers/usb/musb/tusb6010.h:#define MUSB_C_RAM_BITS 12

...

the comment above MUSB_C_RAM_BITS seems to suggest that it's entirely dependent
on the chip, so moving it in to musb_core.c wouldn't be terribly productive. Which
leaves us in a situation where the core is dependent on arbitrary driver
definitions, while the driver itself is obviously only dependent on the core.
Has anyone actually tested this with TUSB6010 support disabled?

A quick grep suggests that blackfin is also going to get bitten by this, so
simply tossing a depends on (ARM && BROKEN) in wouldn't help matters either.

---

diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
index 6bbedae..d0f812a 100644
--- a/drivers/usb/musb/musb_io.h
+++ b/drivers/usb/musb/musb_io.h
@@ -37,7 +37,7 @@
 
 #include <linux/io.h>
 
-#ifndef	CONFIG_ARM
+#if !defined(CONFIG_ARM) && !defined(CONFIG_SUPERH)
 static inline void readsl(const void __iomem *addr, void *buf, int len)
 	{ insl((unsigned long)addr, buf, len); }
 static inline void readsw(const void __iomem *addr, void *buf, int len)



             reply	other threads:[~2008-08-08  8:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-08  8:27 Paul Mundt [this message]
2008-08-08  8:32 ` musb bogosity Felipe Balbi
2008-08-08  8:51   ` Paul Mundt
2008-08-08  9:04   ` Felipe Balbi
2008-08-08  9:21     ` Paul Mundt
2008-08-08  9:37       ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080808082722.GA6580@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=felipe.balbi@nokia.com \
    --cc=gregkh@suse.de \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.