Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp2203066pxb; Fri, 25 Mar 2022 12:59:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxXkDHhVOEN1AMPvGQyrgDRH22dln5aN0fDyfnVZHwyzkNG11ODniIOqhJ7EF7VlG1mygP X-Received: by 2002:a17:903:18c:b0:154:9ee:cedc with SMTP id z12-20020a170903018c00b0015409eecedcmr13626567plg.123.1648238345856; Fri, 25 Mar 2022 12:59:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648238345; cv=none; d=google.com; s=arc-20160816; b=OKpfFnDbIYc+Wvw1g9969t7Okza41xM3YLW8zToXjyQXTBtl3NAf46ak/AFyNtBWDL eDPChS1rbfRLLqUrhjx+aP6/GPu0z3QA4d/RdNvEK2r/wD325twWH07NuCjMil4gd8CW nALfrp8oqlf01b6bnu40BXRcfV+Wr8uYL2KZZAnq+mWZfP6/+ZyArk99/fXY3TmEZ09f 9m35tUsOmFp22F1dvJZ6kJ7hm3CZufghPUb7wHfWX5LzLAtelpsP6LjhQAzjS9P2rRKC jJcwUp4Hn69sxICyS7KuQv0keBCCTeolQMK/UuddHMPPKedH+0zXsrJd2V/4R3byzwWA VBwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=q7IcE0OISoT/FjwMpJ0LZ3QA+QXj5YBJCFcw2MWsXqw=; b=zqO+vSMZFOhW7Mr23k2zGBV0u+D0qSij2XweTVrDTGiMdw1XHajlikQ7kErqTpn2vu x6MHNQSFmVgGa/wvCtIYWiY80EZwN4/Hdiw02KbhKjcxXWv2NY2iS/HdhotSiGO4NgNL FjKsrD9EZSpiki2EMNafxJoRJEkSJ15fouLmK9rA8L13JJQydE1mEXtjjs3bX1nJB/Il lnlJt+9gVUlmkVS3uqtJeBaAL6Z6n5JlfekTaaVlER/czlF8HJLnSLEvRU/JlLTZCCJf fXv5VKmetWBSzm3zZNshfifMoKLA3yMGYNnaUEQR7q8FzvT1e/u9Z07BxtTu4bdXZgrK TXcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=VBegQJ0v; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id np18-20020a17090b4c5200b001c6da33cb62si3711354pjb.182.2022.03.25.12.59.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Mar 2022 12:59:05 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=VBegQJ0v; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F00D0357873; Fri, 25 Mar 2022 11:47:44 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376282AbiCYPMh (ORCPT + 99 others); Fri, 25 Mar 2022 11:12:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359784AbiCYPKJ (ORCPT ); Fri, 25 Mar 2022 11:10:09 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 558F7DBD18; Fri, 25 Mar 2022 08:07:48 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id F3DE3B82833; Fri, 25 Mar 2022 15:07:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24EC0C340E9; Fri, 25 Mar 2022 15:07:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1648220865; bh=JCOVLHohscIa00QIH1ZFiQHu3Zt5Fac47pp88wkyeaI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VBegQJ0vNjzPXPW9DmTFkm5pVsFkPYNj2yUGX1sIi/4o+laVA0lcLstbvV/YtZq40 4rbGYTmgw5CDknoMZuMEZ1XAC5mj/vAsGJLJ+ySZuhqRTeZc5JvvZ0oHn5tew3arMo jVieTeUxArosyZkHhlMG/K3IZth6e3zF9ibjhHus= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Giacomo Guiduzzi , Paolo Valente , Takashi Iwai Subject: [PATCH 5.4 15/29] ALSA: pci: fix reading of swapped values from pcmreg in AC97 codec Date: Fri, 25 Mar 2022 16:04:55 +0100 Message-Id: <20220325150419.025542374@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220325150418.585286754@linuxfoundation.org> References: <20220325150418.585286754@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Giacomo Guiduzzi commit 17aaf0193392cb3451bf0ac75ba396ec4cbded6e upstream. Tests 72 and 78 for ALSA in kselftest fail due to reading inconsistent values from some devices on a VirtualBox Virtual Machine using the snd_intel8x0 driver for the AC'97 Audio Controller device. Taking for example test number 72, this is what the test reports: "Surround Playback Volume.0 expected 1 but read 0, is_volatile 0" "Surround Playback Volume.1 expected 0 but read 1, is_volatile 0" These errors repeat for each value from 0 to 31. Taking a look at these error messages it is possible to notice that the written values are read back swapped. When the write is performed, these values are initially stored in an array used to sanity-check them and write them in the pcmreg array. To write them, the two one-byte values are packed together in a two-byte variable through bitwise operations: the first value is shifted left by one byte and the second value is stored in the right byte through a bitwise OR. When reading the values back, right shifts are performed to retrieve the previously stored bytes. These shifts are executed in the wrong order, thus reporting the values swapped as shown above. This patch fixes this mistake by reversing the read operations' order. Signed-off-by: Giacomo Guiduzzi Signed-off-by: Paolo Valente Cc: Link: https://lore.kernel.org/r/20220322200653.15862-1-guiduzzi.giacomo@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/pci/ac97/ac97_codec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/sound/pci/ac97/ac97_codec.c +++ b/sound/pci/ac97/ac97_codec.c @@ -938,8 +938,8 @@ static int snd_ac97_ad18xx_pcm_get_volum int codec = kcontrol->private_value & 3; mutex_lock(&ac97->page_mutex); - ucontrol->value.integer.value[0] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 0) & 31); - ucontrol->value.integer.value[1] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 8) & 31); + ucontrol->value.integer.value[0] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 8) & 31); + ucontrol->value.integer.value[1] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 0) & 31); mutex_unlock(&ac97->page_mutex); return 0; }