Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp2054362pxf; Sat, 3 Apr 2021 09:18:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztdH4w+3hsPdtQQ4ywS9Cf3lOEsFkWOUVfNa6cVB0WRVl0pW6pkIZRxe70On0GkvZcDNLc X-Received: by 2002:a05:6e02:eaf:: with SMTP id u15mr13634963ilj.45.1617466694493; Sat, 03 Apr 2021 09:18:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617466694; cv=none; d=google.com; s=arc-20160816; b=mp2isv9FfMJ/nn28XapViN0Mxzx3zDLyYfdBam14E6tmBS0Avt9RMaj+9R4Q6x2WHc wOxA+M0i22jYref/6JTOEItSz+WbKtjxGlHvUf3Gw+13kTJ0JKXehJ9z2JUQMv/qMc3Z IeVbYQdEI2FrdPhzm5+bj/Ikapyt6o2xQaHtEk6B4AVtlEqUL1YRsjdo0fv00XCD1gjR bJdoiuKufpAx9M3eja+3IPHQsJP+g6FsbXIbVLlA0WZeBlFgABNrNhHXwaqtr0BL8LaY NaLXQ+Fy638HKHBubG3fytU7Lzv9ZMgCnhJ8JJN6Ln0zxgvD42HUxYJmY9Y9O/jUBF9T EhDg== 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=CWWEeMqwJdH02D7dJJ+UG0pTjR7PHQwtWq0TlcSJtDE=; b=Oxwr6aVr5GLgdkVtr+W7sK5d1+gorYfVVIiwc0Gc3ZktPi5p7JySxTvJ+b5FEnQRaI 3Z56g4zcS2aPsBASa7fNbbXMgXnX88qvo3ZgKIpBMtNtwyNU6hZel15vOpwUfy3qWueZ SS8EVDGFtUXSqsJw98X5huW4PCODU+KXXH/X33eK4MQeWUOXAvb+Rwk9m6JjBu9s9uJ8 +b8O+FxTGPDUy5hWGPjP4eTMy5JXkCK6SIwN8CFrd9DM0vYJdXtNKl6VrnWsSkMAHVzD tK5HTJmvml041btTAy67dfQhFH0WFLreLHFD7i0DaXXljikL/wW60b2WZ6kN9q3jMLlE X5IQ== 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 z23si10819968iod.32.2021.04.03.09.17.58; Sat, 03 Apr 2021 09:18:14 -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 S236792AbhDCQRo (ORCPT + 99 others); Sat, 3 Apr 2021 12:17:44 -0400 Received: from smtprelay0055.hostedemail.com ([216.40.44.55]:36610 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S230450AbhDCQRn (ORCPT ); Sat, 3 Apr 2021 12:17:43 -0400 Received: from omf18.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id E4E811843912D; Sat, 3 Apr 2021 16:17:39 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf18.hostedemail.com (Postfix) with ESMTPA id F0E622EBFA4; Sat, 3 Apr 2021 16:17:38 +0000 (UTC) Message-ID: <7120836b08b680d54c15fd89b8630ccc67a53116.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 09:17:37 -0700 In-Reply-To: <20210403152143.GA1403@agape.jhs> References: <1cd79d781cdcccf621ce8e104a9cdf1e90e7f803.camel@perches.com> <20210403152143.GA1403@agape.jhs> 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-Rspamd-Server: rspamout02 X-Stat-Signature: cb67t64hhuz36xmx6sthh6axymjb9wwg X-Rspamd-Queue-Id: F0E622EBFA4 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX1/d0bwAguyxvRO74mFrz/saWwALiEImrkc= X-HE-Tag: 1617466658-753426 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2021-04-03 at 17:21 +0200, Fabio Aiuto wrote: > On Sat, Apr 03, 2021 at 08:02:25AM -0700, Joe Perches wrote: > > 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 > > Hi, > > I was just about to send the second patchset relative to hal/ files. > The whole has been split up in directories in order to reduce the > number of patch per patchset > It's a good idea, but the patches relative to RT_TRACE removal > could be huge That's really not a significant issue. Simplicity in review is also important. Mechanization of patch creation can reduce review efforts. Few people are actively working on this particular codebase. As far as I can tell no logical defect is being corrected here. None of this is likely to be backported. Applying each individual patch has a 'cost' in maintainer time and review effort. Fewer patches create lower overall costs. Good luck...