[PATCH AUTOSEL 6.19-5.15] ALSA: usb-audio: Check max frame size for implicit feedback mode, too

[PATCH AUTOSEL 6.19-5.15] ALSA: usb-audio: Check max frame size for implicit feedback mode, too

[Sasha Levin]

From: Takashi Iwai <tiwai@suse.de>

[ Upstream commit 7cb2a5422f5bbdf1cf32eae0eda41000485b9346 ]

When the packet sizes are taken from the capture stream in the
implicit feedback mode, the sizes might be larger than the upper
boundary defined by the descriptor.  As already done for other
transfer modes, we have to cap the sizes accordingly at sending,
otherwise this would lead to an error in USB core at submission of
URBs.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260225085233.316306-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Let me write the analysis.

## Analysis

### What the commit fixes

This is a one-line fix that caps the packet size returned from the
implicit feedback path to `ep->maxframesize`. When USB audio uses
implicit feedback mode, packet sizes are derived from the **actual
captured URB lengths** from a companion capture endpoint, rather than
being pre-calculated. These actual lengths can exceed the maximum frame
size defined by the USB descriptor/bus constraints.

Without this cap, oversized packets get submitted to the USB core, which
rejects them with errors, causing audio failures or crashes.

### Bug mechanism

In `snd_usb_endpoint_next_packet_size()`, when `ctx->packet_size[idx]`
is non-zero (implicit feedback path), the raw value from the capture
stream was returned without any bounds check against `maxframesize`. The
other two code paths already have this protection:
- `slave_next_packet_size()` caps via `min(phase >> 16,
  ep->maxframesize)` at line 174
- `next_packet_size()` uses pre-calculated `packsize[]` values, which
  are now capped by the companion commit `7fe8dec3f628`

This was a gap in the implicit feedback path specifically.

### Real-world impact

The linked bugzilla (221076) documents a real user hitting this with a
DIYINHK USB Audio 2.0 device at high sample rates (352.8kHz/384kHz with
6 channels at 32-bit). The device firmware reports an incorrect max
packet size that USB core corrects downward, but the ALSA driver's
implicit feedback path didn't respect this corrected limit.

### Stable criteria assessment

1. **Obviously correct**: Adding `min(packet, ep->maxframesize)` mirrors
   exactly what the other code paths already do. It's a one-line, self-
   evident fix.
2. **Fixes a real bug**: URB submission errors with real hardware
   (bugzilla 221076).
3. **Small and contained**: Single line addition in one file.
4. **No new features**: Pure bug fix.
5. **Low risk**: The cap was already applied in all other paths; this
   just closes a gap for the implicit feedback path.

### Dependency check

