March 2021 - Alsa-devel - mailman.alsa-project.org

[PATCH v3 1/2] ALSA: hda/realtek: fix a determine_headset_type issue for a Dell AIO
by Hui Wang 22 Mar '21

22 Mar '21

We found a recording issue on a Dell AIO, users plug a headset-mic and select headset-mic from UI, but can't record any sound from headset-mic. The root cause is the determine_headset_type() returns a wrong type, e.g. users plug a ctia type headset, but that function returns omtp type. On this machine, the internal mic is not connected to the codec, the "Input Source" is headset mic by default. And when users plug a headset, the determine_headset_type() will be called immediately, the codec on this AIO is alc274, the delay time for this codec in the determine_headset_type() is only 80ms, the delay is too short to correctly determine the headset type, the fail rate is nearly 99% when users plug the headset with the normal speed. Other codecs set several hundred ms delay time, so here I change the delay time to 850ms for alc2x4 series, after this change, the fail rate is zero unless users plug the headset slowly on purpose. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 8239e5efc12d..442e555de44c 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5263,7 +5263,7 @@ static void alc_determine_headset_type(struct hda_codec *codec) case 0x10ec0274: case 0x10ec0294: alc_process_coef_fw(codec, coef0274); - msleep(80); + msleep(850); val = alc_read_coef_idx(codec, 0x46); is_ctia = (val & 0x00f0) == 0x00f0; break; -- 2.25.1

2 3

[PATCH v2] soundwire: cadence_master: fix kernel-doc
by Pierre-Louis Bossart 22 Mar '21

22 Mar '21

v5.12-rc1 flags new warnings with make W=1, fix missing or broken function descriptors. drivers/soundwire/cadence_master.c:914: warning: expecting prototype for To update slave status in a work since we will need to handle(). Prototype was for cdns_update_slave_status_work() instead drivers/soundwire/cadence_master.c:976: warning: expecting prototype for sdw_cdns_enable_slave_interrupt(). Prototype was for cdns_enable_slave_interrupts() instead Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- drivers/soundwire/cadence_master.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/soundwire/cadence_master.c b/drivers/soundwire/cadence_master.c index d05442e646a3..e5c3f304b8f6 100644 --- a/drivers/soundwire/cadence_master.c +++ b/drivers/soundwire/cadence_master.c @@ -905,7 +905,7 @@ irqreturn_t sdw_cdns_irq(int irq, void *dev_id) EXPORT_SYMBOL(sdw_cdns_irq); /** - * To update slave status in a work since we will need to handle + * cdns_update_slave_status_work - update slave status in a work since we will need to handle * other interrupts eg. CDNS_MCP_INT_RX_WL during the update slave * process. * @work: cdns worker thread @@ -968,7 +968,7 @@ int sdw_cdns_exit_reset(struct sdw_cdns *cdns) EXPORT_SYMBOL(sdw_cdns_exit_reset); /** - * sdw_cdns_enable_slave_interrupt() - Enable SDW slave interrupts + * cdns_enable_slave_interrupts() - Enable SDW slave interrupts * @cdns: Cadence instance * @state: boolean for true/false */ -- 2.25.1

2 1

[PATCH v5 2/2] ASoC: rt715:add micmute led state control supports
by Perry Yuan 22 Mar '21

22 Mar '21

