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=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 5FA68C6369E for ; Thu, 19 Nov 2020 16:36:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 118D1241A6 for ; Thu, 19 Nov 2020 16:36:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LGJcQBr5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727369AbgKSQf6 (ORCPT ); Thu, 19 Nov 2020 11:35:58 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:55168 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728537AbgKSQfz (ORCPT ); Thu, 19 Nov 2020 11:35:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605803753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rmz4vMCo9cJbvNaKXKHUnIBAy5VUu+3pBNzGePwX/CQ=; b=LGJcQBr5v4/qtQY4U20Y3P1ZzzIIcmQAvmcArL7LT3uiqZN3xX3TnZkT04DCNyZZky7vhr kEpWlxATej7TV53dtKKBvKtVvGJGA9JN+nDF/KKJk3lopuV67cXZ+r73FRG9zHqxP2pThZ xuNJEkf7/yp3RmIIZxp28ZhWetj7pqc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-361-5cgFMGosMYiOELAYXE56dw-1; Thu, 19 Nov 2020 11:35:48 -0500 X-MC-Unique: 5cgFMGosMYiOELAYXE56dw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A21D91005D5F; Thu, 19 Nov 2020 16:35:44 +0000 (UTC) Received: from carbon (unknown [10.36.110.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8BD6B60636; Thu, 19 Nov 2020 16:35:36 +0000 (UTC) Date: Thu, 19 Nov 2020 17:35:35 +0100 From: Jesper Dangaard Brouer To: Jakub Kicinski , Joe Perches Cc: brouer@redhat.com, Guenter Roeck , Tao Ren , Andrew Lunn , Jean Delvare , Jonathan Corbet , Alexei Starovoitov , Daniel Borkmann , "David S . Miller" , Jesper Dangaard Brouer , John Fastabend , linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, openbmc@lists.ozlabs.org, taoren@fb.com, mikechoi@fb.com Subject: XDP maintainer match (Was [PATCH v2 0/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring) Message-ID: <20201119173535.1474743d@carbon> In-Reply-To: <20201119074634.2e9cb21b@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> References: <20201118230929.18147-1-rentao.bupt@gmail.com> <20201118232719.GI1853236@lunn.ch> <20201118234252.GA18681@taoren-ubuntu-R90MNF91> <20201119010119.GA248686@roeck-us.net> <20201119012653.GA249502@roeck-us.net> <20201119074634.2e9cb21b@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, 19 Nov 2020 07:46:34 -0800 Jakub Kicinski wrote: > On Wed, 18 Nov 2020 17:26:53 -0800 Guenter Roeck wrote: > > On Wed, Nov 18, 2020 at 05:01:19PM -0800, Guenter Roeck wrote: > > > On Wed, Nov 18, 2020 at 03:42:53PM -0800, Tao Ren wrote: > > > > On Thu, Nov 19, 2020 at 12:27:19AM +0100, Andrew Lunn wrote: > > > > > On Wed, Nov 18, 2020 at 03:09:27PM -0800, rentao.bupt@gmail.com wrote: > > > > > > From: Tao Ren > > > > > > > > > > > > The patch series adds hardware monitoring driver for the Maxim MAX127 > > > > > > chip. > > > > > > > > > > Hi Tao > > > > > > > > > > Why are using sending a hwmon driver to the networking mailing list? > > > > > > > > > > Andrew > > > > > > > > Hi Andrew, > > > > > > > > I added netdev because the mailing list is included in "get_maintainer.pl > > > > Documentation/hwmon/index.rst" output. Is it the right command to find > > > > reviewers? Could you please suggest? Thank you. > > > > > > I have no idea why running get_maintainer.pl on > > > Documentation/hwmon/index.rst returns such a large list of mailing > > > lists and people. For some reason it includes everyone in the XDP > > > maintainer list. If anyone has an idea how that happens, please > > > let me know - we'll want to get this fixed to avoid the same problem > > > in the future. > > > > I found it. The XDP maintainer entry has: > > > > K: xdp > > > > This matches Documentation/hwmon/index.rst. > > > > $ grep xdp Documentation/hwmon/index.rst > > xdpe12284 > > > > It seems to me that a context match such as "xdp" in MAINTAINERS isn't > > really appropriate. "xdp" matches a total of 348 files in the kernel. > > The large majority of those is not XDP related. The maintainers > > of XDP (and all the listed mailing lists) should not be surprised > > to get a large number of odd review requests if they want to review > > every single patch on files which include the term "xdp". > > Agreed, we should fix this. For maintainers with high patch volume life > would be so much easier if people CCed the right folks to get reviews, > so we should try our best to fix get_maintainer. > > XDP folks, any opposition to changing the keyword / filename to: > > [^a-z0-9]xdp[^a-z0-9] > > ? I think it is a good idea to change the keyword (K:), but I'm not sure this catch what we want, maybe it does. The pattern match are meant to catch drivers containing XDP related bits. Previously Joe Perches suggested this pattern match, which I don't fully understand... could you explain Joe? (?:\b|_)xdp(?:\b|_) For the filename (N:) regex match, I'm considering if we should remove it and list more files explicitly. I think normal glob * pattern works, which should be sufficient. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer 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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 7C42FC5519F for ; Fri, 20 Nov 2020 05:47:03 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8C40A22226 for ; Fri, 20 Nov 2020 05:47:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LGJcQBr5"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LGJcQBr5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C40A22226 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4CcltD2NYFzDqws for ; Fri, 20 Nov 2020 16:47:00 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=216.205.24.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=brouer@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=LGJcQBr5; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=LGJcQBr5; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4CcQKb4ZX3zDqkq for ; Fri, 20 Nov 2020 03:35:56 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605803753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rmz4vMCo9cJbvNaKXKHUnIBAy5VUu+3pBNzGePwX/CQ=; b=LGJcQBr5v4/qtQY4U20Y3P1ZzzIIcmQAvmcArL7LT3uiqZN3xX3TnZkT04DCNyZZky7vhr kEpWlxATej7TV53dtKKBvKtVvGJGA9JN+nDF/KKJk3lopuV67cXZ+r73FRG9zHqxP2pThZ xuNJEkf7/yp3RmIIZxp28ZhWetj7pqc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605803753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rmz4vMCo9cJbvNaKXKHUnIBAy5VUu+3pBNzGePwX/CQ=; b=LGJcQBr5v4/qtQY4U20Y3P1ZzzIIcmQAvmcArL7LT3uiqZN3xX3TnZkT04DCNyZZky7vhr kEpWlxATej7TV53dtKKBvKtVvGJGA9JN+nDF/KKJk3lopuV67cXZ+r73FRG9zHqxP2pThZ xuNJEkf7/yp3RmIIZxp28ZhWetj7pqc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-361-5cgFMGosMYiOELAYXE56dw-1; Thu, 19 Nov 2020 11:35:48 -0500 X-MC-Unique: 5cgFMGosMYiOELAYXE56dw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A21D91005D5F; Thu, 19 Nov 2020 16:35:44 +0000 (UTC) Received: from carbon (unknown [10.36.110.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8BD6B60636; Thu, 19 Nov 2020 16:35:36 +0000 (UTC) Date: Thu, 19 Nov 2020 17:35:35 +0100 From: Jesper Dangaard Brouer To: Jakub Kicinski , Joe Perches Subject: XDP maintainer match (Was [PATCH v2 0/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring) Message-ID: <20201119173535.1474743d@carbon> In-Reply-To: <20201119074634.2e9cb21b@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> References: <20201118230929.18147-1-rentao.bupt@gmail.com> <20201118232719.GI1853236@lunn.ch> <20201118234252.GA18681@taoren-ubuntu-R90MNF91> <20201119010119.GA248686@roeck-us.net> <20201119012653.GA249502@roeck-us.net> <20201119074634.2e9cb21b@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mailman-Approved-At: Fri, 20 Nov 2020 16:41:21 +1100 X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-hwmon@vger.kernel.org, Andrew Lunn , Jean Delvare , Jesper Dangaard Brouer , Daniel Borkmann , Jonathan Corbet , netdev@vger.kernel.org, openbmc@lists.ozlabs.org, linux-doc@vger.kernel.org, John Fastabend , Alexei Starovoitov , linux-kernel@vger.kernel.org, taoren@fb.com, brouer@redhat.com, Tao Ren , bpf@vger.kernel.org, mikechoi@fb.com, "David S . Miller" , Guenter Roeck Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" On Thu, 19 Nov 2020 07:46:34 -0800 Jakub Kicinski wrote: > On Wed, 18 Nov 2020 17:26:53 -0800 Guenter Roeck wrote: > > On Wed, Nov 18, 2020 at 05:01:19PM -0800, Guenter Roeck wrote: > > > On Wed, Nov 18, 2020 at 03:42:53PM -0800, Tao Ren wrote: > > > > On Thu, Nov 19, 2020 at 12:27:19AM +0100, Andrew Lunn wrote: > > > > > On Wed, Nov 18, 2020 at 03:09:27PM -0800, rentao.bupt@gmail.com wrote: > > > > > > From: Tao Ren > > > > > > > > > > > > The patch series adds hardware monitoring driver for the Maxim MAX127 > > > > > > chip. > > > > > > > > > > Hi Tao > > > > > > > > > > Why are using sending a hwmon driver to the networking mailing list? > > > > > > > > > > Andrew > > > > > > > > Hi Andrew, > > > > > > > > I added netdev because the mailing list is included in "get_maintainer.pl > > > > Documentation/hwmon/index.rst" output. Is it the right command to find > > > > reviewers? Could you please suggest? Thank you. > > > > > > I have no idea why running get_maintainer.pl on > > > Documentation/hwmon/index.rst returns such a large list of mailing > > > lists and people. For some reason it includes everyone in the XDP > > > maintainer list. If anyone has an idea how that happens, please > > > let me know - we'll want to get this fixed to avoid the same problem > > > in the future. > > > > I found it. The XDP maintainer entry has: > > > > K: xdp > > > > This matches Documentation/hwmon/index.rst. > > > > $ grep xdp Documentation/hwmon/index.rst > > xdpe12284 > > > > It seems to me that a context match such as "xdp" in MAINTAINERS isn't > > really appropriate. "xdp" matches a total of 348 files in the kernel. > > The large majority of those is not XDP related. The maintainers > > of XDP (and all the listed mailing lists) should not be surprised > > to get a large number of odd review requests if they want to review > > every single patch on files which include the term "xdp". > > Agreed, we should fix this. For maintainers with high patch volume life > would be so much easier if people CCed the right folks to get reviews, > so we should try our best to fix get_maintainer. > > XDP folks, any opposition to changing the keyword / filename to: > > [^a-z0-9]xdp[^a-z0-9] > > ? I think it is a good idea to change the keyword (K:), but I'm not sure this catch what we want, maybe it does. The pattern match are meant to catch drivers containing XDP related bits. Previously Joe Perches suggested this pattern match, which I don't fully understand... could you explain Joe? (?:\b|_)xdp(?:\b|_) For the filename (N:) regex match, I'm considering if we should remove it and list more files explicitly. I think normal glob * pattern works, which should be sufficient. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer