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: <6273ad6b-3c3c-4cc3-9b7e-1da5066d2321@cosmicgizmosystems.com>
Date: Tue, 14 Jan 2025 14:14:13 -0800
From: Terry Junge <linuxhid@...micgizmosystems.com>
To: Takashi Iwai <tiwai@...e.de>
Cc: Jiri Kosina <jikos@...nel.org>, Takashi Iwai <tiwai@...e.com>,
 Wade Wang <wade.wang@...com>, Benjamin Tissoires <bentiss@...nel.org>,
 Jaroslav Kysela <perex@...ex.cz>, linux-input@...r.kernel.org,
 linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] ALSA: usb-audio: Add quirk for Plantronics
 headsets to fix control names

On 1/14/25 4:38 AM, Takashi Iwai wrote:
> On Tue, 14 Jan 2025 00:51:59 +0100,
> Terry Junge wrote:
>>
>> +/*
>> + * Some Plantronics headsets have control names that don't meet ALSA naming
>> + * standards. This function fixes nonstandard source names. By the time
>> + * this function is called the control name should look like one of these:
>> + * "source names Playback Volume"
>> + * "source names Playback Switch"
>> + * "source names Capture Volume"
>> + * "source names Capture Switch"
>> + * If any of the trigger words are found in the name then the name will
>> + * be changed to:
>> + * "Headset Playback Volume"
>> + * "Headset Playback Switch"
>> + * "Headset Capture Volume"
>> + * "Headset Capture Switch"
>> + * depending on the current suffix.
>> + */
>> +static void snd_fix_plt_name(struct snd_usb_audio *chip,
>> +			     typeof_member(struct snd_ctl_elem_id, name) * name)
> 
> I personally find this style of argument is difficult to use.
> That said, IMO, it's better to stick with the argument
>   struct snd_ctl_elem_id *id
> and access via id->name as in your earlier patch; it's more idiomatic,
> and easier to read.
> 
So, is the coding of the rest of the function body acceptable if I just pass a
   struct snd_ctl_elem_id *id
instead of an
   unsigned char[44] *name
?

If not, what else do I need to address in V4 so it will be accepted?

thanks,

Terry
> 
> thanks,
> 
> Takashi


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