@@ -607,12 +607,8 @@ static int parse_group_terminal_block(struct snd_usb_midi2_ump *rmidi,
return 0;
}
- if (ump->info.protocol && ump->info.protocol != protocol)
- usb_audio_info(rmidi->umidi->chip,
- "Overriding preferred MIDI protocol in GTB %d: %x -> %x\n",
- rmidi->usb_block_id, ump->info.protocol,
- protocol);
- ump->info.protocol = protocol;
+ if (!ump->info.protocol)
+ ump->info.protocol = protocol;
protocol_caps = protocol;
switch (desc->bMIDIProtocol) {
@@ -624,13 +620,7 @@ static int parse_group_terminal_block(struct snd_usb_midi2_ump *rmidi,
break;
}
- if (ump->info.protocol_caps && ump->info.protocol_caps != protocol_caps)
- usb_audio_info(rmidi->umidi->chip,
- "Overriding MIDI protocol caps in GTB %d: %x -> %x\n",
- rmidi->usb_block_id, ump->info.protocol_caps,
- protocol_caps);
- ump->info.protocol_caps = protocol_caps;
-
+ ump->info.protocol_caps |= protocol_caps;
return 0;
}
It's valid to give different protocols via multiple GTBs; e.g. a MIDI 1.0 port is embedded in a MIDI 2.0 device that talks with MIDI 2.0 protocol. However, the current driver implementation assumes only a single protocol over the whole Endpoint, and it can't handle such a scenario. This patch changes the driver's behavior to parse GTBs to accept multiple protocols. Instead of switching to the last given protocol, it adds the protocol capability bits now. Meanwhile, the default protocol is chosen by the first given protocol in GTBs. Practically seen, this should be a minor issue, as new devices should specify the protocols properly via UMP Endpoint Info messages, so this is rather just covering a corner case. Signed-off-by: Takashi Iwai <tiwai@suse.de> --- sound/usb/midi2.c | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-)