Yet more preliminary work for the upcoming USB gadget support.

Now export the helpers to convert between legacy MIDI1 and UMP data
for handling the MIDI 1.0 USB interface.  The header file is moved to
include/sound.

The API functions are slightly changed, so that they can be used
without the direct access to snd_ump object.  The allocation is done
in ump.c itself as it's a simple kcalloc().

Link: https://lore.kernel.org/r/20230623075530.10976-1-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

This is another preliminary patch for USB MIDI 2.0 gadget driver.
Export the currently local snd_ump_receive_ump_val().  It can be used
by the gadget driver for processing the UMP data.

Link: https://lore.kernel.org/r/20230621110241.4751-4-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

This is another preliminary patch for USB MIDI 2.0 gadget driver.
Add a new flag, no_process_stream, to snd_ump for suppressing the UMP
Stream message handling in UMP core.

Link: https://lore.kernel.org/r/20230621110241.4751-3-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

This is a preliminary patch for MIDI 2.0 USB gadget driver.
Export a new helper to allow changing the current MIDI protocol from
the outside.

Link: https://lore.kernel.org/r/20230621110241.4751-2-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

There have been a few enhancements for the new UMP 1.1 features.
Update the documentation accordingly.

Link: https://lore.kernel.org/r/20230612081054.17200-11-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

UMP v1.1 spec allows to inform whether the function blocks are static
and not dynamically updated.  Add a new flag bit to
snd_ump_endpoint_info to reflect that attribute, too.

The flag is set when a USB MIDI device is still in the old MIDI 2.0
without UMP 1.1 support.  Then the driver falls back to GTBs, and they
are supposed to be static-only.

Link: https://lore.kernel.org/r/20230612081054.17200-10-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

UMP v1.1 supports the protocol switch via a UMP Stream message.  When
it's received, we need to take care of the midi_version field in the
corresponding sequencer client, too.

This patch introduces a new ops to notify the protocol change to
snd_seq_ump_ops for handling it.

Link: https://lore.kernel.org/r/20230612081054.17200-9-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

For allowing applications to track the FB active changes, this patch
adds the notification from the system port at each time a FB change is
handled and the active flag or re-grouping happens.

Link: https://lore.kernel.org/r/20230612081054.17200-8-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch implements the handling of the dynamic update of FB info.

When the FB info update is received after the initial parsing, it
means the dynamic FB info update.  We compare the result, and if the
actual update is detected, it's notified via a new ops,
notify_fb_change, to the sequencer client, and the corresponding
sequencer ports are updated accordingly.

Link: https://lore.kernel.org/r/20230612081054.17200-7-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

The UMP Utility and Stream messages are "groupless", i.e. an incoming
groupless packet should be sent only to the UMP EP port, and the event
with the groupless message is sent to UMP EP as is without the group
translation per port.

Also, the former reserved bit 0 for the client group filter is now
used for groupless events.  When the bit 0 is set, the groupless
events are filtered out and skipped.

Link: https://lore.kernel.org/r/20230612081054.17200-6-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add a new option to enable/disable the UMP Endpoint probing.
Some firmware seems screwed up when such a new command issued, and
this option allows user to suppress it.

Link: https://lore.kernel.org/r/20230612081054.17200-5-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Try to parse the UMP Endpoint and UMP Function Blocks for building the
topology at first.  Only when those are missing (e.g. on an older USB
MIDI 2.0 spec or a unidirectional endpoint), the driver still creates
blocks based on USB group terminal block information as fallback.

Link: https://lore.kernel.org/r/20230612081054.17200-4-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch adds the basic support for UMP Endpoint and UMP Function
Block parsing, which are extended in the new UMP v1.1 spec.
The patch provides a new helper function to perform the query of the
UMP Endpoint information and builds up the UMP blocks based on UMP
Function Block information.  For the communication over the UMP
Endpoint, it opens the rawmidi device once internally, inquiries the
UMP Endpoint and Function Block info by sending new UMP Stream
messages, and waits for the response for each query.

The new UMP spec allows to update the FB info and change its
associated groups or its activeness on the fly, too.  For catching it,
the UMP core keeps watching the incoming UMP messages, and
snd_ump_receive() handles the incoming UMP Stream messages to refresh
the FB info.

Link: https://lore.kernel.org/r/20230612081054.17200-3-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add a few more fields to snd_ump_endpoint_info and snd_ump_block_info
that are added in the new v1.1 spec.  Those are filled by the UMP Stream
messages.

The rawmidi protocol version is bumped to 2.0.4 to indicate those
updates.

Also, update the proc outputs to show the newly introduced fields.

Link: https://lore.kernel.org/r/20230612081054.17200-2-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Currently the read event packet size in snd_seq_read() is defined by
client->midi_version value that is guaranteed to be zero if UMP isn't
enabled.  But the static analyzer doesn't know of the fact, and it
still suspects as if it were leading to a potential overflow.

Add the more explicit check of CONFIG_SND_SEQ_UMP to determine the
aligned_size value for avoiding the confusion.

