From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752962AbcBEOjt (ORCPT ); Fri, 5 Feb 2016 09:39:49 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:51803 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751534AbcBEOjr (ORCPT ); Fri, 5 Feb 2016 09:39:47 -0500 From: Arnd Bergmann To: Joao Pinto Cc: Bjorn Helgaas , Vineet.Gupta1@synopsys.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org, CARLOS.PALMINHA@synopsys.com, Alexey.Brodkin@synopsys.com, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org Subject: Re: [PATCH v8 2/2] add new platform driver for PCI RC Date: Fri, 05 Feb 2016 15:39:05 +0100 Message-ID: <4427983.0G6mVNKP5W@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56B47D0D.5030204@synopsys.com> References: <20160204234334.GH7031@localhost> <56B47D0D.5030204@synopsys.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:SPQXbr6oEtHxDWwmxv5NPs9rDuyy8xjvUThuyfysUdRD59hwVo3 PSi+Lt3ccHJaxL+gizsE3mW6qF1KHds8V+96jPIeuITJnPyjoBgXov4GsEgF134QpPciXgv aOUrfAvTv2s+plxmzBrYfUoN07B4lHQI4ZEWIGDK2rXs5kjy4meWfvxduY4rF8noPgw8h03 OhgEp7N30eKLUTtU0R+iw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZlEPt2xaQQw=:+JosFkP9oemUgyXGwYe92Q kOccSU5qWSfrxok6ihztpUiUb3WC5MUyQXaKX9AaOZUW4Nz7SZhNyMqgfbzD2z2n3rzyElPpA Liho5eHNOqpN7/GL34TBYoIPiG1np/DJOu2oyuUDmHNhcp8YyJOy2eAR5x1l2YUYGNiab9GlT 65m/69m1ps91LM5KinrJKgRuuDjEYADm2u9XbHUb/fbM4FWfCtRk4yI8vfRfiJW426SYWH/zr RZ4Wq7LjXyzFG7Rl1+afZ+acisjn51odo/w7wJIAOd0mRoPSbIDZfIF2v2sGo+ZfguI/bMnAx Rm5rO4EgbGz6qin0BbM1LW7ov8cBLJh3xrjlyiCftmJgKByGw4Ktvkj8yIkrlAClF7zZ97Pr3 JrUMXsFH7XXtPfGdchhnLmZPUVrTdH/U55t/R27v88hpqgIf7O7wmq0VYvRtQ0Q99Xbx6Wr/R VLSOzn9erseVtx+08t5FEohqVovT+FekdPtX7WuWLqLGMnoVW1UBXr1Im8H5yZ6XOfZahy/py 5LwGSWxfvV95DZxVn5mwzbzLcp/4MaeEvZqsL2TCPyEOihD7A7xTar+C6YkbGqCgcWBkthBsZ E4CH5PAqJaqdBSyt2QNE5lajWAp3WQQqYufVj59Zgr5cSfh2olUrbaWbzzUCSDYEOijQSOLLs ysroZYPYZpJAjHExA1i2oPRKJbbtnWZ2Zk9FChpctCYa8JDBsC8NM1KgY4LEAFtlG3EbL3X1a 51v2x/W83ii30cmn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 05 February 2016 10:44:29 Joao Pinto wrote: > Hi, > > On 2/4/2016 11:43 PM, Bjorn Helgaas wrote: > >> What do you think? > > > > I don't think the "dw" part is relevant (none of the other > > DesignWare-based drivers includes it in the driver or file name). > > > > How do people typically refer to this board? > > > > I really like "synopsys" because it fits the pattern of being > > recognizable and pronounceable like "altera", "designware", "qcom", > > "keystone", "layerscape", "tegra", etc. But I can't tell whether it's > > too generic. > > > > "ipk" or "haps" would be fine with me. I think it's OK if it doesn't > > cover 100% of the possible systems. > > I think we should follow the iproc example: pcie-iproc-platform.c > In this case we would have pcie-designware-platform.c > I think this would be the best name because the driver is a non soc specific > designware platform driver. > > Arnd and Bjorn agree on this name? Sorry, I did not realize that your submission was for the generic dw-pcie implementation rather than a particular product integrating it. I think in this case, we should do this completely differently: How about putting all the new code into drivers/pci/host/pcie-designware.c as functions that can be used by the other drivers in absence of a chip specific handler? Instead of providing a new instance of struct pcie_host_ops, maybe add it as a default implementation in dw_pcie_link_up() and dw_pcie_host_init() for drivers that don't provide their own. "hisi_pcie_host_ops" currently provides no host_init() callback function, so you will have to change the hisi frontend to a provide nop-function. For all other drivers, check if they can be changed to use your generic implementation and remove their private callbacks if possible. I think the MSI implementation should be split out into a separate file though, as not everyone uses this. Arnd