[{"id":1756756,"web_url":"http://patchwork.ozlabs.org/comment/1756756/","msgid":"","list_archive_url":null,"date":"2017-08-24T20:02:35","subject":"Re: [PATCH v2 3/3] dt-bindings: designware: add binding for\n\tDesignware PCIe in ECAM mode","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring (Arm)","email":"robh@kernel.org"},"content":"Cc the DT list for bindings please.\n\nOn Thu, Aug 24, 2017 at 1:43 PM, Ard Biesheuvel\n wrote:\n> Describe the binding for firmware-configured instances of the Synopsys\n> Designware PCIe controller in RC mode.\n>\n> Cc: Rob Herring \n> Signed-off-by: Ard Biesheuvel \n> ---\n> Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt | 56 ++++++++++++++++++++\n> 1 file changed, 56 insertions(+)\n>\n> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt\n> new file mode 100644\n> index 000000000000..b8127b19c220\n> --- /dev/null\n> +++ b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt\n> @@ -0,0 +1,56 @@\n> +* Synopsys Designware PCIe root complex in ECAM mode\n> +\n> +In some cases, firmware may already have configured the Synopsys Designware\n> +PCIe controller in RC mode with static ATU window mappings that cover all\n> +config, MMIO and I/O spaces in a [mostly] ECAM compatible fashion.\n> +In this case, there is no need for the OS to perform any low level setup\n> +of clocks or device registers, nor is there any reason for the driver to\n> +reconfigure ATU windows for config and/or IO space accesses at runtime.\n> +\n> +Such hardware configurations should be described as \"pci-host-ecam-generic\"\n> +if they are truly ECAM compatible. Configurations that require no low-level\n> +setup by the OS nor any ATU window reconfiguration at runtime, but do\n> +require special handling for type 0 config TLPs may instead be described as\n> +\"snps,dw-pcie-ecam\".\n\nHumm, what happens when we have the next exception that's SoC specific\nor another vendor? Seems like perhaps \"firmware initialized\" should\nhave been a separate property flag for bootloaders to add rather than\na compatible string.\n\nI'd rather see this done in a way that does not require DT updates if\nquirks have to be handled/added later.\n\nRob","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=robh@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xdZwP0YGGz9t2Z\n\tfor ;\n\tFri, 25 Aug 2017 06:03:01 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753142AbdHXUC7 (ORCPT );\n\tThu, 24 Aug 2017 16:02:59 -0400","from mail.kernel.org ([198.145.29.99]:37382 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751168AbdHXUC6 (ORCPT );\n\tThu, 24 Aug 2017 16:02:58 -0400","from mail-qk0-f181.google.com (mail-qk0-f181.google.com\n\t[209.85.220.181])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id CB41721A2B;\n\tThu, 24 Aug 2017 20:02:57 +0000 (UTC)","by mail-qk0-f181.google.com with SMTP id a77so2750214qkb.1;\n\tThu, 24 Aug 2017 13:02:57 -0700 (PDT)","by 10.12.153.1 with HTTP; Thu, 24 Aug 2017 13:02:35 -0700 (PDT)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org CB41721A2B","X-Gm-Message-State":"AHYfb5jMzeULE4HONEQxBNoy78pTCPHlGGzaUtMXXmT6uRF4iPU2xXlQ\n\tzUkwAy6abeoDTRiP2tQpKZrm2lNEOQ==","X-Received":"by 10.55.107.130 with SMTP id\n\tg124mr10588235qkc.210.1503604976542; \n\tThu, 24 Aug 2017 13:02:56 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170824184321.19432-4-ard.biesheuvel@linaro.org>","References":"<20170824184321.19432-1-ard.biesheuvel@linaro.org>\n\t<20170824184321.19432-4-ard.biesheuvel@linaro.org>","From":"Rob Herring ","Date":"Thu, 24 Aug 2017 15:02:35 -0500","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v2 3/3] dt-bindings: designware: add binding for\n\tDesignware PCIe in ECAM mode","To":"Ard Biesheuvel ","Cc":"\"linux-pci@vger.kernel.org\" ,\n\tMarcin Wojtas ,\n\tLeif Lindholm ,\n\tGraeme Gregory ,\n\tBjorn Helgaas , Jingoo Han ,\n\tJoao Pinto ,\n\tMarc Zyngier ,\n\t\"devicetree@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1756759,"web_url":"http://patchwork.ozlabs.org/comment/1756759/","msgid":"","list_archive_url":null,"date":"2017-08-24T20:12:22","subject":"Re: [PATCH v2 3/3] dt-bindings: designware: add binding for\n\tDesignware PCIe in ECAM mode","submitter":{"id":26857,"url":"http://patchwork.ozlabs.org/api/people/26857/","name":"Ard Biesheuvel","email":"ard.biesheuvel@linaro.org"},"content":"On 24 August 2017 at 21:02, Rob Herring wrote:\n> Cc the DT list for bindings please.\n>\n> On Thu, Aug 24, 2017 at 1:43 PM, Ard Biesheuvel\n> wrote:\n>> Describe the binding for firmware-configured instances of the Synopsys\n>> Designware PCIe controller in RC mode.\n>>\n>> Cc: Rob Herring \n>> Signed-off-by: Ard Biesheuvel \n>> ---\n>> Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt | 56 ++++++++++++++++++++\n>> 1 file changed, 56 insertions(+)\n>>\n>> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt\n>> new file mode 100644\n>> index 000000000000..b8127b19c220\n>> --- /dev/null\n>> +++ b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt\n>> @@ -0,0 +1,56 @@\n>> +* Synopsys Designware PCIe root complex in ECAM mode\n>> +\n>> +In some cases, firmware may already have configured the Synopsys Designware\n>> +PCIe controller in RC mode with static ATU window mappings that cover all\n>> +config, MMIO and I/O spaces in a [mostly] ECAM compatible fashion.\n>> +In this case, there is no need for the OS to perform any low level setup\n>> +of clocks or device registers, nor is there any reason for the driver to\n>> +reconfigure ATU windows for config and/or IO space accesses at runtime.\n>> +\n>> +Such hardware configurations should be described as \"pci-host-ecam-generic\"\n>> +if they are truly ECAM compatible. Configurations that require no low-level\n>> +setup by the OS nor any ATU window reconfiguration at runtime, but do\n>> +require special handling for type 0 config TLPs may instead be described as\n>> +\"snps,dw-pcie-ecam\".\n>\n> Humm, what happens when we have the next exception that's SoC specific\n> or another vendor?\n\nThis is not SoC specific, but IP specific. We are working with two\ndifferent SoCs from completely different vendors that both synthesized\nthis IP with a 64 KB ATU window size, not expecting this to break ECAM\ncompatibility.\n\n> Seems like perhaps \"firmware initialized\" should\n> have been a separate property flag for bootloaders to add rather than\n> a compatible string.\n>\n\nYes, but then you still have 10 different drivers that all retain the\nlow-level bits that are all different between SoCs. That is exactly\nwhat I want to get rid of, and usually we can do that with existing\nbindings, because we simply expose it as pci-host-ecam-generic. Only\nin this particular case, that doesn't fly due to the quirk.\n\n> I'd rather see this done in a way that does not require DT updates if\n> quirks have to be handled/added later.\n>\n\nDo you see a way that still allows us to keep the abstraction? I don't\nwant a flag, I simply don't want to expose any low-level specifics\nabout the device to the OS, beyond what it needs to use it in its\nconfigured state.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"Fzvq/mHl\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xdb7G5Yp9z9t2S\n\tfor ;\n\tFri, 25 Aug 2017 06:12:26 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753203AbdHXUMX (ORCPT );\n\tThu, 24 Aug 2017 16:12:23 -0400","from mail-it0-f43.google.com ([209.85.214.43]:37342 \"EHLO\n\tmail-it0-f43.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752751AbdHXUMX (ORCPT\n\t); Thu, 24 Aug 2017 16:12:23 -0400","by mail-it0-f43.google.com with SMTP id x187so2601345ite.0\n\tfor ; Thu, 24 Aug 2017 13:12:23 -0700 (PDT)","by 10.107.162.1 with HTTP; Thu, 24 Aug 2017 13:12:22 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=vxGMH+xkLYAHno5hOmZwp/ZELYpw4KTwQ04xM6Db/aM=;\n\tb=Fzvq/mHlZr/CDGYX4UcpntcYDfSR55yncloq04KSYqLtyVMqrnQM8Le8T1c2Tu34Dw\n\tgJC8t/o6VWMOmk7rXQtt6vBoZj7jj6T92WSyBpiW02HbB+YAG2YIzjQHL5m4E/7JpbZC\n\tcCprA7LBX5RIl0gQniAohCQCkh22Vo2aOO+Qg=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=vxGMH+xkLYAHno5hOmZwp/ZELYpw4KTwQ04xM6Db/aM=;\n\tb=NcM/Ia0EHL5AYO24qSe3x2cncQ5SlAu0sO2Ur+DeYjtB3egyccy8rpcXC51puFAfJd\n\tOGUSRjUdP41q9ntTQJWASvh4KuldBky3kyVDDFLxKYkpbiIaX2Z5kgxjXTZ5dbeLS1Nj\n\tGvL+gQ2y+QsUzmg3/K2P1QRYfJRl+4RVKlniFm1rtY7r3Ky1vMmo//pJez41EU9uXiwt\n\tP4knfq4jq1wN74VSnQPlvz1TyfRBhXELz/oEjHaqAGCC9IlpgRRmPUPMmEgVMWhbXI+m\n\tBsiQRZX5GlvNWAWGcyJWsl8BVqTLGXpLEE9WBZ5M78tzMKSxdQz/rbgzwc3h2n4dDcf9\n\tlxVg==","X-Gm-Message-State":"AHYfb5hPo9yMR+m2eZVGiPTiFPy0fGsQ5brQ8CsJA+JVy5Wbx7hwZ9ei\n\tRoBkYAcpAoJo5908oD5DrlpaGfHAgX1o","X-Received":"by 10.36.222.215 with SMTP id d206mr6812267itg.63.1503605542635; \n\tThu, 24 Aug 2017 13:12:22 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170824184321.19432-1-ard.biesheuvel@linaro.org>\n\t<20170824184321.19432-4-ard.biesheuvel@linaro.org>\n\t","From":"Ard Biesheuvel ","Date":"Thu, 24 Aug 2017 21:12:22 +0100","Message-ID":"","Subject":"Re: [PATCH v2 3/3] dt-bindings: designware: add binding for\n\tDesignware PCIe in ECAM mode","To":"Rob Herring ","Cc":"\"linux-pci@vger.kernel.org\" ,\n\tMarcin Wojtas ,\n\tLeif Lindholm ,\n\tGraeme Gregory ,\n\tBjorn Helgaas , Jingoo Han ,\n\tJoao Pinto ,\n\tMarc Zyngier ,\n\t\"devicetree@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1756849,"web_url":"http://patchwork.ozlabs.org/comment/1756849/","msgid":"","list_archive_url":null,"date":"2017-08-24T22:12:42","subject":"Re: [PATCH v2 3/3] dt-bindings: designware: add binding for\n\tDesignware PCIe in ECAM mode","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring (Arm)","email":"robh@kernel.org"},"content":"On Thu, Aug 24, 2017 at 3:12 PM, Ard Biesheuvel\n wrote:\n> On 24 August 2017 at 21:02, Rob Herring wrote:\n>> Cc the DT list for bindings please.\n>>\n>> On Thu, Aug 24, 2017 at 1:43 PM, Ard Biesheuvel\n>> wrote:\n>>> Describe the binding for firmware-configured instances of the Synopsys\n>>> Designware PCIe controller in RC mode.\n>>>\n>>> Cc: Rob Herring \n>>> Signed-off-by: Ard Biesheuvel \n>>> ---\n>>> Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt | 56 ++++++++++++++++++++\n>>> 1 file changed, 56 insertions(+)\n>>>\n>>> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt\n>>> new file mode 100644\n>>> index 000000000000..b8127b19c220\n>>> --- /dev/null\n>>> +++ b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt\n>>> @@ -0,0 +1,56 @@\n>>> +* Synopsys Designware PCIe root complex in ECAM mode\n>>> +\n>>> +In some cases, firmware may already have configured the Synopsys Designware\n>>> +PCIe controller in RC mode with static ATU window mappings that cover all\n>>> +config, MMIO and I/O spaces in a [mostly] ECAM compatible fashion.\n>>> +In this case, there is no need for the OS to perform any low level setup\n>>> +of clocks or device registers, nor is there any reason for the driver to\n>>> +reconfigure ATU windows for config and/or IO space accesses at runtime.\n>>> +\n>>> +Such hardware configurations should be described as \"pci-host-ecam-generic\"\n>>> +if they are truly ECAM compatible. Configurations that require no low-level\n>>> +setup by the OS nor any ATU window reconfiguration at runtime, but do\n>>> +require special handling for type 0 config TLPs may instead be described as\n>>> +\"snps,dw-pcie-ecam\".\n>>\n>> Humm, what happens when we have the next exception that's SoC specific\n>> or another vendor?\n>\n> This is not SoC specific, but IP specific. We are working with two\n> different SoCs from completely different vendors that both synthesized\n> this IP with a 64 KB ATU window size, not expecting this to break ECAM\n> compatibility.\n\nThis case is not SoC specific, but quirks/bugs show up in both places.\nPlus \"dw-pcie\" is fairly meaningless because the IP is both\nconfigurable and has multiple releases.\n\n>> Seems like perhaps \"firmware initialized\" should\n>> have been a separate property flag for bootloaders to add rather than\n>> a compatible string.\n>>\n>\n> Yes, but then you still have 10 different drivers that all retain the\n> low-level bits that are all different between SoCs. That is exactly\n> what I want to get rid of, and usually we can do that with existing\n> bindings, because we simply expose it as pci-host-ecam-generic. Only\n> in this particular case, that doesn't fly due to the quirk.\n\nYou can expose it as \"vendor,soc-pcie\", \"pci-host-ecam-generic\" and\nthen the kernel can decide. Then you can use: the default ecam driver,\nthe ecam driver but match on \"vendor,soc-pcie\" for quirks, or a vendor\nspecific driver. The only thing that wouldn't work would be having\nboth quirks in the ecam driver and a vendor driver which IMO we just\nshouldn't support anyway.\n\nNow if you have 10 SoCs all needing this same quirk, then maybe adding\n\"snps,dw-pcie-ecam\" addtionally to the above makes sense. But that\nonly saves you match strings.\n\n>> I'd rather see this done in a way that does not require DT updates if\n>> quirks have to be handled/added later.\n>>\n>\n> Do you see a way that still allows us to keep the abstraction? I don't\n> want a flag, I simply don't want to expose any low-level specifics\n> about the device to the OS, beyond what it needs to use it in its\n> configured state.\n\nThat's not how DT works. Detailed information is exposed to the OS and\nthe OS decides if it can handle things generically or not because that\ndecision can change over time. Whenever we don't make things specific\nenough, we've gotten burned.\n\nRob","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=robh@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xddpc2tlNz9t3h\n\tfor ;\n\tFri, 25 Aug 2017 08:13:12 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753959AbdHXWNI (ORCPT );\n\tThu, 24 Aug 2017 18:13:08 -0400","from mail.kernel.org ([198.145.29.99]:48376 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753411AbdHXWNE (ORCPT );\n\tThu, 24 Aug 2017 18:13:04 -0400","from mail-qt0-f177.google.com (mail-qt0-f177.google.com\n\t[209.85.216.177])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 29CA921A2F;\n\tThu, 24 Aug 2017 22:13:04 +0000 (UTC)","by mail-qt0-f177.google.com with SMTP id e2so4175984qta.0;\n\tThu, 24 Aug 2017 15:13:04 -0700 (PDT)","by 10.12.153.1 with HTTP; Thu, 24 Aug 2017 15:12:42 -0700 (PDT)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 29CA921A2F","X-Gm-Message-State":"AHYfb5ia6v586ieddpEPj6Sbqxd2A5nl7sHFpNXMTtHWS4XHWAc7n3KH\n\tDM+0k9iATTZtRBTVrbxRfvd8sXWiLw==","X-Received":"by 10.200.8.35 with SMTP id u32mr348684qth.162.1503612783274;\n\tThu, 24 Aug 2017 15:13:03 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170824184321.19432-1-ard.biesheuvel@linaro.org>\n\t<20170824184321.19432-4-ard.biesheuvel@linaro.org>\n\t\n\t","From":"Rob Herring ","Date":"Thu, 24 Aug 2017 17:12:42 -0500","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v2 3/3] dt-bindings: designware: add binding for\n\tDesignware PCIe in ECAM mode","To":"Ard Biesheuvel ","Cc":"\"linux-pci@vger.kernel.org\" ,\n\tMarcin Wojtas ,\n\tLeif Lindholm ,\n\tGraeme Gregory ,\n\tBjorn Helgaas , Jingoo Han ,\n\tJoao Pinto ,\n\tMarc Zyngier ,\n\t\"devicetree@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1756862,"web_url":"http://patchwork.ozlabs.org/comment/1756862/","msgid":"","list_archive_url":null,"date":"2017-08-24T22:37:37","subject":"Re: [PATCH v2 3/3] dt-bindings: designware: add binding for\n\tDesignware PCIe in ECAM mode","submitter":{"id":26857,"url":"http://patchwork.ozlabs.org/api/people/26857/","name":"Ard Biesheuvel","email":"ard.biesheuvel@linaro.org"},"content":"On 24 August 2017 at 23:12, Rob Herring wrote:\n> On Thu, Aug 24, 2017 at 3:12 PM, Ard Biesheuvel\n> wrote:\n>> On 24 August 2017 at 21:02, Rob Herring wrote:\n>>> Cc the DT list for bindings please.\n>>>\n>>> On Thu, Aug 24, 2017 at 1:43 PM, Ard Biesheuvel\n>>> wrote:\n>>>> Describe the binding for firmware-configured instances of the Synopsys\n>>>> Designware PCIe controller in RC mode.\n>>>>\n>>>> Cc: Rob Herring \n>>>> Signed-off-by: Ard Biesheuvel \n>>>> ---\n>>>> Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt | 56 ++++++++++++++++++++\n>>>> 1 file changed, 56 insertions(+)\n>>>>\n>>>> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt\n>>>> new file mode 100644\n>>>> index 000000000000..b8127b19c220\n>>>> --- /dev/null\n>>>> +++ b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt\n>>>> @@ -0,0 +1,56 @@\n>>>> +* Synopsys Designware PCIe root complex in ECAM mode\n>>>> +\n>>>> +In some cases, firmware may already have configured the Synopsys Designware\n>>>> +PCIe controller in RC mode with static ATU window mappings that cover all\n>>>> +config, MMIO and I/O spaces in a [mostly] ECAM compatible fashion.\n>>>> +In this case, there is no need for the OS to perform any low level setup\n>>>> +of clocks or device registers, nor is there any reason for the driver to\n>>>> +reconfigure ATU windows for config and/or IO space accesses at runtime.\n>>>> +\n>>>> +Such hardware configurations should be described as \"pci-host-ecam-generic\"\n>>>> +if they are truly ECAM compatible. Configurations that require no low-level\n>>>> +setup by the OS nor any ATU window reconfiguration at runtime, but do\n>>>> +require special handling for type 0 config TLPs may instead be described as\n>>>> +\"snps,dw-pcie-ecam\".\n>>>\n>>> Humm, what happens when we have the next exception that's SoC specific\n>>> or another vendor?\n>>\n>> This is not SoC specific, but IP specific. We are working with two\n>> different SoCs from completely different vendors that both synthesized\n>> this IP with a 64 KB ATU window size, not expecting this to break ECAM\n>> compatibility.\n>\n> This case is not SoC specific, but quirks/bugs show up in both places.\n> Plus \"dw-pcie\" is fairly meaningless because the IP is both\n> configurable and has multiple releases.\n>\n>>> Seems like perhaps \"firmware initialized\" should\n>>> have been a separate property flag for bootloaders to add rather than\n>>> a compatible string.\n>>>\n>>\n>> Yes, but then you still have 10 different drivers that all retain the\n>> low-level bits that are all different between SoCs. That is exactly\n>> what I want to get rid of, and usually we can do that with existing\n>> bindings, because we simply expose it as pci-host-ecam-generic. Only\n>> in this particular case, that doesn't fly due to the quirk.\n>\n> You can expose it as \"vendor,soc-pcie\", \"pci-host-ecam-generic\" and\n> then the kernel can decide. Then you can use: the default ecam driver,\n> the ecam driver but match on \"vendor,soc-pcie\" for quirks, or a vendor\n> specific driver. The only thing that wouldn't work would be having\n> both quirks in the ecam driver and a vendor driver which IMO we just\n> shouldn't support anyway.\n>\n> Now if you have 10 SoCs all needing this same quirk, then maybe adding\n> \"snps,dw-pcie-ecam\" addtionally to the above makes sense. But that\n> only saves you match strings.\n>\n\nExposing this as \"pci-host-ecam-generic\" doesn't work, or we wouldn't\nbe having this discussion.\n\nSo if I understand you correctly, you would rather have\n\nmarvell,armada8k-pcie-ecam\nsocionext,synquacer-pcie-ecam\n\nand add more of those to the list if needed, and update the\nbinding+driver to use those and drop the generic identifier? I take it\nthat applies to the description of the MSI frame as well?\n\n>>> I'd rather see this done in a way that does not require DT updates if\n>>> quirks have to be handled/added later.\n>>>\n>>\n>> Do you see a way that still allows us to keep the abstraction? I don't\n>> want a flag, I simply don't want to expose any low-level specifics\n>> about the device to the OS, beyond what it needs to use it in its\n>> configured state.\n>\n> That's not how DT works. Detailed information is exposed to the OS and\n> the OS decides if it can handle things generically or not because that\n> decision can change over time. Whenever we don't make things specific\n> enough, we've gotten burned.\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"HBRZOOfm\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xdfLw4dmJz9s9Y\n\tfor ;\n\tFri, 25 Aug 2017 08:37:44 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753556AbdHXWhj (ORCPT );\n\tThu, 24 Aug 2017 18:37:39 -0400","from mail-it0-f44.google.com ([209.85.214.44]:37392 \"EHLO\n\tmail-it0-f44.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753428AbdHXWhi (ORCPT\n\t); Thu, 24 Aug 2017 18:37:38 -0400","by mail-it0-f44.google.com with SMTP id x187so424451ite.0\n\tfor ; Thu, 24 Aug 2017 15:37:38 -0700 (PDT)","by 10.107.162.1 with HTTP; Thu, 24 Aug 2017 15:37:37 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=GbKUX0QgH4rCj+agLRawDAnVw4byeJMg9Hn8Lv35CTM=;\n\tb=HBRZOOfmdyZc0YpYZCd4C74k5mtWowqJy08UJJkwZv7i2LyDqOozDHxV8ea3UdV8xC\n\tayNEk18jvtH14bIiO5HEEoIA0AlI6/jOex/WpcHLx+saXC/rusS8UoHTc8r0KDrz1W5l\n\tBndex7Xiqhfda7bhzsLfBUq1B8xTIkso5rgR8=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=GbKUX0QgH4rCj+agLRawDAnVw4byeJMg9Hn8Lv35CTM=;\n\tb=mQivH3cBOBSR+RD/+TEVwqq1aagEvDVrCakijwKwwB8JViVGQvc7fm1AqJwm7cU+Z2\n\tZ7K3lq/0LTzbfr1F4TZFZ/hYULltfUPq9AxH6o7Nw+reIbDZPWt6ltfQUU57/uwstelD\n\taxo1umoY0kv8YgIqk0HDmUs1CQQPMDRRHT2jBbGet4bmUH1ORMjIcZxtUwXcG6GlV5zP\n\tmHBEYI/CKmT+l3BZG8ikJu5Ka1UEBZ58aY57jx3knv18rHGtGMyM6Zu6xg7q15pwMJ/d\n\t/rjGJhmaIZuF3VdNGKBeoX758VRzfXWsYS7PIndLtFRby4Hamvh/1bGkSDzjWOv+OhQ2\n\tQygg==","X-Gm-Message-State":"AHYfb5iefjjTSIc3B/gG9RnP1l54k0t/aHVLDsqJOF89WEIBgv1AxDR+\n\t2hVGmjD8c+6XOhKOF17U0ZU5a8kmzGifT+oBuw==","X-Received":"by 10.36.10.17 with SMTP id 17mr297622itw.128.1503614257679; Thu,\n\t24 Aug 2017 15:37:37 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170824184321.19432-1-ard.biesheuvel@linaro.org>\n\t<20170824184321.19432-4-ard.biesheuvel@linaro.org>\n\t\n\t\n\t","From":"Ard Biesheuvel ","Date":"Thu, 24 Aug 2017 23:37:37 +0100","Message-ID":"","Subject":"Re: [PATCH v2 3/3] dt-bindings: designware: add binding for\n\tDesignware PCIe in ECAM mode","To":"Rob Herring ","Cc":"\"linux-pci@vger.kernel.org\" ,\n\tMarcin Wojtas ,\n\tLeif Lindholm ,\n\tGraeme Gregory ,\n\tBjorn Helgaas , Jingoo Han ,\n\tJoao Pinto ,\n\tMarc Zyngier ,\n\t\"devicetree@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1756941,"web_url":"http://patchwork.ozlabs.org/comment/1756941/","msgid":"","list_archive_url":null,"date":"2017-08-25T01:22:36","subject":"Re: [PATCH v2 3/3] dt-bindings: designware: add binding for\n\tDesignware PCIe in ECAM mode","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring (Arm)","email":"robh@kernel.org"},"content":"On Thu, Aug 24, 2017 at 5:37 PM, Ard Biesheuvel\n wrote:\n> On 24 August 2017 at 23:12, Rob Herring wrote:\n>> On Thu, Aug 24, 2017 at 3:12 PM, Ard Biesheuvel\n>> wrote:\n>>> On 24 August 2017 at 21:02, Rob Herring wrote:\n>>>> Cc the DT list for bindings please.\n>>>>\n>>>> On Thu, Aug 24, 2017 at 1:43 PM, Ard Biesheuvel\n>>>> wrote:\n>>>>> Describe the binding for firmware-configured instances of the Synopsys\n>>>>> Designware PCIe controller in RC mode.\n>>>>>\n>>>>> Cc: Rob Herring \n>>>>> Signed-off-by: Ard Biesheuvel \n>>>>> ---\n>>>>> Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt | 56 ++++++++++++++++++++\n>>>>> 1 file changed, 56 insertions(+)\n>>>>>\n>>>>> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt\n>>>>> new file mode 100644\n>>>>> index 000000000000..b8127b19c220\n>>>>> --- /dev/null\n>>>>> +++ b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt\n>>>>> @@ -0,0 +1,56 @@\n>>>>> +* Synopsys Designware PCIe root complex in ECAM mode\n>>>>> +\n>>>>> +In some cases, firmware may already have configured the Synopsys Designware\n>>>>> +PCIe controller in RC mode with static ATU window mappings that cover all\n>>>>> +config, MMIO and I/O spaces in a [mostly] ECAM compatible fashion.\n>>>>> +In this case, there is no need for the OS to perform any low level setup\n>>>>> +of clocks or device registers, nor is there any reason for the driver to\n>>>>> +reconfigure ATU windows for config and/or IO space accesses at runtime.\n>>>>> +\n>>>>> +Such hardware configurations should be described as \"pci-host-ecam-generic\"\n>>>>> +if they are truly ECAM compatible. Configurations that require no low-level\n>>>>> +setup by the OS nor any ATU window reconfiguration at runtime, but do\n>>>>> +require special handling for type 0 config TLPs may instead be described as\n>>>>> +\"snps,dw-pcie-ecam\".\n>>>>\n>>>> Humm, what happens when we have the next exception that's SoC specific\n>>>> or another vendor?\n>>>\n>>> This is not SoC specific, but IP specific. We are working with two\n>>> different SoCs from completely different vendors that both synthesized\n>>> this IP with a 64 KB ATU window size, not expecting this to break ECAM\n>>> compatibility.\n>>\n>> This case is not SoC specific, but quirks/bugs show up in both places.\n>> Plus \"dw-pcie\" is fairly meaningless because the IP is both\n>> configurable and has multiple releases.\n>>\n>>>> Seems like perhaps \"firmware initialized\" should\n>>>> have been a separate property flag for bootloaders to add rather than\n>>>> a compatible string.\n>>>>\n>>>\n>>> Yes, but then you still have 10 different drivers that all retain the\n>>> low-level bits that are all different between SoCs. That is exactly\n>>> what I want to get rid of, and usually we can do that with existing\n>>> bindings, because we simply expose it as pci-host-ecam-generic. Only\n>>> in this particular case, that doesn't fly due to the quirk.\n>>\n>> You can expose it as \"vendor,soc-pcie\", \"pci-host-ecam-generic\" and\n>> then the kernel can decide. Then you can use: the default ecam driver,\n>> the ecam driver but match on \"vendor,soc-pcie\" for quirks, or a vendor\n>> specific driver. The only thing that wouldn't work would be having\n>> both quirks in the ecam driver and a vendor driver which IMO we just\n>> shouldn't support anyway.\n>>\n>> Now if you have 10 SoCs all needing this same quirk, then maybe adding\n>> \"snps,dw-pcie-ecam\" addtionally to the above makes sense. But that\n>> only saves you match strings.\n>>\n>\n> Exposing this as \"pci-host-ecam-generic\" doesn't work, or we wouldn't\n> be having this discussion.\n\nExposing it *alone* won't work, but you could match on it for the\ndriver and then in the probe function have an:\n\nif (of_device_is_compatible(np, \"marvell,armada8k-pcie-ecam\"))\n // handle device quirk\n\nI haven't looked at what exactly you need to handle though. I don't\nhave the rest of the series.\n\nBut since you already know the problem, you could just drop\n\"pci-host-ecam-generic\" in this case.\n\n>\n> So if I understand you correctly, you would rather have\n>\n> marvell,armada8k-pcie-ecam\n> socionext,synquacer-pcie-ecam\n>\n> and add more of those to the list if needed, and update the\n> binding+driver to use those and drop the generic identifier?\n\nYes, but dropping the generic identifier depends if you know you have\nsome problem up front. You do here, but that's not always the case.\n\nThe other part is that \"pci-host-ecam-generic\" alone should not be\nconsidered valid other than for VM guests. But I can't really enforce\nthat.\n\n> I take it\n> that applies to the description of the MSI frame as well?\n\nProbably so. Is there something special about it, too?\n\nRob","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=robh@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xdk1d1PDvz9t3m\n\tfor ;\n\tFri, 25 Aug 2017 11:23:01 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754256AbdHYBW6 (ORCPT );\n\tThu, 24 Aug 2017 21:22:58 -0400","from mail.kernel.org ([198.145.29.99]:33314 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1754249AbdHYBW6 (ORCPT );\n\tThu, 24 Aug 2017 21:22:58 -0400","from mail-qt0-f181.google.com (mail-qt0-f181.google.com\n\t[209.85.216.181])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 6CB6521A2D;\n\tFri, 25 Aug 2017 01:22:57 +0000 (UTC)","by mail-qt0-f181.google.com with SMTP id v29so5474431qtv.3;\n\tThu, 24 Aug 2017 18:22:57 -0700 (PDT)","by 10.12.153.1 with HTTP; Thu, 24 Aug 2017 18:22:36 -0700 (PDT)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 6CB6521A2D","X-Gm-Message-State":"AHYfb5iSu+VHjA3B/BwlbsiX6qHk0egJ5D0jFlK2FjEYzIo+qmXRS5qw\n\tvj5yZw+FYswZiYc89cFMsbrKhaWnXQ==","X-Received":"by 10.200.8.35 with SMTP id u32mr857928qth.162.1503624176548;\n\tThu, 24 Aug 2017 18:22:56 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170824184321.19432-1-ard.biesheuvel@linaro.org>\n\t<20170824184321.19432-4-ard.biesheuvel@linaro.org>\n\t\n\t\n\t\n\t","From":"Rob Herring ","Date":"Thu, 24 Aug 2017 20:22:36 -0500","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v2 3/3] dt-bindings: designware: add binding for\n\tDesignware PCIe in ECAM mode","To":"Ard Biesheuvel ","Cc":"\"linux-pci@vger.kernel.org\" ,\n\tMarcin Wojtas ,\n\tLeif Lindholm ,\n\tGraeme Gregory ,\n\tBjorn Helgaas , Jingoo Han ,\n\tJoao Pinto ,\n\tMarc Zyngier ,\n\t\"devicetree@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}}]