This commit depends on the companion commit `7fe8dec3f628` ("ALSA: usb-
audio: Cap the packet size pre-calculations") which fixes the same class
of bug for the pre-calculated path. Both should be backported together
as they address the same bugzilla issue, but this commit is
**independently valuable** — the implicit feedback path fix stands on
its own since `maxframesize` has been available since long before.

The `Fixes:` tag on the companion commit points to `f0bd62b64016`
("ALSA: usb-audio: Improve frames size computation") from 2020, meaning
the underlying code is present in all active stable trees.

### Verification

- Read `sound/usb/endpoint.c` lines 157-233: confirmed
  `slave_next_packet_size()` caps at line 174 with `min(phase >> 16,
  ep->maxframesize)`, `next_packet_size()` uses `ep->packsize[]` (now
  capped by companion commit), but the `ctx->packet_size[idx]` path at
  line 222-226 had no cap before this fix.
- Confirmed `maxframesize` is set in `snd_usb_endpoint_set_params()` at
  line ~1400 from `maxpacksize / cur_frame_bytes`.
- Confirmed companion commit `7fe8dec3f628` exists and caps
  `packsize[0]` and `packsize[1]` — it has an explicit `Fixes:` tag
  pointing to `f0bd62b64016` (2020), confirming the buggy code exists in
  stable trees.
- Confirmed the bugzilla link 221076 is referenced in the commit
  message, documenting a real user-reported issue.
- The implicit feedback packet sizes come from actual URB lengths (set
  in `retire_inbound_urb` path), which can exceed descriptor limits —
  verified by reading the packet_size assignment code.

This is a textbook stable backport candidate: a one-line fix for a real
user-reported bug, closing a gap where bounds checking was missing for
one specific code path while already present in all others.

**YES**

 sound/usb/endpoint.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
index 1eaf52d1ae9c7..46eff040a1511 100644
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -221,6 +221,7 @@ int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep,
 
 	packet = ctx->packet_size[idx];
 	if (packet) {
+		packet = min(packet, ep->maxframesize);
 		if (avail && packet >= avail)
 			return -EAGAIN;
 		return packet;
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.6] ASoC: cs42l43: Report insert for exotic peripherals

[Sasha Levin]

From: Charles Keepax <ckeepax@opensource.cirrus.com>

[ Upstream commit 6510e1324bcdc8caf21f6d17efe27604c48f0d64 ]

For some exotic peripherals the type detect can return a reserved value
of 0x4. This will currently return an error and not report anything to
user-space, update this to report the insert normally.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260223093616.3800350-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### What the commit does

This is a one-line fix to the CS42L43 audio codec's jack type detection.
The hardware's type detect register can return a reserved value of `0x4`
for "exotic peripherals." Before this fix, value `0x4` falls through to
the `default: return -EINVAL` case in the switch statement.

### What happens when -EINVAL is returned

The caller `cs42l43_tip_sense_work()` checks `if (report < 0)` and on
error:
1. Logs `"Jack detect failed: %d\n"`
2. Jumps to `error:` label
3. **No jack insert event is reported to userspace**

This means users with these "exotic peripherals" get no audio jack
detection at all — the device appears to not be plugged in.

### Bug classification

This is a **hardware quirk/workaround** — the hardware returns a
reserved value for certain real peripherals. The fix treats type `0x4`
the same as CTIA/OMTP (running load detection with headset=true), which
allows the system to properly detect and report the insert.

### Stable criteria assessment

1. **Fixes a real bug**: Yes — exotic peripherals are completely non-
   functional without this fix (no insert reported to userspace)
2. **Obviously correct**: Yes — the fix adds one case label to treat
   `0x4` like other headset types. The author (Charles Keepax) is the
   subsystem maintainer at Cirrus Logic.
3. **Small and contained**: Yes — one line added to a switch statement
   in a single file
4. **No new features**: Correct — this just makes existing hardware work
   properly
5. **Risk**: Extremely low — it only affects the `0x4` type value which
   previously returned an error anyway

This falls squarely into the **hardware quirks/workarounds** exception
category. The CS42L43 driver has been in the kernel since v6.6
(introduced August 2023, merged for 6.6-rc1), so it exists in recent
stable trees.

### Verification

- Explored `cs42l43_tip_sense_work()` at line ~766: confirmed that
  negative return from `cs42l43_run_type_detect()` goes to `error:`
  label without reporting jack state to userspace
- Confirmed the file was introduced in commit `fc918cbe874ee` (August 4,
  2023) — present since v6.6
- Confirmed the author Charles Keepax is the original driver author and
  Cirrus Logic engineer
- The commit was reviewed and merged by Mark Brown (ASoC maintainer)
- Multiple prior commits show ongoing type detection refinement for this
  codec (dc96528b176fa, e77a4081d7e32, etc.)
- The change is a single `case 0x4:` fallthrough to the existing
  CTIA/OMTP handler — no new code paths introduced

The fix is small, surgical, low-risk, and makes real hardware work for
users. It clearly meets stable kernel criteria.

**YES**

 sound/soc/codecs/cs42l43-jack.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/cs42l43-jack.c b/sound/soc/codecs/cs42l43-jack.c
index b83bc4de1301d..3e04e6897b142 100644
--- a/sound/soc/codecs/cs42l43-jack.c
+++ b/sound/soc/codecs/cs42l43-jack.c
@@ -699,6 +699,7 @@ static int cs42l43_run_type_detect(struct cs42l43_codec *priv)
 	switch (type & CS42L43_HSDET_TYPE_STS_MASK) {
 	case 0x0: // CTIA
 	case 0x1: // OMTP
+	case 0x4:
 		return cs42l43_run_load_detect(priv, true);
 	case 0x2: // 3-pole
 		return cs42l43_run_load_detect(priv, false);
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.15] ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio 2.0

[Sasha Levin]

From: Takashi Iwai <tiwai@suse.de>

[ Upstream commit c5bf24c8aba1ff711226ee0f039ff01a5754692b ]

Although DIYINHK USB Audio 2.0 (ID 20b1:2009) shows the implicit
feedback source for the capture stream, this would cause several
problems for the playback.  Namely, the device can get wMaxPackSize
1024 for 24/32 bit format with 6 channels, and when a high sample rate
like 352.8kHz or 384kHz is played, the packet size overflows the max
limit.  Also, the device has another two playback altsets, and those
aren't properly handled with the implicit feedback.

Since the device has been working well even before introducing the
implicit feedback, we can assume that it works fine in the async mode.
This patch adds the explicit skip of the implicit fb detection to make
the playback running in the async mode.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260225085233.316306-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Problem Description
This commit adds a USB audio device quirk for the DIYINHK USB Audio 2.0
device (VID 0x20b1, PID 0x2009) to skip implicit feedback mode. The
bugzilla report (#221076) documents a **kernel crash/oops** when playing
6-channel audio at high sample rates (352.8kHz/384kHz). The root cause
is that implicit feedback mode leads to packet sizes exceeding the
device's wMaxPacketSize of 1024 bytes, causing buffer overruns, URB
submission failures, and ultimately kernel panics.

### Stable Kernel Criteria Assessment

1. **Fixes a real bug**: YES - kernel crash/hard hang with specific
   hardware at high sample rates. The bugzilla report documents kernel
   oops with page faults in memset during URB preparation.

2. **Obviously correct and tested**: YES - it's a 2-line quirk flag
   addition by the ALSA maintainer (Takashi Iwai). The fix was confirmed
   working per the bugzilla discussion.

3. **Small and contained**: YES - adds exactly 2 lines to the quirk
   flags table. Zero risk to any other device.

4. **No new features**: Correct - this is a hardware workaround, not a
   feature.

5. **Category**: This falls squarely into the **hardware quirk**
   exception category, which is explicitly listed as always appropriate
   for stable backporting.

### Risk Assessment

- **Risk**: Essentially zero. The change only affects one specific USB
  device (0x20b1:0x2009). The `QUIRK_FLAG_SKIP_IMPLICIT_FB` flag is
  well-established (since 2022) and simply bypasses implicit feedback
  detection. The `QUIRK_FLAG_DSD_RAW` flag enables DSD format support,
  also well-established (since 2021).
- **Benefit**: Prevents kernel crashes/hangs for users of this specific
  USB audio device at high sample rates.

### Dependencies

The prerequisite infrastructure (`QUIRK_FLAG_SKIP_IMPLICIT_FB`
introduced in commit `0f1f7a6661394` from April 2022, and
`QUIRK_FLAG_DSD_RAW` from `68e851ee4cfd2` in July 2021) should be
present in all currently maintained stable trees (6.1+, 6.6+, etc.). The
patch is a simple table entry addition that should apply cleanly.

### Verification

- **Bugzilla link**
  (https://bugzilla.kernel.org/show_bug.cgi?id=221076): Confirmed real
  user-reported crash with kernel oops, page fault, and hard hangs at
  high sample rates on DIYINHK D2 device.
- **QUIRK_FLAG_SKIP_IMPLICIT_FB** defined in `sound/usb/usbaudio.h` and
  used in `sound/usb/implicit.c:390-391` to return early from implicit
  feedback setup - verified via agent exploration.
- **QUIRK_FLAG_DSD_RAW** defined in `sound/usb/usbaudio.h` and used in
  `sound/usb/quirks.c:2078-2079` - verified via agent exploration.
- **Both flags have existed since 2021-2022** (commits `68e851ee4cfd2`
  and `0f1f7a6661394`) - verified via git log, confirming they exist in
  stable trees.
- **Author is Takashi Iwai**, the ALSA subsystem maintainer - verified
  from commit authorship.
- **The change is a 2-line addition** to an existing quirk flags table
  with no logic changes - verified from the diff.

### Conclusion

This is a textbook stable backport candidate: a small, zero-risk
hardware quirk that fixes a real kernel crash reported by users,
authored by the subsystem maintainer, with well-established
infrastructure already present in stable trees.

**YES**

 sound/usb/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 86c329632e396..57c036ee9ba96 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2363,6 +2363,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
 	DEVICE_FLG(0x2040, 0x7281, /* Hauppauge HVR-950Q-MXL */
 		   QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+	DEVICE_FLG(0x20b1, 0x2009, /* XMOS Ltd DIYINHK USB Audio 2.0 */
+		   QUIRK_FLAG_SKIP_IMPLICIT_FB | QUIRK_FLAG_DSD_RAW),
 	DEVICE_FLG(0x2040, 0x8200, /* Hauppauge Woodbury */
 		   QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
 	DEVICE_FLG(0x21b4, 0x0081, /* AudioQuest DragonFly */
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table

[Sasha Levin]

From: Azamat Almazbek uulu <almazbek1608@gmail.com>

[ Upstream commit 32fc4168fa56f6301d858c778a3d712774e9657e ]

The ASUS ExpertBook BM1503CDA (Ryzen 5 7535U, Barcelo-R) has an
internal DMIC connected through the AMD ACP (Audio CoProcessor)
but is missing from the DMI quirk table, so the acp6x machine
driver probe returns -ENODEV and no DMIC capture device is created.

Add the DMI entry so the internal microphone works out of the box.

Signed-off-by: Azamat Almazbek uulu <almazbek1608@gmail.com>
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://patch.msgid.link/20260221114813.5610-1-almazbek1608@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis: ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table

### What the commit does

This is a simple DMI quirk table addition — a 7-line entry adding the
ASUS EXPERTBOOK BM1503CDA to the `yc_acp_quirk_table[]` in
`sound/soc/amd/yc/acp6x-mach.c`. Without this entry, the internal DMIC
(digital microphone) on this laptop is not detected, and the driver
probe returns `-ENODEV`, meaning **no microphone capture device is
created** — the internal mic simply doesn't work.

### Stable kernel criteria assessment

1. **Fixes a real bug**: Yes — the internal microphone doesn't work on
   this specific laptop model without the quirk entry.
2. **Obviously correct and tested**: Yes — it's a trivial DMI match
   entry following the exact same pattern as dozens of other entries in
   the same table. Reviewed by the AMD audio maintainer (Vijendar
   Mukunda).
3. **Small and contained**: Yes — 7 lines added to a single file, no
   logic changes whatsoever.
4. **No new features**: Correct — this enables existing hardware support
   on a specific device, not a new feature.
5. **Exception category**: This falls squarely under **hardware
   quirks/workarounds** — one of the explicitly allowed categories for
   stable backports.

### Risk assessment

- **Risk**: Essentially zero. The DMI match is specific to one laptop
  model (`ASUS EXPERTBOOK BM1503CDA` from `ASUSTeK COMPUTER INC.`). It
  cannot affect any other hardware.
- **Benefit**: Internal microphone works on this laptop model.
- **Dependencies**: None — the driver and quirk table infrastructure
  already exist in stable trees.

### Verification

- Verified the diff is a pure DMI table entry addition (7 lines) with no
  logic changes.
- Verified the entry follows the identical pattern of all other entries
  in the table (DMI_MATCH on BOARD_VENDOR + PRODUCT_NAME, driver_data =
  &acp6x_card).
- Verified the commit has `Reviewed-by: Vijendar Mukunda
  <Vijendar.Mukunda@amd.com>` (AMD audio subsystem reviewer).
- The file `sound/soc/amd/yc/acp6x-mach.c` and the `yc_acp_quirk_table`
  have existed in stable trees — this is a mature driver with many
  similar quirk entries.

### Conclusion

This is a textbook stable backport candidate: a hardware quirk addition
that enables an internal microphone on a specific laptop. Zero risk,
clear user benefit, trivially correct.

**YES**

 sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index f1a63475100d1..7af4daeb4c6ff 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -703,6 +703,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 				DMI_MATCH(DMI_PRODUCT_NAME, "Vivobook_ASUSLaptop M6501RR_M6501RR"),
 			}
 		},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "ASUS EXPERTBOOK BM1503CDA"),
+		}
+	},
 	{}
 };
 
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter

