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>

When parsing Group Terminal Blocks, we overwrote the preferred
protocol and the protocol capabilities silently from the last parsed
GTB.  This patch adds the information print indicating the unexpected
overrides instead of silent action.

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


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

Attach the legacy rawmidi devices when enabled in Kconfig accordingly.

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


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

This patch extends the UMP core code to support the legacy MIDI 1.0
rawmidi devices.  When the new kconfig CONFIG_SND_UMP_LEGACY_RAWMIDI
is set, the UMP core allows to attach an additional rawmidi device for
each UMP Endpoint.  The rawmidi device contains 16 substreams where
each substream corresponds to a UMP Group belonging to the EP.  The
device reads/writes the legacy MIDI 1.0 byte streams and translates
from/to UMP packets.

The legacy rawmidi devices are exclusive with the UMP rawmidi devices,
hence both of them can't be opened at the same time unless the UMP
rawmidi is opened in APPEND mode.

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


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

This is a code refactoring for abstracting the rawmidi access to the
UMP's own helpers.  It's a preliminary work for the later code
refactoring of the UMP layer.

Until now, we access to the rawmidi substream directly from the
driver via rawmidi access helpers, but after this change, the driver
is supposed to access via the newly introduced snd_ump_ops and
receive/transmit via snd_ump_receive() and snd_ump_transmit() helpers.
As of this commit, those are merely wrappers for the rawmidi
substream, and no much function change is seen here.

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


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

USB MIDI spec defines the Group Terminal Blocks (GTB) that associate
multiple UMP Groups.  Those correspond to snd_ump_block entities in
ALSA UMP abstraction, and now we create those UMP Block objects for
each UMP Endpoint from the parsed GTB information.

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


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

A single USB audio device may have multiple interfaces for different
purposes (e.g. audio, MIDI and HID), where the iInterface descriptor
of each interface may contain an own suffix, e.g. "MIDI" for a MIDI
interface.  as such a suffix is superfluous as a rawmidi and UMP
Endpoint name, this patch trims the superfluous "MIDI" suffix from the
name string.

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


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

USB descriptor may provide a nicer name for USB interface, and we may
take it as the UMP Endpoint name.  The UMP EP name is copied as the
rawmidi name, too.

Also, fill the UMP block product_id field from the iSerialNumber
string of the USB device descriptor as a recommended unique id, too.

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


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

This patch provides a basic support for USB MIDI 2.0.  As of this
patch, the driver creates a UMP device per MIDI I/O endpoints, which
serves as a dumb terminal to read/write UMP streams.

A new Kconfig CONFIG_SND_USB_AUDIO_MIDI_V2 manages whether to enable
or disable the MIDI 2.0 support.  Also, the driver provides a new
module option, midi2_enable, to allow disabling the MIDI 2.0 at
runtime, too.  When MIDI 2.0 support is disabled, the driver tries to
fall back to the already existing MIDI 1.0 device (each MIDI 2.0
device is supposed to provide the MIDI 1.0 interface at the altset
0).

For now, the driver doesn't manage any MIDI-CI or other protocol
setups by itself, but relies on the default protocol given via the
group terminal block descriptors.

The MIDI 1.0 messages on MIDI 2.0 device will be automatically
converted in ALSA sequencer in a later patch.  As of this commit, the
driver accepts merely the rawmidi UMP accesses.

The driver builds up the topology in the following way:
- Create an object for each MIDI endpoint belonging to the USB
  interface
- Find MIDI EP "pairs" that share the same GTB;
  note that MIDI EP is unidirectional, while UMP is (normally)
  bidirectional, so two MIDI EPs can form a single UMP EP
- A UMP endpoint object is created for each I/O pair
- For remaining "solo" MIDI EPs, create unidirectional UMP EPs
- Finally, parse GTBs and fill the protocol bits on each UMP

So the driver may support multiple UMP Endpoints in theory, although
most devices are supposed to have a single UMP EP that can contain up
to 16 groups -- which should be large enough.

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


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

Define new structs and constants from USB MIDI 2.0 specification,
to be used in the upcoming MIDI 2.0 support in USB-audio driver.

A new class-specific endpoint descriptor and group terminal block
descriptors are defined.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-9-tiwai@suse.de


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

We're going to create rawmidi objects for MIDI 2.0 in a different code
from the current code for USB-MIDI 1.0.  As a preliminary work, this
patch adds the number of rawmidi objects to keep globally in a
USB-audio card instance, so that it can be referred from both MIDI 1.0
and 2.0 code.

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


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

UMP devices may have more interesting information than the traditional
rawmidi.  Extend the rawmidi_global_ops to allow the optional proc
info output and show some more bits in the proc file for UMP.

Note that the "Groups" field shows the first and the last UMP Groups,
and both numbers are 1-based (i.e. the first group is 1).

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


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

It'd be convenient to have ioctls to inquiry the UMP Endpoint and UMP
Block information directly via the control API without opening the
rawmidi interface, just like SNDRV_CTL_IOCTL_RAWMIDI_INFO.

This patch extends the rawmidi ioctl handler to support those; new
ioctls, SNDRV_CTL_IOCTL_UMP_ENDPOINT_INFO and
SNDRV_CTL_IOCTL_UMP_BLOCK_INFO, return the snd_ump_endpoint and
snd_ump_block data that is specified by the device field,
respectively.

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


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

