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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E711BC4345F for ; Thu, 18 Apr 2024 16:08:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=V5FGiSFKh34YK9uB7aYGA6tDGEggJ0Ub6A2Wbiez67Q=; b=BDscwtIuwrFTs2UwbxQag6Fk4w xThCP12THPO0OD2mgjQ9+WOku9CJJd4SF+w5XiNGEH2Z6FaQK/h4P2QRMKbu3wsMtf8MrP1OPpAO7 J1xDAoo/PaT/BnQGhrdTNtPuDwCIH/IdRjW5o8zeglJksp4AdZT/Lzl6i7mIg9Yq8lhjvO8JUvZXn aYpT9A/RYiIpmyFbZOmqG+XYMywPy2MMFs+Cex0rgNMJr7RrbcdbNjKGNiIG71/vd9vbq8afL9VXC hs7cEzND5emkgCWWgTjHhNRdcpE1dxtLHJIRigese+X5owpHBgcxJojxXg/LwpqjopizeY6ePEOnb qQEua9sQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxUJ7-00000002x2y-2Rnl; Thu, 18 Apr 2024 16:08:17 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxUJ4-00000002x2P-2vlP; Thu, 18 Apr 2024 16:08:16 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1CCF261821; Thu, 18 Apr 2024 16:08:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C54FC113CC; Thu, 18 Apr 2024 16:08:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713456493; bh=rkrTpsLO+50r5ibEQOEvU3vQMmfUVtgFiQ5k83m5StM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TftbM3dOE3svEIaqrs8h/enmkXGrctoHLiseUF3xQMbQvYuNBYPYXtIAbtEonZ5b1 41TO3gaVUdFt3J52keySYXF+cB4AfcNmvXY4z2m/R31WbwOFgffs3GuPoagJqG+PWk 1YDt8QAR76YXXN5ZOy6B5Q9TXC3cX+UBFZSHUb2RAVsYzUREmpv3qGMzyCizDLjUi8 F6O9Pyj0boTNTgetVQOl58vEVR/ZoQshLTyHAIbiibz/7uC61KyIy1tfU+Mfe4TcMV AheGu7QrCaOrVlc+1rBv1za5Y03RUdUGODesrbMktYMEdOOiHdGZzmh+lvBP1YJne2 hgJ2wfppFkKZg== Date: Thu, 18 Apr 2024 17:08:08 +0100 From: Conor Dooley To: Diederik de Haas Cc: liujianfeng1994@gmail.com, krzk@kernel.org, linux-rockchip@lists.infradead.org, conor+dt@kernel.org, devicetree@vger.kernel.org, ezequiel@vanguardiasur.com.ar, heiko@sntech.de, krzk+dt@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, mchehab@kernel.org, p.zabel@pengutronix.de, robh@kernel.org, sfr@canb.auug.org.au, Conor Dooley Subject: Re: [PATCH v5 2/2] dt-bindings: media: rockchip-vpu: Add rk3588 vdpu121 compatible string Message-ID: <20240418-tipoff-neon-8c1fa60385cb@spud> References: <2a516484-ea87-444e-a89d-9fe33d08148f@kernel.org> <20240413155709.802362-1-liujianfeng1994@gmail.com> <1774986.o0yEF5yP89@bagend> MIME-Version: 1.0 In-Reply-To: <1774986.o0yEF5yP89@bagend> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240418_090814_905405_C93AE7C9 X-CRM114-Status: GOOD ( 25.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2878667514443970484==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============2878667514443970484== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sKET8aOPU1iKBZV1" Content-Disposition: inline --sKET8aOPU1iKBZV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 18, 2024 at 11:19:56AM +0200, Diederik de Haas wrote: > On Saturday, 13 April 2024 17:57:09 CEST Jianfeng Liu wrote: > > I'm sorry for my unkonwing about the kernel patching process. And I'm > > sorry to let maintainers do extra work. Thank you for teaching me this. > > I will do this right in future patches. > >=20 > > I did received a Acked-by tag from Conor in v4: > > Acked-by: Conor Dooley > >=20 > > I note it here in case someone forgets this tag. >=20 > I think it's beneficial to send a v6 with the following changes: > 1) Make this dt-bindings patch the first in the series > 2) Make sure you've collected all the tags you've received to all the pat= ches > 3) Specify the base commit >=20 > ad 1) I don't know if it's a hard rule, but I've seen a consistent patter= n=20 > where the dt-binding changes come before those changes being applied to= =20 > DeviceTree files. It also makes sense as when the dt-binding change hasn'= t been=20 > applied, then the DT file is technically invalid. It is definitely preferred, since there is tooling that checks for undocumented compatibles etc that would see spurious errors during bisection, were that to be done. Generally I wouldn't suggest resending for the order though if it were the only thing amiss. > ad 2) You shouldn't make maintainers do extra work to get your patch(es)= =20 > merged; you want to make their work as easy as possible. Thus you do the= =20 > (extra) work and provide a new version of the patch(es). > Sending multiple versions in a single day is generally not recommended as= you=20 > should give reviewers some time to do the review. But it should be fine n= ow as=20 > several days have past without new reviews. I dunno, the best way to save our time is to not omit the tags in the first place (or give a reason as to why you did) as we'll likely pull up the previous version of the series to see if all comments were addressed, if made by another maintainer (at least I do that and Krzysztof must have here). In my workflow sending another ack takes much less time than looking up previous versions and checking to see if things were dealt with - probably that's in-part to me lacking automation for dfn: lore search from mutt though.. >=20 > ad 3) The `git format-patch` command has a `--base=3D` parameter = with=20 > which you can make explicit upon which commit the patch is based. > That works a lot better/easier then a textual description. >=20 > HTH --sKET8aOPU1iKBZV1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZiFFaAAKCRB4tDGHoIJi 0o0pAP9fk55H5h1zSZnxIKk23cdN+HBXKww/TkXCqriIsMnC6gD9F54oAW2uS2/S BilcF9zkehoRlEKSh4CiiY5wD9hLGAM= =YI8b -----END PGP SIGNATURE----- --sKET8aOPU1iKBZV1-- --===============2878667514443970484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============2878667514443970484==--