Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1467409pxp; Sun, 20 Mar 2022 18:28:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzUz+TKer7Sjd7LLsSkWB8kTYZOFDQwc2VlrCnG9Dhr+Qi/yoYCOpEwyUqXqHBaO/vaoOP6 X-Received: by 2002:aa7:c759:0:b0:419:896:271b with SMTP id c25-20020aa7c759000000b004190896271bmr15070060eds.98.1647826134653; Sun, 20 Mar 2022 18:28:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647826134; cv=none; d=google.com; s=arc-20160816; b=PgxNc5epmnsEFYkJODpvJPPmHBO2cIbCc0RAjbsA146OTBn81zvh208i5zTGbogV3A gm4vjgq2jXkqDLfHm7OtgXI2p/E+JAO3FF43ucoPtEiOSZNCT4F/Iul2nI5pg4ncYRxS VRlWNHglO5kY5hnxZE4h8Os//UgntWvyf+hMsBFn7PEIbfeLobxZkBnlzaK87ONf18A0 htAL6msb4mKGBl+CsVpm0pY6hc2ZC5H4iXeCHD2rzabnL0mBWnphxtL7cMjgxX5ycBHI E7ib9xdbdD50wXHX+ERnpa08+WauFkTQnv35+rYolp03rdAKd19RflaLeO7hWirh5uj6 4vAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=iEoUOGNuvWutEIurlLjPrbp6aIbsgX9NoeRfOy5dLGk=; b=YNIWOqOe7uKEBTwNy8moy8NWzP7bUy9LKOrDYUMah3cP60JSiPVyrQYFJ320k0NN1u PAMXf1ziDP9r9VKWx/rdZUbev16k6TwAbqZijzjsbbAusjdlErqB364wP/TLu2fmC3Vt BobCD6vetyIx/bkR96Vn7Zq1E6j0pLb0QS6Zn8Lzu4pnkXbV5H6w5GyXDopSn3PC/Tdq DjZnjIyvpb+qOAMnthuTXRxedu8DN2y/36iErVuH/UdJBEaPFbBPSu+t3KmvdYQPiuRT f+qhHeHZZo2bptDGiD+DQjF9ujdOeGhGHVR/WfPCWzK1E8+3ITbCnIDMTdFX/VVNTSVJ g6wA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=DNyxJPUV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w27-20020a170906481b00b006e0003920e2si1788107ejq.642.2022.03.20.18.28.30; Sun, 20 Mar 2022 18:28:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=DNyxJPUV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238275AbiCRPq0 (ORCPT + 99 others); Fri, 18 Mar 2022 11:46:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234403AbiCRPqY (ORCPT ); Fri, 18 Mar 2022 11:46:24 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9154465E3 for ; Fri, 18 Mar 2022 08:45:05 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id a8so17800360ejc.8 for ; Fri, 18 Mar 2022 08:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iEoUOGNuvWutEIurlLjPrbp6aIbsgX9NoeRfOy5dLGk=; b=DNyxJPUVY3a3yXjwkgNmDeTZP28aOjJhD5zrO8oUQV22xMuvBRqBEhj1Hz6aw8f95K N8SWbRTkgRh550F17RVQonRKEUhmCMq485ad48SfTs5Wp7ZL0q3xCFzgnCOzNxwjcPyN jJJn8Dn3GnOsMI9itRww5SZHhy+ue+yoUXy6kGuBH6f/vGXHl+XElD/C/ZWF2YZOCyKk 3awiI+4OmS6AcWEVUMpZkPNQdaBX6jhechb1HE1LWI8p0rvC0gMQOmOrOcAmV+tmRQ1B 7bmzYgr0CGm5TQ4rOAAGpkGn5+pB/s5vNs7CJUqvYz/xOAesYKJ1weQh4wnHdbSbcK11 JArQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iEoUOGNuvWutEIurlLjPrbp6aIbsgX9NoeRfOy5dLGk=; b=sSymZXCrGgQUHKhf78y5JxnYt6m6ITpZA65bY0NBUyCf3GP53EIEeqt8FLpJ8RuxsZ mTRGk4yht1+zrvFAXtwURY/RJvXI+i5U2xiN4w/NZAyMIkMDCM7HIoArV3a4PscQTYyE BiuJMqSdSRNXvjLPF3y7iKcTZe2fFBVhJW01uS+SvTwB/ZAUiV6aFpxt9/WWt5KDHpqX MmW02oMbWIfNnKWO2ZkjNbuONRu8794pKbi4C3fd5A9/tvBec0QKPv9atmTzJVFfzH4F Io/12xK/hcQKIP89Oj2P4+0IpC/YSAGBh8j4cQoY/YYRJPA1tAwZpOmdj5C9L3kVN0IK TzAA== X-Gm-Message-State: AOAM530HTRgU9oC+/j+Y/quMZhjasNsQe4YyDWPrSe8EuFoglIfHYGrX JfojnQMQEiPR+COKE7zSRusxbFTOX6NfK//5L9NNIQ== X-Received: by 2002:a17:907:869f:b0:6da:888b:4258 with SMTP id qa31-20020a170907869f00b006da888b4258mr9648477ejc.720.1647618303898; Fri, 18 Mar 2022 08:45:03 -0700 (PDT) MIME-Version: 1.0 References: <20220317140115.541007-1-shraash@google.com> In-Reply-To: From: Guenter Roeck Date: Fri, 18 Mar 2022 08:44:52 -0700 Message-ID: Subject: Re: [PATCH] drm/amd/display: Fixed the unused-but-set-variable warning To: Paul Menzel Cc: Aashish Sharma , Harry Wentland , Leo Li , Rodrigo Siqueira , Alex Deucher , Pan Xinhui , David Airlie , Nicholas Kazlauskas , Meenakshikumar Somasundaram , Jake Wang , Anson Jacob , Guenter Roeck , linux-kernel , Maling list - DRI developers , amd-gfx list , Daniel Vetter , Wayne Lin , Anthony Koo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham 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 Hi Paul, On Thu, Mar 17, 2022 at 10:58 PM Paul Menzel wrote: > > Dear Aashish, > > > Am 17.03.22 um 15:01 schrieb Aashish Sharma: > > Thank you for your patch. If you are going to send a v2, please use > imperative mood. Maybe: > Uuh, sorry, I have to take the blame for that. I am guiding Aashish through the process of submitting patches upstream, and I completely missed that. > drm/amd/display: Fix unused-but-set-variable warning > > > > Fixed this kernel test robot warning: > > Maybe: > > Fix the kernel test robot warning below: > > > drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h:2893:12: > > warning: variable 'temp' set but not used [-Wunused-but-set-variable] > > > > Replaced the assignment to the unused temp variable with READ_ONCE() > > macro to flush the writes. > > Replace =E2=80=A6 > > Excuse my ignorance regarding `READ_ONCE()`, but is that the reason you > remove the volatile qualifier? > It is not the reason to remove volatile, it is to enable removing it. I had suggested using it, following its description " ... Ensuring that the compiler does not fold, spindle, or otherwise * mutilate accesses ... ", to avoid the use of volatile, and to make it obvious from the code that the read is intentional. My apologies if that is the wrong approach. A simpler solution would be to just remove the temp variable if that is preferred. > Some robots ask in their report to add a Found-by tag. If so, please add > one. I think that should be "Reported-by", or more specifically Reported-by: kernel test robot > > > Signed-off-by: Aashish Sharma > > --- > > drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h b/drivers/= gpu/drm/amd/display/dmub/inc/dmub_cmd.h > > index 873ecd04e01d..b7981a781701 100644 > > --- a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h > > +++ b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h > > @@ -2913,13 +2913,12 @@ static inline void dmub_rb_flush_pending(const = struct dmub_rb *rb) > > uint32_t wptr =3D rb->wrpt; > > > > while (rptr !=3D wptr) { > > - uint64_t volatile *data =3D (uint64_t volatile *)((uint8_= t *)(rb->base_address) + rptr); > > + uint64_t *data =3D (uint64_t volatile *)((uint8_t *)(rb->= base_address) + rptr); > > //uint64_t volatile *p =3D (uint64_t volatile *)data; > > - uint64_t temp; > > uint8_t i; > > > > for (i =3D 0; i < DMUB_RB_CMD_SIZE / sizeof(uint64_t); i+= +) > > - temp =3D *data++; > > + (void)READ_ONCE(*data++); > > Did you verify, that the generated code is the same now, or what the > differences are. If it=E2=80=99s different from before, you should docume= nt in > the commit message, that it=E2=80=99s wanted, as otherwise, it=E2=80=99s = an invasive > change just to fix a warning. > The generated code is exactly the same on x86. Thanks, Guenter > > rptr +=3D DMUB_RB_CMD_SIZE; > > if (rptr >=3D rb->capacity) > > > Kind regards, > > Paul