From: Perry Yuan <perry_yuan(a)dell.com> Some new Dell system is going to support audio internal micphone privacy setting from hardware level with micmute led state changing When micmute hotkey pressed by user, soft mute will need to be enabled firstly in case of pop noise, and codec driver need to react to mic mute event to EC(embedded controller) notifying that SW mute is completed Then EC will do the hardware mute physically within the timeout reached This patch allow codec rt715 and rt715 sdca driver to change the local micmute led state. Dell privacy led trigger driver will ack EC when micmute key pressed through this micphone led control interface like hda_generic provided ACPI method defined in dell-privacy micmute led trigger will be called for notifying the EC that software mute has been completed, then hardware audio circuit solution controlled by EC will switch the audio input source off/on Signed-off-by: Perry Yuan <perry_yuan(a)dell.com> -------- v4 -> v5: * rebase to latest 5.12 rc4 upstream kernel v3 -> v4: * remove unused debug log * remove compile flag of DELL privacy * move the micmute_led to local from rt715_priv * when Jaroslav upstream his gerneric LED trigger driver,I will rebase this patch,please consider merge this at first https://lore.kernel.org/alsa-devel/20210211111400.1131020-1-perex@perex.cz/ v2 -> v3: * simplify the patch to reuse some val value * add more detail to the commit info v1 -> v2: * fix some format issue -------- --- sound/soc/codecs/rt715-sdca.c | 11 +++++++++++ sound/soc/codecs/rt715.c | 12 ++++++++++++ 2 files changed, 23 insertions(+) diff --git a/sound/soc/codecs/rt715-sdca.c b/sound/soc/codecs/rt715-sdca.c index 20528afbdc57..70e1181f1dee 100644 --- a/sound/soc/codecs/rt715-sdca.c +++ b/sound/soc/codecs/rt715-sdca.c @@ -11,6 +11,7 @@ #include <linux/moduleparam.h> #include <linux/kernel.h> #include <linux/init.h> +#include <linux/leds.h> #include <linux/pm_runtime.h> #include <linux/pm.h> #include <linux/soundwire/sdw.h> @@ -358,6 +359,7 @@ static int rt715_sdca_put_volsw(struct snd_kcontrol *kcontrol, unsigned int mask = (1 << fls(max)) - 1; unsigned int invert = p->invert; int err; + bool micmute_led; for (i = 0; i < 4; i++) { if (ucontrol->value.integer.value[i] != rt715->kctl_switch_orig[i]) { @@ -393,6 +395,15 @@ static int rt715_sdca_put_volsw(struct snd_kcontrol *kcontrol, if (err < 0) return err; } + /* Micmute LED state changed by muted/unmute switch */ + if (invert) { + if (ucontrol->value.integer.value[0] || ucontrol->value.integer.value[1]) { + micmute_led = LED_OFF; + } else { + micmute_led = LED_ON; + } + ledtrig_audio_set(LED_AUDIO_MICMUTE, micmute_led); + } return k_changed; } diff --git a/sound/soc/codecs/rt715.c b/sound/soc/codecs/rt715.c index 34c3357e943b..13686c5239b3 100644 --- a/sound/soc/codecs/rt715.c +++ b/sound/soc/codecs/rt715.c @@ -13,6 +13,7 @@ #include <linux/init.h> #include <linux/delay.h> #include <linux/i2c.h> +#include <linux/leds.h> #include <linux/pm_runtime.h> #include <linux/pm.h> #include <linux/soundwire/sdw.h> @@ -88,6 +89,7 @@ static int rt715_set_amp_gain_put(struct snd_kcontrol *kcontrol, RT715_SET_GAIN_MIX_ADC2_L}; unsigned int addr_h, addr_l, val_h, val_ll, val_lr; unsigned int read_ll, read_rl, i, j, loop_cnt; + bool micmute_led; if (strstr(ucontrol->id.name, "Main Capture Switch") || strstr(ucontrol->id.name, "Main Capture Volume")) @@ -95,6 +97,16 @@ static int rt715_set_amp_gain_put(struct snd_kcontrol *kcontrol, else loop_cnt = 1; + /* Micmute LED state changed by muted/unmute switch */ + if (mc->invert) { + if (ucontrol->value.integer.value[0] || ucontrol->value.integer.value[1]) { + micmute_led = LED_OFF; + } else { + micmute_led = LED_ON; + } + ledtrig_audio_set(LED_AUDIO_MICMUTE, micmute_led); + } + for (j = 0; j < loop_cnt; j++) { /* Can't use update bit function, so read the original value first */ if (loop_cnt == 1) { -- 2.25.1

1 0

[PATCH v5 0/2] hardware-privacy-implementation-for-dell-laptop
by Perry Yuan 22 Mar '21

22 Mar '21

