| Message ID | 20241030171813.18941-1-jaroslaw.janik@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fix beep notifications by Thinkpad's ACPI firmware | expand |
On Wed, 30 Oct 2024 18:18:11 +0100, Jarosław Janik wrote: > > In Comment 17 of the following bug report: > https://bugzilla.suse.com/show_bug.cgi?id=1228269 > user tigerlily had complained about "audible blip on shutdown" on a > Thinkpad laptop, that led to a commit 4f61c8fe3520 ("ALSA: hda/conexant: > Mute speakers at suspend / shutdown"), which mutes speakers on system > shutdown or whenever HDA controller is suspended by PM. The > aforementioned "blip" is a feature, not a bug however - Thinkpad's ACPI > firmware uses short beeps / beep sequences as notifications in response > to various events (enter/leave suspend or hibernation, AC power > connect/disconnect, low battery, etc.); these can also be triggered by > writing to /proc/acpi/ibm/beep, see details here: > https://www.kernel.org/doc/html/v5.4/admin-guide/laptops/thinkpad-acpi.html#acpi-sounds-proc-acpi-ibm-beep > The firmware doesn't touch any mixer, so depending on current mixer > settings these beeps can be loud, silent or even muted completely, > whatever has been set by the user. > > The patch in question interferes this badly: > - suspend/hibernate/shutdown related events are muted altogether because > HDA controller is in suspend mode when they occur (or snd_hda_intel > module has been closed in the event of system shutdown) > - other events work "randomly", e.g. you can hear AC plug/unplug beep > if something is playing audio at the moment, otherwise the HDA > controller is likely in suspend mode, so you can't hear anything > (unless you disabled PM in snd_hda_intel module). > > That said - let's revert this; this is what 1st commit does, the 2nd > commit is somewhat optional - it removes helpers introduced to implement > this muting, as they are no longer used. As it's a regression, it's OK for the first revert, but the function is useful for other purposes and other devices, so I'd like to keep it. I'm going to apply only the first patch. > PS. Don't forget to have this backported to LTS kernels, please. This should be taken usually automatically as long as Fixes tag points to the right commit. Per reading the patch description, though, the behavior appears to be pretty unreliable, as it depends on the runtime suspend. We may control the runtime PM better if we know that the beep must be submitted; or it's even possible to runtime resume/re-suspend upon beeping, too. But it's maybe too complex than needed. thanks, Takashi
On 31.10.2024 10:15, Takashi Iwai wrote: > Per reading the patch description, though, the behavior appears to be > pretty unreliable, as it depends on the runtime suspend. We may > control the runtime PM better if we know that the beep must be > submitted; or it's even possible to runtime resume/re-suspend upon > beeping, too. But it's maybe too complex than needed. You must have misunderstood that, this unreliable behavior is what happens with your patch applied, once this patch is reverted everything works perfectly fine (again). Perhaps the commit message should be rewritten to indicate it more clearly, e.g. replace: > now those beeps are either muted altogether with > since 4f61c8fe3520 those beeps are either muted altogether ... or perhaps it should be just left as it is... Thanks anyway!
On Thu, 31 Oct 2024 17:12:53 +0100, Jarosław Janik wrote: > > On 31.10.2024 10:15, Takashi Iwai wrote: > > > Per reading the patch description, though, the behavior appears to be > > pretty unreliable, as it depends on the runtime suspend. We may > > control the runtime PM better if we know that the beep must be > > submitted; or it's even possible to runtime resume/re-suspend upon > > beeping, too. But it's maybe too complex than needed. > > You must have misunderstood that, this unreliable behavior is what > happens with your patch applied, once this patch is reverted everything > works perfectly fine (again). Perhaps the commit message should be > rewritten to indicate it more clearly, e.g. replace: > > now those beeps are either muted altogether > with > > since 4f61c8fe3520 those beeps are either muted altogether > > ... or perhaps it should be just left as it is... Hm, so the beep works even if the HD-audio device is runtime-suspended before shutdown? Also, beeping at suspend/resume works no matter whether runtime-suspended or not? thanks, Takashi
On 31.10.2024 17:21, Takashi Iwai wrote: > Hm, so the beep works even if the HD-audio device is runtime-suspended > before shutdown? Also, beeping at suspend/resume works no matter > whether runtime-suspended or not? Well, to what I recall - my (current) Thinkpad has never beeped on shutdown, other than that - without your "extra muting" patch - yes - beeping in every other circumstances works no matter if HDA controller is in PM suspend or not; this is what I've got used to for many years of using Thinkpads. And one more thing - with your patch - beeping is not muted on my laptop completely, you can still hear it if you are in a quiet room, it's just very "weak".
On 31.10.24 10:15, Takashi Iwai wrote: > On Wed, 30 Oct 2024 18:18:11 +0100, > Jarosław Janik wrote: > >> PS. Don't forget to have this backported to LTS kernels, please. > This should be taken usually automatically as long as Fixes tag points > to the right commit. Usually: yes. But a quick reminder: it also might be silently dropped. If you want to ensure it's backported, a stable tag is a must: https://docs.kernel.org/process/stable-kernel-rules.html Ciao, Thorsten
On Thu, 31 Oct 2024 17:43:18 +0100, Jarosław Janik wrote: > > On 31.10.2024 17:21, Takashi Iwai wrote: > > Hm, so the beep works even if the HD-audio device is runtime-suspended > > before shutdown? Also, beeping at suspend/resume works no matter > > whether runtime-suspended or not? > > Well, to what I recall - my (current) Thinkpad has never beeped on > shutdown, other than that - without your "extra muting" patch - yes - > beeping in every other circumstances works no matter if HDA controller > is in PM suspend or not; this is what I've got used to for many years of > using Thinkpads. Do you mean about the beep emitted via thinkpad_acpi stuff or the normal beep via terminal etc? The latter must work even with the patch, but the question is only about the former. And that's the case for the shutdown beep tone. You can pass snd_hda_intel.beep_mode=0 option to disable HD-audio beep, verify the device being runtime-suspended, and check whether the beep via thinkpad_acpi still works (after reverting). > And one more thing - with your patch - beeping is not muted on my laptop > completely, you can still hear it if you are in a quiet room, it's just > very "weak". It might be because there can be two routes of beep tone; one via HD-audio and another internally. thanks, Takashi
On 11/1/24 09:18, Takashi Iwai wrote: >> Well, to what I recall - my (current) Thinkpad has never beeped on >> shutdown, other than that - without your "extra muting" patch - yes - >> beeping in every other circumstances works no matter if HDA controller >> is in PM suspend or not; this is what I've got used to for many years of >> using Thinkpads. > > Do you mean about the beep emitted via thinkpad_acpi stuff or the > normal beep via terminal etc? The latter must work even with the > patch, but the question is only about the former. And that's the case > for the shutdown beep tone. Yes, I meant beeps emitted by ACPI firmware and I'm not confusing them with beeps generated by linux console - as you said - the latter work fine no matter if your patch is applied or not, the former only work fine if that patch is reverted. BTW. The ACPI beeps we are talking about are not emitted by thinkapd_acpi module, but by ACPI firmware; you can take a look at how thinpad_acpi handles writes to /proc/acpi/ibm/beep - it doesn't make any beep itself, it just injects some "fake" ACPI event - and beep is generated by laptop's firmware in response to that event (the terminology here might not be too good, because my knowledge of ACPI is rather modest). Anyway - with that being said - when it comes to the lack of beep on shutdown on *my* laptop - this must be because of *my* laptop's APCI firmware just doesn't emit beep for this specific event. > You can pass snd_hda_intel.beep_mode=0 option to disable HD-audio > beep, verify the device being runtime-suspended, and check whether the > beep via thinkpad_acpi still works (after reverting). Yes, that works. I've even had another test - with patch applied I increased power_save param in this module to 3 seconds and now: - when I unplug AC - there is no beep, because device is PM suspended - now I hit Tab in bash on linux console, kernel emits beep and keeps device awaken for 3 more seconds - so I quickly unplug AC - there is a beep, then wait ~3 seconds and plug it back - no beep now. That shall prove that our understanding of what's going on is OK.
On Sat, 02 Nov 2024 00:15:24 +0100, Jarosław Janik wrote: > > On 11/1/24 09:18, Takashi Iwai wrote: > > >> Well, to what I recall - my (current) Thinkpad has never beeped on > >> shutdown, other than that - without your "extra muting" patch - yes - > >> beeping in every other circumstances works no matter if HDA controller > >> is in PM suspend or not; this is what I've got used to for many years of > >> using Thinkpads. > > > > Do you mean about the beep emitted via thinkpad_acpi stuff or the > > normal beep via terminal etc? The latter must work even with the > > patch, but the question is only about the former. And that's the case > > for the shutdown beep tone. > > Yes, I meant beeps emitted by ACPI firmware and I'm not confusing them > with beeps generated by linux console - as you said - the latter work > fine no matter if your patch is applied or not, the former only work > fine if that patch is reverted. OK. > BTW. The ACPI beeps we are talking about are not emitted by > thinkapd_acpi module, but by ACPI firmware; you can take a look at how > thinpad_acpi handles writes to /proc/acpi/ibm/beep - it doesn't make any > beep itself, it just injects some "fake" ACPI event - and beep is > generated by laptop's firmware in response to that event (the > terminology here might not be too good, because my knowledge of ACPI is > rather modest). > > Anyway - with that being said - when it comes to the lack of beep on > shutdown on *my* laptop - this must be because of *my* laptop's APCI > firmware just doesn't emit beep for this specific event. Yes, it seems like that. > > You can pass snd_hda_intel.beep_mode=0 option to disable HD-audio > > beep, verify the device being runtime-suspended, and check whether the > > beep via thinkpad_acpi still works (after reverting). > > Yes, that works. > I've even had another test - with patch applied I increased power_save > param in this module to 3 seconds and now: > - when I unplug AC - there is no beep, because device is PM suspended > - now I hit Tab in bash on linux console, kernel emits beep and keeps > device awaken for 3 more seconds - so I quickly unplug AC - there is a > beep, then wait ~3 seconds and plug it back - no beep now. That shall > prove that our understanding of what's going on is OK. For checking the runtime-suspend, at best check the sysfs file entry. e.g. cat /sys/bus/hdaudio/devices/hdaudioC0D0/power/runtime_status And, I see that Conexant codec doesn't have the beep generator but it's only passthrough. Then beep_mode option doesn't change anything, but the "Beep" mixer volume/switch may influence on the behavior; not only the beep volume but also the runtime-suspend behavior. You can try adjusting the volume/switch if it influences on anything. In anyway, you can try unload pcspkr module as well. This is the Linux input device for the beep in your case. (For Realtek codecs, there can be additional beep input device driven by HD-audio codec itself, and that's managed via beep_mode module option). Without pcspkr, the beep from the terminal shouldn't work -- unless it's handled by the sound server like pulesaudio. And, if I understand correctly from your description, even without pcspkr, the firmware beep should keep working. As you see, the simple beeping stuff is really complex due to its history. Although it's a legacy feature, a few people still love it, hence it can't go away soon :) Takashi
On 11/2/24 09:27, Takashi Iwai wrote: > For checking the runtime-suspend, at best check the sysfs file entry. > e.g. cat /sys/bus/hdaudio/devices/hdaudioC0D0/power/runtime_status OK, so - just to be sure - I verified my assumptions about PM state of HDA controller when "nothing interesting is happening" (suspended) and for a short while after I generate a beep on a console (active) - so not a huge surprise here :) > As you see, the simple beeping stuff is really complex due to its > history. Although it's a legacy feature, a few people still love it, > hence it can't go away soon :) OK, so (again - just to be sure) - I understand that you are going to revert that patch this is all about (no more tests or whatever needed from my side)?
On Sat, 02 Nov 2024 23:45:33 +0100, Jarosław Janik wrote: > > On 11/2/24 09:27, Takashi Iwai wrote: > > > For checking the runtime-suspend, at best check the sysfs file entry. > > e.g. cat /sys/bus/hdaudio/devices/hdaudioC0D0/power/runtime_status > > OK, so - just to be sure - I verified my assumptions about PM state of > HDA controller when "nothing interesting is happening" (suspended) and > for a short while after I generate a beep on a console (active) - so not > a huge surprise here :) A beep sound triggered via the input beep device -- the one from HD-audio driver, not from pcspkr -- does resume the runtime suspend. So it's no surprise that it works. OTOH, a question is rather the other route -- the beep via pcspkr driver -- if this beep still works while the HD-audio is runtime suspended: that's the interesting point. Could you check that? You can figure out which input device corresponds what, and try to trigger directly there. Also, one more question is whether the beep tone persists if you mute the volume on the HD-audio (e.g. set "Speaker Playback Switch" to off). The beep tone at shutdown should be gone in this state, too. > > As you see, the simple beeping stuff is really complex due to its > > history. Although it's a legacy feature, a few people still love it, > > hence it can't go away soon :) > > OK, so (again - just to be sure) - I understand that you are going to > revert that patch this is all about (no more tests or whatever needed > from my side)? Yes, the revert is on the way to 6.12-rc7. thanks, Takashi
On 8.11.2024 15:17, Takashi Iwai wrote: > OTOH, a question is rather the other route -- the beep via pcspkr > driver -- if this beep still works while the HD-audio is runtime > suspended: that's the interesting point. Could you check that? > You can figure out which input device corresponds what, and try to > trigger directly there. Beep via pcspkr module works fine without your patch - regardless of current PM state of HDA device; with your patch applied - the beep is very quiet if HDA is suspended (same as with firmware generated beeps). > Also, one more question is whether the beep tone persists if you mute > the volume on the HD-audio (e.g. set "Speaker Playback Switch" to > off). The beep tone at shutdown should be gone in this state, too. pcspkr generated beeps are immune to every mixer/switch setting except for "Master Mute Switch", which mutes them completely (i.e. they are not very quiet, they are gone). And again - this is the very same as with firmware beeps; that would mean that both (firmware's and pcspkr's) are using PIT to drive "PC Speaker". > Yes, the revert is on the way to 6.12-rc7. Already there by now, thanks!
On Thu, 14 Nov 2024 01:04:22 +0100, Jarosław Janik wrote: > > On 8.11.2024 15:17, Takashi Iwai wrote: > > OTOH, a question is rather the other route -- the beep via pcspkr > > driver -- if this beep still works while the HD-audio is runtime > > suspended: that's the interesting point. Could you check that? > > You can figure out which input device corresponds what, and try to > > trigger directly there. > > Beep via pcspkr module works fine without your patch - regardless of > current PM state of HDA device; with your patch applied - the beep is > very quiet if HDA is suspended (same as with firmware generated beeps). > > > Also, one more question is whether the beep tone persists if you mute > > the volume on the HD-audio (e.g. set "Speaker Playback Switch" to > > off). The beep tone at shutdown should be gone in this state, too. > > pcspkr generated beeps are immune to every mixer/switch setting except > for "Master Mute Switch", which mutes them completely (i.e. they are not > very quiet, they are gone). And again - this is the very same as with > firmware beeps; that would mean that both (firmware's and pcspkr's) are > using PIT to drive "PC Speaker". So, if the HD-audio Master volume influence on the beep output of pcspkr, it means that it's flowing over HD-audio, likely there is some analog-input loopback. Could you give alsa-info.sh output? (Run with --no-upload option and attach the output). If there is a mixer widget there, one of input pins might correspond to the analog beep input -- even if the pin is marked as unused. Takashi
On 14.11.2024 14:42, Takashi Iwai wrote: > So, if the HD-audio Master volume influence on the beep output of > pcspkr, it means that it's flowing over HD-audio, likely there is some > analog-input loopback. > > Could you give alsa-info.sh output? (Run with --no-upload option and > attach the output). > > If there is a mixer widget there, one of input pins might correspond > to the analog beep input -- even if the pin is marked as unused. alsa-info.txt attached
On Fri, 15 Nov 2024 05:34:57 +0100, Jarosław Janik wrote: > > On 14.11.2024 14:42, Takashi Iwai wrote: > > So, if the HD-audio Master volume influence on the beep output of > > pcspkr, it means that it's flowing over HD-audio, likely there is some > > analog-input loopback. > > > > Could you give alsa-info.sh output? (Run with --no-upload option and > > attach the output). > > > > If there is a mixer widget there, one of input pins might correspond > > to the analog beep input -- even if the pin is marked as unused. > > alsa-info.txt attached Thanks. So this codec chip has no analog input mixer unlike Realtek. Hmm. I'm not sure whether I already asked it: did you try to turn on/off "Beep Playback Switch" (i.e. mute/unute "Beep" mixer element)? It should control the digital beep of HD-audio's own beep input device, but this might be also related with the internal beep from the Lenovo firmware (and the output of pcspkr input device). And, judging from the fact that "Master" volume influences on the beep sound, it also means that the sound is routed to DACs -- for Conexant codecs, Master is a virtual control just changes both Speaker and Headphone volumes/switches, and both Speaker and Headphone controls are tied with the Audio Output widgets. You can check whether the beep tone volume from pcspkr or Thinkpad ACPI is also controlled via Speaker and Headphone mixer volume and switch. Takashi
On 19.11.2024 16:21, Takashi Iwai wrote: > I'm not sure whether I already asked it: did you try to turn on/off > "Beep Playback Switch" (i.e. mute/unute "Beep" mixer element)? > It should control the digital beep of HD-audio's own beep input > device, but this might be also related with the internal beep from the > Lenovo firmware (and the output of pcspkr input device). Both "Beep" mixer and mute switch don't affect beeps generated by ACPI firmware (and pcspkr module for that matter) > And, judging from the fact that "Master" volume influences on the beep > sound, it also means that the sound is routed to DACs -- for Conexant > codecs, Master is a virtual control just changes both Speaker and > Headphone volumes/switches, and both Speaker and Headphone controls > are tied with the Audio Output widgets. You can check whether the > beep tone volume from pcspkr or Thinkpad ACPI is also controlled via > Speaker and Headphone mixer volume and switch. The volume of beeps from firmware and pcspkr is fixed, it's not changed by any available mixer setting; the only thing that affects those beeps is Master Mute Switch, which mutes them both on the speakers and on the headphones. And one more thing - both beep types are audible on the headphones even if Headphones mixer is set minimum and Headphones Mute Switch is set to mute (if Master is unmuted, obviously)
On Wed, 20 Nov 2024 02:29:59 +0100, Jarosław Janik wrote: > > On 19.11.2024 16:21, Takashi Iwai wrote: > > I'm not sure whether I already asked it: did you try to turn on/off > > "Beep Playback Switch" (i.e. mute/unute "Beep" mixer element)? > > It should control the digital beep of HD-audio's own beep input > > device, but this might be also related with the internal beep from the > > Lenovo firmware (and the output of pcspkr input device). > > Both "Beep" mixer and mute switch don't affect beeps generated by ACPI > firmware (and pcspkr module for that matter) > > > And, judging from the fact that "Master" volume influences on the beep > > sound, it also means that the sound is routed to DACs -- for Conexant > > codecs, Master is a virtual control just changes both Speaker and > > Headphone volumes/switches, and both Speaker and Headphone controls > > are tied with the Audio Output widgets. You can check whether the > > beep tone volume from pcspkr or Thinkpad ACPI is also controlled via > > Speaker and Headphone mixer volume and switch. > > The volume of beeps from firmware and pcspkr is fixed, it's not changed > by any available mixer setting; the only thing that affects those beeps > is Master Mute Switch, which mutes them both on the speakers and on the > headphones. > > And one more thing - both beep types are audible on the headphones even > if Headphones mixer is set minimum and Headphones Mute Switch is set to > mute (if Master is unmuted, obviously) Hm, that's odd. At this moment, do you hear from the speaker? Or Speaker Playback Switch is off? Takashi
On 20.11.2024 08:04, Takashi Iwai wrote: > On Wed, 20 Nov 2024 02:29:59 +0100, >> And one more thing - both beep types are audible on the headphones even >> if Headphones mixer is set minimum and Headphones Mute Switch is set to >> mute (if Master is unmuted, obviously) > > Hm, that's odd. At this moment, do you hear from the speaker? Or > Speaker Playback Switch is off? The speakers are completely silent once you connect headphones, regardless of Speakers Volume / Mute Switch settings.
On Wed, 20 Nov 2024 16:00:07 +0100, Jarosław Janik wrote: > > On 20.11.2024 08:04, Takashi Iwai wrote: > > On Wed, 20 Nov 2024 02:29:59 +0100, > > >> And one more thing - both beep types are audible on the headphones even > >> if Headphones mixer is set minimum and Headphones Mute Switch is set to > >> mute (if Master is unmuted, obviously) > > > > Hm, that's odd. At this moment, do you hear from the speaker? Or > > Speaker Playback Switch is off? > > The speakers are completely silent once you connect headphones, > regardless of Speakers Volume / Mute Switch settings. Even if you turn off "Auto-Mute Mode"...? If yes, check the widget NID 0x10 and 0x1f in the codec proc file (/proc/asound/card*/codec#*). The former should have the output amp value like 0x40, and the latter should be pinctl 0x40 (output). You can override the values directly via hda-verb, too. Takashi
On 20.11.2024 16:09, Takashi Iwai wrote: >> The speakers are completely silent once you connect headphones, >> regardless of Speakers Volume / Mute Switch settings. > > Even if you turn off "Auto-Mute Mode"...? If yes, check the widget > NID 0x10 and 0x1f in the codec proc file > (/proc/asound/card*/codec#*). The former should have the output amp > value like 0x40, and the latter should be pinctl 0x40 (output). > You can override the values directly via hda-verb, too. Yes, speakers are always silent when headphones are connected, regardless of Auto-Mute Mode and even if Speaker Mixer is set to max and unmuted (which translates to 0x40 for NID 0x10 in my /proc/asound/card0/codec#0). When it comes to Pin-ctl of 0x1f - it is "0x40: OUT" as you said it should be, unless Auto-Mute is enabled and headphones are connected (it's 0x00 then); but it doesn't change anything - if you plug headphones - speakers are quiet.
On Thu, 21 Nov 2024 02:15:43 +0100, Jarosław Janik wrote: > > On 20.11.2024 16:09, Takashi Iwai wrote: > >> The speakers are completely silent once you connect headphones, > >> regardless of Speakers Volume / Mute Switch settings. > > > > Even if you turn off "Auto-Mute Mode"...? If yes, check the widget > > NID 0x10 and 0x1f in the codec proc file > > (/proc/asound/card*/codec#*). The former should have the output amp > > value like 0x40, and the latter should be pinctl 0x40 (output). > > You can override the values directly via hda-verb, too. > > Yes, speakers are always silent when headphones are connected, > regardless of Auto-Mute Mode and even if Speaker Mixer is set to max and > unmuted (which translates to 0x40 for NID 0x10 in my > /proc/asound/card0/codec#0). > When it comes to Pin-ctl of 0x1f - it is "0x40: OUT" as you said it > should be, unless Auto-Mute is enabled and headphones are connected > (it's 0x00 then); but it doesn't change anything - if you plug > headphones - speakers are quiet. Aha, that's an interesting information. Then basically Auto-Mute Mode control is useless on your machine, and can be omitted. Takashi
In Comment 17 of the following bug report: https://bugzilla.suse.com/show_bug.cgi?id=1228269 user tigerlily had complained about "audible blip on shutdown" on a Thinkpad laptop, that led to a commit 4f61c8fe3520 ("ALSA: hda/conexant: Mute speakers at suspend / shutdown"), which mutes speakers on system shutdown or whenever HDA controller is suspended by PM. The aforementioned "blip" is a feature, not a bug however - Thinkpad's ACPI firmware uses short beeps / beep sequences as notifications in response to various events (enter/leave suspend or hibernation, AC power connect/disconnect, low battery, etc.); these can also be triggered by writing to /proc/acpi/ibm/beep, see details here: https://www.kernel.org/doc/html/v5.4/admin-guide/laptops/thinkpad-acpi.html#acpi-sounds-proc-acpi-ibm-beep The firmware doesn't touch any mixer, so depending on current mixer settings these beeps can be loud, silent or even muted completely, whatever has been set by the user. The patch in question interferes this badly: - suspend/hibernate/shutdown related events are muted altogether because HDA controller is in suspend mode when they occur (or snd_hda_intel module has been closed in the event of system shutdown) - other events work "randomly", e.g. you can hear AC plug/unplug beep if something is playing audio at the moment, otherwise the HDA controller is likely in suspend mode, so you can't hear anything (unless you disabled PM in snd_hda_intel module). That said - let's revert this; this is what 1st commit does, the 2nd commit is somewhat optional - it removes helpers introduced to implement this muting, as they are no longer used. PS. Don't forget to have this backported to LTS kernels, please. Jarosław Janik (2): Revert "ALSA: hda/conexant: Mute speakers at suspend / shutdown" Revert "ALSA: hda/generic: Add a helper to mute speakers at suspend/shutdown" sound/pci/hda/hda_generic.c | 63 ---------------------------------- sound/pci/hda/hda_generic.h | 1 - sound/pci/hda/patch_conexant.c | 2 -- 3 files changed, 66 deletions(-)