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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5FBCEC433EF for ; Mon, 27 Dec 2021 10:05:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233574AbhL0KES (ORCPT ); Mon, 27 Dec 2021 05:04:18 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:47852 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233438AbhL0KEQ (ORCPT ); Mon, 27 Dec 2021 05:04:16 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 90B2260180; Mon, 27 Dec 2021 10:04:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1057C36AEA; Mon, 27 Dec 2021 10:04:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1640599456; bh=dIUo5ofCQLZZ1PsUCb9oGfiTXesB8b/NGHxJvV/9Z0c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eumOjWQo9QHrP6X8xL5qaaoW3R+6hWhiiiUASb5VZs5JBcdwEiRJUHv/r+lb2nUEX HlzLPqz2jWPX5tk2p5b2VWLk+BDRJ2OsDg/HbwkeGU3997sg+I27cBXzIpwJjmwX4V buAzghBEyTMj2qa2JuZSJIpxV5JvojBhp6/qElcbzI3HhxMU/U77YhEAosykA+2QQm 1TyOflEI/YuEqchixgq1LyXNRyLLvZ3omYZaWLAOqtOXDokDJCea8wOqM3CfhCCFVh EvH993i/LzYkT6De7V6HNiKXhRrfnRR+vcuygSvNnqaX4RHVPvf7y6tUmsUXkaKQRG mXkwYi6zkix8A== Received: from cfbb000407.r.cam.camfibre.uk ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n1mrV-00EWsK-Ig; Mon, 27 Dec 2021 10:04:13 +0000 Date: Mon, 27 Dec 2021 10:04:18 +0000 Message-ID: <87v8zaz7ml.wl-maz@kernel.org> From: Marc Zyngier To: Sander Vanheule Cc: Thomas Gleixner , devicetree@vger.kernel.org, Rob Herring , Birger Koblitz , Bert Vermeulen , John Crispin , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v1 3/4] dt-bindings: interrupt-controller: realtek,rtl-intc: replace irq mapping In-Reply-To: References: <8a5931f18a6f1c92f8c8e4965dc65674d7e5a4c4.1640261161.git.sander@svanheule.net> <87y24byzej.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: sander@svanheule.net, tglx@linutronix.de, devicetree@vger.kernel.org, robh+dt@kernel.org, mail@birger-koblitz.de, bert@biot.com, john@phrozen.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 23 Dec 2021 19:29:23 +0000, Sander Vanheule wrote: > > On Thu, 2021-12-23 at 18:00 +0000, Marc Zyngier wrote: > > On Thu, 23 Dec 2021 12:08:33 +0000, > > Sander Vanheule wrote: > > > > > > The binding incorrectly specified the "interrupt-map" property should be > > > used, although the use is non-standard. A quirk had to be introduced in > > > commit de4adddcbcc2 ("of/irq: Add a quirk for controllers with their own > > > definition of interrupt-map") to allow the driver to function again. > > > > That's too late. We have released a kernel with this binding, and it > > will live on forever until we totally remove the platform from the > > tree. > > > > DT is an ABI, and only time travel can fix this blunder. > > Taking into account your comments on the previous patch, this change > wouldn't even be required if I correct the mappings for my > devices. But that wouldn't get rid of the assumed mapping between > output lines and parent interrupts. A driver can always ignore some information from the DT and do its own thing. No sure if that addresses your problem though. > > To what extent can the binding be updated to get rid of this > assumption? Or would that require a completely new binding? You can only extend a binding in a two-way fashion: old kernel works with new DT, new kernel works old DT. Which means that in practice, you can only *add* information to the DT, and have reasonable defaults in the driver when you don't find it. M. -- Without deviation from the norm, progress is not possible.