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 7C46DC27C53 for ; Wed, 12 Jun 2024 16:13:26 +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:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From :Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XXwatvCZK75+gyfT5QGM1hr1TmWbqnnUzJVbqygrw14=; b=dBc4JOYCUs5XE89V76oC7jKklN V2ItAhYgSicyQYDNclKGF4J7EZeqDMecDz1cO6z4UOfWz+iFlT2h4ConbSqlGwg24A3tcLzaE0MHf vgsTERCsPPsQoL4kSb3TCLMHMKnhdHVUio/P8/5PBcmhPZ4vLIJ4Tkghtmivem+tGQvDh6bRPzcBE iYS6rOtwVvqZ7/VfTI7D5j6Zkhu+awyIpXfUgq/AZDu/lOiZmC3KDhWFLzpw48DE1kV9rtU+9C2i2 KDOwWBlvGsK2JItUf9p43h279EqDIJCt+inf41tIiJJLTmX3rtstBe646yNCFe5d2OtFheUXlfV3e mcsc5AwQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHQb4-0000000DKki-0zJp; Wed, 12 Jun 2024 16:13:14 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHQaz-0000000DKjj-0guV; Wed, 12 Jun 2024 16:13:12 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 33ACD1042; Wed, 12 Jun 2024 09:13:30 -0700 (PDT) Received: from [192.168.20.22] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E7B443F73B; Wed, 12 Jun 2024 09:13:04 -0700 (PDT) Message-ID: Date: Wed, 12 Jun 2024 11:10:14 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Raspberry Pi5 - RP1 driver - RFC Content-Language: en-US To: Stefan Wahren , Lee Jones , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Florian Fainelli , Broadcom internal kernel review list , devicetree@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Bjorn Helgaas , linux-pci@vger.kernel.org, Dave Ertman , Lizhi Hou , clement.leger@bootlin.com References: From: Jeremy Linton In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240612_091309_314710_009435AA X-CRM114-Status: GOOD ( 24.64 ) 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 Hi, On 6/11/24 14:05, Stefan Wahren wrote: > Hi Andrea, > > i added Jeremy, because AFAIK he was deeply involved in ACPI > implementation of the RPi 4. I'm not sure what to add here, the RPi4 work was done as an example of using firmware standards to boot multiple OSs with a single boot/firmware interface. Which means ACPI. Alternatively, the PCIe/SMCCC might be able to make this device look more regular, by putting everything on separate PCIe functions. OTOH, I don't think this device is particularly special, except maybe to the extent that it doubles down on ideas regarded as best left in the 1990's. The kernel documents how to handle these cases with ACPI _ADR(). A PCI device can create the _ADR nodes by injecting an SSDT into the ACPI namespace via the PCI option ROMs if the platform firmware doesn't provide them. Should it though? If I were doing it I might be tempted to configure the root port in early firmware and hide it from the OS, claiming instead a bunch of platform devices. IMHO, DT/Linux platforms should probably do something similar to _ADR() for consistency rather than requiring the EP driver to get involved. Further, mixing DT's into a possible ACPI platform is really the worst of both. Even worse if it requires further distro dracut/initrd/grub/etc one off hacking or polluting the initrd or ESP of non RPi platforms to handle the overlay. So, a custom EP/bus driver option solves the problem on linux for both DT and ACPI implementations if the device type/offsets are hard coded into it. And presumably if there is a follow on device, it would use multiple PCIe functions to avoid all these problems, the ones around securing the platform with an IOMMU, enabling VFIO, and everything else one gets for "free" with a proper PCIe EP. PS: The PCIe/SMCC API could probably make all these devices appear as PCIe functions avoiding the need for a monolithic bus or DT/ACPI description to handle it. But that will likely break the second this device is plugged into something with an SMMU (this platform doesn't have one, correct?), and of course if would require all the firmware configured BAR mappings to remain static, which isn't a problem if its presented as an integrated endpoint. If someone is interested in doing it that way then we should talk. > > Am 11.06.24 um 17:39 schrieb Andrea della Porta: >> Hi, >> I'm on the verge of reworking the RP1 driver from downstream in order >> for it to be >> in good shape for upstream inclusion. >> RP1 is an MFD chipset that acts as a south-bridge PCIe endpoint >> sporting a pletora >> of subdevices (i.e.  Ethernet, USB host controller, I2C, PWM, etc.) >> whose registers >> are all reachable starting from an offset from the BAR address. >> The main point here is that while the RP1 as an endpoint itself is >> discoverable via >> usual PCI enumeraiton, the devices it contains are not discoverable >> and must be >> declared e.g. via the devicetree. This is an RFC about the correct >> approach to use >> in integrating the driver and registering the subdevices. >> > I cannot provide much input into the technical discussion, but i would > prefer an approach which works good with DT and ACPI. > > Best regards > Stefan >> >> Link: >> - [1]: >> https://github.com/raspberrypi/linux/blob/rpi-6.6.y/arch/arm/boot/dts/broadcom/rp1.dtsi >> - [2]: >> https://github.com/raspberrypi/linux/blob/rpi-6.6.y/drivers/mfd/rp1.c >> - [3]: >> https://lpc.events/event/17/contributions/1421/attachments/1337/2680/LPC2023%20Non-discoverable%20devices%20in%20PCI.pdf >> - [4]: >> https://lore.kernel.org/lkml/20230419231155.GA899497-robh@kernel.org/t/ >> - [5]: https://lore.kernel.org/lkml/Y862WTT03%2FJxXUG8@kroah.com/ >