Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2854824pxp; Tue, 22 Mar 2022 07:18:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzO9n8lCRVcrug8KxRSfLgoUF6SgIOcH32qReLns+BH5oqVbUWURjLJqVGW4KdeSyJ2FLwc X-Received: by 2002:a05:6402:3553:b0:419:6552:11b7 with SMTP id f19-20020a056402355300b00419655211b7mr904947edd.286.1647958699807; Tue, 22 Mar 2022 07:18:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647958699; cv=none; d=google.com; s=arc-20160816; b=lIIlD9iEoT+rCE4Xu2XJhBZVHfxTytPJ/QPNkk7OY/MhSrSt9prE2a9xwiylzf7gFi yd40NAGb4cginYJTJpgYHJrx/XeqvTZoEfM0vGETI/zWlyiB/DMhrmTxr6wsFxscRJMz 4/BruAP2o32CW2N+D6p4WzDLjtPvREqLXdJIiEdTXbBTOO4kGVfXc4mqOGHQLbgiL/fk Ngqvpn7v1v1oAEh2xYi0CKzqtFWz2cmilKPoizO52sgX/etlLtKGxdxcAzJ18hsthJsG 68SqsRl5RUxeU5OEDT+RtLIaByCYUdvq7pIO4xvUitpxNoo9wafw+vJjJj0yKqrlBeO8 gHHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=4f2AtGe9H5nje/YXxk7I4GZP2QuJkhjRklQGoGlFW1E=; b=a8i8vHx4uFcF3RKPU7InD6nwboxKyVvSbFvxiarhpyOl4WtSn9OUjt3W8TAHdPN51S lkYSzWeEGw8gDZXrJ+mkpa9X30thVUuUIBzj/lSaDxBK17cL+Mj8yyyNDQoGQsarCjNP FgNJe+//oD+zc8Z8l5d4UqNn26SyJbJxevw3SfprwFTiBKQ8LJ9jKKeYVc+cwJHmGCQP jWMoCxTmPjZR/OZLOG18YonVKu7wWGFF4FyKgGofXq20VtaaJzoIa+1669YHbwKIIJLQ SPqAirN99clW5vbTq/qkzE0RODRkBmP7Ju1f8nWTHEtR7kz/1obWqPO/kXtMrsTeJv0C MG6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=j5C+iEKD; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ne3-20020a1709077b8300b006dffb2d6bdcsi6928225ejc.83.2022.03.22.07.17.54; Tue, 22 Mar 2022 07:18:19 -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=@linuxfoundation.org header.s=korg header.b=j5C+iEKD; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232750AbiCVLdK (ORCPT + 99 others); Tue, 22 Mar 2022 07:33:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234248AbiCVLdE (ORCPT ); Tue, 22 Mar 2022 07:33:04 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C110882D2C for ; Tue, 22 Mar 2022 04:31:37 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 2AD6B612F5 for ; Tue, 22 Mar 2022 11:31:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27358C340F0; Tue, 22 Mar 2022 11:31:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647948696; bh=Q803Ahh2mXBrXYeT2gzMvlXoFBqdS/QQwfKfuZr72KE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=j5C+iEKDhFncKyOkwb+7ZLqwnyfRKMuB/qf++cLRjNkSe1LI4aUDhEpKLMdiSSnqt bAOT/Xtxhe3i5Ae0hDn1jDLEW2RwcUuX5+Kqq0hVaS5rg8ojii9VkYsxTQlS/iv9R5 rCD+qeLYUqng7rUXGu6WToL6doPELz0+V8fxgbYA= Date: Tue, 22 Mar 2022 12:31:32 +0100 From: Greg KH To: "Fabio M. De Francesco" Cc: Sathish Kumar , Larry.Finger@lwfinger.net, florian.c.schilhabel@googlemail.com, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] staging: rtl8712: Fix CamelCase warnings Message-ID: References: <20220318101440.13887-1-skumark1902@gmail.com> <3a85ae64-00c1-6483-f1d7-c12abdd3ff3a@gmail.com> <1786742.atdPhlSkOF@leap> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1786742.atdPhlSkOF@leap> X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 On Tue, Mar 22, 2022 at 11:42:21AM +0100, Fabio M. De Francesco wrote: > On marted? 22 marzo 2022 05:30:29 CET Sathish Kumar wrote: > > On 18/03/22 4:58 pm, Greg KH wrote: > > > On Fri, Mar 18, 2022 at 03:44:40PM +0530, Sathish Kumar wrote: > > >> This patch fixes the checkpatch.pl warnings like: > > >> CHECK: Avoid CamelCase: > > >> + u8 blnEnableRxFF0Filter; > > >> > > >> Signed-off-by: Sathish Kumar > > >> --- > > >> Changes in v2: > > >> - Remove the "bln" prefix > > >> --- > > >> drivers/staging/rtl8712/drv_types.h | 2 +- > > >> drivers/staging/rtl8712/rtl871x_cmd.c | 2 +- > > >> drivers/staging/rtl8712/xmit_linux.c | 4 ++-- > > >> 3 files changed, 4 insertions(+), 4 deletions(-) > > >> > > >> [...] > > >> > > >> do { > > >> msleep(100); > > >> - } while (adapter->blnEnableRxFF0Filter == 1); > > >> + } while (adapter->enable_rx_ff0_filter == 1); > > > Ah, that's funny. It's amazing it works at all and that the compiler > > > doesn't optimize this away. This isn't a good pattern to use in kernel > > Do you mean the following code is not a good pattern in kernel? > > do { > > msleep(); > > } while(condition); > > Exactly, this is not a pattern that works as you expect :) > > I was waiting for Greg to detail something more about this subject but, > since it looks like he has no time yet to respond, I'll try to interpret > his words. > > (@Greg, please forgive me if I saying something different from what you > intended to convey :)). > > The reason why this pattern does not work as expected is too long to be > explained here. However, I think that Greg is suggesting to you to research > and use what are called "Condition variables". Kind of. The problem is that "condition" here is just looking at a random variable. There is no sort of assurance that the variable will actually change or that that compiler even has to read from memory for it. It could cache the value the first time it is read and then never update it for the whole loop logic. Please read Documentation/memory-barriers.txt for how to fix this all up and do it properly. Again, it's amazing that the current code even works at all. So maybe it doesn't! :) thansks, greg k-h