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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AC84C433E9 for ; Sun, 27 Dec 2020 11:34:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5553522522 for ; Sun, 27 Dec 2020 11:34:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726174AbgL0Ldw (ORCPT ); Sun, 27 Dec 2020 06:33:52 -0500 Received: from mail.kernel.org ([198.145.29.99]:42604 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726039AbgL0Ldv (ORCPT ); Sun, 27 Dec 2020 06:33:51 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BB4C620809; Sun, 27 Dec 2020 11:33:09 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] 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) (envelope-from ) id 1ktUIN-0041p3-JF; Sun, 27 Dec 2020 11:33:07 +0000 Date: Sun, 27 Dec 2020 11:33:06 +0000 Message-ID: <87eejbpjpp.wl-maz@kernel.org> From: Marc Zyngier To: Bert Vermeulen Cc: Thomas Bogendoerfer , Rob Herring , Paul Burton , Thomas Gleixner , Damien Le Moal , Mateusz Holenko , Stafford Horne , Pawel Czarnecki , Palmer Dabbelt , =?UTF-8?B?Q8OpZHJpYw==?= Le Goater , Shawn Guo , Joel Stanley , Leonard Crestez , Peng Fan , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2] Add support for Realtek RTL838x/RTL839x switch SoCs In-Reply-To: References: <20201223150648.1633113-1-bert@biot.com> <87o8ikqywn.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 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: 62.31.163.78 X-SA-Exim-Rcpt-To: bert@biot.com, tsbogend@alpha.franken.de, robh+dt@kernel.org, paulburton@kernel.org, tglx@linutronix.de, damien.lemoal@wdc.com, mholenko@antmicro.com, shorne@gmail.com, pczarnecki@internships.antmicro.com, palmerdabbelt@google.com, clg@kaod.org, shawnguo@kernel.org, joel@jms.id.au, leonard.crestez@nxp.com, peng.fan@nxp.com, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@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-mips@vger.kernel.org Bert, On Sat, 26 Dec 2020 15:02:21 +0000, Bert Vermeulen wrote: > > On 12/23/20 5:18 PM, Marc Zyngier wrote: > >> + /* Set up interrupt routing */ > >> + writel(RTL8380_IRR0_SETTING, REG(RTL8380_IRR0)); > >> + writel(RTL8380_IRR1_SETTING, REG(RTL8380_IRR1)); > >> + writel(RTL8380_IRR2_SETTING, REG(RTL8380_IRR2)); > >> + writel(RTL8380_IRR3_SETTING, REG(RTL8380_IRR3)); > > > > What is this doing? > > It's fairly evident considering the comments -- routing of secondary > IRQs onto the CPU IRQs. The term "interrupt routing" is normally used when there is multiple possible targets for a given interrupt, in general a SMP system. Given that your toy SoC seems to be UP, using "interrupt routing" in this context is anything *but* evident. Moreover, since this "routing" is obviously SW controlled, how is that going to work when the next system has a different mapping between internal and external interrupts? > But as to packing this into DTS I'm not sure. > > DTS syntax being what it is, this would inevitably get more complex > and harder to understand. Do you have an example where this is done in > a better way? The DT syntax is a lot clearer than the seemingly random bunch of writes above, and has the invaluable advantage of being decoupled from the driver code. If, as I suspect, the same IP block has been copy-pasted across multiple implementations with different interrupt mappings, we'll end up with an explosion of board-specific files, which is exactly the problem DT has been tasked to solve. If the DT model is not suitable for your particular use case, please explain what doesn't work, and people will be more than eager to help. Thanks, M. -- Without deviation from the norm, progress is not possible.