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]
Message-ID: <DM6PR19MB2636D792A7CCEE8937579EA6FAE70@DM6PR19MB2636.namprd19.prod.outlook.com>
Date:   Thu, 12 Nov 2020 15:31:18 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@...l.com>
To:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        "Yuan, Perry" <Perry.Yuan@...l.com>
CC:     "hdegoede@...hat.com" <hdegoede@...hat.com>,
        "mgross@...ux.intel.com" <mgross@...ux.intel.com>,
        "pali@...nel.org" <pali@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>
Subject: RE: [PATCH] platform/x86: dell-privacy: Add support for new privacy
 driver

> > Pressing the mute key activates a time delayed circuit to physically cut
> > off the mute.  The LED is in the same circuit, so it reflects the true
> > state of the HW mute.  The reason for the EC "ack" is so that software
> > can first invoke a SW mute before the HW circuit is cut off.  Without SW
> > cutting this off first does not affect the time delayed muting or status
> > of the LED but there is a possibility of a "popping" noise leading to a
> > poor user experience.
> 
> how long is that timeout ?

The exact duration is controlled by component selection in the circuit.
Linux is typically able to respond faster than Windows in this case.

> 
> > Exposing as an LED device allows the codec drivers notification path to
> > EC ACK to work.
> 
> Which driver exactly ? Who's gonna access this LED ?

The flow is like this:

1) User presses key.  HW does stuff with this key (timeout is started)
2) Event is emitted from FW
3) Event received by dell-privacy
4) KEY_MICMUTE emitted from dell-privacy
5) Userland picks up key and modifies kcontrol for SW mute
6) Codec kernel driver catches and calls ledtrig_audio_set, like this:

ledtrig_audio_set(LED_AUDIO_MICMUTE, rt715->micmute_led ? LED_ON : LED_OFF);

7) If "LED" is set to on dell-privacy notifies ec, and timeout is cancelled,
HW mic mute activated.

Again, if anything in this flow doesn't happen HW mic mute is still activated,
just will take longer (for duration of timeout) and have popping noise.

> 
> 
> --mtx
> 
> --
> ---
> Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
> werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
> GPG/PGP-Schlüssel zu.
> ---
> Enrico Weigelt, metux IT consult
> Free software and Linux embedded engineering
> info@...ux.net -- +49-151-27565287

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