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 35109FD530B for ; Fri, 27 Feb 2026 07:40:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: 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=WLydjPhRFcy1XY3eCD02sOAHoMa1ojbTassrr6OVRpw=; b=Yd7LpRsjjOG0Roqca+HouC5QcV Lxerr5+zoPXlaL18HKusG3o8hAzr8nFqvQ/DsaZYr5Au/THmpoCrzw06eHq/AplJr4ykQItaGKCP6 QY50zrLPrYsaKc6bctyF7ldiEoxkZ1Odxl+qwxvxesGNpuA2aA2LczI8DjwF5D17eD03gRvX9kwpF 8rhQeljPYSJhj8Yjt03vhEsNUNTj03L1ZmunSenLASAltklK9qr5v8Cf5utL14PqqHVfGYYJdU/zb jwY4OOevzK7oR8S4jhs1OGTVXj4Qg8UKJeB6mnPCwtRC7iOo+fZkk3xOKGOcz7TiCnJPKBYEFGOgm KrKvxXcA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vvsS9-00000007u5M-3dP8; Fri, 27 Feb 2026 07:40:01 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vvsS8-00000007u4v-1ixT; Fri, 27 Feb 2026 07:40:00 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 8782C60008; Fri, 27 Feb 2026 07:39:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1085C116C6; Fri, 27 Feb 2026 07:39:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772177998; bh=sOiYomvFhDq7ZX6J8GSoe63dznpvQRU6nVHqlNksY7w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LpG7zHTpjfu9gK+YkZ5ZMc+iPrUQxQRM+TRD/8fEXAvIU2oEzEfJ8EZYp09RZrNle z3507pfPNT1krjeo+CoR+VRzyHlO2kh1EzkCVJHJ5a8JJYvj6KIlVGcFIh/93SuwQA M2zDS1dYhBz6jucMZEAGInEAH7bPHzcg0ntnfCYBsCvJiYo5aE8cg7ymB+v2eTJxFB LIgoibaoj5BtvYbyZHQNhI/XvgaR+E/eKKehM6LSqh/06DCZAXxWtxkia01p/iGxrw GBqIAQCdiGCxgmRw7bxMVr3uAtK5h6TdsSQcgqQDLQIHGH4EBUBW0bxORzur7FjXUS pJfTz/yU345Hg== Date: Fri, 27 Feb 2026 08:39:55 +0100 From: Krzysztof Kozlowski To: Conor Dooley Cc: Cristian Ciocaltea , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Heiko Stuebner , Detlev Casanova , Ezequiel Garcia , Mauro Carvalho Chehab , Nicolas Dufresne , Hans Verkuil , kernel@collabora.com, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, Conor Dooley , linux-media@vger.kernel.org Subject: Re: [PATCH v4 1/3] media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88} Message-ID: <20260227-aromatic-aboriginal-ibis-d14e7f@quoll> References: <20260226-vdec-reg-order-rk3576-v4-0-b8d72dc75250@collabora.com> <20260226-vdec-reg-order-rk3576-v4-1-b8d72dc75250@collabora.com> <20260226-salute-threaten-a3eabb232396@spud> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260226-salute-threaten-a3eabb232396@spud> 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 26, 2026 at 06:43:31PM +0000, Conor Dooley wrote: > On Thu, Feb 26, 2026 at 12:46:53PM +0200, Cristian Ciocaltea wrote: > > With the introduction of the RK3588 SoC, and RK3576 afterwards, two more > > register blocks have been provided for the video decoder unit. > > > > However, the binding does not properly describe the new hardware layout, > > as it breaks the convention expecting the unit address to indicate the > > start of the first register range, i.e. 'function' block is listed > > before 'link' instead of the opposite. > > I don't understand this commit message or rationale for an ABI break. The description is indeed wrong. The binding properly describes new hardware layout. They just don't like it. Hardware has three separate address spaces and EXACT three correct separate address spaces are described the binding. > Changing the unit address seems like a "free" fix to your problem, > especially when reg-names is not a required property that you can rely > on. Actually, there may be a bug in the driver - it expects reg-names > for rk3576-vdec and rk3588-vdec but the binding doesn't mandate their > presence for those devices. > > Deprecating the order also makes little sense to me, given that some of > these devices only have one reg entry, which as far as I can tell from > looking at the driver *is* the "function" region, so it can never be > entirely deprecated. There is "if" at the bottom of the binding, so the one entry does not use reg-names. Best regards, Krzysztof