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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91BF2C433DB for ; Wed, 10 Feb 2021 18:04:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 655B164DB1 for ; Wed, 10 Feb 2021 18:04:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232367AbhBJSD7 (ORCPT ); Wed, 10 Feb 2021 13:03:59 -0500 Received: from mail.baikalelectronics.com ([87.245.175.226]:34978 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233493AbhBJSBG (ORCPT ); Wed, 10 Feb 2021 13:01:06 -0500 Date: Wed, 10 Feb 2021 21:00:07 +0300 From: Serge Semin To: Andrew Lunn CC: Serge Semin , Rob Herring , Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S. Miller" , Jakub Kicinski , Alexey Malahov , Pavel Parkhomenko , Vyacheslav Mitrofanov , Maxime Coquelin , , , , , Subject: Re: [PATCH 00/16] net: stmmac: Add DW MAC GPIOs and Baikal-T1 GMAC support Message-ID: <20210210180007.tjuvbjw7rpmxhsll@mobilestation> References: <20210208140820.10410-1-Sergey.Semin@baikalelectronics.ru> <20210209111609.tjxoqr6stkcf22jy@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Feb 09, 2021 at 03:11:41PM +0100, Andrew Lunn wrote: > > Regarding splitting the series up. I don't see a problem in just > > sending the cover-letter patch and actual GPIO-related patches to > > the GPIO-maintainers with no need to have them added to Cc in the rest > > of the series. > > The Linux community has to handle a large number of patches. I don't > particularly want patches which are of no relevance to me landing in > my mailbox. It might take 4 or 5 rounds for the preparation patches to > be accepted. That is 4 or 5 times you are spamming the GPIO > maintainers with stuff which is not relevant to them. I don't really understand what you are arguing with. My suggestion didn't contradict to what you said. I exactly meant to omit sending the patches to GPIO maintainers, which they had no relevance to. So they wouldn't be spammed with unwanted patches. The GPIO maintainers can be Cc/To-ed only to the messages with GPIO-related patches. It's normal to have intermixed patchsets, but to post individual patches to the maintainers they might be interested in or they need to review. So splitting up isn't required in this case. Moreover doing as you suggest would extend the time of the patches review with no really much gain in the emailing activity optimization. > > One of the unfortunately things about the kernel process is, there are > a lot of developers, and not many maintainers. So the processes need > to make the life of maintainers easier, and not spamming them helps. Can't argue with that.) -Sergey > > Andrew