Received: by 2002:a05:6a10:c7d3:0:0:0:0 with SMTP id h19csp849065pxy; Sun, 15 Aug 2021 02:14:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyaNHGDkG0qc2GiYCyvGO5vRdeNzmoHtcotghhFL0//QXM+age3Z/lCp/Pp7lUuvTAJejhw X-Received: by 2002:a17:906:2bd0:: with SMTP id n16mr10844231ejg.132.1629018870116; Sun, 15 Aug 2021 02:14:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629018870; cv=none; d=google.com; s=arc-20160816; b=wVLmJKFM27vaEowMqLnn+/l8iIE91TG/MKVKZsIwbfKvxD0N8VBNOdSYBvtQWQeFOr SuFbir5kWNaqTQQKfZ0vy1C7CsIdHm/7Y5f22B3MxhqMjXEL5UmlxudTQx6A7oGTwFJV ys7GvUzx7VJ8QLo0P570IYrb82dPikVIF7jOW3I5PMxNky9yC92wVlOHVBOYLNQDPipf 009rMhgmcZGemjNDJSFpabTeaJVra6Jncq3T1/eTjSQFiYyeE0j33CLTLLtjK6CBkLAc X681GtLeqaPx4StxXTn6tn/zskfN685PfWr6Xdqz8MhyspHlUIuwI3o22PITQjqy0Cj7 RpWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date; bh=Uq5LkgPITBOzLmPgDrLqag9+yh+dmxpUj293CEcz0UQ=; b=UQIGqZ4MFVLpoX/bwB+bIOSBEnfLpN7RMGKMNrsUk2H0M5fli04W51J9Zj+a0wdLub 1Y7patLaAMIAo25pBJviXby8Q9LXWBSTMexjLI6VivMdsog6jeI1fIBG3JS1dP4hgjSF 6w53MBKd07Ajt5nSdJFREV03pUlx1Mu4928rpi70T527ffArmJiRcd/kpZOmDgGH76Kx B7DgR785aj/281Odiq8k/cRcaAS5KLybLrxFEqj+FRZTv8OrjMtt6N4nXtaLuyB44uy9 lCa1XV1KUI69zZ0zuLBwSDQfoXV/lEtl+1ox9oT55/hHDR8e1L8q68xJqcLWVlSDxw47 zZUg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x1si6639428ejd.605.2021.08.15.02.14.06; Sun, 15 Aug 2021 02:14:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S236862AbhHOJNR (ORCPT + 99 others); Sun, 15 Aug 2021 05:13:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:60076 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231194AbhHOJNR (ORCPT ); Sun, 15 Aug 2021 05:13:17 -0400 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 3DEF061042; Sun, 15 Aug 2021 09:12:47 +0000 (UTC) Received: from 109-170-232-56.xdsl.murphx.net ([109.170.232.56] 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 1mFCCD-0055bX-6K; Sun, 15 Aug 2021 10:12:45 +0100 Date: Sun, 15 Aug 2021 10:12:44 +0100 Message-ID: <878s131377.wl-maz@kernel.org> From: Marc Zyngier To: Mark Kettenis Cc: Alyssa Rosenzweig , linux-pci@vger.kernel.org, Bjorn Helgaas , Rob Herring , Lorenzo Pieralisi , Krzysztof =?UTF-8?B?V2ls?= =?UTF-8?B?Y3p5xYRza2k=?= , Stan Skowronek , Mark Kettenis , Sven Peter , Hector Martin , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/2] dt-bindings: PCI: Add Apple PCI controller In-Reply-To: <1566004903.6140692.1629015053757@ox-webmail.xs4all.nl> References: <20210815042525.36878-1-alyssa@rosenzweig.io> <20210815042525.36878-2-alyssa@rosenzweig.io> <87bl5z18vt.wl-maz@kernel.org> <1566004903.6140692.1629015053757@ox-webmail.xs4all.nl> 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: 109.170.232.56 X-SA-Exim-Rcpt-To: openbsd@xs4all.nl, alyssa@rosenzweig.io, linux-pci@vger.kernel.org, bhelgaas@google.com, robh+dt@kernel.org, lorenzo.pieralisi@arm.com, kw@linux.com, stan@corellium.com, kettenis@openbsd.org, sven@svenpeter.dev, marcan@marcan.st, devicetree@vger.kernel.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 Hi Mark, On Sun, 15 Aug 2021 09:10:53 +0100, Mark Kettenis wrote: > > Hi Marc, > > What can I do to make progress with my binding proposal? It seems we're stuck > on the MSI issue where you and robh disagree. I still think your idea of > describing the MSIs as a range makes much more sense than describing them > individually and bunching them together with the host bridge port interrupts. > It looks like I missed an email from Rob, which explains why we're in limbo (it was left unread and unmarked, which in my flow means "read once I have too much time on my hands"). Apologies for that, I'll try and reply tonight (travelling at the moment). > Op 15-08-2021 09:09 schreef Marc Zyngier : > > Hi Alyssa, > > On Sun, 15 Aug 2021 05:25:24 +0100, > Alyssa Rosenzweig wrote: > > Document the properties used by the Apple PCI controller. This is a > fairly standard PCI controller, although it is not derived from any > known non-Apple IP. > > Signed-off-by: Alyssa Rosenzweig > > I would rather you post something as an extension to Mark's work, for > multiple reasons: > > - Mark's patch is still being discussed, and is the current > reference (specially given that it is already in use in OpenBSD and > u-boot). > > - we cannot have multiple bindings. There can only be one, shared > across implementations. Otherwise, you need a different kernel > depending on whether you are booting from m1n1 or u-boot. > > - what you have here is vastly inconsistent (you are describing the > MSIs twice, using two different methods). > > That's probably my fault. The current u-boot device tree is a bit of a > Frankenstein thing to ease the transition from my initial binding to the > current proposal. I should clean that up at some point. That would certainly help. There are a lot of moving pieces at the moment, and it is getting hard to get a clear picture of what is using what. Thanks, M. -- Without deviation from the norm, progress is not possible.