From: Perry Yuan <perry_yuan(a)dell.com> Hi All, This patch set is a new driver for Dell mobile platform that has the hardware privacy feature including micmute,camera mute. For micmute led control, the hotkey is Fn + F4, it is a hardware based mute state, and new privacy will prevent micphone void input from hardware layer, any application cannot get voice data when micmute activated. Camera mute use a new hardware design to control the camrea shutter. When video is muted, no OS application should be functionally able to capture images of the person/environment in front of the system Older history: [1]https://patchwork.kernel.org/project/platform-driver-x86/patch/2020122813… [2]https://patchwork.kernel.org/project/alsa-devel/patch/20201103125859.8759… [3]https://www.spinics.net/lists/alsa-devel/msg120537.html [4]https://github.com/thesofproject/linux/pull/2660 [5]https://github.com/thesofproject/linux/issues/2496 Perry Yuan (2): platform/x86: dell-privacy: Add support for Dell hardware privacy ASoC: rt715:add micmute led state control supports .../testing/sysfs-platform-dell-privacy-wmi | 32 ++ drivers/platform/x86/dell/Kconfig | 16 + drivers/platform/x86/dell/Makefile | 3 + drivers/platform/x86/dell/dell-laptop.c | 23 +- drivers/platform/x86/dell/dell-privacy-acpi.c | 164 +++++++++ drivers/platform/x86/dell/dell-privacy-wmi.c | 340 ++++++++++++++++++ drivers/platform/x86/dell/dell-privacy-wmi.h | 35 ++ drivers/platform/x86/dell/dell-wmi.c | 27 +- sound/soc/codecs/rt715-sdca.c | 11 + sound/soc/codecs/rt715.c | 12 + 10 files changed, 650 insertions(+), 13 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi create mode 100644 drivers/platform/x86/dell/dell-privacy-acpi.c create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.c create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.h -- 2.25.1

1 0

[PATCH] ASoC: Intel: Fix a typo
by Bhaskar Chowdhury 22 Mar '21

22 Mar '21

