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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 EEA03C433DB for ; Thu, 25 Mar 2021 21:13:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AE629619FB for ; Thu, 25 Mar 2021 21:13:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230443AbhCYVNR (ORCPT ); Thu, 25 Mar 2021 17:13:17 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:24228 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230467AbhCYVMx (ORCPT ); Thu, 25 Mar 2021 17:12:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616706773; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GWG62i2UZUo8ua5XusiVhjktb0103ycitfGwTI3taRk=; b=BbFVMeEBB1U1FyVFDGR3NB+FRLwvj3PXd7JjkagCyD8VHJfwCmC3h8lOiocRm+Ye0ttWLu YdB2rbf3WT4wII9MOccnnyYtcArJ6+2dwLwLkgywRER0ayoio3rvitq0zGbUki1ulHvaEz jEdx+K0uNKn9mJBKVcM5AA2d9Kmml9E= Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-374-lva6-wLCNa2RmHsduXZcKg-1; Thu, 25 Mar 2021 17:12:48 -0400 X-MC-Unique: lva6-wLCNa2RmHsduXZcKg-1 Received: by mail-ua1-f70.google.com with SMTP id i90so1992999uad.1 for ; Thu, 25 Mar 2021 14:12:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GWG62i2UZUo8ua5XusiVhjktb0103ycitfGwTI3taRk=; b=UkOZMFwYm9DYFaAScAoTBG7S14Vq94BnnfxXNOziz7jOHLU0DIO/fko2l/K2ZjJyFg ywXMpPM9ClVIHiP1LoIWUplIFgBqgwwLMNfcEiYA1adSxqrTgFCMLGP3a6N/G1AMswQK Al8qtxJ6wT1Jl6J9G+E7LHWqfUmfESgdhQBSsc1q+rEEngVrmFic7ty06Wg1i1McE7QF Xr0eZVwnxvdREBRDZNz+x/b6MRyo2UnDOBia2DuFijMLZd/iMqqR5u54D1E244boABbx s0stqALDxg8/V0XsL7BGgIkAli8sI4bRFF12p0PcDf9nuQbBu0luONie1O5OYmYUlv9V OhOA== X-Gm-Message-State: AOAM530hoXNvjdcujKBDdIxJYJk7MrLi+Tj/k9c4k+f2ExR6KSvSJ+l8 7EO0wHxmadwr99k03vq82oPKcfcN1mm5o6NoQvBGUU5TBlhfzjQgfu9bA6PyQq+zSWs25i5ighj dEgw0Q6vPujkRUprdE1cdKD6WZYSkdsSS+Eg3kBUx X-Received: by 2002:ab0:608e:: with SMTP id i14mr6348288ual.92.1616706767532; Thu, 25 Mar 2021 14:12:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxXoT6sMJKhKxYG0uLG8tKxKgRpQ7swSQHje5erIKKsFPTkJAOwmC6qs9temFDCaKGJDlppAY5zSQRdXdZzN/c= X-Received: by 2002:ab0:608e:: with SMTP id i14mr6348271ual.92.1616706767335; Thu, 25 Mar 2021 14:12:47 -0700 (PDT) MIME-Version: 1.0 References: <20210105045735.1709825-1-jeremy.linton@arm.com> <20210107181416.GA3536@willie-the-truck> <56375cd8-8e11-aba6-9e11-1e0ec546e423@jonmasters.org> <20210108103216.GA17931@e121166-lin.cambridge.arm.com> <20210122194829.GE25471@willie-the-truck> <20210126225351.GA30941@willie-the-truck> <20210325131231.GA18590@e121166-lin.cambridge.arm.com> In-Reply-To: From: Jon Masters Date: Thu, 25 Mar 2021 17:12:36 -0400 Message-ID: Subject: Re: [PATCH] arm64: PCI: Enable SMC conduit To: Marcin Wojtas Cc: Lorenzo Pieralisi , Will Deacon , Vikram Sethi , vidyas@nvidia.com, Thierry Reding , Jon Masters , Jeremy Linton , Mark Rutland , linux-pci@vger.kernel.org, Sudeep Holla , Linux Kernel Mailing List , Catalin Marinas , Bjorn Helgaas , linux-arm-kernel@lists.infradead.org, Eric Brower , Grzegorz Jaszczyk , Tomasz Nowicki , Samer El-Haj-Mahmoud Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marcin, Many thanks for your thoughtful, heartfelt response, and I don't disagree with your sentiments. The truth is that we have a messy situation. As a collective community of people who are passionate about the success of Arm in general purpose systems, I know many who would share my personal feeling that this is all beyond very unfortunate. That other architecture has working, robust, PCI IP that adheres to standards (more or less) correctly. There is no reason we can't either. But it takes a collective industry wide effort, alongside leadership from Arm (and others) to push things forward. I'm very impressed with where SystemReady is headed and there are great people behind making that happen. So I have faith that things will improve. Now is a good time to unite as an industry behind improving both the status quo (quirks) and future IP so that it is properly compliant. My opinion is that now is not a good moment to rework entirely how we do PCI enumeration to use an alternative scheme. Please see the below for more. On Thu, Mar 25, 2021 at 4:45 PM Marcin Wojtas wrote: > So what we have after 4 years: > * Direct convincing of IP vendors still being a plan. Things need to improve here. I've *expressed* as much to certain folks around the industry. I'm not afraid to get more vocal. There is too much IP out there even now that is doing inexcusably non-compliant things. When I would talk to these vendors they didn't seem to take standards compliance seriously (to any standard) because they're used to making some BSP for some platform and nobody has stood thoroughly over them to the point of extreme discomfort so that they change their approach. It is now past time that we stand over these folks and get them to change. I am not afraid to get much more intense here in my approach and I would hope that others who feel similarly about standardization would also choose to engage with extreme vigor. Extreme vigor. It must become an extreme embarrassment for any of them to continue to have any IP that claims to be "PCI" which is....not PCI. > * Reverting the original approach towards MCFG quirks. > * Double-standards in action as displayed by 2 cases above. The truth is we've had an inconsistent approach. But an understandable one. It's painful to take quirks. I am grateful that the maintainers are willing to consider this approach now in order to get to where we want to be, but I completely understand the hesitance in the past. Along with the above, we all need to do all we can to ensure that quirks are an absolute last resort. It's one thing to have a corner case issue that couldn't be tested pre-silicon, but there is *no excuse* in 2021 to ever tape out another chip that hasn't had at least a basic level of ECAM testing (and obviously it should be much more). Emulation time should catch the vast majority of bugs as real PCIe devices are used against a design using speed bridges and the like. There's no excuse not to test. And frankly it boggles my mind that anyone would think that was a prudent way to do business. You can have every distro "just work" by doing it right, or you can have years of pain by doing it wrong. And too many still think the BSP hack it up model is the way to go. We ought to be dealing predominantly with the long tail of stuff that is using obviously busted IP that was already baked. We can use quirks for that. But then they need to go away and be replaced with real ECAM that works on future platforms. > I'm sorry for my bitter tone, but I think this time could and should > have been spent better - I doubt it managed to push us in any > significant way towards wide fully-standard compliant PCIE IP > adoption. Truthfully there will be some parts of the Arm story that will be unpleasant footnotes in the historical telling. How we haven't moved the third party IP vendors faster is a significant one. I think we have a chance to finally change that now that Arm is gaining traction. I am very sad that some of the early comers who tried to do the right thing had to deal with the state of third party IP at the time. Jon. 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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 70BD4C433DB for ; Thu, 25 Mar 2021 21:17:18 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 D650661A1E for ; Thu, 25 Mar 2021 21:17:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D650661A1E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=TQoi3uPFvyt/lxCZpfZojXQ5bNkl6/IHNZ8LCfj4JR0=; b=SrDBiBlIhw5qMw0walBE6Xare oXG6z4jQ9YJ7/MOuIvZXY4Fy4O5Nw7vhUJsBOj2mN6qfSl5WRn9wlr/BtucV4wvrThInDwwIqOteJ +ciYmJOO6MYjcR4GzF69G+vcsk7R0pjF+lajUQLT/se4gqkqnI61t/NFhl2X7I1QMosTGbb2MHZHh RRcupYhY078TBuR/mAwUKOf/g0O7f6iCNJULicb36uOtvSltSa9z5zeB7iWDcz+c1mnID5/RNbkQb pF3B+hOLACvHTEUR3i7UNkr/OQXbOUFHfUhhcYswYadFIpMcCHqJsRxt24EkQND+LDDtgA6wKopkL v4i2xMdtQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lPXJv-002D15-Tw; Thu, 25 Mar 2021 21:15:12 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lPXJo-002D0V-Bg for linux-arm-kernel@lists.infradead.org; Thu, 25 Mar 2021 21:15:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616706900; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GWG62i2UZUo8ua5XusiVhjktb0103ycitfGwTI3taRk=; b=D84uQeLtKkytrvmRC47Sx2hZZA8jUOSUXQPPOIS4na5xfGiahleGZkJsQxLIQYVt1gigHZ 3171SnQNXcbbGHSqALC22YzIYJz42KJPkr8HvToMkOXSgLxdbmPIikk8r01Fa8gg55IGmO z2N+VYHyZvSerj51BvagloSW3QCpf+U= Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-296-YQCWyiuRNj6suctShuo0sA-1; Thu, 25 Mar 2021 17:12:48 -0400 X-MC-Unique: YQCWyiuRNj6suctShuo0sA-1 Received: by mail-ua1-f70.google.com with SMTP id h13so1984964uaj.6 for ; Thu, 25 Mar 2021 14:12:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GWG62i2UZUo8ua5XusiVhjktb0103ycitfGwTI3taRk=; b=Z1xszPDl6ZjCH8J7ViYLuCiMfEkT9PzZiIrvPVNGtAxPnlfXqUiiGDDZGwUBHY3d+P uLWQCJFqfTAcuk6J44DtZFtvmCFAcp9hPDW7dNtZYi9NQ2cbU1tBzmunKod/XqadCmhO xWheP6kkLAurAT4rARPlNLyuv3xxynCYTa8qbxKcFscPZ3fT/rxmkxBZOBGKOHT2slPy vlwv913t9MqqPy9m5R5kv8mLXeC+JQDBMzi9vJYCkal2hKXdZa/fWx3sjF4U/WnxOoZH KEFCEyyRBftabKyuRSzcsuGczEKUA4IfypezRrjVBYYTsVCAVynJofX77zD2XfKiPIbf cTNA== X-Gm-Message-State: AOAM5302xB0JkB7TDuTexzrxk5swpReX0hO2x34cr3/OYOBzhGKqdT0m eYw1UBq0z4W6DEQJRr8C3O6xun4+yvQLxgPV6QmZtpEQxuIFT7gAN6D48X7a579JgrSNsMl7yql C60gIAUqLXtcJtARs4icZmaO6r7xcDWjA4rMnY1qLQ0yya9QyO3E= X-Received: by 2002:ab0:608e:: with SMTP id i14mr6348290ual.92.1616706767543; Thu, 25 Mar 2021 14:12:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxXoT6sMJKhKxYG0uLG8tKxKgRpQ7swSQHje5erIKKsFPTkJAOwmC6qs9temFDCaKGJDlppAY5zSQRdXdZzN/c= X-Received: by 2002:ab0:608e:: with SMTP id i14mr6348271ual.92.1616706767335; Thu, 25 Mar 2021 14:12:47 -0700 (PDT) MIME-Version: 1.0 References: <20210105045735.1709825-1-jeremy.linton@arm.com> <20210107181416.GA3536@willie-the-truck> <56375cd8-8e11-aba6-9e11-1e0ec546e423@jonmasters.org> <20210108103216.GA17931@e121166-lin.cambridge.arm.com> <20210122194829.GE25471@willie-the-truck> <20210126225351.GA30941@willie-the-truck> <20210325131231.GA18590@e121166-lin.cambridge.arm.com> In-Reply-To: From: Jon Masters Date: Thu, 25 Mar 2021 17:12:36 -0400 Message-ID: Subject: Re: [PATCH] arm64: PCI: Enable SMC conduit To: Marcin Wojtas Cc: Lorenzo Pieralisi , Will Deacon , Vikram Sethi , vidyas@nvidia.com, Thierry Reding , Jon Masters , Jeremy Linton , Mark Rutland , linux-pci@vger.kernel.org, Sudeep Holla , Linux Kernel Mailing List , Catalin Marinas , Bjorn Helgaas , linux-arm-kernel@lists.infradead.org, Eric Brower , Grzegorz Jaszczyk , Tomasz Nowicki , Samer El-Haj-Mahmoud Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jcm@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210325_211504_599877_C6664F44 X-CRM114-Status: GOOD ( 25.71 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Marcin, Many thanks for your thoughtful, heartfelt response, and I don't disagree with your sentiments. The truth is that we have a messy situation. As a collective community of people who are passionate about the success of Arm in general purpose systems, I know many who would share my personal feeling that this is all beyond very unfortunate. That other architecture has working, robust, PCI IP that adheres to standards (more or less) correctly. There is no reason we can't either. But it takes a collective industry wide effort, alongside leadership from Arm (and others) to push things forward. I'm very impressed with where SystemReady is headed and there are great people behind making that happen. So I have faith that things will improve. Now is a good time to unite as an industry behind improving both the status quo (quirks) and future IP so that it is properly compliant. My opinion is that now is not a good moment to rework entirely how we do PCI enumeration to use an alternative scheme. Please see the below for more. On Thu, Mar 25, 2021 at 4:45 PM Marcin Wojtas wrote: > So what we have after 4 years: > * Direct convincing of IP vendors still being a plan. Things need to improve here. I've *expressed* as much to certain folks around the industry. I'm not afraid to get more vocal. There is too much IP out there even now that is doing inexcusably non-compliant things. When I would talk to these vendors they didn't seem to take standards compliance seriously (to any standard) because they're used to making some BSP for some platform and nobody has stood thoroughly over them to the point of extreme discomfort so that they change their approach. It is now past time that we stand over these folks and get them to change. I am not afraid to get much more intense here in my approach and I would hope that others who feel similarly about standardization would also choose to engage with extreme vigor. Extreme vigor. It must become an extreme embarrassment for any of them to continue to have any IP that claims to be "PCI" which is....not PCI. > * Reverting the original approach towards MCFG quirks. > * Double-standards in action as displayed by 2 cases above. The truth is we've had an inconsistent approach. But an understandable one. It's painful to take quirks. I am grateful that the maintainers are willing to consider this approach now in order to get to where we want to be, but I completely understand the hesitance in the past. Along with the above, we all need to do all we can to ensure that quirks are an absolute last resort. It's one thing to have a corner case issue that couldn't be tested pre-silicon, but there is *no excuse* in 2021 to ever tape out another chip that hasn't had at least a basic level of ECAM testing (and obviously it should be much more). Emulation time should catch the vast majority of bugs as real PCIe devices are used against a design using speed bridges and the like. There's no excuse not to test. And frankly it boggles my mind that anyone would think that was a prudent way to do business. You can have every distro "just work" by doing it right, or you can have years of pain by doing it wrong. And too many still think the BSP hack it up model is the way to go. We ought to be dealing predominantly with the long tail of stuff that is using obviously busted IP that was already baked. We can use quirks for that. But then they need to go away and be replaced with real ECAM that works on future platforms. > I'm sorry for my bitter tone, but I think this time could and should > have been spent better - I doubt it managed to push us in any > significant way towards wide fully-standard compliant PCIE IP > adoption. Truthfully there will be some parts of the Arm story that will be unpleasant footnotes in the historical telling. How we haven't moved the third party IP vendors faster is a significant one. I think we have a chance to finally change that now that Arm is gaining traction. I am very sad that some of the early comers who tried to do the right thing had to deal with the state of third party IP at the time. Jon. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel