From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Daney Subject: Re: [PATCH] net: mdio-octeon: Add PCI driver binding. Date: Thu, 24 Sep 2015 15:45:41 -0700 Message-ID: <56047D15.9080105@caviumnetworks.com> References: <1442968896-30776-1-git-send-email-ddaney.cavm@gmail.com> <20150924.145206.897667718297700953.davem@davemloft.net> <56047367.3060101@caviumnetworks.com> <20150924.151451.1059470233561232912.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150924.151451.1059470233561232912.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: David Miller Cc: ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, pawel.moll-5wv7dgnIgG8@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org List-Id: devicetree@vger.kernel.org On 09/24/2015 03:14 PM, David Miller wrote: > From: David Daney > Date: Thu, 24 Sep 2015 15:04:23 -0700 > >> On 09/24/2015 02:52 PM, David Miller wrote: >>> From: David Daney >>> Date: Tue, 22 Sep 2015 17:41:36 -0700 >>> >>>> From: David Daney >>>> >>>> When the Cavium mdio-octeon devices appear in the Thunder family of >>>> arm64 based SoCs, they show up as PCI devices. Add PCI driver >>>> wrapping so the driver is bound in the standard PCI device scan. >>>> >>>> When in this form, a single PCI device may have more than a single >>>> bus, we call this a "nexus" of buses. The standard firmware >>>> device_for_each_child_node() iterator is used to find the individual >>>> buses underneath the "nexus". >>>> >>>> Update the device tree binding documentation for the new PCI driver >>>> binding. >>>> >>>> Signed-off-by: David Daney >>> >>> This patch breaks the build: >> >> For which architecture? >> >> I tested it on mips and arm64. I will try x86, as I guess that is >> where you tried your test build. > > x86-64. > >> There is, somewhat of, a method behind the madness here. >> >> In order to use MSI-X interrupts, we need a corresponding PCI >> device. Now, this driver doesn't currently use interrupts, but other >> devices in the SoC do, so they must be PCI devices. > > "I need this thing, which isn't needed, therefore I'm making this > change." > That is not the exact argument. It is really more like this: 1) The firmware is supplying a uniform view of the devices by making them all PCI devices. This is done because: a) Devices that use interrupts must be PCI. b) Uniformity is good. 2) The OF device tree nodes for PCI devices do not result in the creation of a platform device. 3) If there is no platform device, platform device driver binding does not occur, and the device is useless to the kernel. So, we think it is a good change. I don't really want to argue about the semantics of it being a "needed change". > Sorry, that's not a good argument. > > ACPI nodes have names and whatnot as well. > > So I haven't heard a compelling argument so far. > > So why not just implement this cleanly and using the existing > framework now, and then when you have a legitimate reason for making a > major change to the probing scheme you can do it then. > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754958AbbIXWpv (ORCPT ); Thu, 24 Sep 2015 18:45:51 -0400 Received: from mail-bn1on0099.outbound.protection.outlook.com ([157.56.110.99]:55516 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753843AbbIXWps (ORCPT ); Thu, 24 Sep 2015 18:45:48 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=David.Daney@caviumnetworks.com; Message-ID: <56047D15.9080105@caviumnetworks.com> Date: Thu, 24 Sep 2015 15:45:41 -0700 From: David Daney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Miller CC: , , , , , , , , , , Subject: Re: [PATCH] net: mdio-octeon: Add PCI driver binding. References: <1442968896-30776-1-git-send-email-ddaney.cavm@gmail.com> <20150924.145206.897667718297700953.davem@davemloft.net> <56047367.3060101@caviumnetworks.com> <20150924.151451.1059470233561232912.davem@davemloft.net> In-Reply-To: <20150924.151451.1059470233561232912.davem@davemloft.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [64.2.3.194] X-ClientProxiedBy: BY2PR07CA059.namprd07.prod.outlook.com (10.141.251.34) To BY1PR0701MB1723.namprd07.prod.outlook.com (25.162.111.142) X-Microsoft-Exchange-Diagnostics: 1;BY1PR0701MB1723;2:vwU4YEubXDbrj3um3/qUio1rhUDhM2UgxI4PzRv30W0FS1eVCpC9ZyjEReOO/ms718yBnB4bRQIotfr04LLg/yKPr20tS91YpX3Yct9hYSWHs1B+IbhQ5JbTCaWJ0bxZwcYHcnamhyBxu4O3Tjn7fe7SDkyLBKMJ3zhx5Lmf5Sk=;3:sbqzOX9sKDFLpVfP23jFzBFbxkp1zJWeK6mEMKB+tNJd9YNEIb9OPckwwLOLiEDdNNlw59NnYFBNy2ZAF1zgKN2z/Wbb9Mtfd43tlFwcxuekMrEg8cewlCiJ2UuPHH2iaKxP7LzoBsY4LKkHpyFWHQ==;25:Iu/uI5pZHqlpobwzjJwzaoeXyClpIupq40+/KU4Y/JmtR/h7APY23LLIojf3CTtdR/XDtL3TGBfvvBE7jJRH800veXVFIP7kQJZNOz3eQiXyZOSzCtKS76qIdHNGOcK/c2Su7Y/caagB2JsPrmWLzb+mrP8umoA+qOUxHJ2kfA/FJBzeukMt8VSw/qd8LTjqBKiSDwJITxWQCNpFcVEyoPYWdKA9GCzEKPLACC8jKCvxP1IsbZSPXmLvqfxSeg1wtTcJjADyOuEoq2weNpYfhA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0701MB1723; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0701MB1723;20:F0NbYd89Ny5kg2d2vPCTIdP8IuOpSx+cibo3+50gRDDasavjxlg4kS7oW1/p3Mh1YjM+Tiif4hYh8RuJTcgd+VWft0votlwqXFW9D16lZytyJii64jDCcRe3IYX2J3t2nPCvvdm/Jd44rBfSHcFVQtV7X6kgvFmXap5MNXMjaRmGZBdEhWUCcOaS+Zms3jKysQBwv7LRpMIBOSmXq4m+G+AR9jorsrU5tDix81JG6EEP3vcB8qK1kixkZYGCu0M+gH4+TFgdxdlNbwwT/BIsE0E+5HTU+Fua/PlQBBDLDBfjVIzQv/nKViU5sEMsawpERbc4lCDjHxNZ/+NPRDaF5KGh6/ayuMHRU9C811hX0kV9/DKVqaDcp5Lv4Iyj6h3bdEX9rN3dQaAtyyXDTT0NEicn6DDSHJWfkzhV06uRx+8p+ktfTCRDsAA3Q0rJj53URVgldg/LMy7blFvjbXQSRXHjM0EmJROr2xLRdBdszZPsLKmfOoTbJarSEZEoTMHHZmBfqkQB23tLauMueVjLWibN0BbUDcsIddDY2y1Tl0EVGY4Ydz6wTdYerb0we3kCa1ygPL8NorBIlKYKrAwI6fUQ9CRZikCl5g51BKKyiMU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001);SRVR:BY1PR0701MB1723;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0701MB1723; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0701MB1723;4:ALAJVUa7RAc35e9/+5YicFQBz/T9AR5TNX/TYYH9NhgOUuqAVVUavZA+j+oxaiwZuOUVvMJ0/nVJv6Qw2+hS2VhIdnQ+orZth35eRqthysBJvbPSw8isqcoJneg3RC8obrBDQ6+dmyl9pUED7bUlwILcQO7W0GkUoO3Vj+lTFzBpkyHEuC5jkXVTr5meSmrlk26HfWNWYp+0UK9dhRqCAgQB6lNNsPR12BHhCuUVYK6PimplkLBZnpFi9r5Tms06th+3xYdzPW6L8I/cNzebgOzfTOaDaXpFooHbHzhD2E34hCyPGlhXs0yjUbfwaqlBuyQGOHZrs2dR4F++ciMHgEgLStXevs2M+99BBZ9rAKM= X-Forefront-PRVS: 070912876F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(24454002)(377454003)(479174004)(189002)(199003)(23756003)(189998001)(53416004)(92566002)(64126003)(2950100001)(69596002)(19580405001)(40100003)(122386002)(46102003)(19580395003)(80316001)(5001960100002)(50466002)(77096005)(110136002)(68736005)(99136001)(33656002)(81156007)(4001540100001)(83506001)(87976001)(62966003)(77156002)(97736004)(47776003)(42186005)(4001350100001)(5007970100001)(59896002)(93886004)(105586002)(5004730100002)(36756003)(76176999)(106356001)(64706001)(54356999)(66066001)(50986999)(87266999)(65806001)(5001860100001)(101416001)(5001830100001)(65816999)(65956001);DIR:OUT;SFP:1101;SCL:1;SRVR:BY1PR0701MB1723;H:dl.caveonetworks.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1;BY1PR0701MB1723;23:X7u9MaVxF9FjA+8rGYJFALwePPQ0EvLuvLBlQ?= =?iso-8859-1?Q?lkXCxNzkg4SuA4+vFFbggtuxW6tLGgAyP1Mo1EJ7bYqWU51JTI5auYl9rX?= =?iso-8859-1?Q?J/LkClvz/RPay8SmN6j69jukQ17loBkP/ZQarIBqYBEH3NDVSq1N9CuR/6?= =?iso-8859-1?Q?6jyh1BfUa4GHAkDS50xb8WqiQCwxzHLqSZX1lbARvqVkFh5WyNLWWnklGL?= =?iso-8859-1?Q?HoqdVIVwl/LwWUBXA71wZfC7Klx0VsouMw7PGgZqhVQBYqCZp5bQBqMlhL?= =?iso-8859-1?Q?StKp5r+pxTBB32yR4ugZ4X0ninz9IPGvF9v/s44qeZqpEH+9K4v5TibUjI?= =?iso-8859-1?Q?HYzaTQ+xupFfG6dRUXKzGNQZi+1ZI0MIBPZrG3yygAb1wPsBnLg8lomS3Z?= =?iso-8859-1?Q?BWJQeWXXBpWGoa6KQwUXAtM6u0ejGryZ+prgpK39NxG0VITpnoYuzrUqCN?= =?iso-8859-1?Q?CYsUluZ10XFAqTC1Rlu3ZwBZJFksF73TD/lV4Hp7dq+WzkZi3dHumCN1iV?= =?iso-8859-1?Q?oPElVb+xoGQC4ACk4Vxk5OrahLnIKWfJJ/3DWDWVhnFyIUOijWt2bkIc/a?= =?iso-8859-1?Q?FKsu7E53mDPBMtdE7AkxdXhS63LXpBb+HbvLEQ+vdbwdZPGXjWebe0c7XN?= =?iso-8859-1?Q?Xm9TUuh2ftEMhCZsUhdqNQPaqyGu1lqExXKYu0Rn/RiE7rFnyimxLW5ODj?= =?iso-8859-1?Q?FKuD4lEksk2IfiCcf3xuNTBGG91C5NFsFlagd/pK9XyFOR1Ap2EOcljbkO?= =?iso-8859-1?Q?H9LVRaPxCo5d792laHL8z1nU8WEvH5+5Df4/t4Hu8v5mSJIG3QSo8O+aCC?= =?iso-8859-1?Q?6CYg4lpFVKshyfeMgT3yvGmjO7kPm/YuRZg4dsC3cIFSmgK3QOGULbDcTg?= =?iso-8859-1?Q?Juk72PL4kgisQ+JIoDN0R0vevnUlbhvGUR1MkR5nQtYzVhSQPzJRWx5IgA?= =?iso-8859-1?Q?N0B3nuoysmA2L5PgfFUP+L7F5fVyNwB3+nzdz38amAQiNpeqYb22xwHzSW?= =?iso-8859-1?Q?fartHtMRQyGPLAkNptm6haHdqDUv5/pf78AU4d52xi4NvYBmtzNS9+beXO?= =?iso-8859-1?Q?pWPvGC2ukRm9o1E6iAIql2kRwtrD18rSNFMM95+7NtG1s75yRTl4F7Iwuy?= =?iso-8859-1?Q?rWq/GKal/lCGNQeqK/TFfl4ofsFOUwSdivDHoxbYfk/ifLycpivwAdGBVf?= =?iso-8859-1?Q?oUmmSO4jAAQ6pgW8YwcjKMXWt+6MP6RBmrriFGSRNfWyyrMkHhsBO72j86?= =?iso-8859-1?Q?8BOjBVCEsKQpUY2Has2yd17OIBvZVdfMLJ0ysZnlpKy6Ba51+VCcnBrBJ9?= =?iso-8859-1?Q?pPIYDrjQNUnrac08o6OkkE7SuJ0OIPkHDf8TmJz1jePqXC3UmPdm6nkNxN?= =?iso-8859-1?Q?uK0UjOZvf5Tni0MDt63g321ynUwQUik9xoIefGy8E00tBpIel/zp1SLjMq?= =?iso-8859-1?Q?M6UOryKa9Fm+hU9WRzsXuysybIQ+J8fkWp0VqFMEkPETGv0Y/YJTSXDksP?= =?iso-8859-1?Q?uuiW0eELDjZ7M5JYltNTZs=3D?= X-Microsoft-Exchange-Diagnostics: 1;BY1PR0701MB1723;5:a/5c/fCAfqi14zEzAgKivWiKTwWIM1dlpyqgmNdqq/s2kFtFeyGBKxF6KuUDrQXZs3XnZ3WqezNaDVJFqfGg9StkIdCh9hkgAgGpcy2LKkGrMcc9DIxHa5pfJJWXwS5NhOVJUPiLxynoLmfZR3xTAg==;24:4frjtJTUf2uGyAPDaY7Yhv3nVmTlj9EQI30QGab5vwOmNVTM0siNhS1jqCyWNcNc8NfvDGH65arDw+dfA8QcxHoao5uJwZySskMTJr9/Ux8=;20:cfp4DnMG0eS+uFZeryo5U4Q/yBMMasxQRbO+VT8vNjM0Gq1RuwKrrGLfUlHOREyNm3PriRaA/fMgvP/zR6vw/g== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2015 22:45:44.4878 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1723 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/24/2015 03:14 PM, David Miller wrote: > From: David Daney > Date: Thu, 24 Sep 2015 15:04:23 -0700 > >> On 09/24/2015 02:52 PM, David Miller wrote: >>> From: David Daney >>> Date: Tue, 22 Sep 2015 17:41:36 -0700 >>> >>>> From: David Daney >>>> >>>> When the Cavium mdio-octeon devices appear in the Thunder family of >>>> arm64 based SoCs, they show up as PCI devices. Add PCI driver >>>> wrapping so the driver is bound in the standard PCI device scan. >>>> >>>> When in this form, a single PCI device may have more than a single >>>> bus, we call this a "nexus" of buses. The standard firmware >>>> device_for_each_child_node() iterator is used to find the individual >>>> buses underneath the "nexus". >>>> >>>> Update the device tree binding documentation for the new PCI driver >>>> binding. >>>> >>>> Signed-off-by: David Daney >>> >>> This patch breaks the build: >> >> For which architecture? >> >> I tested it on mips and arm64. I will try x86, as I guess that is >> where you tried your test build. > > x86-64. > >> There is, somewhat of, a method behind the madness here. >> >> In order to use MSI-X interrupts, we need a corresponding PCI >> device. Now, this driver doesn't currently use interrupts, but other >> devices in the SoC do, so they must be PCI devices. > > "I need this thing, which isn't needed, therefore I'm making this > change." > That is not the exact argument. It is really more like this: 1) The firmware is supplying a uniform view of the devices by making them all PCI devices. This is done because: a) Devices that use interrupts must be PCI. b) Uniformity is good. 2) The OF device tree nodes for PCI devices do not result in the creation of a platform device. 3) If there is no platform device, platform device driver binding does not occur, and the device is useless to the kernel. So, we think it is a good change. I don't really want to argue about the semantics of it being a "needed change". > Sorry, that's not a good argument. > > ACPI nodes have names and whatnot as well. > > So I haven't heard a compelling argument so far. > > So why not just implement this cleanly and using the existing > framework now, and then when you have a legitimate reason for making a > major change to the probing scheme you can do it then. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Daney Subject: Re: [PATCH] net: mdio-octeon: Add PCI driver binding. Date: Thu, 24 Sep 2015 15:45:41 -0700 Message-ID: <56047D15.9080105@caviumnetworks.com> References: <1442968896-30776-1-git-send-email-ddaney.cavm@gmail.com> <20150924.145206.897667718297700953.davem@davemloft.net> <56047367.3060101@caviumnetworks.com> <20150924.151451.1059470233561232912.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: , , , , , , , , , , To: David Miller Return-path: In-Reply-To: <20150924.151451.1059470233561232912.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org On 09/24/2015 03:14 PM, David Miller wrote: > From: David Daney > Date: Thu, 24 Sep 2015 15:04:23 -0700 > >> On 09/24/2015 02:52 PM, David Miller wrote: >>> From: David Daney >>> Date: Tue, 22 Sep 2015 17:41:36 -0700 >>> >>>> From: David Daney >>>> >>>> When the Cavium mdio-octeon devices appear in the Thunder family of >>>> arm64 based SoCs, they show up as PCI devices. Add PCI driver >>>> wrapping so the driver is bound in the standard PCI device scan. >>>> >>>> When in this form, a single PCI device may have more than a single >>>> bus, we call this a "nexus" of buses. The standard firmware >>>> device_for_each_child_node() iterator is used to find the individual >>>> buses underneath the "nexus". >>>> >>>> Update the device tree binding documentation for the new PCI driver >>>> binding. >>>> >>>> Signed-off-by: David Daney >>> >>> This patch breaks the build: >> >> For which architecture? >> >> I tested it on mips and arm64. I will try x86, as I guess that is >> where you tried your test build. > > x86-64. > >> There is, somewhat of, a method behind the madness here. >> >> In order to use MSI-X interrupts, we need a corresponding PCI >> device. Now, this driver doesn't currently use interrupts, but other >> devices in the SoC do, so they must be PCI devices. > > "I need this thing, which isn't needed, therefore I'm making this > change." > That is not the exact argument. It is really more like this: 1) The firmware is supplying a uniform view of the devices by making them all PCI devices. This is done because: a) Devices that use interrupts must be PCI. b) Uniformity is good. 2) The OF device tree nodes for PCI devices do not result in the creation of a platform device. 3) If there is no platform device, platform device driver binding does not occur, and the device is useless to the kernel. So, we think it is a good change. I don't really want to argue about the semantics of it being a "needed change". > Sorry, that's not a good argument. > > ACPI nodes have names and whatnot as well. > > So I haven't heard a compelling argument so far. > > So why not just implement this cleanly and using the existing > framework now, and then when you have a legitimate reason for making a > major change to the probing scheme you can do it then. > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html