Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp2014033pxf; Sat, 3 Apr 2021 08:03:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/+yBcn8jliNHmI6O9iJWJ+utpmoLECIM36z4xLygoEvrL2P1Umys0lGJuiAxOAKzKzDwk X-Received: by 2002:a5d:9682:: with SMTP id m2mr14795310ion.20.1617462182905; Sat, 03 Apr 2021 08:03:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617462182; cv=none; d=google.com; s=arc-20160816; b=wtMSIDhgrFZm3A+t8l4lkXSyRzKKKcLdn8b+0WXkpz4Qzt3gbKDlxc+cJQyEJTla2+ fV/CLMT0wXzGJftlAHjB755ZfKqgyKzlgeLB+8aUVpvZrNGPvONGnaoR7aQ6XQrozMvP 7aV/cibxZC9lS/33CuqU1Q+9kTlhIAG45aNhdXkF16GW8PzDdmpk1yHxwjN9LvgXplwI Wx3ANfp5RwyCSmxEywOE9h4q/CLCTq7MyfncSzGHHVemZqnC8rUHLdOznWoB/GrYPXOg OzlH92eDwadZNDT/MxE5K2FClEH5KCSTQShvjyJWdgriX3x4Xf9oOv4XS966711l21ZQ Dmaw== 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:date:cc:to:from:subject :message-id; bh=mcxPZGcL9OS8SeXcgMFMaYJYc/VdPhzYzjI2ZJRuXR0=; b=Fpq63gUaGmSFf2Xgr3p8RT/pC6OG+nX1G+zuT29LKFxriBIzlaCGm61RikPsq39FEM H/yIVcw5eVv16AxyrHAuV+on15hqUwQ3wOIrYuMaVtFVzSkBvoGawoDDMYFfS3ogLXdP HvfGkuOIsm/v1PgajOf+NMyXlaxj1w/CMVCpRYDxyJHtNj10l/ScfQbnqmrfkCZjbI1T kR4laSCnZZD5lpul+KheX8kw7EvYJrTF5FUYlHvQTvtQFlTeHmayTP0hyGD3K7Chan9S hjkgF9uEWBCPm6Ue9PmUcw4VnZWuqed6LjuL1W1J2uyHPIVkpCpydS8GiYB5127ZhfTM SYOA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r11si10961638ill.77.2021.04.03.08.02.48; Sat, 03 Apr 2021 08:03:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236459AbhDCPCe (ORCPT + 99 others); Sat, 3 Apr 2021 11:02:34 -0400 Received: from smtprelay0195.hostedemail.com ([216.40.44.195]:54202 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S231821AbhDCPCd (ORCPT ); Sat, 3 Apr 2021 11:02:33 -0400 Received: from omf19.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id EEBBB184558E0; Sat, 3 Apr 2021 15:02:27 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf19.hostedemail.com (Postfix) with ESMTPA id 0F57520D756; Sat, 3 Apr 2021 15:02:26 +0000 (UTC) Message-ID: <1cd79d781cdcccf621ce8e104a9cdf1e90e7f803.camel@perches.com> Subject: Re: [PATCH v3 00/30] staging: rtl8723bs: remove RT_TRACE logs in core/* From: Joe Perches To: Fabio Aiuto , gregkh@linuxfoundation.org Cc: dan.carpenter@oracle.com, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Date: Sat, 03 Apr 2021 08:02:25 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.10 X-Stat-Signature: f8y8xwjzigh8njpx8b1i1a3yycqrrokd X-Rspamd-Server: rspamout05 X-Rspamd-Queue-Id: 0F57520D756 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX1/4QJLtXCTzaD3/uBcvaBOi2jxvHRsyFM4= X-HE-Tag: 1617462146-363510 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2021-04-03 at 11:13 +0200, Fabio Aiuto wrote: > This patchset removes all RT_TRACE usages in core/ files. and hal and include and os_dep > > This is the first of a series aimed at removing RT_TRACE macro. > > The whole private tracing system is not tied to a configuration > symbol and the default behaviour is _trace nothing_. It's verbose > and relies on a private log level tracing doomed to be > removed. It's nice, but individual patches per file done by hand are difficult to review because you are interleaving removal patches with cleanup patches. I believe this should be a patch series with a single patch to remove all RT_TRACE macro uses using coccinelle and then use separate patches to do whatever cleanups around these removals you want to do. All of these below should be done for all files in drivers/staging/rtl8723bs at once instead of submitting per-file patches. IMO something like: Cover-letter: Explain why you are doing this Patch 1 of N: Remove all RT_TRACE macro uses using a coccinelle script and include the coccinelle script in the commit message Patch 2 of N: Remove commented out RT_TRACE uses Patch 3 of N: Remove RT_TRACE macro definition Patch 4 of N: Cleanup coccinelle generated {} uses, if/else braces and the now unnecessary if tests around the RT_TRACE removals Patch 5 of N: Cleanup whitespace Patcn x of N: Whatever else related to these RT_TRACE sites... https://lore.kernel.org/lkml/c845d8ea7d0d8e7a613471edb53d780d660142a9.camel@perches.com/ Using a sequence like the above would be much easier to review and would be a significant shorter patch set.