[Sasha Levin]

From: Sean Rhodes <sean@starlabs.systems>

[ Upstream commit 1cb3c20688fc8380c9b365d03aea7e84faf6a9fd ]

On Star Labs StarFighter (Realtek ALC233/235), the internal speakers can
emit an audible pop when entering or leaving runtime suspend.

Mute the speaker output paths via snd_hda_gen_shutup_speakers() in the
Realtek shutup callback before the codec is powered down.

This is enough to avoid the pop without special EAPD handling.

Test results:
- runtime PM pop fixed
- still reaches D3 (PCI 0000:00:1f.3 power_state=D3hot)
- does not address pops on cold boot (G3 exit) or around display manager
  start/shutdown

journalctl -k (boot):
- snd_hda_codec_alc269 hdaudioC0D0: ALC233: picked fixup for PCI SSID
  7017:2014
- snd_hda_codec_alc269 hdaudioC0D0: autoconfig for ALC233: line_outs=1
  (0x1b/0x0/0x0/0x0/0x0) type:speaker

Suggested-by: Takashi Iwai <tiwai@suse.com>
Tested-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Link: https://patch.msgid.link/4d5fb71b132bb283fd41c622b8413770b2065242.1771532060.git.sean@starlabs.systems
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### What the commit does
This adds an audio codec quirk (SND_PCI_QUIRK) for the Star Labs
StarFighter laptop (PCI SSID 0x7017:0x2014, Realtek ALC233/235). It
fixes an audible speaker pop when entering or leaving runtime suspend by
muting speaker output paths via `snd_hda_gen_shutup_speakers()` before
the codec powers down.

