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 shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 403A4C433F5 for ; Wed, 9 Feb 2022 16:37:02 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1nHpxQ-0005R5-92; Wed, 09 Feb 2022 11:36:40 -0500 Received: from mail-qv1-xf33.google.com ([2607:f8b0:4864:20::f33]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nHpxO-0005Qk-6v for kernelnewbies@kernelnewbies.org; Wed, 09 Feb 2022 11:36:38 -0500 Received: by mail-qv1-xf33.google.com with SMTP id o5so2246614qvm.3 for ; Wed, 09 Feb 2022 08:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vt-edu.20210112.gappssmtp.com; s=20210112; h=sender:from:to:cc:subject:in-reply-to:references:mime-version:date :message-id; bh=ERrbFqTA7mn2Fg7iV+B2pa4dLLVFBFrbDFrROgM81P8=; b=8Wsb+PncUDdaYy7OvEUrkbTXKaK0sPcU1euWka2qb6zX1kvUFH+gI9h3objAmlDpuZ IyG0aqeCj39J7C6vLtYfkSwAZjjrhc7L73a/sD4xEllcc5GpFPSfj3Hgz/fAOxWqU62+ EzFXWDVVC1Voi8vJsop3nieVV/ZQLAEX4hFHuPpj6GimiDJ4OI+rb6HhZWQdTT/dPhxt P05Ufm8mKiea8iM2sRy1+A6Pp3mu0oGB4pYFl72GaHUL3njHKtAOHBpfhi+s7++uQYNM ZmUCtb+REj4ResTVrTXZcc6AoGhrS5SveTtFR/37bk7IKeZhsJPZjj50p76H9vRNFl8g bviA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:date:message-id; bh=ERrbFqTA7mn2Fg7iV+B2pa4dLLVFBFrbDFrROgM81P8=; b=N16jeVQ2LV+/rRRsfwIcgpSlXvfQneqd6UjRAKyO2EjwSMUmpMfxGgqYoxvhcPn0bG Nk+dRppZWOp84sQXWjNbqRjJMBQN+0DYNcWsAsdfmViIALPTLDgdxGcdzP75cnGMvOKN 7cm1lnPGed3tRspB6gAx44A8WB19IaMKrumftCcvTUH5nDSFoRumOJov0QAQAYEAnlXJ RB9JCf+4batthp0goxmQMl+NLGQD5L3RD01vYbbsHPKLGTD7vNyvHkoNca7nBxxz+Avk mZJpFncu5RJWla7QPEPANnkln5ZIXj8H/yIEaOCfj99ZyQ9sGdDWaOIiLydoZDW1CE/v 6e+g== X-Gm-Message-State: AOAM530AyotQJdWwEJeCvKjlDm6prKAfunqL8oiu9D7sTipxELgMJJUp N6uy5Ow10j4eKSoeFvMMpgCmHw== X-Google-Smtp-Source: ABdhPJyNuElwCYaoNpz41ez9+OTE6TNe9eFfQeE2gKfyYtJhOQygQ7jA06RvOFIbB0rectKw/muAwg== X-Received: by 2002:ad4:5dc4:: with SMTP id m4mr2130816qvh.17.1644424595849; Wed, 09 Feb 2022 08:36:35 -0800 (PST) Received: from turing-police ([2601:5c0:c380:d61::359]) by smtp.gmail.com with ESMTPSA id 18sm8534764qka.126.2022.02.09.08.36.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 08:36:35 -0800 (PST) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.10.0-pre 07/05/2021 with nmh-1.7+dev To: Ankit Pandey Subject: Re: Fwd: Need guidance regarding fixing styleguide error in rtl871x_pwrctrl.h In-reply-to: References: Mime-Version: 1.0 Date: Wed, 09 Feb 2022 11:36:34 -0500 Message-ID: <76570.1644424594@turing-police> Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Tue, 08 Feb 2022 23:26:54 +0530, Ankit Pandey said: > And I was asked to verify if there is some specific meaning is attached to > comment here (which was causing the issue). > I would be glad you could explain me how should I approach this issue? One > way would > be to rewrite that these variables could be defined as volatile (just add a > comment) and then compile driver and see that build goes through without > any error. It turns out that the C keyword 'volatile' usually doesn't actually do what needs to happen if a variable actually *is* volatile and subject to change while the executing thread isn't looking. There's a good documentation file on this: Documentation/process/volatile-considered-harmful.rst But in summary - "If you thought you needed 'volatile' in your code, you probably needed locking primitives instead". > Other way would be that try to understand what this function is supposed to > be doing and then figure out author's intent of putting volatile there. How > should I take decision on these (or if they are wrong approaches) ? Given that struct pwrctlr_priv already contains a mutex_lock, what was probably *intended* was "the variables cpwm, tog, cpwm_tog, and tgt_rpwm are protected by the mutex_lock and may only be changed by the mutex holder, while pwr_mode, smart_ps, and alives are not subject to change on the fly". But actually reading and understanding the code would be required to verify that. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies