Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp20846971rwd; Thu, 29 Jun 2023 07:44:45 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5vc24DTAOvWlPuahLwyxd38x1h4W3kE1nDcdbKbl5fC0x1pHEKti9gHcDiRhAwBXMPwied X-Received: by 2002:a05:6a21:788a:b0:125:dee8:328f with SMTP id bf10-20020a056a21788a00b00125dee8328fmr15422404pzc.20.1688049885451; Thu, 29 Jun 2023 07:44:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688049885; cv=none; d=google.com; s=arc-20160816; b=F/8XuShHQGQdYzRPZsU8lMXv/BKQlDYuVO/OidveF2+/I8uluA52KwYB4BSXXjIn6w Hdr98+0F5jSajD1Atv9CAah6WKDKxTqs8c5Nnl57HQtF8g3saOG+NLxLg70yDqydJXyJ A0RZozcXFm5Zzuo0u38KlH+QKZv0sI7PiAqOlFZQBNDXZX9TeqFipRvG+EEcfeJFxKby fNxyt1zqcryt5T9YYxglHqsPkJDPgWCpPErn4Cr613AB6RdQC1GJp2T2OJH/xGmtr50M AzfSaVffVM1FSziyqkUtiEuIQh6Wbqlbonbwt+cOfMozYCJANlFjyhgWQulK5YerbRBY niAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Py+lLMH7Hj0VhFLFYo7Q8Ub3uOXuNSMgN/SPNYoMc6w=; fh=5Ws3S33wfl7lVl+H/tt18tLXkExOdSGfGtHw8qcn+N4=; b=UVUFrSAxzOqQdeuLLO3bKL7/p2DzLaZJijUhBO3yhCFSQa2Tlz4XGomdwqQ1H1JZv2 tOdqly3szoFfMjkSjD4Sdv5RZLjYfiRq2FeUbCfCtD+M2LEygNYfNDUhbYmGSC0I8uZh 8HFFwGJWe2vvKPJFJI1pWptZ8Fuwj6ho00FlFH4Gea5nn7D2s3H+7rRHO/u97+GPLx6h 1zEtQyCTUtZB8RChE6UQ2QoxVxQ8D0P2cjAYRbZ+P1Vh3UMjk3hV5b5NuYWH91p3K4KM iB1Xb3JsEDJg/4AcpNbIuM8Y6iR7OEJjC50GuhNCTPMzlQXJL1WQ6dUggEkaC0WpPY+G Zw7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pDOS2el9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y11-20020a634b0b000000b005578023de91si10682540pga.170.2023.06.29.07.44.29; Thu, 29 Jun 2023 07:44:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pDOS2el9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231989AbjF2O3f (ORCPT + 99 others); Thu, 29 Jun 2023 10:29:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230476AbjF2O3d (ORCPT ); Thu, 29 Jun 2023 10:29:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0F9B1BCC; Thu, 29 Jun 2023 07:29:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5EC3261567; Thu, 29 Jun 2023 14:29:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF314C433C8; Thu, 29 Jun 2023 14:29:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688048971; bh=8JR/CItlrlQ0WqXRlW0E1yvLOIt6OvzL+5y4jKGIuYg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pDOS2el9UoNYVZ350IIkDR2ADV9uSmaLE1hmlkn/+A4QGbJN+FI0dIKFXzI4WE9XN 1mcNtZQRj32Kp+xgWEgkyKohlH/QjW6q4wyGeGwzhKNEpfZJisCf/SSSVLAjD8klTJ IiNqI4DyJjVf4ZVMQzckCJe3BfgIP5sSYOZuXiTPZWI7TyzFz4retExRl3m0UIXIj2 4+/1s/q4L54senPb4mgQbI4rEDfOINpMoAWrVyLqeyAOlimVJUFw7+XREu62vDc00T wKsK0UPA/HSYGZF6o5tExCDd6AzQo9+5IGABLCM6LqwNpGka5qd51qAloAaQqfOoWR 1jmYl2lyOVraw== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1qEseM-0006qy-FB; Thu, 29 Jun 2023 16:29:35 +0200 Date: Thu, 29 Jun 2023 16:29:34 +0200 From: Johan Hovold To: Patrick Wildt Cc: Manivannan Sadhasivam , Manivannan Sadhasivam , Johan Hovold , Bjorn Andersson , Andy Gross , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Kettenis Subject: Re: [PATCH] arm64: dts: qcom: sc8280xp-pmics: add explicit rtc interrupt parent Message-ID: References: <20230627085306.6033-1-johan+linaro@kernel.org> <20230627132406.GA5490@thinkpad> <20230628052557.GB20477@thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 28, 2023 at 10:31:57AM +0200, Patrick Wildt wrote: > On Wed, Jun 28, 2023 at 08:47:00AM +0200, Johan Hovold wrote: > > My point is that it's apparently not just Linux as most devicetrees work > > this way at least for the root domain. And then it may be time to update > > the spec in some way. > > I'm not sure about the point you're trying to make. In OpenBSD's > implementation, which I think complies with the spec, for non-extended > interrupts we check the node's (or all its parents') interrupt-parent > property. My point is that that is not compliant with the spec either which only says that in case 'interrupt-parent' is missing in a node for an interrupt-generating device, then the interrupt parent is assumed to be the devicetree parent (which must then also be an interrupt controller or nexus). There is no provision for any recursive lookup in the spec currently. > Technically the SPMI arbiter could define an interrupt-parent that > points to itself, because it's using interrupts-extended anyway to > point to the PDC. But that would feel a bit stupid and not really > correct. Alternatively each child node could have interrupt-parent. I agree that that would not really be correct (e.g. as 'interrupt' and 'interrupt-extended' are supposed to be mutually exclusive). > That said, I understand the point that it might make sense to amend > the spec so that if a parent node is an interrupt-controller, that's > most probably interrupt parent, This bit is already in the spec. > unless an interrupt-parent property > shows up before. But this seems to suggest that you really meant to say "ancestor" in the first clause? > I would like to add that OpenBSD supports a number of SoCs for quite > some years and this is the first time I've hit an issue with interrupts > that were not designed in a way for the current spec to work. That said > we obviously support quite fewer SoCs/boards in total compared to Linux. So OpenBSD apparently implements something similar to Linux (recursive lookup of 'interrupt-parent' properties), but not the part about stopping the recursion when hitting an interrupt controller. Neither part appears to be spec compliant, but you only care about updating DTs that do not comply to the latter bit. That seems reasonable and should importantly not require adding tens of thousands of 'interrupt-parent' properties to the DTs in mainline. Johan