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)
next 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).