There is nothing in the USB code that should be MIPS specific. Despite
what Tom suspects everything is fine. 32-bit kernel symbols always start
with 0xffffffff and the value of usbdevfs_cleanup is an artefact of the
function having been discarded by the linker.
Additional info:
USB has been working on MIPS for well over a year now. There was a problem
early on due to non-coherent MIPS cache, but it was solved back then.
We have been using USB on global span IVR successfully. Maybe there are
still some patches missing in linux-mips tree. I will take a look later.
Jun
There is nothing in the USB code that should be MIPS specific. Despite
what Tom suspects everything is fine. 32-bit kernel symbols always start
with 0xffffffff and the value of usbdevfs_cleanup is an artefact of the
function having been discarded by the linker.
Additional info:
USB has been working on MIPS for well over a year now. There was a problem
early on due to non-coherent MIPS cache, but it was solved back then.
We have been using USB on global span IVR successfully.
... among many other mips boards.
Maybe there are still some patches missing in linux-mips tree. I will
take a look later.
There is nothing in the USB code that should be MIPS specific. Despite
what Tom suspects everything is fine. 32-bit kernel symbols always start
with 0xffffffff and the value of usbdevfs_cleanup is an artefact of the
function having been discarded by the linker.
Additional info:
USB has been working on MIPS for well over a year now. There was a problem
early on due to non-coherent MIPS cache, but it was solved back then.
We have been using USB on global span IVR successfully.
... among many other mips boards.
quoted
Maybe there are still some patches missing in linux-mips tree. I will
take a look later.
I don't have a problem with current CVS tree(linux_2_4 tag) and a small patch.
I tested by the following system.
Hot plug is fine.
NEC VR4122(Eagle)
USB OCHI Controller
SanDisk SDDR-31
128MB CF
I attached a small patch.
Yoichi
dear jun,
do you have the patch to fix "non-coherent MIPS cache"?
thanks in advanced!:)
and thanks you all who reply to this so quickly:)
btw, i don't mean usb not function with linux mips kernel
i mean using the "hotplug"-usb
support(http://linux-hotplug.sourceforge.net/?selected=usb) with linux mips
kernel
for example, after we plug in usb cable with a mips board,
the mips kernel try to execute "/sbin/hotplug" shell script,
then kernel wait_for_complete() for "/sbin/hotplug" with spin_lock_irq(),
the do_execve() of "/sbin/hotplug" return 0(successfully),
however, wait_for_complete() never return,
then kernel is reseted by hardware watchdog(timeout 3 secs)
we already trace this problem over a month,
but still can't figure out is it a userland
problem(cross-compiler/shell(bash))
or a problem with linux mips kernel
best regards,
----- Original Message -----
From: "Jun Sun" <redacted>
To: "Ralf Baechle" <redacted>
Cc: "??" <redacted>; <redacted>; <redacted>
Sent: Wednesday, November 20, 2002 1:54 AM
Subject: Re: usb hotplug function with linux mips kernel
On Tue, Nov 19, 2002 at 01:29:22PM +0100, Ralf Baechle wrote:
quoted
Hello double questionmark ;-)
On Tue, Nov 19, 2002 at 08:09:07PM +0800, ?? wrote:
quoted
anyone successfully using usb hotplug function with linux mips kernel?
There is nothing in the USB code that should be MIPS specific. Despite
what Tom suspects everything is fine. 32-bit kernel symbols always
start
quoted
with 0xffffffff and the value of usbdevfs_cleanup is an artefact of the
function having been discarded by the linker.
Additional info:
USB has been working on MIPS for well over a year now. There was a
problem
early on due to non-coherent MIPS cache, but it was solved back then.
We have been using USB on global span IVR successfully. Maybe there are
still some patches missing in linux-mips tree. I will take a look later.
Jun
dear Yoichi,
thanks for your reply & patch
we are using kernel 2.4.18, after reading your patch,
we found there is no following section:
- if (usb_hub_port_debounce(hub, port)) {
- err("connect-debounce failed, port %d disabled", port+1);
- usb_hub_port_disable(hub, port);
- return;
- }
but a following section: (mentioned redhat bug #23670)
/* Some low speed devices have problems with the quick delay, so */
/* be a bit pessimistic with those devices. RHbug #23670 */
if (portstatus & USB_PORT_STAT_LOW_SPEED) {
wait_ms(400);
delay = HUB_LONG_RESET_TIME;
}
can we safely remove the above section?
best regards,
----- Original Message -----
From: "Yoichi Yuasa" <redacted>
To: <redacted>
Cc: <redacted>; <redacted>; <redacted>;
[off-list ref]
Sent: Wednesday, November 20, 2002 10:49 AM
Subject: Re: usb hotplug function with linux mips kernel
Hi,
On 19 Nov 2002 10:03:47 -0800
Pete Popov [off-list ref] wrote:
quoted
On Tue, 2002-11-19 at 09:54, Jun Sun wrote:
quoted
On Tue, Nov 19, 2002 at 01:29:22PM +0100, Ralf Baechle wrote:
quoted
Hello double questionmark ;-)
On Tue, Nov 19, 2002 at 08:09:07PM +0800, ?? wrote:
quoted
anyone successfully using usb hotplug function with linux mips