### Change breakdown
1. New shutup callback `starlabs_starfighter_shutup()` - calls existing
   `snd_hda_gen_shutup_speakers()` + 30ms delay
2. New fixup function `alc233_fixup_starlabs_starfighter()` - hooks the
   shutup callback during probe
3. New enum `ALC233_FIXUP_STARLABS_STARFIGHTER`
4. Fixup table entry and PCI SSID quirk entry (`0x7017, 0x2014`)
5. Model fixup string entry

### Classification: Hardware quirk (STRONG YES category)

This is a textbook audio codec quirk — one of the most commonly
backported types of changes to stable. It:
- Only activates for one specific PCI SSID (zero risk to other hardware)
- Uses existing, well-tested infrastructure
  (`snd_hda_gen_shutup_speakers()`, standard fixup mechanism)
- Fixes a real user-facing issue (audible speaker pop during runtime PM)
- Was suggested by the HDA subsystem maintainer (Takashi Iwai) and
  tested by the hardware vendor (Sean Rhodes @ Star Labs)

### Risk assessment: Very low
- Scope is strictly limited to one laptop model via PCI SSID matching
- No changes to shared code paths
- All new code uses established patterns seen in hundreds of similar
  fixups in this file
- The fixup mechanism (`HDA_FIXUP_FUNC` + `spec->shutup`) is a standard,
  well-tested pattern

