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=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 45E01C433E0 for ; Thu, 7 Jan 2021 19:21:06 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C72672343E for ; Thu, 7 Jan 2021 19:21:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C72672343E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=0nQOTJwn+VKEPizWKXo9iga2qPXGldlgCet/Z0sTOkk=; b=hmu2ufHNpappDejZVd3z1xYBj JzSb219frnr4mhexErqcnBRxjXuzL4G8YiWCKewAy3byJ5y/ClobZS6dANLzVQyr8RQHVkNIkEcvs zrgnc5I6i8Lx8HpVcjiAD2ZY0Fh7N0f/wNM/FKIcO9sWJ5Evg7wpLKRHGvcr8bkrm01NWQygspTbJ 7HEwl7wAJhh7Kr/0WPd/6FFdkgCbx74IeHufGWnKoQ/GEXPajqovZpl9DFfoiuhVlykdMOqsCt91P tEeL76tSnYV+kTjWda9vNS9ztFeyRCYSQ959cYMU/Oqc2YGHwDotEaz8BgpJ9F2efJbP2szS4IQgQ UR7ff7SwQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxaoG-00014W-9h; Thu, 07 Jan 2021 19:19:00 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxaoC-000143-7m for linux-arm-kernel@lists.infradead.org; Thu, 07 Jan 2021 19:18:58 +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 864DAD6E; Thu, 7 Jan 2021 11:18:50 -0800 (PST) Received: from [192.168.122.166] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 117443F66E; Thu, 7 Jan 2021 11:18:50 -0800 (PST) Subject: Re: [PATCH] arm64: PCI: Enable SMC conduit To: Will Deacon References: <20210105045735.1709825-1-jeremy.linton@arm.com> <20210107181416.GA3536@willie-the-truck> From: Jeremy Linton Message-ID: <61558f73-9ac8-69fe-34c1-2074dec5f18a@arm.com> Date: Thu, 7 Jan 2021 13:18:49 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20210107181416.GA3536@willie-the-truck> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210107_141857_056930_72E8137C X-CRM114-Status: GOOD ( 22.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, lorenzo.pieralisi@arm.com, linux-pci@vger.kernel.org, sudeep.holla@arm.com, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, bhelgaas@google.com, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On 1/7/21 12:14 PM, Will Deacon wrote: > On Mon, Jan 04, 2021 at 10:57:35PM -0600, Jeremy Linton wrote: >> Given that most arm64 platform's PCI implementations needs quirks >> to deal with problematic config accesses, this is a good place to >> apply a firmware abstraction. The ARM PCI SMMCCC spec details a >> standard SMC conduit designed to provide a simple PCI config >> accessor. This specification enhances the existing ACPI/PCI >> abstraction and expects power, config, etc functionality is handled >> by the platform. It also is very explicit that the resulting config >> space registers must behave as is specified by the pci specification. >> >> Lets hook the normal ACPI/PCI config path, and when we detect >> missing MADT data, attempt to probe the SMC conduit. If the conduit >> exists and responds for the requested segment number (provided by the >> ACPI namespace) attach a custom pci_ecam_ops which redirects >> all config read/write requests to the firmware. >> >> This patch is based on the Arm PCI Config space access document @ >> https://developer.arm.com/documentation/den0115/latest > > Why does firmware need to be involved with this at all? Can't we just > quirk Linux when these broken designs show up in production? We'll need > to modify Linux _anyway_ when the firmware interface isn't implemented > correctly... IMHO, The short answer is that having the quirk in the firmware keeps it centralized over multiple OSs and linux distro versions and avoids a lot of costly kernel->distro churning to backport/maintain quirks over a dozen distro versions. There is also a long-term maintenance advantage since its hard for the kernel community as a whole to have a good view of how long a particular model of machine is actually in use. For example, today we could ask are any of those xgene1's still in use and remove their quirks, but no one really has a clear view. As far as working around the firmware, that is of course potentially problematic, but I think it is easier to say "fix the firmware if you want/need linux support" than it is to get people to fix their ECAM implementations. Hypothetically, if at some point there is a broken version of this interface in firmware, the kernel could choose to bypass it entirely and talk to whatever broken config space method the hardware implements. At which point we aren't any worse off than the situation today. The flip side of this is that a fair number of these platforms have open source firmware as well, so it may be trivial to fix the firmware. Thanks for looking a this! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel