Received: by 2002:ab2:710b:0:b0:1ef:a325:1205 with SMTP id z11csp558055lql; Mon, 11 Mar 2024 10:14:34 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCV4ebc3/KtJiUAfHhpkRH4bzmmR8+uV4SPDVvt+wAYuXtQ+6QhhEApBfgmG80QamV5rN8SNx93hQApeNauJQxUbGMbzpZqjaJWPcg/IFg== X-Google-Smtp-Source: AGHT+IEN7HeKIlu2b1VeZZkfZ2JeOiGq6TbnoIC2nnkqMfUYd/Sn3RjleJ20ZE7V5zLzlqsCMZnp X-Received: by 2002:a05:620a:372a:b0:787:4148:f6e3 with SMTP id de42-20020a05620a372a00b007874148f6e3mr12947932qkb.37.1710177273949; Mon, 11 Mar 2024 10:14:33 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1710177273; cv=pass; d=google.com; s=arc-20160816; b=skEkXOZ2hHPR7sXJoel3hN3chWeSSQR33dqQlkypwPFz4dY/Gl3YfOm+zEePEKwoYX VYiNo3juf1RZNAzMwV1u4AG/UUs3JLpvCHuGpELOyzxqI/ttJXxAqFLahQXLtrBZUN6u lBxn/b4GMdAsXpOfpuyUQ2UD5nNmgeXUCkwQFucpFtdD++m8eysKs8zqSgtLtRSMNws5 cCr44760nXSiIRRtP59oki6t/fIVy8UG5So4cc9POREwCoYk3yynFdkvmxmziB9pSEWH pgLg/YkXP6qGNAkpbJX35gmetHJNib73r1xelSPrQXeXn9cRildySBltQ9AyGekhdj7l pMZA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=P2GR4uOWRvV9LUa2om+IBcMx165Eh7xWd2ADdHcPVwc=; fh=OvTzxGe87ucHs8KNllGQh4dn+t9icYmTRSs2O6CqYKY=; b=H2feAutXc7L7kNvutQ+5EhyR4sLEtQ5JkbWHVK7S/bQ9GJcAxYIWOFH7PYM6vuRZOG itXcgx/BiczaAZ2KpUGdkz27S061wq3Y32oV3//IvO3mESzJuIa95fwOxWQcGmpFMk0n O5Av4Ll9EexCjHhJ/xGAH71k9K6Fb8TCKp7qAlHM/sV7JB0etI0xFpERjOAU/1uYYtN2 wY9xnn/TcK4ktew3mark4D3mOr6wGdvRe8iFLkri+XU/AgpjOJZsSR6GodgoAD1N8ZoE dVfpZPOPcVUFJoorDGmTtrnWtHfDmdivIR5iJkg50SUiL+dfwwTGwM5LH2h8dlgq+Vr1 xeeA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CZRm1iAL; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-99296-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-99296-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id f22-20020a05620a409600b007880180f408si6413480qko.354.2024.03.11.10.14.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Mar 2024 10:14:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-99296-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CZRm1iAL; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-99296-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-99296-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 98A161C219CB for ; Mon, 11 Mar 2024 17:14:33 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BA6694D108; Mon, 11 Mar 2024 17:14:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CZRm1iAL" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4DA04AEE6; Mon, 11 Mar 2024 17:14:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710177264; cv=none; b=Mwil8vCH3pMOpXp4SmE1ssvFTg7lnVtiPeye6YFNC3L/TwQiVwMiD+gXz0+4ch5fibSRp4YeudIpch3byJcm8jz3HGtQ6FCQFsMaasT5pFeBlyP8HTc1ViwTDIvIXyRfV1ouiWX3jumSPTYH6O6xWSMi6irrGL4isOEEIybhY8c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710177264; c=relaxed/simple; bh=t3vnkmWShAx/8G71252L599Ej7yx1121Mw9K2xlBgIQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=U6zwn5Tr/VLRCu0pBfIWSwokivzYH9LxsxVSHYs15gyYH6rGknuyEQuh3VmCFCXUCyJNc30cE9EIhpF5Li5IBGo4cH4kNTzU/UZMI6ponQn4n1u0z1D8zDQ1WyJ6AzDPwKmS83tPnEWMpKKuRGl9EQdIHrhrv4m3eFO+dHB2eWg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CZRm1iAL; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 386FFC433F1; Mon, 11 Mar 2024 17:14:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1710177263; bh=t3vnkmWShAx/8G71252L599Ej7yx1121Mw9K2xlBgIQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CZRm1iALCVUbGpzHr/TrYAFHOvdjAhlOux8+FJioVXZ6WWxMaghRBZL3oxAxgOhX8 Qy5K+8D0AST8m2f+E02ntTM/vNB8QS2PVGvz++ehiSIe6n+7LwJyjSUs8xDlQIgVke A0DUHgyQOC9qy9cZF43sJFlwhmWwiah2v7hozV3GVpOqdHPlNFYGT/qvXgXL5GaQ28 Hs3PnkXTNl6mYdCgxnCRDQ/13SjBAs5P2zi6cMDNm9NOa5qVFQLLVs7YYFlAODWKfm ztc+nspXu+qDHw0vvzk7VccrUsxlBJt2tYPb5zUn6Ul9vCkbgW4oDy7G/uFLfz3CNA I9n1pqLybpZxg== Date: Mon, 11 Mar 2024 10:14:22 -0700 From: Jakub Kicinski To: Krzysztof Kozlowski Cc: Simon Horman , Luiz Angelo Daros de Luca , Linus Walleij , Alvin =?UTF-8?B?xaBpcHJhZ2E=?= , Andrew Lunn , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 2/4] net: dsa: realtek: keep default LED state in rtl8366rb Message-ID: <20240311101422.2f48360e@kernel.org> In-Reply-To: <82d38961-8792-49ea-8c9c-5214669e0ef6@kernel.org> References: <20240310-realtek-led-v1-0-4d9813ce938e@gmail.com> <20240310-realtek-led-v1-2-4d9813ce938e@gmail.com> <388b435f-13c5-446f-b265-6da98ccfd313@kernel.org> <20240310113738.GA1623@kernel.org> <09793a72-bfe5-4cb5-a6da-ffee565e6956@kernel.org> <20240311091111.53191e08@kernel.org> <82d38961-8792-49ea-8c9c-5214669e0ef6@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 11 Mar 2024 17:19:59 +0100 Krzysztof Kozlowski wrote: > No, it does not reset the version number, because RFC->PATCH does not > mean that suddenly there were no reviews or changes. We all count in > brains from 1, so whatever we see - RFC, RFT, RFkisses or hugs - is the > first version we see. Then next one, whatever it is called PATCH, > RF-non-comments, RFmorekisses, is v2. I'm describing what I see as the prevalent interpretation on netdev, more than expressing an opinion. It's not based on any guidance from us, people just seem to think that they should reset when they post a PATCH. Whether we want to enforce a different scheme is up for a discussion, I don't really care. But I do see how not resetting is easier for tools, and that I think is a _bad_ reason to add rules. > There are RFCs which go to "v4", with significant discussion and review, > thus natural next version is "5", not "1". > > It's extremely confusing for me to be involved in some sort four > revisions of RFC and the suddenly see v1. What happened with my > comments? Why its state should be the same as new submission state? Well, as I said, changelog with links in the cover letter... > Plus, people do not understand or do not have the same meaning of RFC. > Some people send RFC with meaning "do not apply, just some > work-in-progress" but some send as regular patch with intention to > apply. I really, really saw exactly these two approaches. Yeah, that I do agree with 100%. People get confused by what RFC means. I think it's partially maintainers' fault. Without naming names, there are some people who used to apply RFC postings, if they liked the code :|