### Stable criteria
- **Obviously correct**: Yes — standard quirk pattern, suggested by
  maintainer
- **Fixes real bug**: Yes — audible pop during runtime suspend
- **Small and contained**: Yes — ~25 new lines, all device-specific
- **No new features**: Correct — just a hardware workaround
- **Tested**: Yes — tested by hardware vendor, confirmed runtime PM
  still works (D3hot)

### Verification
- The commit uses `snd_hda_gen_shutup_speakers()` which is an existing
  function in the HDA generic layer — verified by the fact it's called
  without any new includes or declarations
- The fixup pattern (`HDA_FIXUP_FUNC` with `spec->shutup` assignment) is
  identical to patterns used by many other fixups in this same file
  (standard approach)
- Takashi Iwai (HDA subsystem maintainer) both suggested the approach
  and merged the patch — strong trust indicator
- The PCI SSID `0x7017:0x2014` is device-specific, limiting blast radius
  to exactly one laptop model
- The patch is self-contained with no dependencies on other commits —
  all additions are new enum values, table entries, and small functions
- "Tested-by: Sean Rhodes" from Star Labs confirms hardware validation

**YES**

 sound/hda/codecs/realtek/alc269.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 36053042ca772..9f64bb97c3f9a 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -1017,6 +1017,24 @@ static int alc269_resume(struct hda_codec *codec)
 	return 0;
 }
 
