linux-kernel - Re: [PATCH v1] ALSA: hda: cs35l41: Support mute notifications for CS35L41 HDA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 29 Aug 2023 16:23:59 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Stefan Binding <sbinding@...nsource.cirrus.com>
Cc:     Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
        <alsa-devel@...a-project.org>, <linux-kernel@...r.kernel.org>,
        <patches@...nsource.cirrus.com>,
        Vitaly Rodionov <vitalyr@...nsource.cirrus.com>
Subject: Re: [PATCH v1] ALSA: hda: cs35l41: Support mute notifications for CS35L41 HDA

On Tue, 29 Aug 2023 16:18:12 +0200,
Stefan Binding wrote:
> 
> 
> On 25/08/2023 13:13, Takashi Iwai wrote:
> > On Fri, 25 Aug 2023 14:05:25 +0200,
> > Stefan Binding wrote:
> >> From: Vitaly Rodionov <vitalyr@...nsource.cirrus.com>
> >> 
> >> Some laptops require a hardware based mute system, where when a hotkey
> >> is pressed, it forces the amp to be muted.
> >> 
> >> For CS35L41, when the hotkey is pressed, an acpi notification is sent
> >> to the CS35L41 Device Node. The driver needs to handle this notification
> >> and call a _DSM function to retrieve the mute state.
> >> 
> >> Since the amp is only muted during playback, the driver will only mute
> >> or unmute if playback is occurring, otherwise it will save the mute
> >> state for when playback starts.
> >> 
> >> Only one handler can be registered for the acpi notification, but all
> >> amps need to receive that notification, we can register a single handler
> >> inside the Realtek HDA driver, so that it can then notify through the
> >> component framework.
> >> 
> >> Signed-off-by: Vitaly Rodionov <vitalyr@...nsource.cirrus.com>
> >> Signed-off-by: Stefan Binding <sbinding@...nsource.cirrus.com>
> > We don't do normally in this way.  The ACPI hot key handling is done
> > via user-space, and user-space daemon triggers the mute of the
> > system.
> > 
> > Can't the ACPI notify the key event on those machines?
> 
> This feature is not the "normal" mute button on a keyboard, it is a
> custom request
> from a manufacturer which only mutes the audio on the speakers.
> On previous generations, this was achieved using a GPIO controlled by
> the BIOS/EC.
> However, since CS35L41 does not have such GPIO, we must control it by
> other means.
> 
> Our solution, which we have to share with the Windows driver, it to use ACPI
> notifications to tell the driver to mute the amps when the shortcut is
> pressed.
> 
> Does this seem like a valid exception to the typical approach?

It's still the question whether we have to do this inevitably in the
kernel in a way like that.  It sounds quite unusual.  Why this must be
handled directly?  IOW, what's the difference from the "normal" mute
button?

And, even if we take this approach, it leaves the device muted without
exposing it to user-space.  Then user wouldn't know what happens.


thanks,

Takashi