Applications may look for rawmidi devices with the ioctl
SNDRV_CTL_IOCTL_RAWMIDI_NEXT_DEVICE.  Returning a UMP device from this
ioctl may confuse the existing applications that support only the
legacy rawmidi.

This patch changes the code to skip the UMP devices from the lookup
for avoiding the confusion, and introduces a new ioctl to look for the
UMP devices instead.

Along with this change, bump the CTL protocol version to 2.0.9.

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


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

This patch adds the support helpers for UMP (Universal MIDI Packet) in
ALSA core.

The basic design is that a rawmidi instance is assigned to each UMP
Endpoint.  A UMP Endpoint provides a UMP stream, typically
bidirectional (but can be also uni-directional, too), which may hold
up to 16 UMP Groups, where each UMP (input/output) Group corresponds
to the traditional MIDI I/O Endpoint.

Additionally, the ALSA UMP abstraction provides the multiple UMP
Blocks that can be assigned to each UMP Endpoint.  A UMP Block is a
metadata to hold the UMP Group clusters, and can represent the
functions assigned to each UMP Group.  A typical implementation of UMP
Block is the Group Terminal Blocks of USB MIDI 2.0 specification.

For distinguishing from the legacy byte-stream MIDI device, a new
device "umpC*D*" will be created, instead of the standard (MIDI 1.0)
devices "midiC*D*".  The UMP instance can be identified by the new
rawmidi info bit SNDRV_RAWMIDI_INFO_UMP, too.

A UMP rawmidi device reads/writes only in 4-bytes words alignment,
stored in CPU native endianness.

The transmit and receive functions take care of the input/out data
alignment, and may return zero or aligned size, and the params ioctl
may return -EINVAL when the given input/output buffer size isn't
aligned.

A few new UMP-specific ioctls are added for obtaining the new UMP
endpoint and block information.

As of this commit, no ALSA sequencer instance is attached to UMP
devices yet.  They will be supported by later patches.

Along with those changes, the protocol version for rawmidi is bumped
to 2.0.3.

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


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

A new callback, ioctl, is added to snd_rawmidi_global_ops for allowing
the driver to deal with the own ioctls.  This is another preparation
patch for the upcoming UMP support.

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


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

snd_rawmidi_kernel_open() is used only internally from ALSA sequencer,
so far, and parsing the card / device matching table at each open is
redundant, as each sequencer client already gets the rawmidi object
beforehand.

This patch optimizes the path by passing the rawmidi object directly
at snd_rawmidi_kernel_open().  This is also a preparation for the
upcoming UMP rawmidi I/O support.

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


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

Pull compute express link fixes from Dan Williams:

 - Fix a compilation issue with DEFINE_STATIC_SRCU() in the unit tests

 - Fix leaking kernel memory to a root-only sysfs attribute

* tag 'cxl-fixes-6.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl:
  cxl: Add missing return to cdat read error path
  tools/testing/cxl: Use DEFINE_STATIC_SRCU()

Pull parisc architecture fixes from Helge Deller:

 - Fix encoding of swp_entry due to added SWP_EXCLUSIVE flag

 - Include reboot.h to avoid gcc-12 compiler warning

* tag 'parisc-for-6.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Fix encoding of swp_entry due to added SWP_EXCLUSIVE flag
  parisc: kexec: include reboot.h

Pull ARM fixes from Russell King:

 - fix unwinder for uleb128 case

 - fix kernel-doc warnings for HP Jornada 7xx

 - fix unbalanced stack on vfp success path

* tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 9297/1: vfp: avoid unbalanced stack on 'success' return path
  ARM: 9296/1: HP Jornada 7XX: fix kernel-doc warnings
  ARM: 9295/1: unwind:fix unwind abort for uleb128 case

Pull locking fix from Borislav Petkov:

 - Make sure __down_read_common() is always inlined so that the callers'
   names land in traceevents output and thus the blocked function can be
   identified

* tag 'locking_urgent_for_v6.4_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  locking/rwsem: Add __always_inline annotation to __down_read_common() and inlined callers

Pull perf fixes from Borislav Petkov:

 - Make sure the PEBS buffer is flushed before reprogramming the
   hardware so that the correct record sizes are used

 - Update the sample size for AMD BRS events

 - Fix a confusion with using the same on-stack struct with different
   events in the event processing path

* tag 'perf_urgent_for_v6.4_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/intel/ds: Flush PEBS DS when changing PEBS_DATA_CFG
  perf/x86: Fix missing sample size update on AMD BRS
  perf/core: Fix perf_sample_data not properly initialized for different swevents in perf_tp_event()

Pull scheduler fix from Borislav Petkov:

 - Fix a couple of kernel-doc warnings

* tag 'sched_urgent_for_v6.4_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: fix cid_lock kernel-doc warnings

Pull x86 fix from Borislav Petkov:

 - Add the required PCI IDs so that the generic SMN accesses provided by
   amd_nb.c work for drivers which switch to them. Add a PCI device ID
   to k10temp's table so that latter is loaded on such systems too

* tag 'x86_urgent_for_v6.4_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  hwmon: (k10temp) Add PCI ID for family 19, model 78h
  x86/amd_nb: Add PCI ID for family 19h model 78h

Pull timer fix from Borislav Petkov:

 - Prevent CPU state corruption when an active clockevent broadcast
   device is replaced while the system is already in oneshot mode

* tag 'timers_urgent_for_v6.4_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  tick/broadcast: Make broadcast device replacement work correctly