Fixes: 46397622 ("ALSA: seq: Add UMP support")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/r/202305261415.NY0vapZK-lkp@intel.com/
Link: https://lore.kernel.org/r/20230605144758.6677-2-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Use proper notion for 16bit values for fixing the sparse warnings.

Fixes: f8ddb0fb ("ALSA: usb-audio: Define USB MIDI 2.0 specs")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202305260528.wcqjXso8-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202305270534.odwHL9F0-lkp@intel.com/
Link: https://lore.kernel.org/r/20230605144758.6677-1-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

The MIDI 1.0 parser retrieved the 0xFx command with a wrong bit shift,
resulting in the bogus type.  Fix the bit shift size.

Fixes: 0b5288f5 ("ALSA: ump: Add legacy raw MIDI support")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/0fbc0b27-54b8-4cda-800e-37e7a03fed39@kili.mountain


Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/20230525083124.15277-2-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

The check of a note-on event with zero velocity is done twice, and the
latter one is superfluous.  Let's drop it.

Fixes: 0b5288f5 ("ALSA: ump: Add legacy raw MIDI support")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/4683198a-84f6-4238-9e87-c70667d84523@kili.mountain


Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/20230525083124.15277-1-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

The #endif is placed obviously at a wrong position, which caused a
build error on the big endian machine.

Fixes: 0b5288f5 ("ALSA: ump: Add legacy raw MIDI support")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20230524135448.3ecad334@canb.auug.org.au


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add the brief document for describing the MIDI 2.0 implementation on
Linux kernel.  Both rawmidi and sequencer API extensions are
described.

Acked-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-38-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add a new filter bitmap for UMP groups for reducing the unnecessary
read/write when the client is connected to UMP EP seq port.

The new group_filter field contains the bitmap for the groups, i.e.
when the bit is set, the corresponding group is filtered out and
the messages to that group won't be delivered.

The filter bitmap consists of each bit of 1-based UMP Group number.
The bit 0 is reserved for the future use.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-37-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch enhances the /proc/asound/seq/clients output to show a few
more information about the assigned UMP Endpoint and Blocks.

The "Groups" are shown in 1-based group number to align with the
sequencer client name and port number.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-36-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add new ioctls for sequencer clients to query and set the UMP endpoint
and block information.

As a sequencer client corresponds to a UMP Endpoint, one UMP Endpoint
information can be assigned at most to a single sequencer client while
multiple UMP block infos can be assigned by passing the type with the
offset of block id (i.e. type = block_id + 1).

For the kernel client, only SNDRV_SEQ_IOCTL_GET_CLIENT_UMP_INFO is
allowed.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-35-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Create a sequencer port for broadcasting the all group inputs at the
port number 0.  This corresponds to a UMP Endpoint connection;
application can read all UMP events from this port no matter which
group the UMP packet belongs to.

Unlike seq ports for other UMP groups, a UMP Endpoint port has no
SND_SEQ_PORT_TYPE_MIDI_GENERIC bit, so that it won't be treated as a
normal MIDI 1.0 device from legacy applications.

The port is named as "MIDI 2.0" to align with representations on other
operation systems.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-34-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch introduces a new ALSA sequencer client for the kernel UMP
object, snd-seq-ump-client.  It's a UMP version of snd-seq-midi
driver, while this driver creates a sequencer client per UMP endpoint
which contains (fixed) 16 ports.

The UMP rawmidi device is opened in APPEND mode for output, so that
multiple sequencer clients can share the same UMP endpoint, as well as
the legacy UMP rawmidi devices that are opened in APPEND mode, too.
For input, on the other hand, the incoming data is processed on the
fly in the dedicated hook, hence it doesn't open a rawmidi device.

The UMP packet group is updated upon delivery depending on the target
sequencer port (which corresponds to the actual UMP group).

Each sequencer port sets a new port type bit,
SNDRV_SEQ_PORT_TYPE_MIDI_UMP, in addition to the other standard
types for MIDI.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-33-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

A sequencer client like seq_dummy rather doesn't want to convert UMP
events but receives / sends as is.  Add a new event filter flag to
suppress the automatic UMP conversion and applies accordingly.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-32-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch enables the automatic conversion of UMP events from/to the
legacy ALSA sequencer MIDI events.  Also, as UMP itself has two
different modes (MIDI 1.0 and MIDI 2.0), yet another converters
between them are needed, too.  Namely, we have conversions between the
legacy and UMP like:
  - seq legacy event -> seq UMP MIDI 1.0 event
  - seq legacy event -> seq UMP MIDI 2.0 event
  - seq UMP MIDI 1.0 event -> seq legacy event
  - seq UMP MIDI 2.0 event -> seq legacy event

and the conversions between UMP MIDI 1.0 and 2.0 clients like:
  - seq UMP MIDI 1.0 event -> seq UMP MIDI 2.0 event
  - seq UMP MIDI 2.0 event -> seq UMP MIDI 1.0 event