s/struture/structure/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar(a)gmail.com> --- sound/soc/intel/atom/sst-mfld-dsp.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/atom/sst-mfld-dsp.h b/sound/soc/intel/atom/sst-mfld-dsp.h index 5795f98e04d4..102b0e7eafb0 100644 --- a/sound/soc/intel/atom/sst-mfld-dsp.h +++ b/sound/soc/intel/atom/sst-mfld-dsp.h @@ -358,7 +358,7 @@ struct snd_wma_params { u8 reserved; /* reserved */ } __packed; -/* Codec params struture */ +/* Codec params structure */ union snd_sst_codec_params { struct snd_pcm_params pcm_params; struct snd_mp3_params mp3_params; -- 2.31.0

1 0

[alsa-lib][PATCH 0/6] add API of equality and comparison for a pair of control element IDs
by Takashi Sakamoto 22 Mar '21

22 Mar '21

Hi, This patchset is a fix for bug issued in the message thread[1]. In this development period, alsa-lib got new API as implementation for one of comparison algorithms to a pair of control element IDs. However, it has several issues. At first, the name, 'snd_ctl_elem_id_compare()', is inappropriate since it implements one of comparison algorithms. The name itself implies the algorithm is single and unique for control element ID. However, the target structure, 'struct snd_ctl_elem_id', is hybrid and compound one. We can not find such single and unique comparison algorithm for it. Secondary, it subtracts a pair of values in fields of 'unsigned int' type in storage size of the type. It brings integer overflow. Tertiary, it has simple bug to compare subdevice field in the same structure. Essentially, equality is different from comparison. In a point of programming, implementation for comparison algorithm can have more overhead than implementation for equality. In this meaning, it's better to add different API for them. This patchset adds new API below: * for equality * snd_ctl_elem_id_equal_by_numid() * snd_ctl_elem_id_equal_by_tuple() * for each comparison algorithm * snd_ctl_elem_id_compare_by_numid() * snd_ctl_elem_id_compare_by_tuple_arithmetic() I've got bothered to decide the name of API for the case to use tuples. Here I use the word, 'tuple', which comes from documentation of alsa-lib[2]. Furthermore, this patchset adds test program for them since equality and comparison are quite basic method to operate data. It's better to have no bug. Finally, the issued API, 'snd_ctl_elem_id_compare()' is dropped. After merging the patchset, I'm going to post additional patch to alsa-utils to fix issued line[3]. [1] https://mailman.alsa-project.org/pipermail/alsa-devel/2021-March/181738.html [2] https://github.com/alsa-project/alsa-lib/blob/master/src/control/control.c#… [3] https://github.com/alsa-project/alsa-utils/blob/master/alsactl/clean.c#L55 Regards Takashi Sakamoto (6): test: ctl-elem-id: add test program for future APIs relevant to control element ID ctl: add API to check equality between a pair of control element IDs by numid ctl: add API to check equality between a pair of control element IDs by tuple ctl: add API to compare a pair of control element IDs by numid ctl: add API to compare a pair of control element IDs by one of algorithms according to tuple ctl: drop deprecated API to compare a pair of control element IDs include/control.h | 5 +- src/control/control.c | 135 ++++++++++++++---- test/lsb/Makefile.am | 6 +- test/lsb/ctl-elem-id.c | 301 +++++++++++++++++++++++++++++++++++++++++ 4 files changed, 418 insertions(+), 29 deletions(-) create mode 100644 test/lsb/ctl-elem-id.c -- 2.27.0

2 13

Fwd: Pioneer DJ DDJ-SR2 sound degradation
by Geraldo 21 Mar '21

21 Mar '21

Good news: my JACK transport has been rolling for more than 2 hours without sound degradation. I'll leave it overnight just to be sure sound degradation has been fixed and not just postponed. But yes, I think I managed to engage implicit feedback sync for the playback on my Pioneer DJ DDJ-SR2. Dr. Iwai, my initial assesment was ALSA not honoring .ep_attr on quirks-table.h was the culprit for the Incompatible EP Setup messages. Turns out that for implicit feedback sync the EP is opened twice, and the ep->opened refcount prevents that. Once I commented out ep->opened++; inside snd_usb_endpoint_open on endpoint.c the kernel was able to open the EP twice(one time for data, second time for sync). I could use some help in coding an elegant way of going around the ep->opened refcount instead of simpy disabling it! Once that particular problem is sorted out I'll be able to provide a proper PATCH for all users of Pioneer gear to test implicit feedback sync. Here's the relevant dyndbg info for the success case: [35084.131891] usb 3-2: 0:1: added playback implicit_fb sync_ep 82, iface 0:1 [35084.131905] usb 3-2: Creating new data endpoint #1 [35084.131911] usb 3-2: Creating new data endpoint #82 [35084.131917] xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev 0000000052e95692 [35084.132102] usb 3-2: 0:1 Set sample rate 44100, clock 0 [35084.132116] xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev 0000000052e95692 [35084.132163] usb 3-2: 0:1 Set sample rate 44100, clock 0 [35084.132592] usbcore: registered new interface driver snd-usb-audio [35096.805245] usb 3-2: Open EP 0x82, iface=0:1, idx=1 [35096.805254] usb 3-2: channels=6, rate=44100, format=S24_3LE, period_bytes=9216, periods=2, implicit_fb=0 [35096.805259] usb 3-2: Setting usb interface 0:0 for EP 0x82 [35096.805264] xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev 0000000052e95692 [35096.805475] usb 3-2: Setting usb interface 0:1 for EP 0x82 [35096.805486] xhci_hcd 0000:00:14.0: add ep 0x1, slot id 32, new drop flags = 0x0, new add flags = 0x5 [35096.805492] xhci_hcd 0000:00:14.0: add ep 0x82, slot id 32, new drop flags = 0x0, new add flags = 0x25 [35096.805495] xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev 0000000052e95692 [35096.805499] xhci_hcd 0000:00:14.0: Adding 2 ep ctxs, 6 now active. [35096.805503] xhci_hcd 0000:00:14.0: Recalculating BW for rootport 2 [35096.805505] xhci_hcd 0000:00:14.0: Final bandwidth: 282, Limit: 1607, Reserved: 322, Available: 62 percent [35096.805510] xhci_hcd 0000:00:14.0: // Ding dong! [35096.805652] xhci_hcd 0000:00:14.0: Successful Endpoint Configure command [35096.805895] usb 3-2: 0:1 Set sample rate 44100, clock 0 [35096.805902] usb 3-2: Setting params for data EP 0x82, pipe 0x14180 [35096.805910] usb 3-2: Set up 12 URBS, ret=0 [35096.805996] usb 3-2: Open EP 0x1, iface=0:1, idx=0 [35096.806000] usb 3-2: channels=4, rate=44100, format=S24_3LE, period_bytes=6144, periods=2, implicit_fb=1 [35096.806003] usb 3-2: Open EP 0x82, iface=0:1, idx=1 [35096.806005] usb 3-2: channels=6, rate=44100, format=S24_3LE, period_bytes=9216, periods=2, implicit_fb=0 [35096.806008] usb 3-2: 0:1 Set sample rate 44100, clock 0 [35096.806011] usb 3-2: Setting params for data EP 0x1, pipe 0xc100 [35096.806018] usb 3-2: Set up 12 URBS, ret=0 [35096.806021] usb 3-2: 0:1 Set sample rate 44100, clock 0 [35096.806025] usb 3-2: Setting params for data EP 0x82, pipe 0x14180 [35096.806029] usb 3-2: Set up 12 URBS, ret=0 [35096.806048] usb 3-2: Starting data EP 0x1 (running 0) [35096.806051] usb 3-2: No URB submission due to implicit fb sync [35096.806053] usb 3-2: Starting data EP 0x82 (running 0) [35096.806076] usb 3-2: 12 URBs submitted for EP 0x82 [35096.807337] usb 3-2: Starting data EP 0x82 (running 1) [35096.807343] usb 3-2: 0:1 Start Capture PCM [35096.807346] usb 3-2: 0:1 Start Playback PCM On Sun, Mar 21, 2021 at 5:22 AM Takashi Iwai <tiwai(a)suse.de> wrote: > > On Sun, 21 Mar 2021 05:31:11 +0100, > Geraldo wrote: > > > > Until we manage to engage implicit feedback sync for Pioneer gear I'm > > afraid the clock will drift on DUPLEX mode. > > > > I reread the Pioneer related source code and implicit feedback sync was > > disabled because it gave Incompatible EP Setup messages. I should know, I > > was a reporter on that regression. > > > > Only those messages are fake. They arise because our ALSA code it's not > > honoring .ep_attr on quirks-table.h specifically in regards to > > USB_ENDPOINT_USAGE_IMPLICIT_FB. > > That's right. The parser reads from the original descriptor, not the > one from the quirk table. That is, the implicit fb quirk has to be > declared explicitly in another quirk table. And, the implicit fb is > skipped for those devices because they didn't work; see > sound/usb/implicit.c. > > > In fact the new improved implicit feedback sync code inside pcm.c that sets > > sync upon probe is failing to set implicit_fb to 1. I commented the > > conditional for testing and I told endpoint_compatible to always return > > true. > > > > Voilà, JACK started in duplex mode without nasty Incompatible EP Setup > > problems and supposedly with implicit feedback sync on. We are not setting > > bits 5..7 of bmAttributes, at least that's what I get from the missing > > Usage field in lsusb. > > > > My JACK transport has been rolling for 17 minutes and if it goes for two > > complete hours without distortion passing-thru vinyl on Mixxxx I'll provide > > the list with a more elegant PATCH and not this gambiarra as we say on > > Brazil. > > > > Hopefully their will be implicit feedback sync for Pioneer :-) > > I know there are quite a few users with Pioneer devices around here, > so let's hope that they can test the implicit feedback things and find > the culprit of the buggy behavior. Unfortunately it's quite hard to > debug such a thing remotely without the hardware from my side. > > > Takashi > > > > > > > > On Thu, Mar 18, 2021 at 7:41 PM Geraldo <geraldogabriel(a)gmail.com> wrote: > > > > > > Hi everyone, > > > > > > I'm running stable kernel 5.11.6 together with my Pioneer DJ DDJ-SR2 and > > JACK. Mixxx is running on top of JACK. > > > > > > > > > After I start JACK I have about 40 minutes of good sound quality from the > > inputs. After this period the sound will begin to degrade slowly until it > > is almost pure distortion. > > > > > > The issue is gone if I restart the JACK server, no need to reboot the > > hardware. The description I gave above sounds a lot like soundcard clock > > drift (which happens to those using more than one soundcard. You know) > > which motivates me to believe we missed a bug somewhere around the recent > > changes introduced in implicit feedback sync for Pioneer devices > > > > > > Dyndbg shows nothing useful I guess. No xruns reported. > > > > > > I've recorded a 1KHz tone and after 50+ minutes the sound degradation > > kicks in. Only problem is even after cutting and encoding to mp3 128kbps > > it's still a 10 megabytes file. I suppose I could post it to Soundcloud or > > Mixcloud if anyone is interested. > > > > > > Is anyone else experiencing these symptoms with Pioneer hardware? Note > > that the sound degradation kicks in after about an hour, more or less, and > > it's for the inputs only. Outputs continue to operate fine without the need > > to restart the JACK server every hour. > > > > > > Thanks everybody, > > > Geraldo > >

1 0

pcm: dshare - fix shared memory pointer check
by GitHub pull_request - opened 21 Mar '21

21 Mar '21

alsa-project/alsa-lib pull request #128 was opened from VanithaChannaiah: Currently shared memory pointer is initialized to 0 and set to -1 in some, but not in all error paths. In cleanup path of open the shm pointer is only compared to be non-NULL before dereferencing it which leads to SEGFAULT in case it was set to -1. This patch initializes pointer to -1 to have a unique identification for invalid pointer and also checks for pointer being not -1 on access in cleanup path. Signed-off-by: Vanitha Channaiah <vanitha.channaiah(a)in.bosch.com> Request URL : https://github.com/alsa-project/alsa-lib/pull/128 Patch URL : https://github.com/alsa-project/alsa-lib/pull/128.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Pioneer DJ DDJ-SR2 sound degradation
by Geraldo 21 Mar '21

21 Mar '21

Hi everyone, I'm running stable kernel 5.11.6 together with my Pioneer DJ DDJ-SR2 and JACK. Mixxx is running on top of JACK. After I start JACK I have about 40 minutes of good sound quality from the inputs. After this period the sound will begin to degrade slowly until it is almost pure distortion. The issue is gone if I restart the JACK server, no need to reboot the hardware. The description I gave above sounds a lot like soundcard clock drift (which happens to those using more than one soundcard. You know) which motivates me to believe we missed a bug somewhere around the recent changes introduced in implicit feedback sync for Pioneer devices Dyndbg shows nothing useful I guess. No xruns reported. I've recorded a 1KHz tone and after 50+ minutes the sound degradation kicks in. Only problem is even after cutting and encoding to mp3 128kbps it's still a 10 megabytes file. I suppose I could post it to Soundcloud or Mixcloud if anyone is interested. Is anyone else experiencing these symptoms with Pioneer hardware? Note that the sound degradation kicks in after about an hour, more or less, and it's for the inputs only. Outputs continue to operate fine without the need to restart the JACK server every hour. Thanks everybody, Geraldo

2 2

[PATCH 0/2] ALSA: hdsp and hdspm, don't disable device if not enabled
by Tong Zhang 21 Mar '21

21 Mar '21

This series fixes issues in hdsp and hdspm. The drivers in question want to disable a device that is not enabled on error path. Tong Zhang (2): ALSA: hdsp: don't disable if not enabled ALSA: hdspm: don't disable if not enabled sound/pci/rme9652/hdsp.c | 10 ++++++---- sound/pci/rme9652/hdspm.c | 10 ++++++---- 2 files changed, 12 insertions(+), 8 deletions(-) -- 2.25.1

1 2