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 88CF3FEFB72 for ; Fri, 27 Feb 2026 17:49:48 +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:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=G/YpL6nohn85Bq182A4cVkKIZITsZYZrFrUtUs1eFaY=; b=nNYR2I/PznENZ7L6hnU9edVs1v ZTLsBBVwtzldSHSKIYMiCjKsMYAfhMhPeBPuehHShox9S8/fbW2GwoPHVTgocO2kVcKswwL7Go2o+ VC4QQx/EtlP1LWADzPp+jBE0ZBNgZyPEuRGzwDeIhElS0OHQLeSDPjrafymIcoWldw3skAliWlOmX f4/Dkz5ondGF3sqr9qhvcZk+T6DkXsF2U19JRAzqeWc+mJMMhAbeiHd8nIaEwILdQc6mcO/hCnYVF ft9Oc/JQlkP9aza59fgdN86ZKEd0s0gwUvj0Dh7ei9Y4Rd+0MWrDDf1GyJkxgtkMOyzj+ZIqD/i5i Hzl6MWHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vw1yA-00000008pWk-35IZ; Fri, 27 Feb 2026 17:49:42 +0000 Received: from bali.collaboradmins.com ([148.251.105.195]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vw1y5-00000008pWA-38UF; Fri, 27 Feb 2026 17:49:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1772214574; bh=SpE+cfNaP1TFrPzaUFYC0O9H8FoRYo0yR/OZFLjxALo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=DVaKcqErMmK37/uJXaKthCMiluQqJM7uAJYCmJcrnFscZ4q+4KopoQJ+kelS7x7jw 3YaldOMsay/sDkvHIHQw6Iuqmw9XDH7+TMWuetAm5rW9kgUOntjSJE2nBUc85SDs81 0M88Z1csETPWYBba9DmoDjZReGL9fo7PGZRYiz6dJDQ4byM9jWuMTSyqdg6e/dBMYP RpbzOwsS3E4AqG9TY+jcdS+m9Ha9taIcgFm8H084/xiGRq7zaKvANQEfCzgOOlvQlS v62oXqNpUmHncmwHovx9ANNPB7XIxEo4rdRaFNSvqLqX/8KXty5Ccb72vCQAoXoRfb yOGMqWMxIf7TQ== Received: from [192.168.1.90] (unknown [86.123.23.225]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: cristicc) by bali.collaboradmins.com (Postfix) with ESMTPSA id C587C17E03E5; Fri, 27 Feb 2026 18:49:33 +0100 (CET) Message-ID: <86f4e4ee-cf49-4ebe-8cc6-0a9763ade36a@collabora.com> Date: Fri, 27 Feb 2026 19:49:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/3] media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88} To: Conor Dooley , Nicolas Dufresne Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Heiko Stuebner , Detlev Casanova , Ezequiel Garcia , Mauro Carvalho Chehab , 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 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> <429f3c7aa22eccffedbf8db6aa91bee3dd13814a.camel@collabora.com> <20260226-snide-foil-a05e1aa156a8@spud> <3d28c699e47f606bad46bb6447785badace37793.camel@collabora.com> <20260227-atonable-glamorous-920cfd832bc1@spud> Content-Language: en-US From: Cristian Ciocaltea In-Reply-To: <20260227-atonable-glamorous-920cfd832bc1@spud> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260227_094937_936524_8FE9F395 X-CRM114-Status: GOOD ( 21.68 ) 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 2/27/26 7:18 PM, Conor Dooley wrote: > On Thu, Feb 26, 2026 at 04:56:30PM -0500, Nicolas Dufresne wrote: >> Le jeudi 26 février 2026 à 20:59 +0000, Conor Dooley a écrit : >>> On Thu, Feb 26, 2026 at 02:45:11PM -0500, Nicolas Dufresne wrote: >>>> Le jeudi 26 février 2026 à 18:43 +0000, Conor Dooley a écrit : > >>>>> 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. >>>> >>>> What I'd like to see, is a binding expression that behave like a set, not a >>>> list, and leave the ordering open. As people keep repeating, there is nothing in >>>> a binding that assist to define the right ordering (its not address or base >>>> addres aware). That basically means, we can't as reviewer see that ordering is >>>> going to imposing using a base address in the unit name (which is a convenience, >>>> not a rule I suppose) that differ from the vendor documented base address. >>>> >>>> By explicitly removing the ordering in the binding, we create a strict rule that >>>> driver should retrieve this by name, and never assume the ordering, which I >>>> personally like. >>>> >>>> thoughts ? >>> >>> Yeah, you can do this, but to avoid potential breaks you have to do it >>> from the start, not after the fact. Probably there's bindings that get >>> acked every day that do do this. Even the retcon is okay to do when >>> reg-names is mandated by the binding and the users use reg-names in my >>> opinion. >> >> I think from the above analyses, since the usage only starts in rc1, we have >> room for improving it knowing we aren't creating problem for anyone. Note that I >> have no idea what the syntax is to "do this", and I doubt either Detlev or >> Cristian have a clue. > > I think this is the only bit that really still needs a reply, this can > be solved by adding reg-names as "required" to the existing conditional > portion of the binding. There's probably hundreds of examples if one > does a search for "then:\n.*required:" to use a basis for the change > here. Probably should be an independent change, since it is needed even > without the re-order given the bug I brought up. As mentioned in my previous reply, the actual problem is that the binding has been already released, and I'm not sure we can change this without breaking the ABI. Regards, Cristian