The translation is per best-effort; some MIDI 2.0 specific events are
ignored when translated to MIDI 1.0.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-31-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add yet more new filed "ump_group" to snd_seq_port_info for specifying
the associated UMP Group number for each sequencer port.  This will be
referred in the upcoming automatic UMP conversion in sequencer core.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-30-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add a new field "direction" to snd_seq_port_info for allowing a client
to tell the expected direction of the port access.  A port might still
allow subscriptions for read/write (e.g. for MIDI-CI) even if the
primary usage of the port is a single direction (either input or
output only).  This new "direction" field can help to indicate such
cases.

When the direction is unspecified at creating a port and the port has
either read or write capability, the corresponding direction bits are
set automatically as default.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-29-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

This is an extension to ALSA sequencer infrastructure to support the
MIDI 2.0 UMP Endpoint port.  It's a "catch-all" port that is supposed
to be present for each UMP Endpoint.  When this port is read via
subscription, it sends any events from all ports (UMP Groups) found in
the same client.

A UMP Endpoint port can be created with the new capability bit
SNDRV_SEQ_PORT_CAP_UMP_ENDPOINT.  Although the port assignment isn't
strictly defined, it should be the port number 0.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-28-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

This extends the ALSA sequencer port capability bit to indicate the
"inactive" flag.  When this flag is set, the port is essentially
invisible, and doesn't appear in the port query ioctls, while the
direct access and the connection to this port are still allowed.  The
active/inactive state can be flipped dynamically, so that it can be
visible at any time later.

This feature is introduced basically for UMP; some UMP Groups in a UMP
Block may be unassigned, hence those are practically invisible.  On
ALSA sequencer, the corresponding sequencer ports will get this new
"inactive" flag to indicate the invisible state.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-27-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Starting from this commit, we add the basic support of UMP (Universal
MIDI Packet) events on ALSA sequencer infrastructure.  The biggest
change here is that, for transferring UMP packets that are up to 128
bits, we extend the data payload of ALSA sequencer event record when
the client is declared to support for the new UMP events.

A new event flag bit, SNDRV_SEQ_EVENT_UMP, is defined and it shall be
set for the UMP packet events that have the larger payload of 128
bits, defined as struct snd_seq_ump_event.

For controlling the UMP feature enablement in kernel, a new Kconfig,
CONFIG_SND_SEQ_UMP is introduced.  The extended event for UMP is
available only when this Kconfig item is set.  Similarly, the size of
the internal snd_seq_event_cell also increases (in 4 bytes) when the
Kconfig item is set.  (But the size increase is effective only for
32bit architectures; 64bit archs already have padding there.)
Overall, when CONFIG_SND_SEQ_UMP isn't set, there is no change in the
event and cell, keeping the old sizes.

For applications that want to access the UMP packets, first of all, a
sequencer client has to declare the user-protocol to match with the
latest one via the new SNDRV_SEQ_IOCTL_USER_PVERSION; otherwise it's
treated as if a legacy client without UMP support.

Then the client can switch to the new UMP mode (MIDI 1.0 or MIDI 2.0)
with a new field, midi_version, in snd_seq_client_info.  When switched
to UMP mode (midi_version = 1 or 2), the client can write the UMP
events with SNDRV_SEQ_EVENT_UMP flag.  For reads, the alignment size
is changed from snd_seq_event (28 bytes) to snd_seq_ump_event (32
bytes).  When a UMP sequencer event is delivered to a legacy sequencer
client, it's ignored or handled as an error.

Conceptually, ALSA sequencer client and port correspond to the UMP
Endpoint and Group, respectively; each client may have multiple ports
and each port has the fixed number (16) of channels, total up to 256
channels.

As of this commit, ALSA sequencer core just sends and receives the UMP
events as-is from/to clients.  The automatic conversions between the
legacy events and the new UMP events will be implemented in a later
patch.

Along with this commit, bump the sequencer protocol version to 1.0.3.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-26-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

For the future extension of ALSA sequencer ABI, introduce a new ioctl
SNDRV_SEQ_IOCTL_USER_PVERSION.  This is similar like the ioctls used
in PCM and other interfaces, for an application to specify its
supporting ABI version.

The use of this ioctl will be mandatory for the upcoming UMP support.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-25-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Some port numbers are special, such as 254 for subscribers and 255 for
broadcast.  Return error if application tries to create such a port.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-24-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

The client type and the port info validity check should be done before
actually creating a port, instead of unnecessary create-and-scratch.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-23-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

We didn't check if a port with the given port number has been already
present at creating a new port.  Check it and return -EBUSY properly
if the port number conflicts.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-22-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

The broadcast and multicast supports have been never enabled.
Let's drop the dead code.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-21-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Introduce the new helpers, snd_seq_kernel_client_get() and _put() for
kernel client drivers to treat the snd_seq_client more directly.
This allows us to reduce the exported symbols and APIs at each time we
need to access some field in future.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-20-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Create a new variant of snd_seq_expand_var_event() for expanding the
data starting from the given byte offset.  It'll be used by the new
UMP sequencer code later.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-19-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>

There can be a small memory hole that may not be cleared at expanding
an event with the variable length type.  Make sure to clear it.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-18-tiwai@suse.de


Signed-off-by: Takashi Iwai <tiwai@suse.de>