Add a workaround for the ESI M4U that claims to support 32-byte packets
but ignores the remaining bytes of packets bigger than four bytes.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
The firmware of the M-Audio USB Uno MIDI Interface has, at least in
hardware revision 1.25, a bug that garbles its USB output. When it
receives a Note On MIDI message that uses running status, the resulting
USB MIDI packet has a wrong CIN (4 instead of 9) and a wrong length
(2 bytes, the status byte is still missing).
This patch adds a workaround to track the CINs and the MIDI messages of
received USB MIDI packets to detect whether a packet with CIN 4 is a
correct SysEx packet or a buggy running status packet.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
The purpose of this patch is to split off the case when a device does
not reply on the lower level (which is reported by HC hardware), and
a case when the device accepted the request, but does not reply at
upper level. This redefinition allows to diagnose issues easier,
without asking the user if the -110 happened "immediately".
The usbmon splits such cases already thanks to its timestamp, but
it's not always available.
I adjusted all drivers which I found affected (by searching for "urb").
Out of tree drivers may suffer a little bit, but I do not expect much
breakage. At worst they may print a few messages.
Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Removed the CS_AUDIO_* #defines, which were duplicates of the
class-specific USB_DT_CS_* #defines in <linux/usb_ch9.h>.
Signed-off-by: Ben Williamson <ben.williamson@greyinnovation.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a get_port_info callback to the snd_rawmidi_global_ops structure to
allow the USB MIDI driver to supply information flags for the sequencer
ports created by seq_midi.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Modules: USB generic driver
Reduce the code size of the snd_usbmidi_count_bits() function by using
simpler operations.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Modules: USB generic driver
Rename QUIRK_MIDI_MIDITECH to QUIRK_MIDI_CME because Miditech keyboards
are built by CME and use the same protocol, and don't force a Miditech
product name for the USB ID used by both Miditech and CME UF-x
keyboards.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Modules: USB generic driver
This is my naive attempt at adding ALSA device support. The attached
patch provides support for the EDIROL UM-3ex. This is a 3-port USB midi
interface with a built-in USB hub and the ability to chain 2 other
UM-3x's in a master-slave configuration. I only have one, so I do not
know how this works in practice.
Though this is a 3-port device, I had to throw in that 4th 'Control' interface
to the definition in order to make the 3rd port work. If I set in/out_cables
to 0x000b, a 3rd interface appears on the driver, but it does nothing.
Changing it to 0x000f allows the 3rd interface to work, but of course
interface 4 does not work because it does not exist.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Modules: USB generic driver
Move the usb_complete_callback() compatibility wrapper out of the
kernel tree.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Modules: USB generic driver
Move the usb_pipe_needs_resubmit() compatibility wrapper out of the
kernel tree.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Modules: USB generic driver
Simplify the handling of MIDI quirks by treating an interface without
quirks as a QUIRK_MIDI_STANDARD_INTERFACE.
This also fixes the bug where a MIDI_STANDARD quirk would not be
recognized.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
USB generic driver
When a USB error occurs that might indicate that the device has been
unplugged, don't resubmit the URB immediately to prevent flooding the
log with error messages before khubd has us disconnect()ed.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
USB generic driver
Emagic devices pad their packets not with 0xff bytes but with a 0xff
byte followed by garbage, so we have to stop at the first such byte.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
USB generic driver
Use the USB buffer allocation functions to avoid repeated DMA mappings
of our buffers, which are re-used quite a lot.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
USB generic driver
Add support for Miditech Midistart and MidiStudio keyboards (another
case of devices using the standard protocol but having no descriptors).
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
USB generic driver
Rename the protocol used by the MOTU FastLane to 'raw' because it might
be useful with other devices, and there are other MOTU interfaces that
do not use this protocol.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
USB generic driver
Cache the decoded values of idVendor/idProduct to get rid of most of
those ugly le16_to_cpu() calls.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
USB generic driver,USB USX2Y
This patch removes the superfluous driver parameter from the
disconnect functions.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
USB generic driver
This patch reintroduces the check for endpoint numbers that are
specified explicitly in the quirk structure.
This check was accidentally dropped in the last rewrite of
snd_usbmidi_detect_endpoints().
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Clemens Ladisch