Hi all,
This patch adds a USB MIDI Gadget driver. This driver is glue between
the USB gadget interface and the ALSA MIDI interface. It allows an
embedded Linux system to appear as a class-compliant USB-MIDI device
to a host system on the other end of a USB cable.
Much of the code is borrowed fro
> Yes, I confused a point and it is a big difference. I restated, and my
> current question w.r.t ehci-hcd still stands. The resubmission code
> is in ehci-hcd, and I pasted the code block.
It's not "resubmission". One or more URBs were queued by the driver, and
haven't even been seen by the c
On Wednesday 05 July 2006 6:14 pm, Christopher Montgomery wrote:
>
> > And as a simplification: to date there's been only one data
> > structure, which encodes both the schedule and all allocations.
> > This is a Good Thing (tm) because it's less error prone ... and
> > it's also a useful simplifi
On Wed, 5 Jul 2006 19:46:14 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 5 Jul 2006 19:42:29 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 5 Jul 2006 19:34:52 -0700
> > "Miles Lane" <[EMAIL PROTECTED]> wrote:
> >
> > > On 7/5/06, Miles Lane <[EMAIL PROTECTED]> wrote:
On Wed, 5 Jul 2006 19:42:29 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 5 Jul 2006 19:34:52 -0700
> "Miles Lane" <[EMAIL PROTECTED]> wrote:
>
> > On 7/5/06, Miles Lane <[EMAIL PROTECTED]> wrote:
> > > Hi Petko,
> > >
> > > David Brownell pointed out that you are the author of this dr
On Wed, 5 Jul 2006 19:34:52 -0700
"Miles Lane" <[EMAIL PROTECTED]> wrote:
> On 7/5/06, Miles Lane <[EMAIL PROTECTED]> wrote:
> > Hi Petko,
> >
> > David Brownell pointed out that you are the author of this driver (rtl8150).
> > My laptop is crashing every time I remove the Linksys EtherFast 10/100
Hi,
I just got a "ZyXEL Prestige USB Adapter" that is actually RTL8150
adapter. Here is the relevant /proc/bus/usb/devices output (after
adding the vendor/product IDs to the driver):
T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#=119 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS
> > I see that's exactly what's happening. It merely seems unfortunate.
>
> That sort of behavior is inevitable in hardware-parallel systems.
>
> But it's also a rather minor failure mode, and the only folk who
> seem to run into it are people tweaking host controller drivers
> and adding lots
On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 1:52 pm, Christopher Montgomery wrote:
> > On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> >
> > > I'm hampered by lack of detailed knowledge of the driver. However it
> > > seems to me that those two calls should
> > In particular, that transfer errors will start
> > long before usbcore has any clue that the root cause is that
> > the device has been disconnected. You need to be re-thinking
> > a bunch of things if you believe otherwise.
>
> I see that's exactly what's happening. It merely seems un
On Wed, 5 Jul 2006 14:40:54 -0400, "Christopher Montgomery" <[EMAIL PROTECTED]>
wrote:
> > And in any case, the only way qh_completions would reactivate
> > a halted endpoint is if its queue were non-empty after a fault
> > got reported. And that's solidly in the hands of the driver
> > which fi
Ah, yes, as a quick test I can. They keyboard works fine if it's connected
to the computer instead of the hub.
The problem is probably the hub.
Also, I tested the same keyboard with another hub, the keyboard works.
Also, I tested with the original hub, but another keyboard, and it worked
too.
The
On Wednesday 05 July 2006 11:40 am, Christopher Montgomery wrote:
> I plug in a hub. I unplug a hub. Nothing else happens in between and
> I see the resubmission loop happen until the disconnect code catches
> up and removes the hub's intr endpoint. Exactly what driver are you
> talking about?
On Wednesday 05 July 2006 1:52 pm, Christopher Montgomery wrote:
> On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > I'm hampered by lack of detailed knowledge of the driver. However it
> > seems to me that those two calls should affect the schedule (cheap) and
> > not the budget (expensive)
On Wed, 5 Jul 2006, Paulo R. Zanoni wrote:
> No, it's not 2 hubs...
>
> It's only one "physical" hub, with 7 ports. I think it simulates 2 hubs
> with 4 ports each, or maybe there are REALLY 2 hubs inside the little
> box... But they sell saying that it's 1 hub with 7 ports.
>
> And I can't plug
On Wed, 5 Jul 2006, Paulo R. Zanoni wrote:
> But, isn't there a way to "turn around" it?
> If manually unplugging/plugging solves the problem? Isn't there a way to
> simulate unplugging/plugging using software? (the program someone sent me
> didn't work).
It depends on the type of hub you use. W
No, it's not 2 hubs...
It's only one "physical" hub, with 7 ports. I think it simulates 2 hubs
with 4 ports each, or maybe there are REALLY 2 hubs inside the little
box... But they sell saying that it's 1 hub with 7 ports.
And I can't plug it directly to the computer... I have 4 keyboards and 4
m
But, isn't there a way to "turn around" it?
If manually unplugging/plugging solves the problem? Isn't there a way to
simulate unplugging/plugging using software? (the program someone sent me
didn't work).
Thanks a lot!!
> On Wednesday 05 July 2006 7:25 am, Paulo R. Zanoni wrote:
>
>>
>> With the
On Wed, 5 Jul 2006, Foli Ayivoh wrote:
> Alan Stern wrote:
> >
> > The dump shows that the drive just stopped responding at one spot and then
> > was reset. Sometimes devices do that; nobody seems to know why.
> >
> > The real test is to use CONFIG_USB_STORAGE_DEBUG when you boot off the USB
On Wed, 5 Jul 2006, Paulo R. Zanoni wrote:
> We've tried using this "ac power control", but it didn't work.
> We turned off the port, then we turned it on, but the bug still happened.
> Turning the port on/off has not the same effect as unplugging/plugging
> manually.
Like I said, many brands of
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> I'm hampered by lack of detailed knowledge of the driver. However it
> seems to me that those two calls should affect the schedule (cheap) and
> not the budget (expensive).
Oh, hmm. That's actually not a bad idea. Some part of me is saying 'du
The attached patch includes the following changes:
* More generi-fication of function/macro names where appropriate:
ax88772_xx() -> asix_xx()
* Reorder functions to provide more logical grouping
* AX88178 device support
* Hopefully resolve all endian-ness issues
* Use more defines for bit
The attached patch allows Ethernet devices based on the usbnet driver to
unlink all RX URBs to facilitate an MTU change. This capability is used
by the AX88178 support in the asix.c driver to allow for Jumbo Frame
support.
Based on a patch supplied by James Painter <[EMAIL PROTECTED]>.
usbnet.c
On Wed, 5 Jul 2006, Christopher Montgomery wrote:
> / the two lines below
> */
>
> intr_deschedule (ehci, qh);
> (void) periodic_qh_schedule (ehci, qh);
>
>
>
On Wed, 5 Jul 2006, DervishD wrote:
> I've finally managed to test the issue with a 2.6.17 kernel with
> usbmon enabled. The log is attached, together with an example of the
> file /var/log/messages when the device is attached. I haven't been
> able to decode the raw text log because I don't f
On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 8:42 am, Christopher Montgomery wrote:
>
> > The hub is plugged in doing nothing.
>
> Except being regularly polled "did anything happen" about 4x/second.
> It's certainly active. (Though there's some new autosuspend
On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> To repeat myself: the instant the physical disconnect happens,
> then pending transfers to that device's endpoints may trigger
> USB transfer errors. And that can happen a LONG time before any
> component of the USB stack (e.g. qh_completion
On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 8:30 am, Christopher Montgomery wrote:
>
> > / the two lines below
> > */
> >
> > intr_deschedule (ehci, qh);
> >
On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 7:16 am, Christopher Montgomery wrote:
> Odd ... "interwoven" certainly allows gaps, and all of your
> additional details agree completely with the facts as I had
> pointed out.
I think we both actually agree on all
On Wednesday 05 July 2006 8:42 am, Christopher Montgomery wrote:
> The hub is plugged in doing nothing.
Except being regularly polled "did anything happen" about 4x/second.
It's certainly active. (Though there's some new autosuspend stuff
in the works that could de-activate it and use remote wa
On Wednesday 05 July 2006 7:25 am, Paulo R. Zanoni wrote:
>
> With the computer powered off I connect the keyboard on the USB HUB and
> then I connect the usb hub to the computer. When, I turn on the computer,
> I get a lot of error messages, and the keyboard doesn't work.
>
> The messages I get
On Wednesday 05 July 2006 8:30 am, Christopher Montgomery wrote:
> / the two lines below
> */
>
> intr_deschedule (ehci, qh);
> (void) periodic_qh_schedule (ehci, qh);
> ...
>
> I
On Wednesday 05 July 2006 7:56 am, Christopher Montgomery wrote:
> The resubmission is in ehci-q.c:qh_completions(); it is not checking
> to see if the device is disconnected (is this possible?) before
> deciding the endpoint EPROTO fault calls for tearing it down and
> setting it back up.
To re
On Wednesday 05 July 2006 7:16 am, Christopher Montgomery wrote:
> On 7/2/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Sunday 02 July 2006 6:29 am, Christopher Montgomery wrote:
> >
> > > Disconnecting a hub/device causes two things to happen at the same time:
> > >
> > > 1) usb_disconnect
Greg KH <[EMAIL PROTECTED]> wrote on 06/29/2006 08:43:08 PM:
> > >>Is sysfs the right way to do such a thing or are there better
> > >>alternatives?
> > >
> > >It all depends on what you want to do. If you can express things with
> > >a single text value per file, sysfs is a good way to do this.
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> ehci-hcd doesn't schedule endpoints; it schedules QHs.
Effectively the same thing. An INTR endpoint maps to one and only one
QH in the schedule.
As for ISO endpoints, it schedules the stream. Each ISO endpoint has
one and exactly one stream.
S
On 7/5/06, Christopher Montgomery <[EMAIL PROTECTED]> wrote:
> / the two lines below
> */
>
> intr_deschedule (ehci, qh);
> (void) periodic_qh_schedule (ehci, qh);
Oops, 'period
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> > ) before
> > deciding the endpoint EPROTO fault calls for tearing it down and
> > setting it back up. Active/submitted URBs potentially have nothing to
> > do with it; it is happening even when my devices are idle.
>
> I'm not terribly familiar
One more thing. I added this device to the omninet driver.
lsusb -v shows the device as:
Bus 004 Device 003: ID 0586:1500 ZyXEL Communications Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 1.00
bDeviceClass0 (Defined at Int
On Wed, 5 Jul 2006, Christopher Montgomery wrote:
> On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > Ummm... I've lost track of the original question. What is suboptimal and
> > would be painful to fix?
>
> The fact that when I unplug a hub/device the ehci work handler is
> descheduling/r
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> The only catch is that you have to make sure usbcore isn't in use, because
> the kernel won't let you unload modules that are being used. For usbcore,
> this means you first have to unload all the other USB driver modules and
> you have to unmoun
On Wed, 5 Jul 2006, Christopher Montgomery wrote:
> The resubmission is in ehci-q.c:qh_completions(); it is not checking
> to see if the device is disconnected (is this possible?
No.
> ) before
> deciding the endpoint EPROTO fault calls for tearing it down and
> setting it back up. Active/submit
On Wed, 5 Jul 2006, Christopher Montgomery wrote:
> > Ah, okay. That's different from what I thought you meant -- the "Nobody
> > cared" message when the kernel disables an entire IRQ.
>
> Sorry; the last aside question I asked confused things because it was
> about the 'Nobody cared' message.
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> Actually it is. Look in drivers/usb/core/hub.c at the
> usb_set_device_state() routine.
will do.
> Potentially tight doesn't have to mean tight. Higher-level drivers should
> strive to avoid immediate resubmissions of URBs that fail because of
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> Ummm... I've lost track of the original question. What is suboptimal and
> would be painful to fix?
The fact that when I unplug a hub/device the ehci work handler is
descheduling/rescheduling the endpoints repeatedly [because each hit
in the har
Hi Oliver,
You were write, adding
< { USB_DEVICE(0x0586,0x1500), /* ZYZEL OMNI 56K Plus */
< .driver_info = NO_UNION_NORMAL, /* has no union descriptor */
< },
to cdc-acm.c leads to a kernel oops as soon as I plug in the USB cable.
I've pasted the traceback below. I'm going
On Wed, 5 Jul 2006, Paulo R. Zanoni wrote:
> Hi.
>
> Please help me.
>
> My problem is this:
> I have a keyboard (that uses usb 2.0) and a USB HUB.
>
> With the computer powered off I connect the keyboard on the USB HUB and
> then I connect the usb hub to the computer. When, I turn on the compu
On Wed, 5 Jul 2006, Christopher Montgomery wrote:
> > If you look more closely at what's really happening, you should find that
> > it all makes sense. You can't get -EPROTO status in URBs for devices that
> > the kernel knows are disconnected, because the core won't even accept
> > these URBs wh
On Wed, 5 Jul 2006, Christopher Montgomery wrote:
> On 7/2/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Sunday 02 July 2006 6:29 am, Christopher Montgomery wrote:
> >
> > > Disconnecting a hub/device causes two things to happen at the same time:
> > >
> > > 1) usb_disconnect is called on t
On 7/3/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> > The part I forgot to mention is that usb-hub.c implements a magic
> > number of ten consecutive interrupt errors on a given hcd before it
> > starts aggressively resetting/downing hardware.
>
> Ah, okay. That's different from what I thought you
Hi.
Please help me.
My problem is this:
I have a keyboard (that uses usb 2.0) and a USB HUB.
With the computer powered off I connect the keyboard on the USB HUB and
then I connect the usb hub to the computer. When, I turn on the computer,
I get a lot of error messages, and the keyboard doesn't w
On 7/2/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Sunday 02 July 2006 6:29 am, Christopher Montgomery wrote:
>
> > Disconnecting a hub/device causes two things to happen at the same time:
> >
> > 1) usb_disconnect is called on the root device.
> > 2) each active transfer descriptor throws a
Luiz Fernando N. Capitulino wrote:
> | take mutex
> | take port lock
> | again:
> | save local copy of icount
> | release port lock
> | get_mctrl
> | take port lock
> | if (icount changed)
> | goto again
> | update tty->hw_stopped
> | release port lock
> | release mutex
>
>
> I am wondering if someone have successfully utilized existing kernel
> anydata.c driver... The serial converter looks detected/attached just
> fine, but could neither read nor write to the respective ttyUSB
> devices.
What you describe is what happened to me when I just plugged the modem
in
Heya,
I apologize for the time its been since we have jabbed, just wanted to
mention with you the place that made me better after my syndrome, it was at
http://bbpy.iyoungerhealth.org/hb/. Give them a glance.
film to dampen even if himself the up I irrational exuberance He had
recalled of a bee
Hi Alan :)
* Alan Stern <[EMAIL PROTECTED]> dixit:
> > I'm having a problem with an usb-storage device (namely a Inovix
> > IMP65 MP3 player): when I plug it and I try to mount it, the sd_mod
> > driver sees it write protected, so I cannot mount it read-write.
> >
> > If I remount it
56 matches
Mail list logo
