[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <DM6PR19MB2636C714D1EE520F98617018FAE70@DM6PR19MB2636.namprd19.prod.outlook.com>
Date: Thu, 12 Nov 2020 15:57:55 +0000
From: "Limonciello, Mario" <Mario.Limonciello@...l.com>
To: Hans de Goede <hdegoede@...hat.com>,
"Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
Matthew Garrett <mjg59@...f.ucam.org>,
"Yuan, Perry" <Perry.Yuan@...l.com>
CC: "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
> >
> > 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.
>
> Thank you, can we put this in a comment in the driver please ?
Yes, I agree. I suggested to Perry that his next submission of this driver
needs a lot more context in commit message (and it sounds like probably
code comments too).
>
> I guess this also means that the led_class device is just there to
> catch the ledtrig_audio_set() call so that dell-firmware can tell the
> EC that the sw-mute is done and that it can move ahead with the hw-mute.
>
> While the real, physical LED is fully under hardware control, right ?
>
> That should probably also be in the same comment in the driver
> (feel free to re-use part of my wording for that if that helps).
>
> Regards,
>
> Hans
Yes - exactly.
Powered by blists - more mailing lists