+#define STARLABS_STARFIGHTER_SHUTUP_DELAY_MS	30
+
+static void starlabs_starfighter_shutup(struct hda_codec *codec)
+{
+	if (snd_hda_gen_shutup_speakers(codec))
+		msleep(STARLABS_STARFIGHTER_SHUTUP_DELAY_MS);
+}
+
+static void alc233_fixup_starlabs_starfighter(struct hda_codec *codec,
+					      const struct hda_fixup *fix,
+					      int action)
+{
+	struct alc_spec *spec = codec->spec;
+
+	if (action == HDA_FIXUP_ACT_PRE_PROBE)
+		spec->shutup = starlabs_starfighter_shutup;
+}
+
 static void alc269_fixup_pincfg_no_hp_to_lineout(struct hda_codec *codec,
 						 const struct hda_fixup *fix, int action)
 {
@@ -4040,6 +4058,7 @@ enum {
 	ALC245_FIXUP_CLEVO_NOISY_MIC,
 	ALC269_FIXUP_VAIO_VJFH52_MIC_NO_PRESENCE,
 	ALC233_FIXUP_MEDION_MTL_SPK,
+	ALC233_FIXUP_STARLABS_STARFIGHTER,
 	ALC294_FIXUP_BASS_SPEAKER_15,
 	ALC283_FIXUP_DELL_HP_RESUME,
 	ALC294_FIXUP_ASUS_CS35L41_SPI_2,
@@ -6499,6 +6518,10 @@ static const struct hda_fixup alc269_fixups[] = {
 			{ }
 		},
 	},
+	[ALC233_FIXUP_STARLABS_STARFIGHTER] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc233_fixup_starlabs_starfighter,
+	},
 	[ALC294_FIXUP_BASS_SPEAKER_15] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc294_fixup_bass_speaker_15,
@@ -7651,6 +7674,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x2782, 0x1705, "MEDION E15433", ALC269VC_FIXUP_INFINIX_Y4_MAX),
 	SND_PCI_QUIRK(0x2782, 0x1707, "Vaio VJFE-ADL", ALC298_FIXUP_SPK_VOLUME),
 	SND_PCI_QUIRK(0x2782, 0x4900, "MEDION E15443", ALC233_FIXUP_MEDION_MTL_SPK),
+	SND_PCI_QUIRK(0x7017, 0x2014, "Star Labs StarFighter", ALC233_FIXUP_STARLABS_STARFIGHTER),
 	SND_PCI_QUIRK(0x8086, 0x2074, "Intel NUC 8", ALC233_FIXUP_INTEL_NUC8_DMIC),
 	SND_PCI_QUIRK(0x8086, 0x2080, "Intel NUC 8 Rugged", ALC256_FIXUP_INTEL_NUC8_RUGGED),
 	SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10),
@@ -7747,6 +7771,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = {
 	{.id = ALC298_FIXUP_TPT470_DOCK_FIX, .name = "tpt470-dock-fix"},
 	{.id = ALC298_FIXUP_TPT470_DOCK, .name = "tpt470-dock"},
 	{.id = ALC233_FIXUP_LENOVO_MULTI_CODECS, .name = "dual-codecs"},
+	{.id = ALC233_FIXUP_STARLABS_STARFIGHTER, .name = "starlabs-starfighter"},
 	{.id = ALC700_FIXUP_INTEL_REFERENCE, .name = "alc700-ref"},
 	{.id = ALC269_FIXUP_SONY_VAIO, .name = "vaio"},
 	{.id = ALC269_FIXUP_DELL_M101Z, .name = "dell-m101z"},
-- 
2.51.0