From patchwork Mon Mar 13 08:14:19 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gabriele Paoloni X-Patchwork-Id: 9619985 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id BCB8060244 for ; Mon, 13 Mar 2017 08:14:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AA393283BA for ; Mon, 13 Mar 2017 08:14:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9C08828417; Mon, 13 Mar 2017 08:14:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8C164283BA for ; Mon, 13 Mar 2017 08:14:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751068AbdCMIOm convert rfc822-to-8bit (ORCPT ); Mon, 13 Mar 2017 04:14:42 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:48698 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751004AbdCMIOl (ORCPT ); Mon, 13 Mar 2017 04:14:41 -0400 Received: from 172.24.1.137 (EHLO nkgeml411-hub.china.huawei.com) ([172.24.1.137]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVJ78675; Mon, 13 Mar 2017 16:14:37 +0800 (CST) Received: from FRAEML701-CAH.china.huawei.com (10.206.14.32) by nkgeml411-hub.china.huawei.com (10.98.56.70) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 13 Mar 2017 16:14:34 +0800 Received: from FRAEML521-MBX.china.huawei.com ([169.254.1.242]) by FRAEML701-CAH.china.huawei.com ([10.206.14.32]) with mapi id 14.03.0301.000; Mon, 13 Mar 2017 09:14:21 +0100 From: Gabriele Paoloni To: Mark Rutland , "liudongdong (C)" , Bjorn Helgaas CC: "Wangzhou (B)" , "devicetree@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: Bad DT binding (hisi-pcie-almost-ecam) Thread-Topic: Bad DT binding (hisi-pcie-almost-ecam) Thread-Index: AQHSmcWDRNN6g20vXkSgiBf6vOqy/KGSa0EA Date: Mon, 13 Mar 2017 08:14:19 +0000 Message-ID: References: <20170310174045.GB24571@leverpostej> In-Reply-To: <20170310174045.GB24571@leverpostej> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.85.132] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58C654ED.0111, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.242, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 424da683cd720b365f2b985d6c6b221f Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Mark > -----Original Message----- > From: Mark Rutland [mailto:mark.rutland@arm.com] > Sent: 10 March 2017 17:41 > To: liudongdong (C); Bjorn Helgaas > Cc: Gabriele Paoloni; Wangzhou (B); devicetree@vger.kernel.org; linux- > pci@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Bad DT binding (hisi-pcie-almost-ecam) > > I've just spotted commit: > > a2ec1996098c7da0 ("PCI: hisi: Add DT almost-ECAM support for > Hip06/Hip07 host controllers") > > ... which went in for v4.11-rc1. > > I hadn't seen this until now, and as far as I can tell this never went > to the devicetree list. Sorry about this, we'll be more careful next time > > The commit adds the "hisilicon,pcie-almost-ecam", which goes against > the > usual DT conventions, and is non-sensical in that it describes the IP > based on what it isn't. > > This binding shouldn't have gone in as-is, and we should fix it before > v4.11. > > The binding states that this IP is found in Hip06 and Hip07. For these > cases we'd usually take the name of the first implementation, e.g. > something like "hisilicon,hip06-pcie", which can be used as a fallback > in the compatible list if reused in subsequent SoC generations. > > I also see that "hisilicon,hip06-pcie" already exists, so I'm even more > suspicious. For Hip06 the IP is the same but in we have a different BIOS configuration that allows the controller be ECAM compliant for all the devices of the hierarchy except the RC. > > What exactly is the "hisilicon,pcie-almost-ecam" binding trying to > describe? Is it a different IP also found on Hip06, or is it a new > binding for the same IP? The reason why we need this new BIOS is to support the recent PCIe quirks for the ACPI Root Port driver (commit 5b69b85ba1ddd36be01f5c57830b37a3c8256009 "PCI/ACPI: Check for platform-specific MCFG quirks"). So using one BIOS we support both DT and ACPI. This is the reason why you see Hip-06 being already there... About the name to use here from what you suggest we should use "hisilicon,hip06-pcie-almost-ecam" and re-use it for hip07 SoC. To be honest I would prefer it either as it is now or to modify the driver as: What do you think? Many Thanks Gab > > Thanks, > Mark. diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c index 52f1e3f..7527b4c 100644 --- a/drivers/pci/dwc/pcie-hisi.c +++ b/drivers/pci/dwc/pcie-hisi.c @@ -381,7 +381,11 @@ struct pci_ecam_ops hisi_pcie_platform_ops = { static const struct of_device_id hisi_pcie_almost_ecam_of_match[] = { { - .compatible = "hisilicon,pcie-almost-ecam", + .compatible = "hisilicon,pcie-almost-ecam-hip06", + .data = (void *) &hisi_pcie_platform_ops, + }, + { + .compatible = "hisilicon,pcie-almost-ecam-hip07", .data = (void *) &hisi_pcie_platform_ops, }, {},