From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751737AbcGQUm1 (ORCPT ); Sun, 17 Jul 2016 16:42:27 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:63010 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751138AbcGQUmZ (ORCPT ); Sun, 17 Jul 2016 16:42:25 -0400 From: Arnd Bergmann To: Jamie Lentin Cc: linux-arm-kernel@lists.infradead.org, Jason Cooper , Andrew Lunn , Sebastian Hesselbarth , Gregory Clement , Imre Kaloz , Florian Fainelli , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T Date: Sun, 17 Jul 2016 22:41:35 +0200 Message-ID: <6404488.GyOP57DJrV@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1468679348-10522-1-git-send-email-jm@lentin.co.uk> <4290281.AD5Bhg23o6@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:FLa7LyaSmpvB1g+Dx6bK3Kfrj13pBbbQKXlijnhs4eMRL9X4CON NsFrJaAMF+6rlASUEbZWnq/Zj4ZMsElpbKueoA7T01k68hAN3FUBF0ctEAas4PIEx2Bx2aO O13sGV/VvT9cUFxSvGHvPuVBbDlywptvaoCbfhEtcA57+WJk63xOh3rfExRlzrIkkX8CYQ/ hk0FwNAGXIZ5kilB/zd4w== X-UI-Out-Filterresults: notjunk:1;V01:K0:fCIBh29Hki4=:Xa6uH4rdsh4LgT3s/vV3SD 4201/YbH8KsnMB1VnGl/5tQtQQEjN+4XC7gcPPPRfvPDM1RA0IBh/U/pQP5LhNrRT1isRi5vr MmlhWr0JFTAFTx4KmZxZ18LhKYBrvJJ2NVomukm5fdLM/cBCpKHpp/UBd2u/9L2Y33ZMn661o z1rRQ5jWlz7fB8vugdHAT9pMLsAQG6GMu0SEmynA2xnNkv10LOyzaCMql+KvVJriel5bsbkIJ WtuXYooUB8Sqhf1QvL8N8R9NGIJNBSjUN7p/yzUu3n3y3pX4WbDngo1mLP/QDUOdPJCPpyAVl 9SXhwsMbsoQRXH5c8uiEpi6B3o1BzDUKySYTX4sUzu72BFzqDh17jCFdLADsmsrOgq1KHELw3 xGo+YPJ3h8mMm8bFte+8mXcyI+aP05IQbeFFH1VCPKAaRer6keANKv9Ov2wbUlt8+l2tAZSQA VV+4Ee5uDzdYEfAI7b5VfFjJucEbH3D+3cEQwf1yOGfLAyTKWo1LsMbqnDjTAKP2ZB4gCsSRl 9dy6hPPZTUEhqzgbFrNYa/xswniLJnJVL+DmfAFBzcYSGMBuSbPg6a32jbVxUBI7aMdXu4YVk TTwZ9pacnGmywqJfCX46AFstAdJWNXmOMgvyr/l+6R6yUUH8XgnmcUjpV2z+CWvyLuzWU8/zl AKvBDF5RYoI+sxgoRA/l19thOgcS+we6X7dRbGuxmEtoJe1WgsjWMXlxF7K0KECRMx20O03av qF2h0Hc7lIWvt6mI Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sunday, July 17, 2016 10:39:01 AM CEST Jamie Lentin wrote: > On Sat, 16 Jul 2016, Arnd Bergmann wrote: > > The other patches all appear good to me, but I find this one suspicious. > > > > Why are you not using the device tree for probing PCI? Is there anything > > missing in drivers/pci/host/pci-mvebu.c, or do you just need help > > describing it in DT? > > Unlike the other SoC's supported by pci-mvebu.c, orion5x has one PCI port > as well as a PCIe port. Given no other orion5x boards seem to use > pci-mvebu, I'm assuming there's work to be done before the PCI port can be > used via. pci-mvebu.c > > This is something I can look into if there aren't patches out there, but > wanted to get the rest into a reasonable state first. Ok, I see your point. However, we also don't have any other Orion5x machines using DT that rely on old probe method, and I this is something that is particularly hard to retrofit later. I would assume that the PCIe port should work out of the box with the driver we have, but the PCI controller does not, and it will require some work. Looking at https://wiki.openwrt.org/toh/netgear/wnr854t, I assume that you want only PCI but not PCIe, correct? The good news is that we can completely separate the two, we just have two different PCI domains if both are enabled, so we just need to add a new driver for the PCI port to drivers/pci/host. The pci_ops can be copied from the existing driver, although a couple of minor cleanups would be possible. The special handling of bus numbers and the rc_pci_fixup() can probably just go away, and the latter part is particularly important, because building a kernel with the fixup included might break any system with a Marvell host bridge. We also don't seem to need any MBUS window setup for the I/O and memory spaces, which greatly simplifies the driver compared to the pci-mvebu one, it would be a fairly straightforward implementation based on pci-host-generic.c (which unfortunately just got way more complicated and might need to go on a diet). Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Sun, 17 Jul 2016 22:41:35 +0200 Subject: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T In-Reply-To: References: <1468679348-10522-1-git-send-email-jm@lentin.co.uk> <4290281.AD5Bhg23o6@wuerfel> Message-ID: <6404488.GyOP57DJrV@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Sunday, July 17, 2016 10:39:01 AM CEST Jamie Lentin wrote: > On Sat, 16 Jul 2016, Arnd Bergmann wrote: > > The other patches all appear good to me, but I find this one suspicious. > > > > Why are you not using the device tree for probing PCI? Is there anything > > missing in drivers/pci/host/pci-mvebu.c, or do you just need help > > describing it in DT? > > Unlike the other SoC's supported by pci-mvebu.c, orion5x has one PCI port > as well as a PCIe port. Given no other orion5x boards seem to use > pci-mvebu, I'm assuming there's work to be done before the PCI port can be > used via. pci-mvebu.c > > This is something I can look into if there aren't patches out there, but > wanted to get the rest into a reasonable state first. Ok, I see your point. However, we also don't have any other Orion5x machines using DT that rely on old probe method, and I this is something that is particularly hard to retrofit later. I would assume that the PCIe port should work out of the box with the driver we have, but the PCI controller does not, and it will require some work. Looking at https://wiki.openwrt.org/toh/netgear/wnr854t, I assume that you want only PCI but not PCIe, correct? The good news is that we can completely separate the two, we just have two different PCI domains if both are enabled, so we just need to add a new driver for the PCI port to drivers/pci/host. The pci_ops can be copied from the existing driver, although a couple of minor cleanups would be possible. The special handling of bus numbers and the rc_pci_fixup() can probably just go away, and the latter part is particularly important, because building a kernel with the fixup included might break any system with a Marvell host bridge. We also don't seem to need any MBUS window setup for the I/O and memory spaces, which greatly simplifies the driver compared to the pci-mvebu one, it would be a fairly straightforward implementation based on pci-host-generic.c (which unfortunately just got way more complicated and might need to go on a diet). Arnd