From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F7DBC433EF for ; Wed, 23 Feb 2022 16:44:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242958AbiBWQpP (ORCPT ); Wed, 23 Feb 2022 11:45:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242897AbiBWQpO (ORCPT ); Wed, 23 Feb 2022 11:45:14 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2041E6E79E for ; Wed, 23 Feb 2022 08:44:47 -0800 (PST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id CA9BD2170C; Wed, 23 Feb 2022 16:44:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1645634685; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=l+WB0ESK8j3z2cDtTd/JikkFK7xyn5JoySiR/5RaGwQ=; b=1ls3lYp2uvxY0LVSTMQa6uY48CxBWGh+eiMktzjINs/UO74HHfkjXYpip6gOVig2lgEogR S+xoBPG7i/faJbAQ3L36ZuTwchnkLMp4TkmjCErZpIEqkovXt0OWQ9v6OOJOmiRYbZsUYh nl1GpfSSs9FNBCbaRYcXGEI7BTnuelc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1645634685; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=l+WB0ESK8j3z2cDtTd/JikkFK7xyn5JoySiR/5RaGwQ=; b=gx41fAmKEal94s9PbbN+leuLpQPpTlVpd7cNTLMYYE8Bz+G6pRB6NjlPjpDzqG1uwTtBMA bipl6NWAedP+7cBA== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id C15D2A3B85; Wed, 23 Feb 2022 16:44:45 +0000 (UTC) Date: Wed, 23 Feb 2022 17:44:45 +0100 Message-ID: From: Takashi Iwai To: Mark Brown Cc: Marek Vasut , alsa-devel@alsa-project.org, stable@vger.kernel.org Subject: Re: [PATCH] ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min In-Reply-To: References: <20220215130645.164025-1-marex@denx.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Wed, 23 Feb 2022 17:32:19 +0100, Mark Brown wrote: > > On Wed, Feb 23, 2022 at 03:55:54PM +0100, Takashi Iwai wrote: > > > > But, more reading the code, I suspect whether the function does work > > correctly at all... How is the mask calculation done in that way? > > unsigned int mask = (1U << (fls(min + max) - 1)) - 1; > > What's the difference of this function with snd_soc_put_volsw()? > > Yeah, I'm not clear either - Marek mentioned _SX when he was doing the > patch but I didn't get the bandwidth to figure out what it's doing > properly yet. At this point I'm not clear what _SX is supposed to do, > I'm hoping it works well for the devices that use it but I don't have > any of them. OK, let's hope that... > > Furthermore, the mask calculation and usage in snd_soc_put_volsw() > > isn't right, either, I'm afraid; if the range is [-10, 0], max=0, then > > mask will 0, which will omit all values... > > Indeed, if anyone did that. Fortunately I don't *think* that's an > issue. The whole way that code handles signed bitfields by remapping > them into unsigned user visible controls is a landmine, it's not even > obvious that they handle signed bitfields in the first place. Thanks, then it seems OK as is for now. I guess the signed bit should be detected by the helper instead of hard-coding, but it's no urgent issue. Takashi