[{"id":1797889,"web_url":"http://patchwork.ozlabs.org/comment/1797889/","msgid":"<20171102124339.GF4772@lunn.ch>","list_archive_url":null,"date":"2017-11-02T12:43:39","subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> +static int bgx_probe(struct platform_device *pdev)\n> +{\n> +\tstruct mac_platform_data platform_data;\n> +\tconst __be32 *reg;\n> +\tu32 port;\n> +\tu64 addr;\n> +\tstruct device_node *child;\n> +\tstruct platform_device *new_dev;\n> +\tstruct platform_device *pki_dev;\n> +\tint numa_node, interface;\n> +\tint i;\n> +\tint r = 0;\n> +\tchar id[64];\n> +\tu64 data;\n> +\n> +\treg = of_get_property(pdev->dev.of_node, \"reg\", NULL);\n> +\taddr = of_translate_address(pdev->dev.of_node, reg);\n> +\tinterface = (addr >> 24) & 0xf;\n> +\tnuma_node = (addr >> 36) & 0x7;\n> +\n> +\t/* Assign 8 CAM entries per LMAC */\n> +\tfor (i = 0; i < 32; i++) {\n> +\t\tdata = i >> 3;\n> +\t\toct_csr_write(data, BGX_CMR_RX_ADRX_CAM(numa_node, interface, i));\n> +\t}\n> +\n> +\tfor_each_available_child_of_node(pdev->dev.of_node, child) {\n> +\t\tsnprintf(id, sizeof(id), \"%llx.%u.ethernet-mac\",\n> +\t\t\t (unsigned long long)addr, port);\n> +\t\tnew_dev = of_platform_device_create(child, id, &pdev->dev);\n> +\t\tif (!new_dev) {\n> +\t\t\tdev_err(&pdev->dev, \"Error creating %s\\n\", id);\n> +\t\t\tcontinue;\n> +\t\t}\n> +\t\tplatform_data.mac_type = BGX_MAC;\n> +\t\tplatform_data.numa_node = numa_node;\n> +\t\tplatform_data.interface = interface;\n> +\t\tplatform_data.port = port;\n> +\t\tif (is_xcv)\n> +\t\t\tplatform_data.src_type = XCV;\n> +\t\telse\n> +\t\t\tplatform_data.src_type = QLM;\n> +\n> +\t\t/* Add device to the list of created devices so we can remove it\n> +\t\t * on exit.\n> +\t\t */\n> +\t\tpdev_item = kmalloc(sizeof(*pdev_item), GFP_KERNEL);\n> +\t\tpdev_item->pdev = new_dev;\n> +\t\tmutex_lock(&pdev_list_lock);\n> +\t\tlist_add(&pdev_item->list, &pdev_list);\n> +\t\tmutex_unlock(&pdev_list_lock);\n> +\n> +\t\ti = atomic_inc_return(&pki_id);\n> +\t\tpki_dev = platform_device_register_data(&new_dev->dev,\n> +\t\t\t\t\t\t\tis_mix ? \"octeon_mgmt\" : \"ethernet-mac-pki\",\n> +\t\t\t\t\t\t\ti, &platform_data, sizeof(platform_data));\n> +\t\tdev_info(&pdev->dev, \"Created %s %u: %p\\n\",\n> +\t\t\t is_mix ? \"MIX\" : \"PKI\", pki_dev->id, pki_dev);\n\nIs there any change of these ethernet ports being used to connect to\nan Ethernet switch. We have had issues in the past with these sort of\nplatform devices combined with DSA.\n\n\t Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@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=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySPsd0G0tz9sDB\n\tfor ;\n\tThu, 2 Nov 2017 23:44:05 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932424AbdKBMnu (ORCPT );\n\tThu, 2 Nov 2017 08:43:50 -0400","from vps0.lunn.ch ([185.16.172.187]:38932 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752139AbdKBMnr (ORCPT );\n\tThu, 2 Nov 2017 08:43:47 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1eAEqR-0006oC-DF; Thu, 02 Nov 2017 13:43:39 +0100"],"Date":"Thu, 2 Nov 2017 13:43:39 +0100","From":"Andrew Lunn ","To":"David Daney ","Cc":"linux-mips@linux-mips.org, ralf@linux-mips.org,\n\tJames Hogan , netdev@vger.kernel.org,\n\t\"David S. Miller\" ,\n\tRob Herring , Mark Rutland ,\n\tlinux-kernel@vger.kernel.org, \"Steven J. Hill\" ,\n\tdevicetree@vger.kernel.org, Carlos Munoz ","Subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","Message-ID":"<20171102124339.GF4772@lunn.ch>","References":"<20171102003606.19913-1-david.daney@cavium.com>\n\t<20171102003606.19913-7-david.daney@cavium.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20171102003606.19913-7-david.daney@cavium.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1798032,"web_url":"http://patchwork.ozlabs.org/comment/1798032/","msgid":"<521d6b21-b7f0-66e0-4b49-cf95d83452d1@caviumnetworks.com>","list_archive_url":null,"date":"2017-11-02T15:55:33","subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","submitter":{"id":721,"url":"http://patchwork.ozlabs.org/api/people/721/","name":"David Daney","email":"ddaney@caviumnetworks.com"},"content":"On 11/02/2017 05:43 AM, Andrew Lunn wrote:\n[...]\n>> +\n>> +\t\ti = atomic_inc_return(&pki_id);\n>> +\t\tpki_dev = platform_device_register_data(&new_dev->dev,\n>> +\t\t\t\t\t\t\tis_mix ? \"octeon_mgmt\" : \"ethernet-mac-pki\",\n>> +\t\t\t\t\t\t\ti, &platform_data, sizeof(platform_data));\n>> +\t\tdev_info(&pdev->dev, \"Created %s %u: %p\\n\",\n>> +\t\t\t is_mix ? \"MIX\" : \"PKI\", pki_dev->id, pki_dev);\n> \n> Is there any change of these ethernet ports being used to connect to\n> an Ethernet switch. We have had issues in the past with these sort of\n> platform devices combined with DSA.\n> \n\nThere are only two possibilities. The BGX MACs have a multiplexer that \nallows them to be connected to either the \"octeon_mgmt\" MIX packet \nprocessor, or to the \"ethernet-mac-pki\" PKI/PKO packet processor. The \nSoCs supported by these drivers do not contain any hardware that would \nbe considered an \"Ethernet switch\".\n\nI'm not sure I fully understand what your question is though, so I may \nnot have answered it.\n\nDavid Daney","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@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=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"Xwha/gL+\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=David.Daney@cavium.com; "],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySV725n1lz9t2M\n\tfor ;\n\tFri, 3 Nov 2017 02:55:58 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S933872AbdKBPzo (ORCPT );\n\tThu, 2 Nov 2017 11:55:44 -0400","from mail-cys01nam02on0048.outbound.protection.outlook.com\n\t([104.47.37.48]:55503\n\t\"EHLO NAM02-CY1-obe.outbound.protection.outlook.com\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S932244AbdKBPzl (ORCPT );\n\tThu, 2 Nov 2017 11:55:41 -0400","from ddl.caveonetworks.com (50.233.148.156) by\n\tMWHPR07MB3503.namprd07.prod.outlook.com (10.164.192.30) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.197.13; Thu, 2 Nov 2017 15:55:36 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=BK/LFZBs3gmGskjR4lv5TiU75DKo9CIPrPFqP0rUT8Q=;\n\tb=Xwha/gL+uHpQUwroF45v0M5NdaBNbQ0Kj9PmOp+gb8Wv9My2sP13gCTlC9+XbqNpbG0ny5wZEAdtyRDdDW0beaYwZuFePsmfckElltfG5JqFMeUP+/TP20beCfnOJqfeFjKJqzldY6QJCK9zbpqkXc7D1+5CF3ei4VIef5N4d2k=","Subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","To":"Andrew Lunn , David Daney ","Cc":"linux-mips@linux-mips.org, ralf@linux-mips.org,\n\tJames Hogan , netdev@vger.kernel.org,\n\t\"David S. Miller\" ,\n\tRob Herring , Mark Rutland ,\n\tlinux-kernel@vger.kernel.org, \"Steven J. Hill\" ,\n\tdevicetree@vger.kernel.org, Carlos Munoz ","References":"<20171102003606.19913-1-david.daney@cavium.com>\n\t<20171102003606.19913-7-david.daney@cavium.com>\n\t<20171102124339.GF4772@lunn.ch>","From":"David Daney ","Message-ID":"<521d6b21-b7f0-66e0-4b49-cf95d83452d1@caviumnetworks.com>","Date":"Thu, 2 Nov 2017 08:55:33 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<20171102124339.GF4772@lunn.ch>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[50.233.148.156]","X-ClientProxiedBy":"DM5PR07CA0032.namprd07.prod.outlook.com (10.168.109.18) To\n\tMWHPR07MB3503.namprd07.prod.outlook.com (10.164.192.30)","X-MS-PublicTrafficType":"Email","X-MS-Office365-Filtering-Correlation-Id":"9f0c69eb-743c-4296-1dc8-08d5220a2937","X-Microsoft-Antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199);\n\tSRVR:MWHPR07MB3503; ","X-Microsoft-Exchange-Diagnostics":["1; MWHPR07MB3503;\n\t3:57dMwCarFDCVlQ3/GA9hvwZxeCBDrhAWL5jVGYoCiJxA5f/e+r7ljgI3zvhl2RTr9Man7gTA87TLZOoim2m1ATVb4USVtr6fd9vU/7daRnYTyhu62rGmvjzoANQosbUFN6mrkz7Xpk1QfOaE+gAFr7yNWS/2ODkcZHQgJPEk2RjoqSbNGX30cDaFl8kI4M29K4opnGFobhCU477Q0gG8TsUoBOpoFIdNBnLdWzRjnhAysFQX/luvZy5HpIZzpFh0;\n\t25:lyYMg0DkU8/kcKTcmTgOO+Z7367ZLFWmuj8sN/7B3fo5+dC5LIE1BLsceBrtMY7Gk8lXdNBsNRwKU3izLgdH3ehpxwaqKYppYlLy9oRubMKrNyCVv/OiFLt9cBhSr40TLmdCNi2ktFZoA5W8jvfDEEihHA/a+WtBBi07UQwY5kZVQozOHrZuxk5IQpNUPCLciEAZZrfNOtHuU4gAdhP1oMlrklSY+B0nqIRF26qUky8UEMqwfdQqEQ4wF7XgoB7k/KJSqju6XkF69HAkl07srsbR6wbMCRQ0B2eJ8nKm6tzgs00g/GL+P3Qd9ycTAg7RQ0sJQmi5kcJJU8SGGI7ySA==;\n\t31:/0u2uSqej1cVho0fWpHWx5FkYmxxGRxpX5gqxkvwy5VSyx8xzl/FdOJ29A5XJRqFiigFayHs215Hbn/cNrJ3Y6JK9CHWieRw2W3rQ92oeL+S6Ll4a6OSgkKj4PZfggfjx7CBImICzVb6JhVCzNK9oG+oJd8WD1JQlCaZgvBVsqrlwbcuZvJ0mWRjUmi39wL81By2GjIxnbP7s+HgmdWijEd+WECrQ3bVErpIk25UuGQ=","1; MWHPR07MB3503;\n\t20:y4DZ9XutLUbNInSHLI6YxpZQUuw10bzC4VtLZ1N0a7VGJjGhjOmtBU86mgHVhxaqZyamcY6lBmkK6tUV6Nv1IIX+9ej7jTBZLgoUr11F4lodxVwG1mB7oAv03k1fEEF2uGqXGTcc2uGsD9wMEdgSpNiIzxOm4k0wN1mgcv+PA0r6TMUFJ9JhRVoS73KDS5xdb0BR9lUiX33wh4luYVLpCSKr/OdnAfDKMPvMuUmc3X2xIpTJG+a40oOmJAJTGhkHJdWi/04s/WI0dnRd8RBxKmHgMQoq2HqWlz8IkhMrxW+lRuM5Wc/IvQthnuCsgHvUgImUG7c4gtAsQ5mSvduCaoRfO5gd9OwVY4bkCP5S8emt495HwwWK/uanlFyOkhcGAfkCA/CTfJ4quEIusm04ZotPYXyGGdjGr3SY1ms1earaCwh023CqHS/qn67H3T4x/t0aCxq0N4akANoieucLA5Bpbhr+s1BkC/mUEXAoPxmmpkfwfPJ1eVJM6jOY9Wauh+Mxa1qo08Ohd8ITQ84REIpWd+A/47FVEc5RWr5n4/ka9MhZ11e8N4pdfL7i3AHjL0W7RzJIxzKQnq+RsDf+rS6CnnCoLxNh5rka3nGCfQE=;\n\t4:UXoHjjZfdqkz5eF/efHLxdEBbZ3CWcPYK7R/PQVjRKX/DYt8SVeu5kZ04qLR8jx0T014P6LY/5xCYY1mEK/WJZchV/6iGtBUsaIFAC8JXj6RgjHTGkOe5jzA8kr9Uj5Pt4fMV7gtnNubcxlGsqcAq5z++FO65WiPcW5QY2wMdbx9IgWQf4NIXwnjhHyMpvw0gMk7c/9MpTE2zOmPUg739AS6+qf/5EV+IRT+KOjN9IALhigOOBC+A8rMLSozHypxLM4kzNoNr7K6TI/cOBuRuffJDHvcqD9U6phPHdfQdoV/KHxEgWYtP1Ixl6JVqsN1","=?utf-8?q?1=3BMWHPR07MB3503=3B23=3AuREg?=\n\t=?utf-8?q?1ku/NifC5eG7RS9Wm4cVDbJCddCPpsGThMBPnO3JqKyrTq0BPZllHZEi?=\n\t=?utf-8?q?ChWnOc7Lb/SUFBy1pxeO+uBuQ+7XFN83Ig+WwnUj8uXN/oMeGMdYy7bR?=\n\t=?utf-8?q?eC9IDwBErNicgOeDXmL/LOpBD9X+15Sas7DCjQ+SQEfToua7MduFJsBJ?=\n\t=?utf-8?q?StSwSEnU68e2b/Pory5yevjti01fLRH7Qgz6CqcxE6XBGYTKvcoKDr9D?=\n\t=?utf-8?q?is0yoBzZ452weYdFzsFG2q+a8UgzStXmP+s43X2SMQ2MP74rNYH19tuO?=\n\t=?utf-8?q?WD3pGWumBKEsLA0tw+qO6rfK08UZdLuvgI3JOQq3pn0YU//IiqqfTL3P?=\n\t=?utf-8?q?szx0dcPap0fvLOb49TyMeNwVSOXRQhACEkBgedRfwHgN0dZAmm1eUM8u?=\n\t=?utf-8?q?5mhpxBnGw8FaMfNALgvYmteQNt7DzXPiqXTXh6o+F+z5KKWwHmynGljU?=\n\t=?utf-8?q?5miiO8W/rxr9+DyuV3QZg0aIjy816pRYqdnOW9/LE7nN6YADCle6+GQV?=\n\t=?utf-8?q?tRAQV3hi9NvMgZrHDvE1iriTWNuVlU03ro4w+c4e2orkOa0DIsvPPerm?=\n\t=?utf-8?q?jxoSqB2TcwOuqYOxmI7v+AmGOvNdNhifoBkMWgRBA8Y6hXeis/LX4Okk?=\n\t=?utf-8?q?5F5SXA10fqnLBovSsi6c/G/IA3IVFa9tGf2n4V1mP0dezG9jDKcBNn+U?=\n\t=?utf-8?q?9jbwMRIuPuVks0MuNYHGCYx4Vz/VOEhQCPCaXeDnIzikqgK3fJW3e52G?=\n\t=?utf-8?q?PqNlkMCJ5m2lv2dV/hWDDqF+xs2vP6i9WU/ZyQ92U7FOqlDvJ4ID9YQQ?=\n\t=?utf-8?q?+ygdpOjhnLpDh6xlZ6Uk+TVPH50fjznwB/iR8jYEhkOM0MvhkJxtyz55?=\n\t=?utf-8?q?fUMma0akAMJlwOc9J04z4xzAdkRZtLXTONmx7kgkmsj7Qo24IsH2/3hv?=\n\t=?utf-8?q?0WLGrFZyiJZqSvU2QiF69giXY+zE/n0mQ52yirhtqQhVkj/+kM2lTbs1?=\n\t=?utf-8?q?yQQ9LstGJB9Mivhs3Uzjtd7VE18ByGafLJCIZNKtj5ITYyHkKX1nEQPJ?=\n\t=?utf-8?q?6iH1nKEtEulxLGfGwOVTB7o2lfGawuY7+qoVu6vlnJwNmhJepg8BdsZZ?=\n\t=?utf-8?q?YqZRMw+hfo9uIzkIPew4TdNK+VI52gt0mhsqqg+VqePY2+abuykXeU3T?=\n\t=?utf-8?q?lMPoujNPPW42rWbC9oevnSikpoV0WsaC/+LWZkg0Pmu4WwgZB0j44k5y?=\n\t=?utf-8?q?n5PZ053IOc/lL0ev0Swe+lWsG6vPN+YVJOaAxcapDLPbDdnJPU7vf63p?=\n\t=?utf-8?q?8lfJvM9P2fkfQFx0f5Lreyb5juczkhdPi+wQGyPIUISw3izxwTWPJhJG?=\n\t=?utf-8?q?jwtL7Q2yjj1Dr/3+Tu/IOdky7jKGiRSoHoO6K5JLPxb+4jrIqeqLGOxF?=\n\t=?utf-8?q?Va0RXIgiPF5vyPdGwb4e7EEwK9Phl7jcQw7j3TrbP247AKiYk1ngeKM9?=\n\t=?utf-8?q?Rr/2yvLKvLC6Jgljta3EuT0OZU1KhxCo1imWcd1B0UxvHcA=3D?=","1; MWHPR07MB3503;\n\t6:zac3yv5YUsqz4TWTmfTP3P/E6ksFmMwsknbvmLcZx71HN3P0tQ8Dt8NbYTRjvUahRxS+iOXQ9kGr0jQEebnxhv9XVZwnVK/ZTMnw4UW+pp/oNFxUn4VZ7g34D46HCqqqm73IAzr5TFhgJk+27geBV2aU7RSe5WnfD9/hb3UG1l7oErcQh2GISj3STi6jE5T56zr19QDJLZblYBcJcHY23NTgzgYxftVgwFsCZumpgpB4nw2ymwzJrwB4KOg9wYFGCH3f4xb7CQ4jdJfet4siFSC5NOfmkE+J5vtf7POT5e/CEbJ+64SU1vGbIGlhMytr40L0c68yXCuTtg7K1gMFG0g3IHq1ZfusEMTanAa9ol8=;\n\t5:nfvw1XlgvjUHbANytFiaNwq5jJaWNWPdGPiASqlk7HFy9klw4G8oIYlDlsU1Kf480b6NUP3IG47WBTaRv2va01k86VAViV+JNm1kV613chIuSqV8h/EZq4K4uLzUKyJyoRN0pkweV2CixuYcpoeKRHZi093Nv4lmxkEMzQfW0O4=;\n\t24:9CbMwccGbRzYKYM87L3gcS3Ew2Bgrtx/DfYIOf9mmHfF90aOz2VHDWE09EMpkTABwfr+Y4qIkQ35vSYWh1tcdfmDmUlk8QXonMIIigg/VeM=;\n\t7:VYvE5s6hsRBmY7zbGjjtB2CGl16hNKeGMyhWnNJ92Hh8UWqOons705brKx5mhrOOwxI298Va9jCtpvgDwVIyraWOnTAjBTnOJPNxu4ajamDGD/Cu2f2l75Gu0Eh03EZ44RpOj1NW4JoU18tQ5su1xPTIvvdWt355Crj3xZCPWUoS6GbMhtr1e9xEqbe/mUgRKA6G4747GLo/Cat/Jc2whVTGgwtXkja/AJ3zFccTetlHKd54Ss8JeXTCc65bEgVP"],"X-MS-TrafficTypeDiagnostic":"MWHPR07MB3503:","X-Exchange-Antispam-Report-Test":"UriScan:(21532816269658);","X-Microsoft-Antispam-PRVS":"","X-Exchange-Antispam-Report-CFA-Test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231020)(10201501046)(93006095)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:MWHPR07MB3503; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:MWHPR07MB3503; ","X-Forefront-PRVS":"047999FF16","X-Forefront-Antispam-Report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(346002)(376002)(24454002)(189002)(199003)(3846002)(7736002)(36756003)(230700001)(65826007)(6116002)(76176999)(478600001)(54356999)(50986999)(53416004)(305945005)(47776003)(54906003)(72206003)(110136005)(5660300001)(65956001)(65806001)(6486002)(8936002)(66066001)(6506006)(42882006)(6666003)(2950100002)(58126008)(316002)(229853002)(7416002)(106356001)(189998001)(97736004)(83506002)(67846002)(23676003)(6246003)(33646002)(64126003)(53936002)(107886003)(53546010)(101416001)(50466002)(105586002)(81156014)(2906002)(6512007)(81166006)(8676002)(31696002)(31686004)(4326008)(16526018)(68736007)(25786009)(69596002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR07MB3503;\n\tH:ddl.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords;\n\tMX:1; A:1; LANG:en; ","Received-SPF":"None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)","SpamDiagnosticOutput":"1:99","SpamDiagnosticMetadata":"NSPM","X-OriginatorOrg":"caviumnetworks.com","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"02 Nov 2017 15:55:36.6788\n\t(UTC)","X-MS-Exchange-CrossTenant-Network-Message-Id":"9f0c69eb-743c-4296-1dc8-08d5220a2937","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"711e4ccf-2e9b-4bcf-a551-4094005b6194","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"MWHPR07MB3503","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1798055,"web_url":"http://patchwork.ozlabs.org/comment/1798055/","msgid":"<20171102161016.GH24320@lunn.ch>","list_archive_url":null,"date":"2017-11-02T16:10:16","subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"On Thu, Nov 02, 2017 at 08:55:33AM -0700, David Daney wrote:\n> On 11/02/2017 05:43 AM, Andrew Lunn wrote:\n> [...]\n> >>+\n> >>+\t\ti = atomic_inc_return(&pki_id);\n> >>+\t\tpki_dev = platform_device_register_data(&new_dev->dev,\n> >>+\t\t\t\t\t\t\tis_mix ? \"octeon_mgmt\" : \"ethernet-mac-pki\",\n> >>+\t\t\t\t\t\t\ti, &platform_data, sizeof(platform_data));\n> >>+\t\tdev_info(&pdev->dev, \"Created %s %u: %p\\n\",\n> >>+\t\t\t is_mix ? \"MIX\" : \"PKI\", pki_dev->id, pki_dev);\n> >\n> >Is there any change of these ethernet ports being used to connect to\n> >an Ethernet switch. We have had issues in the past with these sort of\n> >platform devices combined with DSA.\n> >\n> \n> There are only two possibilities. The BGX MACs have a multiplexer that\n> allows them to be connected to either the \"octeon_mgmt\" MIX packet\n> processor, or to the \"ethernet-mac-pki\" PKI/PKO packet processor. The SoCs\n> supported by these drivers do not contain any hardware that would be\n> considered an \"Ethernet switch\".\n\nHi David\n\nI was thinking of an external Ethernet switch. You generally connect\nvia RGMII to a port of the switch.\n\nhttp://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt\n\n\tAndrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@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=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySVS64k84z9t30\n\tfor ;\n\tFri, 3 Nov 2017 03:10:46 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S933972AbdKBQKe (ORCPT );\n\tThu, 2 Nov 2017 12:10:34 -0400","from vps0.lunn.ch ([185.16.172.187]:39469 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S932833AbdKBQKb (ORCPT );\n\tThu, 2 Nov 2017 12:10:31 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1eAI4O-0000Wc-P3; Thu, 02 Nov 2017 17:10:16 +0100"],"Date":"Thu, 2 Nov 2017 17:10:16 +0100","From":"Andrew Lunn ","To":"David Daney ","Cc":"David Daney , linux-mips@linux-mips.org,\n\tralf@linux-mips.org, James Hogan ,\n\tnetdev@vger.kernel.org, \"David S. Miller\" ,\n\tRob Herring , Mark Rutland ,\n\tlinux-kernel@vger.kernel.org, \"Steven J. Hill\" ,\n\tdevicetree@vger.kernel.org, Carlos Munoz ","Subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","Message-ID":"<20171102161016.GH24320@lunn.ch>","References":"<20171102003606.19913-1-david.daney@cavium.com>\n\t<20171102003606.19913-7-david.daney@cavium.com>\n\t<20171102124339.GF4772@lunn.ch>\n\t<521d6b21-b7f0-66e0-4b49-cf95d83452d1@caviumnetworks.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<521d6b21-b7f0-66e0-4b49-cf95d83452d1@caviumnetworks.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1798075,"web_url":"http://patchwork.ozlabs.org/comment/1798075/","msgid":"<0f39046d-dc99-5c05-d918-10952cd20e1b@caviumnetworks.com>","list_archive_url":null,"date":"2017-11-02T16:37:18","subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","submitter":{"id":721,"url":"http://patchwork.ozlabs.org/api/people/721/","name":"David Daney","email":"ddaney@caviumnetworks.com"},"content":"On 11/02/2017 09:10 AM, Andrew Lunn wrote:\n> On Thu, Nov 02, 2017 at 08:55:33AM -0700, David Daney wrote:\n>> On 11/02/2017 05:43 AM, Andrew Lunn wrote:\n>> [...]\n>>>> +\n>>>> +\t\ti = atomic_inc_return(&pki_id);\n>>>> +\t\tpki_dev = platform_device_register_data(&new_dev->dev,\n>>>> +\t\t\t\t\t\t\tis_mix ? \"octeon_mgmt\" : \"ethernet-mac-pki\",\n>>>> +\t\t\t\t\t\t\ti, &platform_data, sizeof(platform_data));\n>>>> +\t\tdev_info(&pdev->dev, \"Created %s %u: %p\\n\",\n>>>> +\t\t\t is_mix ? \"MIX\" : \"PKI\", pki_dev->id, pki_dev);\n>>>\n>>> Is there any change of these ethernet ports being used to connect to\n>>> an Ethernet switch. We have had issues in the past with these sort of\n>>> platform devices combined with DSA.\n>>>\n>>\n>> There are only two possibilities. The BGX MACs have a multiplexer that\n>> allows them to be connected to either the \"octeon_mgmt\" MIX packet\n>> processor, or to the \"ethernet-mac-pki\" PKI/PKO packet processor. The SoCs\n>> supported by these drivers do not contain any hardware that would be\n>> considered an \"Ethernet switch\".\n> \n> Hi David\n> \n> I was thinking of an external Ethernet switch. You generally connect\n> via RGMII to a port of the switch.\n> \n\nOK, now I think I understand. Yes, the MAC can be hardwired to a \nswitch. In fact, there are system designs that do exactly that.\n\nWe try to handle this case by not having a \"phy-handle\" property in the \ndevice tree. The link to the remote device (switch IC in this case) is \nbrought up on ndo_open()\n\nThere may be opportunities to improve how this works in the future, but \nthe current code is serviceable.\n\n> http://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt\n> \n> \tAndrew\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@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=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"nhex3jeg\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=David.Daney@cavium.com; "],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySW3C4x5hz9t16\n\tfor ;\n\tFri, 3 Nov 2017 03:37:43 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755823AbdKBQh3 (ORCPT );\n\tThu, 2 Nov 2017 12:37:29 -0400","from mail-dm3nam03on0069.outbound.protection.outlook.com\n\t([104.47.41.69]:4380\n\t\"EHLO NAM03-DM3-obe.outbound.protection.outlook.com\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S1755760AbdKBQh0 (ORCPT );\n\tThu, 2 Nov 2017 12:37:26 -0400","from ddl.caveonetworks.com (50.233.148.156) by\n\tDM5PR07MB3497.namprd07.prod.outlook.com (10.164.153.28) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.178.6; Thu, 2 Nov 2017 16:37:20 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=QfXJfeVko32lo1cXkISZmZIESQPwWA9eP9DCLFNg8T0=;\n\tb=nhex3jeg0+gdB/XXUHEe6fdi0AOGeNRCds3+lPv0sqLs6AdHZyW0NUkaqtVSuLLWq20wxH7CWy9Q/oSvuZHsbAb+TEmoQFkdH3p8mpTCD8Z+7zsgV7wUE4mIwAwqt+0BvhPwUgTB4rhO2yb0l2ba34Z5N/MCnw6Oj44TbR5sXBs=","Subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","To":"Andrew Lunn ","Cc":"David Daney , linux-mips@linux-mips.org,\n\tralf@linux-mips.org, James Hogan ,\n\tnetdev@vger.kernel.org, \"David S. Miller\" ,\n\tRob Herring , Mark Rutland ,\n\tlinux-kernel@vger.kernel.org, \"Steven J. Hill\" ,\n\tdevicetree@vger.kernel.org, Carlos Munoz ","References":"<20171102003606.19913-1-david.daney@cavium.com>\n\t<20171102003606.19913-7-david.daney@cavium.com>\n\t<20171102124339.GF4772@lunn.ch>\n\t<521d6b21-b7f0-66e0-4b49-cf95d83452d1@caviumnetworks.com>\n\t<20171102161016.GH24320@lunn.ch>","From":"David Daney ","Message-ID":"<0f39046d-dc99-5c05-d918-10952cd20e1b@caviumnetworks.com>","Date":"Thu, 2 Nov 2017 09:37:18 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<20171102161016.GH24320@lunn.ch>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[50.233.148.156]","X-ClientProxiedBy":"DM5PR07CA0035.namprd07.prod.outlook.com (10.168.109.21) To\n\tDM5PR07MB3497.namprd07.prod.outlook.com (10.164.153.28)","X-MS-PublicTrafficType":"Email","X-MS-Office365-Filtering-Correlation-Id":"925bb96a-2e26-4d6e-3efd-08d5220ffd45","X-Microsoft-Antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199);\n\tSRVR:DM5PR07MB3497; ","X-Microsoft-Exchange-Diagnostics":["1; DM5PR07MB3497;\n\t3:31aIW0gpsdUJ33rSwQNLzNaAXeilQS4Z4IWRm1bmAHJVsaOHAfVIVhrBu4WluBkv+Q5RdlXKYv61XKce2K7JxLa76NeWvPrRSVqRhVMxZIxDz7UbY1H0Nlg91gRZSOUKEcAkioDBPSaTTKNh4w5RS20+MzU9DJ/9t80N3KCoAT1uQ5d3z/s2ZcKSIViC9edjz9xQCeYr5IWpVdmKcDc7lFF4g7A6YUdFt6eTorCIQEgReLXiv/mbU6by6zPFiuyd;\n\t25:J5fdaXDmKaebeehp8D6bXUx5dNUZ61RKJV0qh+zMxtOxpThYWQ6AU8QjCNLkFpWubEisiwfUc6HQiYu7cSRadl8XJnvAQcoJEJpDJTTTZ1Gl3nAwNOGeTlg5YEuIKsykjzM+SSvLMDBzPQNFyh4TyaneFV4Rgybwr52G56LJNNTYLzShiYK1iCjHfLbDbpgwScDwthkmphOu5000SU/9ZrIwuNx3RG3WLKN5Bl3fxnX+QZaZlfw1n8aFgKkmbjNiEfBT2ey97I70rAzcK51W9MuXpTO9gYBqnjCAd7d8CxthwIM5oQs/zgxkKdpowIS6fPa3+TIvJwLhen1jLohQJg==;\n\t31:quqjdvyVJDNKuSc3lOT59bsrwlnNIs7BYlKQ3Ffkqihov2uiPS8V16EJDZxzbdCMmMxCoRS2krUNUzXRtKsdqFD0Ww4/tsg03uKElAgJa94xNTiQG8fyHbQN3vGoOn/cQ+bttugfbe1JiQYi7wb5CrFyR5hKuYiwdddEgv09vJpter5BPnoH2cgLchXUADN8dFDb5IZ3hENoMNx5WM3sd0OxCScTtOgBcZ15c1Wi/sE=","1; DM5PR07MB3497;\n\t20:XS53L6UyjGbeh8Yogi+tgUCib0ga3bwcZRSPEmpBgbGzCK1oVPD0Wq1/9bsRIHhdc5Sewn1U9zeXk0sHg6VqH5e6BzekMvpxhVZW7dNvO+ST2pUzz4txPyh5xjxczHEawAeT2rl+yZK/JMc2RP4C5MIdsi3dpn79oTw8gm5SRRJfNrjd3z5c/EdLmC+mqSx3bTiwuAtcvcsjLORsAO763hYIyQTV+Mvbs/QXY0JJceTcsDio0AD9y5q5u46t2xPRLVEoVsysOiAYxRXH/BEIoXS75E3zLZ4wnDJ7myqpQvhFN9p4UTiUjUPQz9RJArHZlZJxwmUVoc2IJHEcXSFKk0Q+SLSqSDbc09lpqnaqraKJYFiTQe8LzakMVcPpNAjlEgpXvO0ZjPchaQ3jvalBS5V9OACv69FOXuLxRN+tyZbFBaeu75Maw/M9Vxyu3zNP1GXYYYbyAjpGODhrT0bkLdKrRwnUMbe4WqNlvDmj6iVvO311tOFpHaXEy1JWeRmi7k/rOFTlcjECicypkfVj0mzV1c9h3Q3JVOr9dwsz4pAVi0efTGrzDx1C0qxDObwXpBP0IEh6RT4+TJpR0XgrCdI0E8GFIt15lzXkq3sjjrw=","1; DM5PR07MB3497;\n\t4:z6UWxWE6as/H6LZm67dsxmpvCjiYkWwyd4fxSgnJ/o6ARV+jBU6sgRt9TwgNWBRxpK1yihXfQJ1lsub1Z/IO2c57EgWKSqdiqlHB3iJOf0vtfEGH2PuCN3ZmavXuUk9/AhoEyZICO60N2COSDiOpGYgBiA5QxlUUcJgdyjrZc5w4Od4VAFe4TALCjAkf9NAiQecJA9KnH4PXHq5j+9fniw5fUhoXZvBbKc7T0HY5gOu+n/v3cuAxNjrpkwctimnPy8/oLg1T9XMh9US/7aemBcrijUjdwwcWvOcOTsKCsSlwXXDFaoACrQCvhG33G4zeGtrI/kb9p0wglmgLpAsU6atcbcVovlwjlFE7dyT3Hp8=","=?utf-8?q?1=3BDM5PR07MB3497=3B23=3ARWfT?=\n\t=?utf-8?q?r6bGWvcvzfwfT9ZPVZU3qVjcDKNxRtAOlLi2uS89bPQpSchp8jhOPRNo?=\n\t=?utf-8?q?O8YvHXswu8NJa8r227ZwgNFDWuHNqiGJY4nYExehPJVKwPJsemq1RS7X?=\n\t=?utf-8?q?yUK/FKKigzY4vUMshWVn9kaGC60ahdyibSWleWDFvUWWAL4qvybqqmcw?=\n\t=?utf-8?q?oBC5aZPy3Rl4wIYk39JYraV+8+PYh+c9BZEukQNoxaXXQazxkeG97lh6?=\n\t=?utf-8?q?OEgUUIoku22nuK5i+SjbWafE7LPnvdiYIr3OmevO+7yBCRGv6ko0kgL+?=\n\t=?utf-8?q?CYF427MRqPqc4vWdF8LVWZOrofRb2rj0TOOereTVCiYdqxjMf2OqA3jQ?=\n\t=?utf-8?q?+LUR6WSw/vV1rggt6avg9jAUZXI1H+PjefIvLKRERPDbnDigb/z+ztT+?=\n\t=?utf-8?q?N2x1XtuqEsRwB5QADoUt8RPGd9zSc9GWbQRX7RGRufHZeLU5lP/5XrWe?=\n\t=?utf-8?q?XS24GmMeRTdFCwkHDQZV8waffATbKcvy7bUQneUW/1Z0Rnv2ctuSrvcL?=\n\t=?utf-8?q?hClY9B4oa4DoNJh6RR58RDleljJ90SsyH0QYQhrTB/p5JfmvpNc396x0?=\n\t=?utf-8?q?cXcN/pTVLDFJcW9+ul5xziouxZ7e7XtfDdzWp46+m3plQYHt3jubTHcB?=\n\t=?utf-8?q?3JSetSV6Z625hY65QgkSyBvh4nSvQfcQFsww4AaEIvjA8DWSOG1iJdN0?=\n\t=?utf-8?q?KEfVSd0R0gdhafbc3W7aYW2ZbP8L3A7+7s0KQOl92xkIZwGk/Eg+KppB?=\n\t=?utf-8?q?BxkHHqNGvgaSY4IZ7eaBS7ftMCrKSERaxjxpjOeZhjaXmh1hPADtqUxS?=\n\t=?utf-8?q?rShkFPsO8KG73GwSK0WIwIH4Nxr1lRznP5tQlQnAUxOtFODYjnhU8AuH?=\n\t=?utf-8?q?NMx/KJuxTEiMwzss6XkLkHJSKt3ewWASDCXWHIU/YaOQu/dAD+3OH5lN?=\n\t=?utf-8?q?Tr3VxNeF6yX1UMKAgadnkvWhp21ab50jydWLY/J2M8DU/VIaYlUmM6PV?=\n\t=?utf-8?q?t/I949SxO1QLgPGNkSR81aa5gSzWRXMPvo8HwW5asnAfLwmJ/09tdsMh?=\n\t=?utf-8?q?gfwGdHxyUuefUpOmnmm9g3vVuer53E/57uWXeF8s2lyDsRtUxklJ9xpt?=\n\t=?utf-8?q?h21ucC99jo2E2f7FGlBwnT5D8f7XEb5K/bfmaWTHUkRgTIJnQrDqtZUy?=\n\t=?utf-8?q?SCxPoaTh7ogXSQV4UsaowA93sNAnHJyK2dB0ipkLk7YQ4vJi8NUUGUt7?=\n\t=?utf-8?q?Pxa9rrYrrRmtqjsGS1f2s7wfMTvpMIIzuK950TYnxmThqTvlwL5xIrhu?=\n\t=?utf-8?q?33hnpz3XFRZojDNGW89tvbs8qObHtcwpVpVa3RgpEWs7TTgKvGOu4CSp?=\n\t=?utf-8?q?i9h0yPItysyjCJ6ZqTc5tRGZjAogCSB01u4P66FyTEVi8AYQQmEEKQsR?=\n\t=?utf-8?q?a2/ec4HuBm34f1iUS+cG2ffsMH6bjyHsqeQ6bUGoES6kWIZM03izInGu?=\n\t=?utf-8?q?QAdzyHdRBIut1XU2F6tGQAxU99zOn8D9H6HaAyhRs4LKmohkvtNxoWAt?=\n\t=?utf-8?q?AgEOFi57w9KZCl1yuXmsBHXe1D5ItwgNJQ=3D=3D?=","1; DM5PR07MB3497;\n\t6:vV1jtIHaD5Z7R764e9QUV3A0d7V/wws4Uc0sWsnTr6D8jchHWG57z6uxu/xn+KrTCaxTzPFBKRNf9myqHvbu5PhT3263+BA+fMenTTKEYOWq6Xmtzfvf8HnVbrt2lby3TnX49P0/UJBsbVKxE4+LoNAT3o4XW7CmgoKSWlaRUZnKbIEAMI9K8CxdIeKbNlLSWMQ6SrFzdmoxdmOUqlLhEPSdQFpeaZVuIVb5R4ZyhptEjpdfSpN3l6l/b3MfBB7G5AtTKO/K684TnF4tfGYxcyT3EtBGNdEi0FuuMx8+XjSMknpmOwmVNecQISuqZXDqGr9zCpk1ek2Hlr1pSZ0fhUF2K034l07XViEkSGDZoCg=;\n\t5:qjyTmv6cU0t/v1bZzmM/JIN4Z5qhldCrLJPiLkcIsS7x3Sj6FFqdEHZc2LLptm6QiA5tIuRMG2IQLIS/Mk3F3duXx6h0EdXofsfXj+b51uk1YZ4rrOOjKfj/km7o+Ou+bSNgPSMpyNczH0NrRlxnTtKxQNzsuU233huhaOVg9Vc=;\n\t24:76C159HtEMIjVMPmEW7nkgu80iboIck92ZRY0+JEJlwOqAVnTxevm+KTdvVDdpg4tllERENr4wPwFAH8zqA64H9AzL7OmY5hQMSDi6shiwM=;\n\t7:QjGP2L8YoZQs1/e8VQ8kN8hTuYK/t1+WE6cV69THc2MkBT4LUA93ipYdvtps129RsPqhBndw6z7/04FdhZWE30CD7dHiac1fv3l018phTMjUpRbk2Ogak3Dr+V/nC/L11Kp/w0JRjIPgSCVtUU95CFKw1I/Ft+8+i7Whrfuov/8Nb2NGwxsE5sGgn8DnlrS7tMhalCW0oge0+Q99sXCTG9rzXVxB8aUa5HtZdJlsTxgTDz8NRpU1XV0BLhS9GxWz"],"X-MS-TrafficTypeDiagnostic":"DM5PR07MB3497:","X-Exchange-Antispam-Report-Test":"UriScan:(58145275503218)(21532816269658);","X-Microsoft-Antispam-PRVS":"","X-Exchange-Antispam-Report-CFA-Test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(10201501046)(3231020)(6041248)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:DM5PR07MB3497; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:DM5PR07MB3497; ","X-Forefront-PRVS":"047999FF16","X-Forefront-Antispam-Report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(376002)(346002)(189002)(24454002)(199003)(36756003)(93886005)(54906003)(33646002)(316002)(58126008)(31686004)(53416004)(106356001)(105586002)(65956001)(31696002)(47776003)(66066001)(65806001)(50986999)(54356999)(76176999)(966005)(6512007)(229853002)(6506006)(6486002)(101416001)(2906002)(6306002)(72206003)(478600001)(97736004)(69596002)(81166006)(25786009)(68736007)(4326008)(230700001)(6246003)(8676002)(189998001)(8936002)(107886003)(6116002)(50466002)(3846002)(23676003)(67846002)(5660300001)(65826007)(83506002)(42882006)(2950100002)(305945005)(6916009)(64126003)(7416002)(7736002)(16526018)(53546010)(81156014)(53936002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR07MB3497;\n\tH:ddl.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords;\n\tMX:1; A:1; LANG:en; ","Received-SPF":"None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)","SpamDiagnosticOutput":"1:99","SpamDiagnosticMetadata":"NSPM","X-OriginatorOrg":"caviumnetworks.com","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"02 Nov 2017 16:37:20.4320\n\t(UTC)","X-MS-Exchange-CrossTenant-Network-Message-Id":"925bb96a-2e26-4d6e-3efd-08d5220ffd45","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"711e4ccf-2e9b-4bcf-a551-4094005b6194","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"DM5PR07MB3497","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1798088,"web_url":"http://patchwork.ozlabs.org/comment/1798088/","msgid":"<20171102165605.GJ24320@lunn.ch>","list_archive_url":null,"date":"2017-11-02T16:56:05","subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> OK, now I think I understand. Yes, the MAC can be hardwired to a switch.\n> In fact, there are system designs that do exactly that.\n> \n> We try to handle this case by not having a \"phy-handle\" property in the\n> device tree. The link to the remote device (switch IC in this case) is\n> brought up on ndo_open()\n\nO.K, so you totally ignore the Linux way of doing this and hack\ntogether your own proprietary solution.\n \n> There may be opportunities to improve how this works in the future, but the\n> current code is serviceable.\n\nIt might be serviceable, but it will never get into mainline. For\nmainline, you need to use DSA.\n\nhttp://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt\n\nGetting back to my original point, having these platform devices can\ncause issues for DSA. Freescale FMAN has a similar architecture, and\nit took a while to restructure it to make DSA work.\n\nhttps://www.spinics.net/lists/netdev/msg459394.html\n\n\tAndrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@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=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySWTN1d9mz9s83\n\tfor ;\n\tFri, 3 Nov 2017 03:56:56 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S934029AbdKBQ4n (ORCPT );\n\tThu, 2 Nov 2017 12:56:43 -0400","from vps0.lunn.ch ([185.16.172.187]:39603 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S932383AbdKBQ4l (ORCPT );\n\tThu, 2 Nov 2017 12:56:41 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1eAImj-0000zN-SC; Thu, 02 Nov 2017 17:56:05 +0100"],"Date":"Thu, 2 Nov 2017 17:56:05 +0100","From":"Andrew Lunn ","To":"David Daney ","Cc":"David Daney , linux-mips@linux-mips.org,\n\tralf@linux-mips.org, James Hogan ,\n\tnetdev@vger.kernel.org, \"David S. Miller\" ,\n\tRob Herring , Mark Rutland ,\n\tlinux-kernel@vger.kernel.org, \"Steven J. Hill\" ,\n\tdevicetree@vger.kernel.org, Carlos Munoz ","Subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","Message-ID":"<20171102165605.GJ24320@lunn.ch>","References":"<20171102003606.19913-1-david.daney@cavium.com>\n\t<20171102003606.19913-7-david.daney@cavium.com>\n\t<20171102124339.GF4772@lunn.ch>\n\t<521d6b21-b7f0-66e0-4b49-cf95d83452d1@caviumnetworks.com>\n\t<20171102161016.GH24320@lunn.ch>\n\t<0f39046d-dc99-5c05-d918-10952cd20e1b@caviumnetworks.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<0f39046d-dc99-5c05-d918-10952cd20e1b@caviumnetworks.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1798180,"web_url":"http://patchwork.ozlabs.org/comment/1798180/","msgid":"<0168761e-cb18-e489-4689-8c9062aa316b@caviumnetworks.com>","list_archive_url":null,"date":"2017-11-02T18:31:45","subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","submitter":{"id":721,"url":"http://patchwork.ozlabs.org/api/people/721/","name":"David Daney","email":"ddaney@caviumnetworks.com"},"content":"On 11/02/2017 09:56 AM, Andrew Lunn wrote:\n>> OK, now I think I understand. Yes, the MAC can be hardwired to a switch.\n>> In fact, there are system designs that do exactly that.\n>>\n>> We try to handle this case by not having a \"phy-handle\" property in the\n>> device tree. The link to the remote device (switch IC in this case) is\n>> brought up on ndo_open()\n> \n> O.K, so you totally ignore the Linux way of doing this and hack\n> together your own proprietary solution.\n\nI am going to add handling of the \"phy-mode\" property, but other than \nthat I don't know what the \"Linux way\" of specifying a hard MAC-to-MAC \nconnection with no intervening phy devices is. Wether the remote MAC is \na switch, or something else, would seem to be irrelevant. All we are \nconcerned about in this code is putting the thing into a state where \ndata flows in both directions through the MAC.\n\nA pointer to an existing device tree binding for an Ethernet device that \nhas no (or an optional) phy device would be useful, we can try to do the \nsame.\n\n\n> \n>> There may be opportunities to improve how this works in the future, but the\n>> current code is serviceable.\n> \n> It might be serviceable, but it will never get into mainline. For\n> mainline, you need to use DSA.\n> \n> http://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt\n\n\nI am truly at a loss here. That DSA document states:\n\n Master network devices are regular, unmodified Linux\n network device drivers for the CPU/management Ethernet\n interface.\n\nWhat modification do you suggest I make?\n\n\n> \n> Getting back to my original point, having these platform devices can\n> cause issues for DSA. Freescale FMAN has a similar architecture, and\n> it took a while to restructure it to make DSA work.\n> \n> https://www.spinics.net/lists/netdev/msg459394.html\n> \n> \tAndrew\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@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=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"o5+vaxxr\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=David.Daney@cavium.com; "],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySYb00S7Cz9sNw\n\tfor ;\n\tFri, 3 Nov 2017 05:31:56 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S934118AbdKBSby (ORCPT );\n\tThu, 2 Nov 2017 14:31:54 -0400","from mail-dm3nam03on0071.outbound.protection.outlook.com\n\t([104.47.41.71]:7072\n\t\"EHLO NAM03-DM3-obe.outbound.protection.outlook.com\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S933393AbdKBSbv (ORCPT );\n\tThu, 2 Nov 2017 14:31:51 -0400","from ddl.caveonetworks.com (50.233.148.156) by\n\tBN6PR07MB3491.namprd07.prod.outlook.com (10.161.153.30) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.197.13; Thu, 2 Nov 2017 18:31:48 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=AaGxfUhDRQ930fANYt7/WYscyx3j10KS5aq0tiiFFrI=;\n\tb=o5+vaxxrA3GyEpRHU0lU9cCvsQsoALz80/Hng5zCfwWco15/PfcBsoudIfQkT7yqvj//USnUaPE60ZA2MHY7+0q5Q0qC75qfkEs/FyMq8c14TY1lqpQp6XLOiO9jqBae4fKZAfHjLZT3GHfMUrM5NOeSlfnWbJZNM3WZaiKTVFI=","Subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","To":"Andrew Lunn ","Cc":"David Daney , linux-mips@linux-mips.org,\n\tralf@linux-mips.org, James Hogan ,\n\tnetdev@vger.kernel.org, \"David S. Miller\" ,\n\tRob Herring , Mark Rutland ,\n\tlinux-kernel@vger.kernel.org, \"Steven J. Hill\" ,\n\tdevicetree@vger.kernel.org, Carlos Munoz ","References":"<20171102003606.19913-1-david.daney@cavium.com>\n\t<20171102003606.19913-7-david.daney@cavium.com>\n\t<20171102124339.GF4772@lunn.ch>\n\t<521d6b21-b7f0-66e0-4b49-cf95d83452d1@caviumnetworks.com>\n\t<20171102161016.GH24320@lunn.ch>\n\t<0f39046d-dc99-5c05-d918-10952cd20e1b@caviumnetworks.com>\n\t<20171102165605.GJ24320@lunn.ch>","From":"David Daney ","Message-ID":"<0168761e-cb18-e489-4689-8c9062aa316b@caviumnetworks.com>","Date":"Thu, 2 Nov 2017 11:31:45 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<20171102165605.GJ24320@lunn.ch>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[50.233.148.156]","X-ClientProxiedBy":"SN4PR0701CA0008.namprd07.prod.outlook.com (10.161.192.146)\n\tTo BN6PR07MB3491.namprd07.prod.outlook.com (10.161.153.30)","X-MS-PublicTrafficType":"Email","X-MS-Office365-Filtering-Correlation-Id":"0da9a5b2-10a7-449d-d409-08d5221ffb0e","X-Microsoft-Antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603238);\n\tSRVR:BN6PR07MB3491; ","X-Microsoft-Exchange-Diagnostics":["1; BN6PR07MB3491;\n\t3:iCVDuqbsUUn8qwGLKi/ba7V7e5yrn48trYC27DzMQI69Ar/DaBhroEouEXhO9vgzlWEmDVm06MGEv1XRcIq6fdFQEGdPJUQS076wkUw3ql6u4cL4o2HjFdzpojXn8CM2XpMvMThAqYMLkMDwIvL+UFqOgWN14Hxj3jidjbh2MIYuWaSWr/QHZD3wwkHrW0d+dgFolChOh645SReeA9gvzLTMHxhjuWkv/7KfctXFTwyyuROWFNAI7RwATAIDNhdN;\n\t25:ZYl6BOrqFL+RzAuzzOkjp4JfYpgRCh4rnQlnJrnVVRLl4ER1VS8ZZDlAdke0TYAm6tMlN1Qo59jGp5I1JTVtFYLhCzTL0ELgOl3QePpJcNnYy3ZdCyQjNL/UHQYEpXlddrfMpQQTlz08kFpNQf0WxC8qmLMbTHZpij4DcjxoBmWEW5TPGPOnzau40cwvJYmtwll8ZQb82M9PsnBekYx1N7GpOWZlKlO5Jl3ELo+ReOmjd832aWtv5vN732KiQiqovDmmT9rtXZ6DBTsroWKjClH4nVMHS6EVO1nqyi3Wj3V6JTVathDNf1pwa9vKhmebIEY1A4lbW3DpBnZrGmnl7g==;\n\t31:g8M972Z3dpvwzDEAUP0pJZa4ePiH5mHQ8w0tJvXCjyCMfmkvud8t0Oyg2sK94KdHs2jm/KbaDzSv53TZrAzjZyJ/s+p7yeo1gEc+HNdE4f+pyf87z1xhTEqXsqhmH78WEVbqcNAfD4gXzb5IWKechZdyREX47ndXP2OFnC9MMuwcV3zFlPTrYFWaD9ZwemXEZQwMprs20H0asVyboJ5ZC80pCxxG/unjYTZikpKoccM=","1; BN6PR07MB3491;\n\t20:vG4IF8J/XlKBZnVLDq5wSrcufOo2eGws+tc/jutvC8EYeZz7c/oQkMPITg6lFQEI9rjONrASo99rPVZfu0jH5fMX3g6T5t1x2msOfyQrDHW/NiJ0tHnxI/R0j6MCocK4D/JlAu5i+zF9F8/kn8ux8O006zBy61iMcBncYSsOVvsUHrkx5n1dVIWzxC41oZ9Zcd1iqJe6j6WtgbukBsZO44G4Eo30qmDtQbiB02eK5r1nrCTXf0DMI7KiBYsBo7w0OKL/MnB4jHF/iClQAISmxXNUFoGMLDrOMOFbRPM7lZ5Y8dq1HCMNDMjUcrX3rYx911OdqRTAy8+6TP31ezGcFdxYIqEK+el06l/gCzjCdEqHQMyckTMMdUxTiEiKEJmxQWVKNmH/6WlXNi6fecq1j847eiOgcunk4qOV2IKw/EBuX87iV4Q3n+lpX13i7M7ExAAbpHUn3RwYZXMxVjWxtnck8PKFfuUsImuRh2oy4CdgXxlW7W37/wIAlUQiaFm3okVcutKmSPKQvLlJmF/sZelZwtgsMiqhp5VLp9lhr+xlK9QNfsiQIqsRAFqr490v5MJQAEsdORtmnmef0LvkpB46Ps9XRJYFJgMmRCBBWjc=;\n\t4:ywQzcIw9FytovCQOSBnajzzs/SF8BjngaEeOnbrv4orSlZs/H7eS/1Cu8UkLWUs7SBCnKwVfZSfEjHD7Z3mE4LsBY/Sa3oofd8bLRJXDAYjHkBSP5qQi8lioGvAXiqIKrPy8z4hM6FNByzi75i+wrIyvdB+y6b9BupFpW7rzStmm7eYVjYQBT42aemrWJqqJtSNVZ/syHkpl7j0h2R6dhbx4GXLBXGSzReUEfM8iiKDqKx4ju5wMmpJkdS4zCA84P+FPSpYctzsClU1/CVfG+JgOCx0yk1bEtVFoEFV0T7EGbFtBoWyQwXbq+qjrsVld","=?utf-8?q?1=3BBN6PR07MB3491=3B23=3AZQ31?=\n\t=?utf-8?q?1JXRQQr5D6zARUcOXyEuyn9ILYZikIC2Ju68kZQUhYL2GyynGYh/UCB6?=\n\t=?utf-8?q?CuOdF3uztuOWGTBSwjDQX5EvWwETLhOJUEIcihQuecfxd0QDbmNRIe12?=\n\t=?utf-8?q?xM7EYxb3s6wxAG7NmDrtWfx5rIlepmHunLcXUDP3NgtY5ZRo+sEy49Tu?=\n\t=?utf-8?q?QOdHsxijYfAA7q1rm9faEDB2ki0Hs64wiJzndrliDJehO62J/JNYzpEK?=\n\t=?utf-8?q?A52/4mALTlGxnIbjigXqNzG+D5ctPcaymbDVlAdedI5Wb432j5V8Viu2?=\n\t=?utf-8?q?677lJQePMTBbABYu4nBXVAA+i0JnP9TzXoz3fehF6Hhdzc2dk5Kp5Jj2?=\n\t=?utf-8?q?GmHm0LcH6N9yQgHXw/COt63dtgCIkCymj2lfM1Pg5bDCNcHMq0haZlHi?=\n\t=?utf-8?q?ezbjyT8KabGe4wziCb3KoCZ9ecb1+gGi6jz2N9ZBeSEzLHjPABML1CE7?=\n\t=?utf-8?q?3A0iozCSFbRvI5EaPwyH9J5ZbqWvvWFr9laobcDrzgAOfCJE811uWBXH?=\n\t=?utf-8?q?l5cwT7VCUXw1zsUAVYH+qK42f5Qbcb2MXZaaGdKUZNvoVksLVsY8AK+T?=\n\t=?utf-8?q?N9u97mqc909XpNlX6vwjRd64CS3SEV5qnHq+ie1h3xv5zuAAbIfSsiLW?=\n\t=?utf-8?q?6nkVrdImqtzekWgXGxbxL6GyvLQH+xmRgYbgr/fqgSMCGJh/xYZMW5bs?=\n\t=?utf-8?q?e2iCsbZQ3bP9qqtDi4PAjsO8VgpYQfEjdPJrKD+4drwR4p/c44FenaiS?=\n\t=?utf-8?q?BlPjY35jUDyh+H5rZKNCPvEqo+O+urNb9fKDZyr9oeXYhas2FoTqbVU0?=\n\t=?utf-8?q?poZlW9f52Vdjxv5KOhA8Qfk+ALKA2TkiZkI6BTmIaHL80aeKDWGAmh4m?=\n\t=?utf-8?q?fAfWFoOhSEGbIEmpYkkP2dEtBhcA/ie5Gccrr7IQJFGAIXlC6SSqQ87J?=\n\t=?utf-8?q?u9Y1JE5A0UdOuzT+LHSvBDWgx4i1RZrFOEWQC4T8hiyh22yQeYmBXaCg?=\n\t=?utf-8?q?Hpe2KPPNozBvo2KvvyIx5mN3tBii4Hha4mfxpLqD8CeIivfOw6WI6Xa8?=\n\t=?utf-8?q?1B11batCcC3TL3iWdOqXfxQF9BTFUEWSOuN6lRuw4DrGIdw4zCUReQWB?=\n\t=?utf-8?q?mWrSWblZRIICnu1TE+U3c5UcB8HD5+TXrBsa0Lx6ym7ELHJHt2zoOaGG?=\n\t=?utf-8?q?BOrAgTkUxKJ37k54Vg+hixzwp5HpxF6tcw2NrcuETXMBthnrKDcQkQE1?=\n\t=?utf-8?q?4Ud5ByIDn8CTQTYFzMH3Ky8TJ1tVjrWlkSrQYu4vmBnCPrkY0yxGSx9z?=\n\t=?utf-8?q?mnvwPoltj4dezcqF7gRUEQh/dsz7k64D6gwpVZnU2f+rLK0Gd4XXpkkr?=\n\t=?utf-8?q?pX+hUn02W1RH3a+twTBTcUbtkhrK+/ao1P6l8GZvquoIcJO15CQoapMH?=\n\t=?utf-8?q?hJ2ZmnEl96XbIm3rbyTA7dsQjDvyG27qi8mMStJh4zlAqkXIXl5kXHET?=\n\t=?utf-8?q?rOyKx3Fc7blTIufRN8tHm0OkZysrdoqYjtOYOc5Ia2uYpMEyf1fEVrcR?=\n\t=?utf-8?q?JJwJE/uvYkLdrwUp8QyekPE1crmBNL+L9g=3D=3D?=","1; BN6PR07MB3491;\n\t6:90VfmgLSyTSTlryR8mu584ndiuMbuqkztYAen77iaM5ii7g2xcAw5Eke46bj7LZVzoxRNfY0Pc5ymR/6bm5qr1Weu86a51w9SRnGW54SPbjJjp4mSynUJ5UaVMOU+X+bS/jZbrZc6e0KgPc5DP1pq58xpiTn4Kyn0DaniiiuTmEXxTHEE1jtTrmDlYutKkrjLzdSee7Ei0kx3lWZtkYPid02O8DXg2Qhc4LdjVPjvV4h27L4hK3EacdKyp78gCAG+dmhSAFFDq0eXcuLJyudIArJ3rHhRuInZYuR7WbFJcHLm9v9x9g0FyKMUH815YRCJs3KKdl9RHWdf2Jj0Oel3epUmog88HuptcxeptCm7JE=;\n\t5:Ieq+VVjGuHCQY4zPOz22oxVxJdHVNjvwrvCNVkVyjyIKAsbE7Cd94bwhPS5zagkz2JBHwGmCJxMHSAdZEPaKiFl6+nVRT/pD8TdPRLRO444y7QduaYOCNoJUTVmjvb1lh9Z2UUdgupDlygYmM4QLqB5YaFDnDNX6zu3314xf4wQ=;\n\t24:JOXLLTJFzRZsSWt5hX1c7Bm8vZmakmYjTHw3/lvhHxCVmO7pjv9z1qld7Kz1ZIFoyP4KArNfNUeaQLCaV1cElsfJsQqoBtJWnmigKGzK2v4=;\n\t7:gSmT+9Xr8ay+YjWOO4+tNxzG1/TGcFN+3/oxXhNPtT02BCyYslh89mzdDv2HRTgSN5NGR2dctMPeW6QqadkMdrfHavYDkZJQL/Hz7zMO2GBnc1Gcifb3fH8eCfnzlV/Fp/UyUK3MDzu2UEBB1ScCsPMgNTmL+cfcGTvsGHCSjzmoI+kQQ2wOe90NIltv/qWIIig3TioqFMme3fm5MOYaqp/Cq/C/pldMxMGOFHOf+XA+TxWXx/PCiCRrEmbVp9b5"],"X-MS-TrafficTypeDiagnostic":"BN6PR07MB3491:","X-Exchange-Antispam-Report-Test":"UriScan:(58145275503218);","X-Microsoft-Antispam-PRVS":"","X-Exchange-Antispam-Report-CFA-Test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(93006095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:BN6PR07MB3491; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:BN6PR07MB3491; ","X-Forefront-PRVS":"047999FF16","X-Forefront-Antispam-Report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(346002)(376002)(24454002)(199003)(189002)(6666003)(478600001)(72206003)(7416002)(42882006)(53546010)(2950100002)(6916009)(6506006)(6512007)(6306002)(50986999)(93886005)(316002)(8936002)(6246003)(107886003)(58126008)(54906003)(64126003)(81166006)(54356999)(76176999)(81156014)(53936002)(966005)(69596002)(8676002)(229853002)(6116002)(3846002)(36756003)(33646002)(106356001)(53416004)(305945005)(7736002)(83506002)(230700001)(97736004)(189998001)(25786009)(105586002)(2906002)(47776003)(5660300001)(50466002)(23676003)(67846002)(101416001)(31696002)(31686004)(16526018)(66066001)(68736007)(4326008)(6486002)(65806001)(65956001)(65826007);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR07MB3491;\n\tH:ddl.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords;\n\tA:1; MX:1; LANG:en; ","Received-SPF":"None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)","SpamDiagnosticOutput":"1:99","SpamDiagnosticMetadata":"NSPM","X-OriginatorOrg":"caviumnetworks.com","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"02 Nov 2017 18:31:48.1676\n\t(UTC)","X-MS-Exchange-CrossTenant-Network-Message-Id":"0da9a5b2-10a7-449d-d409-08d5221ffb0e","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"711e4ccf-2e9b-4bcf-a551-4094005b6194","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"BN6PR07MB3491","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1798192,"web_url":"http://patchwork.ozlabs.org/comment/1798192/","msgid":"","list_archive_url":null,"date":"2017-11-02T18:53:08","subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 11/02/2017 11:31 AM, David Daney wrote:\n> On 11/02/2017 09:56 AM, Andrew Lunn wrote:\n>>> OK, now I think I understand. Yes, the MAC can be hardwired to a\n>>> switch.\n>>> In fact, there are system designs that do exactly that.\n>>>\n>>> We try to handle this case by not having a \"phy-handle\" property in the\n>>> device tree. The link to the remote device (switch IC in this case) is\n>>> brought up on ndo_open()\n>>\n>> O.K, so you totally ignore the Linux way of doing this and hack\n>> together your own proprietary solution.\n> \n> I am going to add handling of the \"phy-mode\" property, but other than\n> that I don't know what the \"Linux way\" of specifying a hard MAC-to-MAC\n> connection with no intervening phy devices is. Wether the remote MAC is\n> a switch, or something else, would seem to be irrelevant. All we are\n> concerned about in this code is putting the thing into a state where\n> data flows in both directions through the MAC.\n\nThe canonical way to support that type of connections is to use use a\nfixed-link property describing the link between the two MACs, ideally\nputting the same fixed-link property on both sides.\n\n> \n> A pointer to an existing device tree binding for an Ethernet device that\n> has no (or an optional) phy device would be useful, we can try to do the\n> same.\n> \n> \n>> \n>>> There may be opportunities to improve how this works in the future,\n>>> but the\n>>> current code is serviceable.\n>>\n>> It might be serviceable, but it will never get into mainline. For\n>> mainline, you need to use DSA.\n>>\n>> http://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt\n>>\n> \n> \n> I am truly at a loss here. That DSA document states:\n> \n> Master network devices are regular, unmodified Linux\n> network device drivers for the CPU/management Ethernet\n> interface.\n> \n> What modification do you suggest I make?\n\nIf you support normal phy_device and fixed-link devices, you should be\ngood as far as using PHYLIB and interfacing with Ethernet switchses\nusing DSA for instance. What Andrew is asking you though is to make sure\nthat the platform device dance between the bgx drivers and the other\nmodules preserves the Device Tree parenting, of_node pointers such that\na DSA switch, which needs to reference a CPU/management port, has a\nchance to successfully look up that node via of_find_net_device_by_node().\n\n> \n> \n>>\n>> Getting back to my original point, having these platform devices can\n>> cause issues for DSA. Freescale FMAN has a similar architecture, and\n>> it took a while to restructure it to make DSA work.\n>>\n>> https://www.spinics.net/lists/netdev/msg459394.html\n>>\n>> Andrew\n>>\n> \n> -- \n> To unsubscribe from this list: send the line \"unsubscribe devicetree\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@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=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"OeFFs5cJ\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySZ3p6q7Lz9sPm\n\tfor ;\n\tFri, 3 Nov 2017 05:53:26 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S934179AbdKBSxR (ORCPT );\n\tThu, 2 Nov 2017 14:53:17 -0400","from mail-qk0-f194.google.com ([209.85.220.194]:55146 \"EHLO\n\tmail-qk0-f194.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S932571AbdKBSxP (ORCPT\n\t); Thu, 2 Nov 2017 14:53:15 -0400","by mail-qk0-f194.google.com with SMTP id n5so572443qke.11;\n\tThu, 02 Nov 2017 11:53:14 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\ts19sm2509808qki.3.2017.11.02.11.53.10\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 02 Nov 2017 11:53:11 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=Mh0+jf9IibybIPV36RiqOt8RtH03Clv4cQALQ0GYqCY=;\n\tb=OeFFs5cJaebKC0bDB9oNleGAugDNaqA1saloJ4xA4gc1Du8RMHh6i26QvLMNnycWvh\n\ttGC5u10o8x2LH7EsEDdtwp47CQcn4AXl9mkS2BDbK42UOVHD9hVkPA+8LKL9cpKRw2Rp\n\tfW8kxV6t2i75bD0qQOBLa+eWzPORjS8h5K8fz826BZjJBYoyif3MdRc60NuIZ8h+1wfc\n\t3rEShSfbRq/OYnUQX5XjOKGl0D3U/nKGNKBFA4rUGxzQwrC/7YgtR37FP2G+rEAUXfcK\n\tR5s5afP0ge54RM80gPlsnNPvbnc8XLKGp6cQ4QD7rHdarvcka5512bfJz0UXKpMxHPHu\n\tGHdA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=Mh0+jf9IibybIPV36RiqOt8RtH03Clv4cQALQ0GYqCY=;\n\tb=Tpf9wBBl+HiNu3DssJoyHVE1FMPnsAVUDBmUwpYnIjUY1gLqY3kq9GNfKQLtobWu8u\n\twXr1Nv6L6vWTIVpi/rLh8GBJNZhNfcCDGjWJS/owILYE1jrdmupBXjdlb298HPBOt15A\n\t0hxJAqsZoQimPTiwTFvWcTypAzOLDo55bA8yFmfVe4BxX7pPszAl048D+DRE9CR8pRR8\n\topFdxO5AAI/6wDGf1lYI4D5UrXHBRuMLUlgHUID6/KTPShWHzf1+4ZhS7Xi/t8Regmgf\n\tDqjDcbxpIxNNxSM25qwv0ObLmDGxo9MR1DScZsP1q0TSk0K9BIOpN3dWUzscDmCN37KZ\n\tsaag==","X-Gm-Message-State":"AMCzsaVQPELQz5IC0WWlLAjn+xR14iW8rv3tdT3yVfqQgJZxrpi3xpWP\n\taxBM5dtrpxrBbrrEjq54wA4=","X-Google-Smtp-Source":"ABhQp+Q9h708l8VX79tswmSLgcoRiTXwKjFHnS9T9B6b/6nqteh3l2VL6/pT0H1dgp4uqcpUfSJ1fw==","X-Received":"by 10.55.209.86 with SMTP id s83mr6438101qki.145.1509648792749; \n\tThu, 02 Nov 2017 11:53:12 -0700 (PDT)","Subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","To":"David Daney , Andrew Lunn ","Cc":"David Daney , linux-mips@linux-mips.org,\n\tralf@linux-mips.org, James Hogan ,\n\tnetdev@vger.kernel.org, \"David S. Miller\" ,\n\tRob Herring , Mark Rutland ,\n\tlinux-kernel@vger.kernel.org, \"Steven J. Hill\" ,\n\tdevicetree@vger.kernel.org, Carlos Munoz ","References":"<20171102003606.19913-1-david.daney@cavium.com>\n\t<20171102003606.19913-7-david.daney@cavium.com>\n\t<20171102124339.GF4772@lunn.ch>\n\t<521d6b21-b7f0-66e0-4b49-cf95d83452d1@caviumnetworks.com>\n\t<20171102161016.GH24320@lunn.ch>\n\t<0f39046d-dc99-5c05-d918-10952cd20e1b@caviumnetworks.com>\n\t<20171102165605.GJ24320@lunn.ch>\n\t<0168761e-cb18-e489-4689-8c9062aa316b@caviumnetworks.com>","From":"Florian Fainelli ","Message-ID":"","Date":"Thu, 2 Nov 2017 11:53:08 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<0168761e-cb18-e489-4689-8c9062aa316b@caviumnetworks.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1798203,"web_url":"http://patchwork.ozlabs.org/comment/1798203/","msgid":"<55d6cf88-7444-42ea-02f1-27efdee2be4b@gmail.com>","list_archive_url":null,"date":"2017-11-02T19:13:49","subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 11/01/2017 05:36 PM, David Daney wrote:\n> From: Carlos Munoz \n> \n> The Cavium OCTEON cn78xx and cn73xx SoCs have network packet I/O\n> hardware that is significantly different from previous generations of\n> the family.\n> \n> Add a new driver for this hardware. The Ethernet MAC is called BGX on\n> these devices. Common code for the MAC is in octeon3-bgx-port.c.\n> Four of these BGX MACs are grouped together and managed as a group by\n> octeon3-bgx-nexus.c. Ingress packet classification is done by the PKI\n> unit initialized in octeon3-pki.c. Queue management is done in the\n> SSO, initialized by octeon3-sso.c. Egress is handled by the PKO,\n> initialized in octeon3-pko.c.\n> \n> Signed-off-by: Carlos Munoz \n> Signed-off-by: Steven J. Hill \n> Signed-off-by: David Daney \n> ---\n\n> +static char *mix_port;\n> +module_param(mix_port, charp, 0444);\n> +MODULE_PARM_DESC(mix_port, \"Specifies which ports connect to MIX interfaces.\");\n\nCan you derive this from Device Tree /platform data configuration?\n\n> +\n> +static char *pki_port;\n> +module_param(pki_port, charp, 0444);\n> +MODULE_PARM_DESC(pki_port, \"Specifies which ports connect to the PKI.\");\n\nLikewise\n\n> +\n> +#define MAX_MIX_PER_NODE\t2\n> +\n> +#define MAX_MIX\t\t\t(MAX_NODES * MAX_MIX_PER_NODE)\n> +\n> +/**\n> + * struct mix_port_lmac - Describes a lmac that connects to a mix\n> + *\t\t\t port. The lmac must be on the same node as\n> + *\t\t\t the mix.\n> + * @node:\tNode of the lmac.\n> + * @bgx:\tBgx of the lmac.\n> + * @lmac:\tLmac index.\n> + */\n> +struct mix_port_lmac {\n> +\tint\tnode;\n> +\tint\tbgx;\n> +\tint\tlmac;\n> +};\n> +\n> +/* mix_ports_lmacs contains all the lmacs connected to mix ports */\n> +static struct mix_port_lmac mix_port_lmacs[MAX_MIX];\n> +\n> +/* pki_ports keeps track of the lmacs connected to the pki */\n> +static bool pki_ports[MAX_NODES][MAX_BGX_PER_NODE][MAX_LMAC_PER_BGX];\n> +\n> +/* Created platform devices get added to this list */\n> +static struct list_head pdev_list;\n> +static struct mutex pdev_list_lock;\n> +\n> +/* Created platform device use this structure to add themselves to the list */\n> +struct pdev_list_item {\n> +\tstruct list_head\tlist;\n> +\tstruct platform_device\t*pdev;\n> +};\n\nDon't you have a top-level platform device that you could use which\nwould hold this data instead of having it here?\n\n[snip]\n\n> +/* Registers are accessed via xkphys */\n> +#define SSO_BASE\t\t\t0x1670000000000ull\n> +#define SSO_ADDR(node)\t\t\t(SET_XKPHYS + NODE_OFFSET(node) + \\\n> +\t\t\t\t\t SSO_BASE)\n> +#define GRP_OFFSET(grp)\t\t\t((grp) << 16)\n> +#define GRP_ADDR(n, g)\t\t\t(SSO_ADDR(n) + GRP_OFFSET(g))\n> +#define SSO_GRP_AQ_CNT(n, g)\t\t(GRP_ADDR(n, g)\t\t + 0x20000700)\n> +\n> +#define MIO_PTP_BASE\t\t\t0x1070000000000ull\n> +#define MIO_PTP_ADDR(node)\t\t(SET_XKPHYS + NODE_OFFSET(node) + \\\n> +\t\t\t\t\t MIO_PTP_BASE)\n> +#define MIO_PTP_CLOCK_CFG(node)\t\t(MIO_PTP_ADDR(node)\t\t+ 0xf00)\n> +#define MIO_PTP_CLOCK_HI(node)\t\t(MIO_PTP_ADDR(node)\t\t+ 0xf10)\n> +#define MIO_PTP_CLOCK_COMP(node)\t(MIO_PTP_ADDR(node)\t\t+ 0xf18)\n\nI am sure this will work great on anything but MIPS64 ;)\n\n> +\n> +struct octeon3_ethernet;\n> +\n> +struct octeon3_rx {\n> +\tstruct napi_struct\tnapi;\n> +\tstruct octeon3_ethernet *parent;\n> +\tint rx_grp;\n> +\tint rx_irq;\n> +\tcpumask_t rx_affinity_hint;\n> +} ____cacheline_aligned_in_smp;\n> +\n> +struct octeon3_ethernet {\n> +\tstruct bgx_port_netdev_priv bgx_priv; /* Must be first element. */\n> +\tstruct list_head list;\n> +\tstruct net_device *netdev;\n> +\tenum octeon3_mac_type mac_type;\n> +\tstruct octeon3_rx rx_cxt[MAX_RX_QUEUES];\n> +\tstruct ptp_clock_info ptp_info;\n> +\tstruct ptp_clock *ptp_clock;\n> +\tstruct cyclecounter cc;\n> +\tstruct timecounter tc;\n> +\tspinlock_t ptp_lock;\t\t/* Serialize ptp clock adjustments */\n> +\tint num_rx_cxt;\n> +\tint pki_aura;\n> +\tint pknd;\n> +\tint pko_queue;\n> +\tint node;\n> +\tint interface;\n> +\tint index;\n> +\tint rx_buf_count;\n> +\tint tx_complete_grp;\n> +\tint rx_timestamp_hw:1;\n> +\tint tx_timestamp_hw:1;\n> +\tspinlock_t stat_lock;\t\t/* Protects stats counters */\n> +\tu64 last_packets;\n> +\tu64 last_octets;\n> +\tu64 last_dropped;\n> +\tatomic64_t rx_packets;\n> +\tatomic64_t rx_octets;\n> +\tatomic64_t rx_dropped;\n> +\tatomic64_t rx_errors;\n> +\tatomic64_t rx_length_errors;\n> +\tatomic64_t rx_crc_errors;\n> +\tatomic64_t tx_packets;\n> +\tatomic64_t tx_octets;\n> +\tatomic64_t tx_dropped;\n\nDo you really need those to be truly atomic64_t types, can't you use u64\nand use the helpers from u64_stats_sync.h? That should be good enough?\n\n> +\t/* The following two fields need to be on a different cache line as\n> +\t * they are updated by pko which invalidates the cache every time it\n> +\t * updates them. The idea is to prevent other fields from being\n> +\t * invalidated unnecessarily.\n> +\t */\n> +\tchar cacheline_pad1[CVMX_CACHE_LINE_SIZE];\n> +\tatomic64_t buffers_needed;\n> +\tatomic64_t tx_backlog;\n> +\tchar cacheline_pad2[CVMX_CACHE_LINE_SIZE];\n> +};\n> +\n> +static DEFINE_MUTEX(octeon3_eth_init_mutex);\n> +\n> +struct octeon3_ethernet_node;\n> +\n> +struct octeon3_ethernet_worker {\n> +\twait_queue_head_t queue;\n> +\tstruct task_struct *task;\n> +\tstruct octeon3_ethernet_node *oen;\n> +\tatomic_t kick;\n> +\tint order;\n> +};\n> +\n> +struct octeon3_ethernet_node {\n> +\tbool init_done;\n> +\tint next_cpu_irq_affinity;\n> +\tint node;\n> +\tint pki_packet_pool;\n> +\tint sso_pool;\n> +\tint pko_pool;\n> +\tvoid *sso_pool_stack;\n> +\tvoid *pko_pool_stack;\n> +\tvoid *pki_packet_pool_stack;\n> +\tint sso_aura;\n> +\tint pko_aura;\n> +\tint tx_complete_grp;\n> +\tint tx_irq;\n> +\tcpumask_t tx_affinity_hint;\n> +\tstruct octeon3_ethernet_worker workers[8];\n> +\tstruct mutex device_list_lock;\t/* Protects the device list */\n> +\tstruct list_head device_list;\n> +\tspinlock_t napi_alloc_lock;\t/* Protects napi allocations */\n> +};\n> +\n> +static int wait_pko_response;\n> +module_param(wait_pko_response, int, 0644);\n> +MODULE_PARM_DESC(wait_pko_response, \"Wait for response after each pko command.\");\n\nUnder which circumstances is this used?\n\n> +\n> +static int num_packet_buffers = 768;\n> +module_param(num_packet_buffers, int, 0444);\n> +MODULE_PARM_DESC(num_packet_buffers,\n> +\t\t \"Number of packet buffers to allocate per port.\");\n\nConsider implementing ethtool -g/G for this.\n\n> +\n> +static int packet_buffer_size = 2048;\n> +module_param(packet_buffer_size, int, 0444);\n> +MODULE_PARM_DESC(packet_buffer_size, \"Size of each RX packet buffer.\");\n\nHow is that different from adjusting the network device's MTU?\n\n> +\n> +static int rx_queues = 1;\n> +module_param(rx_queues, int, 0444);\n> +MODULE_PARM_DESC(rx_queues, \"Number of RX threads per port.\");\n\nSame thing, can you consider using an ethtool knob for that?\n\n> +\n> +int ilk0_lanes = 1;\n> +module_param(ilk0_lanes, int, 0444);\n> +MODULE_PARM_DESC(ilk0_lanes, \"Number of SerDes lanes used by ILK link 0.\");\n> +\n> +int ilk1_lanes = 1;\n> +module_param(ilk1_lanes, int, 0444);\n> +MODULE_PARM_DESC(ilk1_lanes, \"Number of SerDes lanes used by ILK link 1.\");\n> +\n> +static struct octeon3_ethernet_node octeon3_eth_node[MAX_NODES];\n> +static struct kmem_cache *octeon3_eth_sso_pko_cache;\n> +\n> +/**\n> + * Reads a 64 bit value from the processor local scratchpad memory.\n> + *\n> + * @param offset byte offset into scratch pad to read\n> + *\n> + * @return value read\n> + */\n> +static inline u64 scratch_read64(u64 offset)\n> +{\n> +\treturn *(u64 *)((long)SCRATCH_BASE + offset);\n> +}\n\nNo barriers needed whatsoever?\n\n> +\n> +/**\n> + * Write a 64 bit value to the processor local scratchpad memory.\n> + *\n> + * @param offset byte offset into scratch pad to write\n> + @ @praram value to write\n> + */\n> +static inline void scratch_write64(u64 offset, u64 value)\n> +{\n> +\t*(u64 *)((long)SCRATCH_BASE + offset) = value;\n> +}\n> +\n> +static int get_pki_chan(int node, int interface, int index)\n> +{\n> +\tint\tpki_chan;\n> +\n> +\tpki_chan = node << 12;\n> +\n> +\tif (OCTEON_IS_MODEL(OCTEON_CNF75XX) &&\n> +\t (interface == 1 || interface == 2)) {\n> +\t\t/* SRIO */\n> +\t\tpki_chan |= 0x240 + (2 * (interface - 1)) + index;\n> +\t} else {\n> +\t\t/* BGX */\n> +\t\tpki_chan |= 0x800 + (0x100 * interface) + (0x10 * index);\n> +\t}\n> +\n> +\treturn pki_chan;\n> +}\n> +\n> +/* Map auras to the field priv->buffers_needed. Used to speed up packet\n> + * transmission.\n> + */\n> +static void *aura2bufs_needed[MAX_NODES][FPA3_NUM_AURAS];\n> +\n> +static int octeon3_eth_lgrp_to_ggrp(int node, int grp)\n> +{\n> +\treturn (node << 8) | grp;\n> +}\n> +\n> +static void octeon3_eth_gen_affinity(int node, cpumask_t *mask)\n> +{\n> +\tint cpu;\n> +\n> +\tdo {\n> +\t\tcpu = cpumask_next(octeon3_eth_node[node].next_cpu_irq_affinity, cpu_online_mask);\n> +\t\tocteon3_eth_node[node].next_cpu_irq_affinity++;\n> +\t\tif (cpu >= nr_cpu_ids) {\n> +\t\t\tocteon3_eth_node[node].next_cpu_irq_affinity = -1;\n> +\t\t\tcontinue;\n> +\t\t}\n> +\t} while (false);\n> +\tcpumask_clear(mask);\n> +\tcpumask_set_cpu(cpu, mask);\n> +}\n> +\n> +struct wr_ret {\n> +\tvoid *work;\n> +\tu16 grp;\n> +};\n> +\n> +static inline struct wr_ret octeon3_core_get_work_sync(int grp)\n> +{\n> +\tu64\t\tnode = cvmx_get_node_num();\n> +\tu64\t\taddr;\n> +\tu64\t\tresponse;\n> +\tstruct wr_ret\tr;\n> +\n> +\t/* See SSO_GET_WORK_LD_S for the address to read */\n> +\taddr = 1ull << 63;\n> +\taddr |= BIT(48);\n> +\taddr |= DID_TAG_SWTAG << 40;\n> +\taddr |= node << 36;\n> +\taddr |= BIT(30);\n> +\taddr |= BIT(29);\n> +\taddr |= octeon3_eth_lgrp_to_ggrp(node, grp) << 4;\n> +\taddr |= SSO_NO_WAIT << 3;\n> +\tresponse = __raw_readq((void __iomem *)addr);\n> +\n> +\t/* See SSO_GET_WORK_RTN_S for the format of the response */\n> +\tr.grp = (response & GENMASK_ULL(57, 48)) >> 48;\n> +\tif (response & BIT(63))\n> +\t\tr.work = NULL;\n> +\telse\n> +\t\tr.work = phys_to_virt(response & GENMASK_ULL(41, 0));\n\nThere are quite a lot of phys_to_virt() and virt_to_phys() uses\nthroughout this driver, this will likely not work on anything but\nMIPS64, so there should be a better way, abstracted to do this, see below.\n\n> +\n> +\treturn r;\n> +}\n> +\n> +/**\n> + * octeon3_core_get_work_async - Request work via a iobdma command. Doesn't wait\n> + *\t\t\t\t for the response.\n> + *\n> + * @grp: Group to request work for.\n> + */\n> +static inline void octeon3_core_get_work_async(unsigned int grp)\n> +{\n> +\tu64\tdata;\n> +\tu64\tnode = cvmx_get_node_num();\n> +\n> +\t/* See SSO_GET_WORK_DMA_S for the command structure */\n> +\tdata = SCR_SCRATCH << 56;\n> +\tdata |= 1ull << 48;\n> +\tdata |= DID_TAG_SWTAG << 40;\n> +\tdata |= node << 36;\n> +\tdata |= 1ull << 30;\n> +\tdata |= 1ull << 29;\n> +\tdata |= octeon3_eth_lgrp_to_ggrp(node, grp) << 4;\n> +\tdata |= SSO_NO_WAIT << 3;\n> +\n> +\t__raw_writeq(data, (void __iomem *)IOBDMA_SENDSINGLE);\n> +}\n> +\n> +/**\n> + * octeon3_core_get_response_async - Read the request work response. Must be\n> + *\t\t\t\t called after calling\n> + *\t\t\t\t octeon3_core_get_work_async().\n> + *\n> + * Returns work queue entry.\n> + */\n> +static inline struct wr_ret octeon3_core_get_response_async(void)\n> +{\n> +\tstruct wr_ret\tr;\n> +\tu64\t\tresponse;\n> +\n> +\tCVMX_SYNCIOBDMA;\n> +\tresponse = scratch_read64(SCR_SCRATCH);\n> +\n> +\t/* See SSO_GET_WORK_RTN_S for the format of the response */\n> +\tr.grp = (response & GENMASK_ULL(57, 48)) >> 48;\n> +\tif (response & BIT(63))\n> +\t\tr.work = NULL;\n> +\telse\n> +\t\tr.work = phys_to_virt(response & GENMASK_ULL(41, 0));\n> +\n> +\treturn r;\n> +}\n> +\n> +static void octeon3_eth_replenish_rx(struct octeon3_ethernet *priv, int count)\n> +{\n> +\tstruct sk_buff *skb;\n> +\tint i;\n> +\n> +\tfor (i = 0; i < count; i++) {\n> +\t\tvoid **buf;\n> +\n> +\t\tskb = __alloc_skb(packet_buffer_size, GFP_ATOMIC, 0, priv->node);\n> +\t\tif (!skb)\n> +\t\t\tbreak;\n> +\t\tbuf = (void **)PTR_ALIGN(skb->head, 128);\n> +\t\tbuf[SKB_PTR_OFFSET] = skb;\n\nCan you use build_skb()?\n\n> +\t\tocteon_fpa3_free(priv->node, priv->pki_aura, buf);\n> +\t}\n> +}\n> +\n\n[snip]\n\n> +static int octeon3_eth_tx_complete_worker(void *data)\n> +{\n> +\tstruct octeon3_ethernet_worker *worker = data;\n> +\tstruct octeon3_ethernet_node *oen = worker->oen;\n> +\tint backlog;\n> +\tint order = worker->order;\n> +\tint tx_complete_stop_thresh = order * 100;\n> +\tint backlog_stop_thresh = order == 0 ? 31 : order * 80;\n> +\tu64 aq_cnt;\n> +\tint i;\n> +\n> +\twhile (!kthread_should_stop()) {\n> +\t\twait_event_interruptible(worker->queue, octeon3_eth_tx_complete_runnable(worker));\n> +\t\tatomic_dec_if_positive(&worker->kick); /* clear the flag */\n> +\n> +\t\tdo {\n> +\t\t\tbacklog = octeon3_eth_replenish_all(oen);\n> +\t\t\tfor (i = 0; i < 100; i++) {\n\nDo you really want to bound your TX reclamation worker, all other\nnetwork drivers never bound their napi TX completion task and instead\nreclaim every transmitted buffers.\n\n> +\t\t\t\tvoid **work;\n> +\t\t\t\tstruct net_device *tx_netdev;\n> +\t\t\t\tstruct octeon3_ethernet *tx_priv;\n> +\t\t\t\tstruct sk_buff *skb;\n> +\t\t\t\tstruct wr_ret r;\n> +\n> +\t\t\t\tr = octeon3_core_get_work_sync(oen->tx_complete_grp);\n> +\t\t\t\twork = r.work;\n> +\t\t\t\tif (!work)\n> +\t\t\t\t\tbreak;\n> +\t\t\t\ttx_netdev = work[0];\n> +\t\t\t\ttx_priv = netdev_priv(tx_netdev);\n> +\t\t\t\tif (unlikely(netif_queue_stopped(tx_netdev)) &&\n> +\t\t\t\t atomic64_read(&tx_priv->tx_backlog) < MAX_TX_QUEUE_DEPTH)\n> +\t\t\t\t\tnetif_wake_queue(tx_netdev);\n> +\t\t\t\tskb = container_of((void *)work, struct sk_buff, cb);\n> +\t\t\t\tif (unlikely(tx_priv->tx_timestamp_hw) &&\n> +\t\t\t\t unlikely(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS))\n> +\t\t\t\t\tocteon3_eth_tx_complete_hwtstamp(tx_priv, skb);\n\nThis is where you should be incremeting the TX bytes and packets\nstatistcs, not in your ndo_start_xmit() like you are currently doing.\n\n> +\t\t\t\tdev_kfree_skb(skb);\n\nConsider using dev_consume_skb() to be drop-monitor friendly.\n\n> +\t\t\t}\n> +\n> +\t\t\taq_cnt = oct_csr_read(SSO_GRP_AQ_CNT(oen->node, oen->tx_complete_grp));\n> +\t\t\taq_cnt &= GENMASK_ULL(32, 0);\n> +\t\t\tif ((backlog > backlog_stop_thresh || aq_cnt > tx_complete_stop_thresh) &&\n> +\t\t\t order < ARRAY_SIZE(oen->workers) - 1) {\n> +\t\t\t\tatomic_set(&oen->workers[order + 1].kick, 1);\n> +\t\t\t\twake_up(&oen->workers[order + 1].queue);\n> +\t\t\t}\n> +\t\t} while (!need_resched() &&\n> +\t\t\t (backlog > backlog_stop_thresh ||\n> +\t\t\t aq_cnt > tx_complete_stop_thresh));\n> +\n> +\t\tcond_resched();\n> +\n> +\t\tif (!octeon3_eth_tx_complete_runnable(worker))\n> +\t\t\tocteon3_sso_irq_set(oen->node, oen->tx_complete_grp, true);\n> +\t}\n> +\n> +\treturn 0;\n> +}\n> +\n> +static irqreturn_t octeon3_eth_tx_handler(int irq, void *info)\n> +{\n> +\tstruct octeon3_ethernet_node *oen = info;\n> +\t/* Disarm the irq. */\n> +\tocteon3_sso_irq_set(oen->node, oen->tx_complete_grp, false);\n> +\tatomic_set(&oen->workers[0].kick, 1);\n> +\twake_up(&oen->workers[0].queue);\n\nCan you move the whole worker to a NAPI context/softirq context?\n\n> +\treturn IRQ_HANDLED;\n> +}\n> +\n> +static int octeon3_eth_global_init(unsigned int node,\n> +\t\t\t\t struct platform_device *pdev)\n> +{\n> +\tint i;\n> +\tint rv = 0;\n> +\tunsigned int sso_intsn;\n> +\tstruct octeon3_ethernet_node *oen;\n> +\n> +\tmutex_lock(&octeon3_eth_init_mutex);\n> +\n> +\toen = octeon3_eth_node + node;\n> +\n> +\tif (oen->init_done)\n> +\t\tgoto done;\n> +\n> +\t/* CN78XX-P1.0 cannot un-initialize PKO, so get a module\n> +\t * reference to prevent it from being unloaded.\n> +\t */\n> +\tif (OCTEON_IS_MODEL(OCTEON_CN78XX_PASS1_0))\n> +\t\tif (!try_module_get(THIS_MODULE))\n> +\t\t\tdev_err(&pdev->dev,\n> +\t\t\t\t\"ERROR: Could not obtain module reference for CN78XX-P1.0\\n\");\n> +\n> +\tINIT_LIST_HEAD(&oen->device_list);\n> +\tmutex_init(&oen->device_list_lock);\n> +\tspin_lock_init(&oen->napi_alloc_lock);\n> +\n> +\toen->node = node;\n> +\n> +\tocteon_fpa3_init(node);\n> +\trv = octeon_fpa3_pool_init(node, -1, &oen->sso_pool,\n> +\t\t\t\t &oen->sso_pool_stack, 40960);\n> +\tif (rv)\n> +\t\tgoto done;\n> +\n> +\trv = octeon_fpa3_pool_init(node, -1, &oen->pko_pool,\n> +\t\t\t\t &oen->pko_pool_stack, 40960);\n> +\tif (rv)\n> +\t\tgoto done;\n> +\n> +\trv = octeon_fpa3_pool_init(node, -1, &oen->pki_packet_pool,\n> +\t\t\t\t &oen->pki_packet_pool_stack, 64 * num_packet_buffers);\n> +\tif (rv)\n> +\t\tgoto done;\n> +\n> +\trv = octeon_fpa3_aura_init(node, oen->sso_pool, -1,\n> +\t\t\t\t &oen->sso_aura, num_packet_buffers, 20480);\n> +\tif (rv)\n> +\t\tgoto done;\n> +\n> +\trv = octeon_fpa3_aura_init(node, oen->pko_pool, -1,\n> +\t\t\t\t &oen->pko_aura, num_packet_buffers, 20480);\n> +\tif (rv)\n> +\t\tgoto done;\n> +\n> +\tdev_info(&pdev->dev, \"SSO:%d:%d, PKO:%d:%d\\n\", oen->sso_pool,\n> +\t\t oen->sso_aura, oen->pko_pool, oen->pko_aura);\n> +\n> +\tif (!octeon3_eth_sso_pko_cache) {\n> +\t\tocteon3_eth_sso_pko_cache = kmem_cache_create(\"sso_pko\", 4096, 128, 0, NULL);\n> +\t\tif (!octeon3_eth_sso_pko_cache) {\n> +\t\t\trv = -ENOMEM;\n> +\t\t\tgoto done;\n> +\t\t}\n> +\t}\n> +\n> +\trv = octeon_fpa3_mem_fill(node, octeon3_eth_sso_pko_cache,\n> +\t\t\t\t oen->sso_aura, 1024);\n> +\tif (rv)\n> +\t\tgoto done;\n> +\n> +\trv = octeon_fpa3_mem_fill(node, octeon3_eth_sso_pko_cache,\n> +\t\t\t\t oen->pko_aura, 1024);\n> +\tif (rv)\n> +\t\tgoto done;\n> +\n> +\trv = octeon3_sso_init(node, oen->sso_aura);\n> +\tif (rv)\n> +\t\tgoto done;\n> +\n> +\toen->tx_complete_grp = octeon3_sso_alloc_grp(node, -1);\n> +\tif (oen->tx_complete_grp < 0)\n> +\t\tgoto done;\n> +\n> +\tsso_intsn = SSO_INTSN_EXE << 12 | oen->tx_complete_grp;\n> +\toen->tx_irq = irq_create_mapping(NULL, sso_intsn);\n> +\tif (!oen->tx_irq) {\n> +\t\trv = -ENODEV;\n> +\t\tgoto done;\n> +\t}\n> +\n> +\trv = octeon3_pko_init_global(node, oen->pko_aura);\n> +\tif (rv) {\n> +\t\trv = -ENODEV;\n> +\t\tgoto done;\n> +\t}\n> +\n> +\tocteon3_pki_vlan_init(node);\n> +\tocteon3_pki_cluster_init(node, pdev);\n> +\tocteon3_pki_ltype_init(node);\n> +\tocteon3_pki_enable(node);\n> +\n> +\tfor (i = 0; i < ARRAY_SIZE(oen->workers); i++) {\n> +\t\toen->workers[i].oen = oen;\n> +\t\tinit_waitqueue_head(&oen->workers[i].queue);\n> +\t\toen->workers[i].order = i;\n> +\t}\n> +\tfor (i = 0; i < ARRAY_SIZE(oen->workers); i++) {\n> +\t\toen->workers[i].task = kthread_create_on_node(octeon3_eth_tx_complete_worker,\n> +\t\t\t\t\t\t\t oen->workers + i, node,\n> +\t\t\t\t\t\t\t \"oct3_eth/%d:%d\", node, i);\n> +\t\tif (IS_ERR(oen->workers[i].task)) {\n> +\t\t\trv = PTR_ERR(oen->workers[i].task);\n> +\t\t\tgoto done;\n> +\t\t} else {\n> +#ifdef CONFIG_NUMA\n> +\t\t\tset_cpus_allowed_ptr(oen->workers[i].task, cpumask_of_node(node));\n> +#endif\n> +\t\t\twake_up_process(oen->workers[i].task);\n> +\t\t}\n> +\t}\n> +\n> +\tif (OCTEON_IS_MODEL(OCTEON_CN78XX_PASS1_X))\n> +\t\tocteon3_sso_pass1_limit(node, oen->tx_complete_grp);\n> +\n> +\trv = request_irq(oen->tx_irq, octeon3_eth_tx_handler,\n> +\t\t\t IRQ_TYPE_EDGE_RISING, \"oct3_eth_tx_done\", oen);\n> +\tif (rv)\n> +\t\tgoto done;\n> +\tocteon3_eth_gen_affinity(node, &oen->tx_affinity_hint);\n> +\tirq_set_affinity_hint(oen->tx_irq, &oen->tx_affinity_hint);\n> +\n> +\tocteon3_sso_irq_set(node, oen->tx_complete_grp, true);\n> +\n> +\toen->init_done = true;\n> +done:\n> +\tmutex_unlock(&octeon3_eth_init_mutex);\n> +\treturn rv;\n> +}\n> +\n> +static struct sk_buff *octeon3_eth_work_to_skb(void *w)\n> +{\n> +\tstruct sk_buff *skb;\n> +\tvoid **f = w;\n> +\n> +\tskb = f[-16];\n> +\treturn skb;\n> +}\n> +\n> +/* Receive one packet.\n> + * returns the number of RX buffers consumed.\n> + */\n> +static int octeon3_eth_rx_one(struct octeon3_rx *rx, bool is_async, bool req_next)\n> +{\n> +\tint segments;\n> +\tint ret;\n> +\tunsigned int packet_len;\n> +\tstruct wqe *work;\n> +\tu8 *data;\n> +\tint len_remaining;\n> +\tstruct sk_buff *skb;\n> +\tunion buf_ptr packet_ptr;\n> +\tstruct wr_ret r;\n> +\tstruct octeon3_ethernet *priv = rx->parent;\n> +\n> +\tif (is_async)\n> +\t\tr = octeon3_core_get_response_async();\n> +\telse\n> +\t\tr = octeon3_core_get_work_sync(rx->rx_grp);\n> +\twork = r.work;\n> +\tif (!work)\n> +\t\treturn 0;\n> +\n> +\t/* Request the next work so it'll be ready when we need it */\n> +\tif (is_async && req_next)\n> +\t\tocteon3_core_get_work_async(rx->rx_grp);\n> +\n> +\tskb = octeon3_eth_work_to_skb(work);\n> +\n> +\tsegments = work->word0.bufs;\n> +\tret = segments;\n> +\tpacket_ptr = work->packet_ptr;\n> +\tif (unlikely(work->word2.err_level <= PKI_ERRLEV_LA &&\n> +\t\t work->word2.err_code != PKI_OPCODE_NONE)) {\n> +\t\tatomic64_inc(&priv->rx_errors);\n> +\t\tswitch (work->word2.err_code) {\n> +\t\tcase PKI_OPCODE_JABBER:\n> +\t\t\tatomic64_inc(&priv->rx_length_errors);\n> +\t\t\tbreak;\n> +\t\tcase PKI_OPCODE_FCS:\n> +\t\t\tatomic64_inc(&priv->rx_crc_errors);\n> +\t\t\tbreak;\n> +\t\t}\n> +\t\tdata = phys_to_virt(packet_ptr.addr);\n> +\t\tfor (;;) {\n> +\t\t\tdev_kfree_skb_any(skb);\n> +\t\t\tsegments--;\n> +\t\t\tif (segments <= 0)\n> +\t\t\t\tbreak;\n> +\t\t\tpacket_ptr.u64 = *(u64 *)(data - 8);\n> +#ifndef __LITTLE_ENDIAN\n> +\t\t\tif (OCTEON_IS_MODEL(OCTEON_CN78XX_PASS1_X)) {\n> +\t\t\t\t/* PKI_BUFLINK_S's are endian-swapped */\n> +\t\t\t\tpacket_ptr.u64 = swab64(packet_ptr.u64);\n> +\t\t\t}\n> +#endif\n> +\t\t\tdata = phys_to_virt(packet_ptr.addr);\n> +\t\t\tskb = octeon3_eth_work_to_skb((void *)round_down((unsigned long)data, 128ull));\n> +\t\t}\n> +\t\tgoto out;\n> +\t}\n> +\n> +\tpacket_len = work->word1.len;\n> +\tdata = phys_to_virt(packet_ptr.addr);\n> +\tskb->data = data;\n> +\tskb->len = packet_len;\n> +\tlen_remaining = packet_len;\n> +\tif (segments == 1) {\n> +\t\t/* Strip the ethernet fcs */\n> +\t\tskb->len -= 4;\n> +\t\tskb_set_tail_pointer(skb, skb->len);\n> +\t} else {\n> +\t\tbool first_frag = true;\n> +\t\tstruct sk_buff *current_skb = skb;\n> +\t\tstruct sk_buff *next_skb = NULL;\n> +\t\tunsigned int segment_size;\n> +\n> +\t\tskb_frag_list_init(skb);\n> +\t\tfor (;;) {\n> +\t\t\tsegment_size = (segments == 1) ? len_remaining : packet_ptr.size;\n> +\t\t\tlen_remaining -= segment_size;\n> +\t\t\tif (!first_frag) {\n> +\t\t\t\tcurrent_skb->len = segment_size;\n> +\t\t\t\tskb->data_len += segment_size;\n> +\t\t\t\tskb->truesize += current_skb->truesize;\n> +\t\t\t}\n> +\t\t\tskb_set_tail_pointer(current_skb, segment_size);\n> +\t\t\tsegments--;\n> +\t\t\tif (segments == 0)\n> +\t\t\t\tbreak;\n> +\t\t\tpacket_ptr.u64 = *(u64 *)(data - 8);\n> +#ifndef __LITTLE_ENDIAN\n> +\t\t\tif (OCTEON_IS_MODEL(OCTEON_CN78XX_PASS1_X)) {\n> +\t\t\t\t/* PKI_BUFLINK_S's are endian-swapped */\n> +\t\t\t\tpacket_ptr.u64 = swab64(packet_ptr.u64);\n> +\t\t\t}\n> +#endif\n> +\t\t\tdata = phys_to_virt(packet_ptr.addr);\n> +\t\t\tnext_skb = octeon3_eth_work_to_skb((void *)round_down((unsigned long)data, 128ull));\n> +\t\t\tif (first_frag) {\n> +\t\t\t\tnext_skb->next = skb_shinfo(current_skb)->frag_list;\n> +\t\t\t\tskb_shinfo(current_skb)->frag_list = next_skb;\n> +\t\t\t} else {\n> +\t\t\t\tcurrent_skb->next = next_skb;\n> +\t\t\t\tnext_skb->next = NULL;\n> +\t\t\t}\n> +\t\t\tcurrent_skb = next_skb;\n> +\t\t\tfirst_frag = false;\n> +\t\t\tcurrent_skb->data = data;\n> +\t\t}\n> +\n> +\t\t/* Strip the ethernet fcs */\n> +\t\tpskb_trim(skb, skb->len - 4);\n> +\t}\n> +\n> +\tif (likely(priv->netdev->flags & IFF_UP)) {\n> +\t\tskb_checksum_none_assert(skb);\n> +\t\tif (unlikely(priv->rx_timestamp_hw)) {\n> +\t\t\t/* The first 8 bytes are the timestamp */\n> +\t\t\tu64 hwts = *(u64 *)skb->data;\n> +\t\t\tu64 ns;\n> +\t\t\tstruct skb_shared_hwtstamps *shts;\n> +\n> +\t\t\tns = timecounter_cyc2time(&priv->tc, hwts);\n> +\t\t\tshts = skb_hwtstamps(skb);\n> +\t\t\tmemset(shts, 0, sizeof(*shts));\n> +\t\t\tshts->hwtstamp = ns_to_ktime(ns);\n> +\t\t\t__skb_pull(skb, 8);\n> +\t\t}\n> +\n> +\t\tskb->protocol = eth_type_trans(skb, priv->netdev);\n> +\t\tskb->dev = priv->netdev;\n> +\t\tif (priv->netdev->features & NETIF_F_RXCSUM) {\n> +\t\t\tif ((work->word2.lc_hdr_type == PKI_LTYPE_IP4 ||\n> +\t\t\t work->word2.lc_hdr_type == PKI_LTYPE_IP6) &&\n> +\t\t\t (work->word2.lf_hdr_type == PKI_LTYPE_TCP ||\n> +\t\t\t work->word2.lf_hdr_type == PKI_LTYPE_UDP ||\n> +\t\t\t work->word2.lf_hdr_type == PKI_LTYPE_SCTP))\n> +\t\t\t\tif (work->word2.err_code == 0)\n> +\t\t\t\t\tskb->ip_summed = CHECKSUM_UNNECESSARY;\n> +\t\t}\n> +\n> +\t\tnapi_gro_receive(&rx->napi, skb);\n> +\t} else {\n> +\t\t/* Drop any packet received for a device that isn't up */\n\nIf that happens, is not that a blatant indication that there is a bug in\nhow the interface is brought down?\n\n> +\t\tatomic64_inc(&priv->rx_dropped);\n> +\t\tdev_kfree_skb_any(skb);\n> +\t}\n> +out:\n> +\treturn ret;\n> +}\n> +\n> +static int octeon3_eth_napi(struct napi_struct *napi, int budget)\n> +{\n> +\tint rx_count = 0;\n> +\tstruct octeon3_rx *cxt;\n> +\tstruct octeon3_ethernet *priv;\n> +\tu64 aq_cnt;\n> +\tint n = 0;\n> +\tint n_bufs = 0;\n> +\tu64 old_scratch;\n> +\n> +\tcxt = container_of(napi, struct octeon3_rx, napi);\n> +\tpriv = cxt->parent;\n> +\n> +\t/* Get the amount of work pending */\n> +\taq_cnt = oct_csr_read(SSO_GRP_AQ_CNT(priv->node, cxt->rx_grp));\n> +\taq_cnt &= GENMASK_ULL(32, 0);\n> +\n> +\tif (likely(USE_ASYNC_IOBDMA)) {\n> +\t\t/* Save scratch in case userspace is using it */\n> +\t\tCVMX_SYNCIOBDMA;\n> +\t\told_scratch = scratch_read64(SCR_SCRATCH);\n> +\n> +\t\tocteon3_core_get_work_async(cxt->rx_grp);\n> +\t}\n> +\n> +\twhile (rx_count < budget) {\n> +\t\tn = 0;\n> +\n> +\t\tif (likely(USE_ASYNC_IOBDMA)) {\n> +\t\t\tbool req_next = rx_count < (budget - 1) ? true : false;\n> +\n> +\t\t\tn = octeon3_eth_rx_one(cxt, true, req_next);\n> +\t\t} else {\n> +\t\t\tn = octeon3_eth_rx_one(cxt, false, false);\n> +\t\t}\n> +\n> +\t\tif (n == 0)\n> +\t\t\tbreak;\n> +\n> +\t\tn_bufs += n;\n> +\t\trx_count++;\n> +\t}\n> +\n> +\t/* Wake up worker threads */\n> +\tn_bufs = atomic64_add_return(n_bufs, &priv->buffers_needed);\n> +\tif (n_bufs >= 32) {\n> +\t\tstruct octeon3_ethernet_node *oen;\n> +\n> +\t\toen = octeon3_eth_node + priv->node;\n> +\t\tatomic_set(&oen->workers[0].kick, 1);\n> +\t\twake_up(&oen->workers[0].queue);\n> +\t}\n> +\n> +\t/* Stop the thread when no work is pending */\n> +\tif (rx_count < budget) {\n> +\t\tnapi_complete(napi);\n> +\t\tocteon3_sso_irq_set(cxt->parent->node, cxt->rx_grp, true);\n> +\t}\n> +\n> +\tif (likely(USE_ASYNC_IOBDMA)) {\n> +\t\t/* Restore the scratch area */\n> +\t\tscratch_write64(SCR_SCRATCH, old_scratch);\n> +\t}\n> +\n> +\treturn rx_count;\n> +}\n> +\n> +#undef BROKEN_SIMULATOR_CSUM\n> +\n> +static void ethtool_get_drvinfo(struct net_device *netdev,\n> +\t\t\t\tstruct ethtool_drvinfo *info)\n> +{\n> +\tstrcpy(info->driver, \"octeon3-ethernet\");\n> +\tstrcpy(info->version, \"1.0\");\n> +\tstrcpy(info->bus_info, \"Builtin\");\n\nI believe the correct way to specify that type of bus is to use \"platform\".\n\n[snip]\n\n> +static int octeon3_eth_common_ndo_stop(struct net_device *netdev)\n> +{\n> +\tstruct octeon3_ethernet *priv = netdev_priv(netdev);\n> +\tvoid **w;\n> +\tstruct sk_buff *skb;\n> +\tstruct octeon3_rx *rx;\n> +\tint i;\n> +\n> +\t/* Allow enough time for ingress in transit packets to be drained */\n> +\tmsleep(20);\n\nCan you find a better way to do that? You can put a hard disable on the\nhardware, and then wait until a particular condition to indicate full\ndrainage?\n\n[snip]\n\n> +static int octeon3_eth_ndo_start_xmit(struct sk_buff *skb,\n> +\t\t\t\t struct net_device *netdev)\n> +{\n> +\tstruct sk_buff *skb_tmp;\n> +\tstruct octeon3_ethernet *priv = netdev_priv(netdev);\n> +\tu64 scr_off = LMTDMA_SCR_OFFSET;\n> +\tu64 pko_send_desc;\n> +\tu64 lmtdma_data;\n> +\tu64 aq_cnt = 0;\n> +\tstruct octeon3_ethernet_node *oen;\n> +\tlong backlog;\n> +\tint frag_count;\n> +\tu64 head_len;\n> +\tint i;\n> +\tu64 *dma_addr;\n\ndma_addr_t?\n\n> +\tvoid **work;\n> +\tunsigned int mss;\n> +\tint grp;\n> +\n> +\tfrag_count = 0;\n> +\tif (skb_has_frag_list(skb))\n> +\t\tskb_walk_frags(skb, skb_tmp)\n> +\t\t\tfrag_count++;\n> +\n> +\t/* Stop the queue if pko or sso are not keeping up */\n> +\toen = octeon3_eth_node + priv->node;\n> +\taq_cnt = oct_csr_read(SSO_GRP_AQ_CNT(oen->node, oen->tx_complete_grp));\n> +\taq_cnt &= GENMASK_ULL(32, 0);\n> +\tbacklog = atomic64_inc_return(&priv->tx_backlog);\n> +\tif (unlikely(backlog > MAX_TX_QUEUE_DEPTH || aq_cnt > 100000))\n> +\t\tnetif_stop_queue(netdev);\n> +\n> +\t/* We have space for 11 segment pointers, If there will be\n> +\t * more than that, we must linearize. The count is: 1 (base\n> +\t * SKB) + frag_count + nr_frags.\n> +\t */\n> +\tif (unlikely(skb_shinfo(skb)->nr_frags + frag_count > 10)) {\n> +\t\tif (unlikely(__skb_linearize(skb)))\n> +\t\t\tgoto skip_xmit;\n> +\t\tfrag_count = 0;\n> +\t}\n\nWhat's so special about 10? The maximum the network stack could pass is\nSKB_MAX_FRAGS, what would happen in that case?\n\n> +\n> +\twork = (void **)skb->cb;\n> +\twork[0] = netdev;\n> +\twork[1] = NULL;\n> +\n> +\t/* Adjust the port statistics. */\n> +\tatomic64_inc(&priv->tx_packets);\n> +\tatomic64_add(skb->len, &priv->tx_octets);\n\nDo this in the TX completion worker, there is no guarantee the packet\nwill be transmitted that early in this function.\n\n> +\n> +\t/* Make sure packet data writes are committed before\n> +\t * submitting the command below\n> +\t */\n> +\twmb();\n\nThat seems just wrong here, if your goal is to make sure that e.g:\nskb_linearize() did finish its pending writes to DRAM, you need to use\nDMA-API towards that goal. If the device is cache coherent, DMA-API will\nknow that and do nothing.\n\n> +\n> +\t/* Build the pko command */\n> +\tpko_send_desc = build_pko_send_hdr_desc(skb);\n> +\tpreempt_disable();\n\nWhy do you disable preemption here?\n\n> +\tscratch_write64(scr_off, pko_send_desc);\n> +\tscr_off += sizeof(pko_send_desc);\n> +\n> +\t/* Request packet to be ptp timestamped */\n> +\tif ((unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) &&\n> +\t unlikely(priv->tx_timestamp_hw)) {\n> +\t\tpko_send_desc = build_pko_send_ext_desc(skb);\n> +\t\tscratch_write64(scr_off, pko_send_desc);\n> +\t\tscr_off += sizeof(pko_send_desc);\n> +\t}\n> +\n> +\t/* Add the tso descriptor if needed */\n> +\tmss = skb_shinfo(skb)->gso_size;\n> +\tif (unlikely(mss)) {\n> +\t\tpko_send_desc = build_pko_send_tso(skb, netdev->mtu);\n> +\t\tscratch_write64(scr_off, pko_send_desc);\n> +\t\tscr_off += sizeof(pko_send_desc);\n> +\t}\n> +\n> +\t/* Add a gather descriptor for each segment. See PKO_SEND_GATHER_S for\n> +\t * the send gather descriptor format.\n> +\t */\n> +\tpko_send_desc = 0;\n> +\tpko_send_desc |= (u64)PKO_SENDSUBDC_GATHER << 45;\n> +\thead_len = skb_headlen(skb);\n> +\tif (head_len > 0) {\n> +\t\tpko_send_desc |= head_len << 48;\n> +\t\tpko_send_desc |= virt_to_phys(skb->data);\n> +\t\tscratch_write64(scr_off, pko_send_desc);\n> +\t\tscr_off += sizeof(pko_send_desc);\n> +\t}\n> +\tfor (i = 1; i <= skb_shinfo(skb)->nr_frags; i++) {\n> +\t\tstruct skb_frag_struct *fs = skb_shinfo(skb)->frags + i - 1;\n> +\n> +\t\tpko_send_desc &= ~(GENMASK_ULL(63, 48) | GENMASK_ULL(41, 0));\n> +\t\tpko_send_desc |= (u64)fs->size << 48;\n> +\t\tpko_send_desc |= virt_to_phys((u8 *)page_address(fs->page.p) + fs->page_offset);\n> +\t\tscratch_write64(scr_off, pko_send_desc);\n> +\t\tscr_off += sizeof(pko_send_desc);\n> +\t}\n> +\tskb_walk_frags(skb, skb_tmp) {\n> +\t\tpko_send_desc &= ~(GENMASK_ULL(63, 48) | GENMASK_ULL(41, 0));\n> +\t\tpko_send_desc |= (u64)skb_tmp->len << 48;\n> +\t\tpko_send_desc |= virt_to_phys(skb_tmp->data);\n> +\t\tscratch_write64(scr_off, pko_send_desc);\n> +\t\tscr_off += sizeof(pko_send_desc);\n> +\t}\n> +\n> +\t/* Subtract 1 from the tx_backlog. */\n> +\tpko_send_desc = build_pko_send_mem_sub(virt_to_phys(&priv->tx_backlog));\n> +\tscratch_write64(scr_off, pko_send_desc);\n> +\tscr_off += sizeof(pko_send_desc);\n> +\n> +\t/* Write the ptp timestamp in the skb itself */\n> +\tif ((unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) &&\n> +\t unlikely(priv->tx_timestamp_hw)) {\n> +\t\tpko_send_desc = build_pko_send_mem_ts(virt_to_phys(&work[1]));\n> +\t\tscratch_write64(scr_off, pko_send_desc);\n> +\t\tscr_off += sizeof(pko_send_desc);\n> +\t}\n> +\n> +\t/* Send work when finished with the packet. */\n> +\tgrp = octeon3_eth_lgrp_to_ggrp(priv->node, priv->tx_complete_grp);\n> +\tpko_send_desc = build_pko_send_work(grp, virt_to_phys(work));\n> +\tscratch_write64(scr_off, pko_send_desc);\n> +\tscr_off += sizeof(pko_send_desc);\n> +\n> +\t/* See PKO_SEND_DMA_S in the HRM for the lmtdam data format */\n> +\tlmtdma_data = 0;\n> +\tlmtdma_data |= (u64)(LMTDMA_SCR_OFFSET >> 3) << 56;\n> +\tif (wait_pko_response)\n> +\t\tlmtdma_data |= 1ull << 48;\n> +\tlmtdma_data |= 0x51ull << 40;\n> +\tlmtdma_data |= (u64)priv->node << 36;\n> +\tlmtdma_data |= priv->pko_queue << 16;\n> +\n> +\tdma_addr = (u64 *)(LMTDMA_ORDERED_IO_ADDR | ((scr_off & 0x78) - 8));\n> +\t*dma_addr = lmtdma_data;\n> +\n> +\tpreempt_enable();\n> +\n> +\tif (wait_pko_response) {\n> +\t\tu64\tquery_rtn;\n> +\n> +\t\tCVMX_SYNCIOBDMA;\n> +\n> +\t\t/* See PKO_QUERY_RTN_S in the HRM for the return format */\n> +\t\tquery_rtn = scratch_read64(LMTDMA_SCR_OFFSET);\n> +\t\tquery_rtn >>= 60;\n> +\t\tif (unlikely(query_rtn != PKO_DQSTATUS_PASS)) {\n> +\t\t\tnetdev_err(netdev, \"PKO enqueue failed %llx\\n\",\n> +\t\t\t\t (unsigned long long)query_rtn);\n> +\t\t\tdev_kfree_skb_any(skb);\n> +\t\t}\n> +\t}\n\nSo I am not sure I fully understand how sending packets works, although\nit seems to be like you are building a work element (pko_send_desc)\nwhich references either a full-size Ethernet frame, or that frame and\nits fragments (multiple pko_send_desc). In that case, I don't see why\nyou can't juse dma_map_single()/dma_unmap_single() against skb->data and\nits potential fragments instead of using virt_to_phys() like you\ncurrently do, which is absolutely not portable.\n\ndma_map_single() on the kernel linear address space should be equivalent\nto virt_to_phys() anyway, and you would get the nice things about\nDMA-API like its portability.\n\nI could imagine that, for coherency purposes, there may be a requirement\nto keep tskb->data and frieds to be within XKSEG0/1, if that's the case,\nDMA-API should know that too.\n\nI might be completely off, but using virt_to_phys() sure does sound non\nportable here.\n\n> +\n> +\treturn NETDEV_TX_OK;\n> +skip_xmit:\n> +\tatomic64_inc(&priv->tx_dropped);\n> +\tdev_kfree_skb_any(skb);\n> +\treturn NETDEV_TX_OK;\n> +}\n> +\n> +static void octeon3_eth_ndo_get_stats64(struct net_device *netdev,\n> +\t\t\t\t\tstruct rtnl_link_stats64 *s)\n> +{\n> +\tstruct octeon3_ethernet *priv = netdev_priv(netdev);\n> +\tu64 packets, octets, dropped;\n> +\tu64 delta_packets, delta_octets, delta_dropped;\n> +\n> +\tspin_lock(&priv->stat_lock);\n\nConsider using u64_stats_sync to get rid of this lock...\n\n> +\n> +\tocteon3_pki_get_stats(priv->node, priv->pknd, &packets, &octets, &dropped);\n> +\n> +\tdelta_packets = (packets - priv->last_packets) & ((1ull << 48) - 1);\n> +\tdelta_octets = (octets - priv->last_octets) & ((1ull << 48) - 1);\n> +\tdelta_dropped = (dropped - priv->last_dropped) & ((1ull << 48) - 1);\n> +\n> +\tpriv->last_packets = packets;\n> +\tpriv->last_octets = octets;\n> +\tpriv->last_dropped = dropped;\n> +\n> +\tspin_unlock(&priv->stat_lock);\n> +\n> +\tatomic64_add(delta_packets, &priv->rx_packets);\n> +\tatomic64_add(delta_octets, &priv->rx_octets);\n> +\tatomic64_add(delta_dropped, &priv->rx_dropped);\n\nand summing up these things as well.\n\n> +\n> +\ts->rx_packets = atomic64_read(&priv->rx_packets);\n> +\ts->rx_bytes = atomic64_read(&priv->rx_octets);\n> +\ts->rx_dropped = atomic64_read(&priv->rx_dropped);\n> +\ts->rx_errors = atomic64_read(&priv->rx_errors);\n> +\ts->rx_length_errors = atomic64_read(&priv->rx_length_errors);\n> +\ts->rx_crc_errors = atomic64_read(&priv->rx_crc_errors);\n> +\n> +\ts->tx_packets = atomic64_read(&priv->tx_packets);\n> +\ts->tx_bytes = atomic64_read(&priv->tx_octets);\n> +\ts->tx_dropped = atomic64_read(&priv->tx_dropped);\n> +}\n\n[snip]\n\n> +enum port_mode {\n> +\tPORT_MODE_DISABLED,\n> +\tPORT_MODE_SGMII,\n> +\tPORT_MODE_RGMII,\n> +\tPORT_MODE_XAUI,\n> +\tPORT_MODE_RXAUI,\n> +\tPORT_MODE_XLAUI,\n> +\tPORT_MODE_XFI,\n> +\tPORT_MODE_10G_KR,\n> +\tPORT_MODE_40G_KR4\n> +};\n\nCan you use phy_interface_t values for this?\n\n> +\n> +enum lane_mode {\n> +\tR_25G_REFCLK100,\n> +\tR_5G_REFCLK100,\n> +\tR_8G_REFCLK100,\n> +\tR_125G_REFCLK15625_KX,\n> +\tR_3125G_REFCLK15625_XAUI,\n> +\tR_103125G_REFCLK15625_KR,\n> +\tR_125G_REFCLK15625_SGMII,\n> +\tR_5G_REFCLK15625_QSGMII,\n> +\tR_625G_REFCLK15625_RXAUI,\n> +\tR_25G_REFCLK125,\n> +\tR_5G_REFCLK125,\n> +\tR_8G_REFCLK125\n> +};\n> +\n> +struct port_status {\n> +\tint\tlink;\n> +\tint\tduplex;\n> +\tint\tspeed;\n> +};\n\nLikewise, using phy_device would give you this information.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@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=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"Dys5ETXz\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySZX26nYbz9sBd\n\tfor ;\n\tFri, 3 Nov 2017 06:14:26 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S934305AbdKBTN6 (ORCPT );\n\tThu, 2 Nov 2017 15:13:58 -0400","from mail-pg0-f68.google.com ([74.125.83.68]:48211 \"EHLO\n\tmail-pg0-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S932571AbdKBTNz (ORCPT\n\t); Thu, 2 Nov 2017 15:13:55 -0400","by mail-pg0-f68.google.com with SMTP id v78so442000pgb.5;\n\tThu, 02 Nov 2017 12:13:55 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\tr78sm8823363pfb.29.2017.11.02.12.13.50\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 02 Nov 2017 12:13:51 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=nbkXiN1XIvyBk2F0ZSTD2iaIU1Fmi+RXsdEAcqVxa5Y=;\n\tb=Dys5ETXzNRZHF6ZEU7E6SKcbSaw4qaL/gN/Xee8D0ToZc6n8lBfvBHLROI5+5gQ6Pu\n\tWBBGS2ubUkyDPz4hMeujMbC1feefNBWN8utWjnd1sO1+z0s31CoMJprcFXRuQdDykygs\n\teH8WYuHgMkMDOa2D44Agqr03nfUsFHjktNKdSTiJ4NLZ+8SgHKI6evbHmPyeEROXD40u\n\tQy5AaLCJNSxXmHP28U/OVPG28V2NU4tcyDbf1n+XKZoiDxwRCIM1wmkJllH9OMXJacYX\n\t7BkYQNjQs3iYteoUUPYDwKE6MirJY1oi6mrXRTuj/HagGcwO5zGZ20t6ATcytJqm93GK\n\tJCFQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=nbkXiN1XIvyBk2F0ZSTD2iaIU1Fmi+RXsdEAcqVxa5Y=;\n\tb=OYQBpZKv9G8VGZ4I9MCOOfmpE9XIOZ/794VlVn+sL6S4N3ys4J4MZuQkT/63rD8EVM\n\t6JPaoDX5qdsPIUgSZ/9p0iXgh2i3eS7akPCJFqRQJPhT0EB9M5r1LR33P4p7FZBsoZIy\n\tkgxSWPIR0iS9FbqTrjtBVBg2RlcQ8z6P3yf1+SxE8ICCROZ13dH4Flc81Zw+snJEiX+P\n\txXraWvjpURBCqXXiVKQ1wQIBBG9q9l8vxvjtLa3yVaJGRbndhqYw5RwxXqs9NKmgZ/By\n\tCAcWiGAukO8oT/CwfgK+viybCWj2c4/1Q5l4bAQXnnlIlSaWMYfqP2iXsBST6u+uAOq5\n\tK73g==","X-Gm-Message-State":"AMCzsaWQImB9MPHSg53lbOlrH8DrjU0a/ibUaU1kF6fuDT3Scwh/g8iQ\n\tsdsuSBZPysgHUy9QgoVPBiw=","X-Google-Smtp-Source":"ABhQp+R6muuuu7c5sjWBJRk5Frm1oSXt/K5AEgb/tnGY+KNgxx5MLXp5Ss3L11pgRdqmmvg4hp1rFA==","X-Received":"by 10.159.235.147 with SMTP id f19mr4304845plr.42.1509650032899; \n\tThu, 02 Nov 2017 12:13:52 -0700 (PDT)","Subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","To":"David Daney , linux-mips@linux-mips.org,\n\tralf@linux-mips.org, James Hogan ,\n\tnetdev@vger.kernel.org, \"David S. Miller\" ,\n\tRob Herring , Mark Rutland ","Cc":"linux-kernel@vger.kernel.org, \"Steven J. Hill\" ,\n\tdevicetree@vger.kernel.org, Carlos Munoz ","References":"<20171102003606.19913-1-david.daney@cavium.com>\n\t<20171102003606.19913-7-david.daney@cavium.com>","From":"Florian Fainelli ","Message-ID":"<55d6cf88-7444-42ea-02f1-27efdee2be4b@gmail.com>","Date":"Thu, 2 Nov 2017 12:13:49 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20171102003606.19913-7-david.daney@cavium.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1798328,"web_url":"http://patchwork.ozlabs.org/comment/1798328/","msgid":"","list_archive_url":null,"date":"2017-11-02T22:45:26","subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","submitter":{"id":721,"url":"http://patchwork.ozlabs.org/api/people/721/","name":"David Daney","email":"ddaney@caviumnetworks.com"},"content":"On 11/02/2017 12:13 PM, Florian Fainelli wrote:\n> On 11/01/2017 05:36 PM, David Daney wrote:\n>> From: Carlos Munoz \n>>\n>> The Cavium OCTEON cn78xx and cn73xx SoCs have network packet I/O\n>> hardware that is significantly different from previous generations of\n>> the family.\n>>\n>> Add a new driver for this hardware. The Ethernet MAC is called BGX on\n>> these devices. Common code for the MAC is in octeon3-bgx-port.c.\n>> Four of these BGX MACs are grouped together and managed as a group by\n>> octeon3-bgx-nexus.c. Ingress packet classification is done by the PKI\n>> unit initialized in octeon3-pki.c. Queue management is done in the\n>> SSO, initialized by octeon3-sso.c. Egress is handled by the PKO,\n>> initialized in octeon3-pko.c.\n>>\n>> Signed-off-by: Carlos Munoz \n>> Signed-off-by: Steven J. Hill \n>> Signed-off-by: David Daney \n>> ---\n> \n>> +static char *mix_port;\n>> +module_param(mix_port, charp, 0444);\n>> +MODULE_PARM_DESC(mix_port, \"Specifies which ports connect to MIX interfaces.\");\n> \n> Can you derive this from Device Tree /platform data configuration?\n> \n>> +\n>> +static char *pki_port;\n>> +module_param(pki_port, charp, 0444);\n>> +MODULE_PARM_DESC(pki_port, \"Specifies which ports connect to the PKI.\");\n> \n> Likewise\n\nThe SoC is flexible in how it is configured. Technically the device \ntree should only be used to specify information about the physical \nconfiguration of the system that cannot be probed for, and this is about \npolicy rather that physical wiring. That said, we do take the default \nconfiguration from the device tree, but give the option here to override \nvia the module command line.\n\n> \n>> +\n>> +#define MAX_MIX_PER_NODE\t2\n>> +\n>> +#define MAX_MIX\t\t\t(MAX_NODES * MAX_MIX_PER_NODE)\n>> +\n>> +/**\n>> + * struct mix_port_lmac - Describes a lmac that connects to a mix\n>> + *\t\t\t port. The lmac must be on the same node as\n>> + *\t\t\t the mix.\n>> + * @node:\tNode of the lmac.\n>> + * @bgx:\tBgx of the lmac.\n>> + * @lmac:\tLmac index.\n>> + */\n>> +struct mix_port_lmac {\n>> +\tint\tnode;\n>> +\tint\tbgx;\n>> +\tint\tlmac;\n>> +};\n>> +\n>> +/* mix_ports_lmacs contains all the lmacs connected to mix ports */\n>> +static struct mix_port_lmac mix_port_lmacs[MAX_MIX];\n>> +\n>> +/* pki_ports keeps track of the lmacs connected to the pki */\n>> +static bool pki_ports[MAX_NODES][MAX_BGX_PER_NODE][MAX_LMAC_PER_BGX];\n>> +\n>> +/* Created platform devices get added to this list */\n>> +static struct list_head pdev_list;\n>> +static struct mutex pdev_list_lock;\n>> +\n>> +/* Created platform device use this structure to add themselves to the list */\n>> +struct pdev_list_item {\n>> +\tstruct list_head\tlist;\n>> +\tstruct platform_device\t*pdev;\n>> +};\n> \n> Don't you have a top-level platform device that you could use which\n> would hold this data instead of having it here?\n\nThis is the top-level platform device.\n\n\n> \n> [snip]\n> \n>> +/* Registers are accessed via xkphys */\n>> +#define SSO_BASE\t\t\t0x1670000000000ull\n>> +#define SSO_ADDR(node)\t\t\t(SET_XKPHYS + NODE_OFFSET(node) + \\\n>> +\t\t\t\t\t SSO_BASE)\n>> +#define GRP_OFFSET(grp)\t\t\t((grp) << 16)\n>> +#define GRP_ADDR(n, g)\t\t\t(SSO_ADDR(n) + GRP_OFFSET(g))\n>> +#define SSO_GRP_AQ_CNT(n, g)\t\t(GRP_ADDR(n, g)\t\t + 0x20000700)\n>> +\n>> +#define MIO_PTP_BASE\t\t\t0x1070000000000ull\n>> +#define MIO_PTP_ADDR(node)\t\t(SET_XKPHYS + NODE_OFFSET(node) + \\\n>> +\t\t\t\t\t MIO_PTP_BASE)\n>> +#define MIO_PTP_CLOCK_CFG(node)\t\t(MIO_PTP_ADDR(node)\t\t+ 0xf00)\n>> +#define MIO_PTP_CLOCK_HI(node)\t\t(MIO_PTP_ADDR(node)\t\t+ 0xf10)\n>> +#define MIO_PTP_CLOCK_COMP(node)\t(MIO_PTP_ADDR(node)\t\t+ 0xf18)\n> \n> I am sure this will work great on anything but MIPS64 ;)\n\nSarcasm duly noted.\n\nThat said, by definition it is exactly an OCTEON-III/MIPS64, and can \nnever be anything else. It is known a priori that the hardware and this \ndriver will never be used anywhere else.\n\n> \n>> +\n>> +struct octeon3_ethernet;\n>> +\n>> +struct octeon3_rx {\n>> +\tstruct napi_struct\tnapi;\n>> +\tstruct octeon3_ethernet *parent;\n>> +\tint rx_grp;\n>> +\tint rx_irq;\n>> +\tcpumask_t rx_affinity_hint;\n>> +} ____cacheline_aligned_in_smp;\n>> +\n>> +struct octeon3_ethernet {\n>> +\tstruct bgx_port_netdev_priv bgx_priv; /* Must be first element. */\n>> +\tstruct list_head list;\n>> +\tstruct net_device *netdev;\n>> +\tenum octeon3_mac_type mac_type;\n>> +\tstruct octeon3_rx rx_cxt[MAX_RX_QUEUES];\n>> +\tstruct ptp_clock_info ptp_info;\n>> +\tstruct ptp_clock *ptp_clock;\n>> +\tstruct cyclecounter cc;\n>> +\tstruct timecounter tc;\n>> +\tspinlock_t ptp_lock;\t\t/* Serialize ptp clock adjustments */\n>> +\tint num_rx_cxt;\n>> +\tint pki_aura;\n>> +\tint pknd;\n>> +\tint pko_queue;\n>> +\tint node;\n>> +\tint interface;\n>> +\tint index;\n>> +\tint rx_buf_count;\n>> +\tint tx_complete_grp;\n>> +\tint rx_timestamp_hw:1;\n>> +\tint tx_timestamp_hw:1;\n>> +\tspinlock_t stat_lock;\t\t/* Protects stats counters */\n>> +\tu64 last_packets;\n>> +\tu64 last_octets;\n>> +\tu64 last_dropped;\n>> +\tatomic64_t rx_packets;\n>> +\tatomic64_t rx_octets;\n>> +\tatomic64_t rx_dropped;\n>> +\tatomic64_t rx_errors;\n>> +\tatomic64_t rx_length_errors;\n>> +\tatomic64_t rx_crc_errors;\n>> +\tatomic64_t tx_packets;\n>> +\tatomic64_t tx_octets;\n>> +\tatomic64_t tx_dropped;\n> \n> Do you really need those to be truly atomic64_t types, can't you use u64\n> and use the helpers from u64_stats_sync.h? That should be good enough?\n\nThere is room for improvement here. We probably need to keep statistics \nper queue, and then the atomic business would be unnecessary.\n\n\n> \n>> +\t/* The following two fields need to be on a different cache line as\n>> +\t * they are updated by pko which invalidates the cache every time it\n>> +\t * updates them. The idea is to prevent other fields from being\n>> +\t * invalidated unnecessarily.\n>> +\t */\n>> +\tchar cacheline_pad1[CVMX_CACHE_LINE_SIZE];\n>> +\tatomic64_t buffers_needed;\n>> +\tatomic64_t tx_backlog;\n>> +\tchar cacheline_pad2[CVMX_CACHE_LINE_SIZE];\n>> +};\n>> +\n>> +static DEFINE_MUTEX(octeon3_eth_init_mutex);\n>> +\n>> +struct octeon3_ethernet_node;\n>> +\n>> +struct octeon3_ethernet_worker {\n>> +\twait_queue_head_t queue;\n>> +\tstruct task_struct *task;\n>> +\tstruct octeon3_ethernet_node *oen;\n>> +\tatomic_t kick;\n>> +\tint order;\n>> +};\n>> +\n>> +struct octeon3_ethernet_node {\n>> +\tbool init_done;\n>> +\tint next_cpu_irq_affinity;\n>> +\tint node;\n>> +\tint pki_packet_pool;\n>> +\tint sso_pool;\n>> +\tint pko_pool;\n>> +\tvoid *sso_pool_stack;\n>> +\tvoid *pko_pool_stack;\n>> +\tvoid *pki_packet_pool_stack;\n>> +\tint sso_aura;\n>> +\tint pko_aura;\n>> +\tint tx_complete_grp;\n>> +\tint tx_irq;\n>> +\tcpumask_t tx_affinity_hint;\n>> +\tstruct octeon3_ethernet_worker workers[8];\n>> +\tstruct mutex device_list_lock;\t/* Protects the device list */\n>> +\tstruct list_head device_list;\n>> +\tspinlock_t napi_alloc_lock;\t/* Protects napi allocations */\n>> +};\n>> +\n>> +static int wait_pko_response;\n>> +module_param(wait_pko_response, int, 0644);\n>> +MODULE_PARM_DESC(wait_pko_response, \"Wait for response after each pko command.\");\n> \n> Under which circumstances is this used?\n\nRarely if ever, I think I will remove it.\n\n> \n>> +\n>> +static int num_packet_buffers = 768;\n>> +module_param(num_packet_buffers, int, 0444);\n>> +MODULE_PARM_DESC(num_packet_buffers,\n>> +\t\t \"Number of packet buffers to allocate per port.\");\n> \n> Consider implementing ethtool -g/G for this.\n\nThat may be work for a follow-on patch.\n\n> \n>> +\n>> +static int packet_buffer_size = 2048;\n>> +module_param(packet_buffer_size, int, 0444);\n>> +MODULE_PARM_DESC(packet_buffer_size, \"Size of each RX packet buffer.\");\n> \n> How is that different from adjusting the network device's MTU?\n\nMultiple buffers may be linked together creating a fragmented packet for \nMTU greater than packet_buffer_size.\n\nMTU controls which packets are rejected because they are too large.\npacket_buffer_size is the size of the RX buffers.\n\n\n> \n>> +\n>> +static int rx_queues = 1;\n>> +module_param(rx_queues, int, 0444);\n>> +MODULE_PARM_DESC(rx_queues, \"Number of RX threads per port.\");\n> \n> Same thing, can you consider using an ethtool knob for that?\n\nAlso may be work for a follow-on patch.\n\n> \n>> +\n>> +int ilk0_lanes = 1;\n>> +module_param(ilk0_lanes, int, 0444);\n>> +MODULE_PARM_DESC(ilk0_lanes, \"Number of SerDes lanes used by ILK link 0.\");\n>> +\n>> +int ilk1_lanes = 1;\n>> +module_param(ilk1_lanes, int, 0444);\n>> +MODULE_PARM_DESC(ilk1_lanes, \"Number of SerDes lanes used by ILK link 1.\");\n>> +\n>> +static struct octeon3_ethernet_node octeon3_eth_node[MAX_NODES];\n>> +static struct kmem_cache *octeon3_eth_sso_pko_cache;\n>> +\n>> +/**\n>> + * Reads a 64 bit value from the processor local scratchpad memory.\n>> + *\n>> + * @param offset byte offset into scratch pad to read\n>> + *\n>> + * @return value read\n>> + */\n>> +static inline u64 scratch_read64(u64 offset)\n>> +{\n>> +\treturn *(u64 *)((long)SCRATCH_BASE + offset);\n>> +}\n> \n> No barriers needed whatsoever?\n\nNope.\n\n> \n>> +\n>> +/**\n>> + * Write a 64 bit value to the processor local scratchpad memory.\n>> + *\n>> + * @param offset byte offset into scratch pad to write\n>> + @ @praram value to write\n>> + */\n>> +static inline void scratch_write64(u64 offset, u64 value)\n>> +{\n>> +\t*(u64 *)((long)SCRATCH_BASE + offset) = value;\n>> +}\n>> +\n>> +static int get_pki_chan(int node, int interface, int index)\n>> +{\n>> +\tint\tpki_chan;\n>> +\n>> +\tpki_chan = node << 12;\n>> +\n>> +\tif (OCTEON_IS_MODEL(OCTEON_CNF75XX) &&\n>> +\t (interface == 1 || interface == 2)) {\n>> +\t\t/* SRIO */\n>> +\t\tpki_chan |= 0x240 + (2 * (interface - 1)) + index;\n>> +\t} else {\n>> +\t\t/* BGX */\n>> +\t\tpki_chan |= 0x800 + (0x100 * interface) + (0x10 * index);\n>> +\t}\n>> +\n>> +\treturn pki_chan;\n>> +}\n>> +\n>> +/* Map auras to the field priv->buffers_needed. Used to speed up packet\n>> + * transmission.\n>> + */\n>> +static void *aura2bufs_needed[MAX_NODES][FPA3_NUM_AURAS];\n>> +\n>> +static int octeon3_eth_lgrp_to_ggrp(int node, int grp)\n>> +{\n>> +\treturn (node << 8) | grp;\n>> +}\n>> +\n>> +static void octeon3_eth_gen_affinity(int node, cpumask_t *mask)\n>> +{\n>> +\tint cpu;\n>> +\n>> +\tdo {\n>> +\t\tcpu = cpumask_next(octeon3_eth_node[node].next_cpu_irq_affinity, cpu_online_mask);\n>> +\t\tocteon3_eth_node[node].next_cpu_irq_affinity++;\n>> +\t\tif (cpu >= nr_cpu_ids) {\n>> +\t\t\tocteon3_eth_node[node].next_cpu_irq_affinity = -1;\n>> +\t\t\tcontinue;\n>> +\t\t}\n>> +\t} while (false);\n>> +\tcpumask_clear(mask);\n>> +\tcpumask_set_cpu(cpu, mask);\n>> +}\n>> +\n>> +struct wr_ret {\n>> +\tvoid *work;\n>> +\tu16 grp;\n>> +};\n>> +\n>> +static inline struct wr_ret octeon3_core_get_work_sync(int grp)\n>> +{\n>> +\tu64\t\tnode = cvmx_get_node_num();\n>> +\tu64\t\taddr;\n>> +\tu64\t\tresponse;\n>> +\tstruct wr_ret\tr;\n>> +\n>> +\t/* See SSO_GET_WORK_LD_S for the address to read */\n>> +\taddr = 1ull << 63;\n>> +\taddr |= BIT(48);\n>> +\taddr |= DID_TAG_SWTAG << 40;\n>> +\taddr |= node << 36;\n>> +\taddr |= BIT(30);\n>> +\taddr |= BIT(29);\n>> +\taddr |= octeon3_eth_lgrp_to_ggrp(node, grp) << 4;\n>> +\taddr |= SSO_NO_WAIT << 3;\n>> +\tresponse = __raw_readq((void __iomem *)addr);\n>> +\n>> +\t/* See SSO_GET_WORK_RTN_S for the format of the response */\n>> +\tr.grp = (response & GENMASK_ULL(57, 48)) >> 48;\n>> +\tif (response & BIT(63))\n>> +\t\tr.work = NULL;\n>> +\telse\n>> +\t\tr.work = phys_to_virt(response & GENMASK_ULL(41, 0));\n> \n> There are quite a lot of phys_to_virt() and virt_to_phys() uses\n> throughout this driver, this will likely not work on anything but\n> MIPS64, so there should be a better way, abstracted to do this, see below.\n\nSee above, this is OCTEON-III/MIPS64 only. More abstractions don't \nsolve any problems, and may introduce function calls in the hot path \nwith their associated pipeline stalls and branch mispredictions.\n\n\n> \n>> +\n>> +\treturn r;\n>> +}\n>> +\n>> +/**\n>> + * octeon3_core_get_work_async - Request work via a iobdma command. Doesn't wait\n>> + *\t\t\t\t for the response.\n>> + *\n>> + * @grp: Group to request work for.\n>> + */\n>> +static inline void octeon3_core_get_work_async(unsigned int grp)\n>> +{\n>> +\tu64\tdata;\n>> +\tu64\tnode = cvmx_get_node_num();\n>> +\n>> +\t/* See SSO_GET_WORK_DMA_S for the command structure */\n>> +\tdata = SCR_SCRATCH << 56;\n>> +\tdata |= 1ull << 48;\n>> +\tdata |= DID_TAG_SWTAG << 40;\n>> +\tdata |= node << 36;\n>> +\tdata |= 1ull << 30;\n>> +\tdata |= 1ull << 29;\n>> +\tdata |= octeon3_eth_lgrp_to_ggrp(node, grp) << 4;\n>> +\tdata |= SSO_NO_WAIT << 3;\n>> +\n>> +\t__raw_writeq(data, (void __iomem *)IOBDMA_SENDSINGLE);\n>> +}\n>> +\n>> +/**\n>> + * octeon3_core_get_response_async - Read the request work response. Must be\n>> + *\t\t\t\t called after calling\n>> + *\t\t\t\t octeon3_core_get_work_async().\n>> + *\n>> + * Returns work queue entry.\n>> + */\n>> +static inline struct wr_ret octeon3_core_get_response_async(void)\n>> +{\n>> +\tstruct wr_ret\tr;\n>> +\tu64\t\tresponse;\n>> +\n>> +\tCVMX_SYNCIOBDMA;\n>> +\tresponse = scratch_read64(SCR_SCRATCH);\n>> +\n>> +\t/* See SSO_GET_WORK_RTN_S for the format of the response */\n>> +\tr.grp = (response & GENMASK_ULL(57, 48)) >> 48;\n>> +\tif (response & BIT(63))\n>> +\t\tr.work = NULL;\n>> +\telse\n>> +\t\tr.work = phys_to_virt(response & GENMASK_ULL(41, 0));\n>> +\n>> +\treturn r;\n>> +}\n>> +\n>> +static void octeon3_eth_replenish_rx(struct octeon3_ethernet *priv, int count)\n>> +{\n>> +\tstruct sk_buff *skb;\n>> +\tint i;\n>> +\n>> +\tfor (i = 0; i < count; i++) {\n>> +\t\tvoid **buf;\n>> +\n>> +\t\tskb = __alloc_skb(packet_buffer_size, GFP_ATOMIC, 0, priv->node);\n>> +\t\tif (!skb)\n>> +\t\t\tbreak;\n>> +\t\tbuf = (void **)PTR_ALIGN(skb->head, 128);\n>> +\t\tbuf[SKB_PTR_OFFSET] = skb;\n> \n> Can you use build_skb()?\n\nIn theory we could, but that would require changing the architecture of \nthe driver to use page fragments. For better or worse, the choice was \nmade to use __alloc_skb() instead.\n\n\n> \n>> +\t\tocteon_fpa3_free(priv->node, priv->pki_aura, buf);\n>> +\t}\n>> +}\n>> +\n> \n> [snip]\n> \n>> +static int octeon3_eth_tx_complete_worker(void *data)\n>> +{\n>> +\tstruct octeon3_ethernet_worker *worker = data;\n>> +\tstruct octeon3_ethernet_node *oen = worker->oen;\n>> +\tint backlog;\n>> +\tint order = worker->order;\n>> +\tint tx_complete_stop_thresh = order * 100;\n>> +\tint backlog_stop_thresh = order == 0 ? 31 : order * 80;\n>> +\tu64 aq_cnt;\n>> +\tint i;\n>> +\n>> +\twhile (!kthread_should_stop()) {\n>> +\t\twait_event_interruptible(worker->queue, octeon3_eth_tx_complete_runnable(worker));\n>> +\t\tatomic_dec_if_positive(&worker->kick); /* clear the flag */\n>> +\n>> +\t\tdo {\n>> +\t\t\tbacklog = octeon3_eth_replenish_all(oen);\n>> +\t\t\tfor (i = 0; i < 100; i++) {\n> \n> Do you really want to bound your TX reclamation worker, all other\n> network drivers never bound their napi TX completion task and instead\n> reclaim every transmitted buffers.\n\nThey are not bounded, just chunked. Note the outer do loop.\n\n> \n>> +\t\t\t\tvoid **work;\n>> +\t\t\t\tstruct net_device *tx_netdev;\n>> +\t\t\t\tstruct octeon3_ethernet *tx_priv;\n>> +\t\t\t\tstruct sk_buff *skb;\n>> +\t\t\t\tstruct wr_ret r;\n>> +\n>> +\t\t\t\tr = octeon3_core_get_work_sync(oen->tx_complete_grp);\n>> +\t\t\t\twork = r.work;\n>> +\t\t\t\tif (!work)\n>> +\t\t\t\t\tbreak;\n>> +\t\t\t\ttx_netdev = work[0];\n>> +\t\t\t\ttx_priv = netdev_priv(tx_netdev);\n>> +\t\t\t\tif (unlikely(netif_queue_stopped(tx_netdev)) &&\n>> +\t\t\t\t atomic64_read(&tx_priv->tx_backlog) < MAX_TX_QUEUE_DEPTH)\n>> +\t\t\t\t\tnetif_wake_queue(tx_netdev);\n>> +\t\t\t\tskb = container_of((void *)work, struct sk_buff, cb);\n>> +\t\t\t\tif (unlikely(tx_priv->tx_timestamp_hw) &&\n>> +\t\t\t\t unlikely(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS))\n>> +\t\t\t\t\tocteon3_eth_tx_complete_hwtstamp(tx_priv, skb);\n> \n> This is where you should be incremeting the TX bytes and packets\n> statistcs, not in your ndo_start_xmit() like you are currently doing.\n\nSee below...\n\n> \n>> +\t\t\t\tdev_kfree_skb(skb);\n> \n> Consider using dev_consume_skb() to be drop-monitor friendly.\n\nI will look at that.\n\n> \n>> +\t\t\t}\n>> +\n>> +\t\t\taq_cnt = oct_csr_read(SSO_GRP_AQ_CNT(oen->node, oen->tx_complete_grp));\n>> +\t\t\taq_cnt &= GENMASK_ULL(32, 0);\n>> +\t\t\tif ((backlog > backlog_stop_thresh || aq_cnt > tx_complete_stop_thresh) &&\n>> +\t\t\t order < ARRAY_SIZE(oen->workers) - 1) {\n>> +\t\t\t\tatomic_set(&oen->workers[order + 1].kick, 1);\n>> +\t\t\t\twake_up(&oen->workers[order + 1].queue);\n>> +\t\t\t}\n>> +\t\t} while (!need_resched() &&\n>> +\t\t\t (backlog > backlog_stop_thresh ||\n>> +\t\t\t aq_cnt > tx_complete_stop_thresh));\n>> +\n>> +\t\tcond_resched();\n>> +\n>> +\t\tif (!octeon3_eth_tx_complete_runnable(worker))\n>> +\t\t\tocteon3_sso_irq_set(oen->node, oen->tx_complete_grp, true);\n>> +\t}\n>> +\n>> +\treturn 0;\n>> +}\n>> +\n>> +static irqreturn_t octeon3_eth_tx_handler(int irq, void *info)\n>> +{\n>> +\tstruct octeon3_ethernet_node *oen = info;\n>> +\t/* Disarm the irq. */\n>> +\tocteon3_sso_irq_set(oen->node, oen->tx_complete_grp, false);\n>> +\tatomic_set(&oen->workers[0].kick, 1);\n>> +\twake_up(&oen->workers[0].queue);\n> \n> Can you move the whole worker to a NAPI context/softirq context?\n\nThis could be an enhancement.\n\n> \n>> +\treturn IRQ_HANDLED;\n>> +}\n>> +\n[...]\n\n>> +\n>> +\t\t/* Strip the ethernet fcs */\n>> +\t\tpskb_trim(skb, skb->len - 4);\n>> +\t}\n>> +\n>> +\tif (likely(priv->netdev->flags & IFF_UP)) {\n>> +\t\tskb_checksum_none_assert(skb);\n>> +\t\tif (unlikely(priv->rx_timestamp_hw)) {\n>> +\t\t\t/* The first 8 bytes are the timestamp */\n>> +\t\t\tu64 hwts = *(u64 *)skb->data;\n>> +\t\t\tu64 ns;\n>> +\t\t\tstruct skb_shared_hwtstamps *shts;\n>> +\n>> +\t\t\tns = timecounter_cyc2time(&priv->tc, hwts);\n>> +\t\t\tshts = skb_hwtstamps(skb);\n>> +\t\t\tmemset(shts, 0, sizeof(*shts));\n>> +\t\t\tshts->hwtstamp = ns_to_ktime(ns);\n>> +\t\t\t__skb_pull(skb, 8);\n>> +\t\t}\n>> +\n>> +\t\tskb->protocol = eth_type_trans(skb, priv->netdev);\n>> +\t\tskb->dev = priv->netdev;\n>> +\t\tif (priv->netdev->features & NETIF_F_RXCSUM) {\n>> +\t\t\tif ((work->word2.lc_hdr_type == PKI_LTYPE_IP4 ||\n>> +\t\t\t work->word2.lc_hdr_type == PKI_LTYPE_IP6) &&\n>> +\t\t\t (work->word2.lf_hdr_type == PKI_LTYPE_TCP ||\n>> +\t\t\t work->word2.lf_hdr_type == PKI_LTYPE_UDP ||\n>> +\t\t\t work->word2.lf_hdr_type == PKI_LTYPE_SCTP))\n>> +\t\t\t\tif (work->word2.err_code == 0)\n>> +\t\t\t\t\tskb->ip_summed = CHECKSUM_UNNECESSARY;\n>> +\t\t}\n>> +\n>> +\t\tnapi_gro_receive(&rx->napi, skb);\n>> +\t} else {\n>> +\t\t/* Drop any packet received for a device that isn't up */\n> \n> If that happens, is not that a blatant indication that there is a bug in\n> how the interface is brought down?\n\nYes. I think we can remove this bit.\n\n> \n>> +\t\tatomic64_inc(&priv->rx_dropped);\n>> +\t\tdev_kfree_skb_any(skb);\n>> +\t}\n>> +out:\n>> +\treturn ret;\n>> +}\n>> +\n>> +static int octeon3_eth_napi(struct napi_struct *napi, int budget)\n>> +{\n>> +\tint rx_count = 0;\n>> +\tstruct octeon3_rx *cxt;\n>> +\tstruct octeon3_ethernet *priv;\n>> +\tu64 aq_cnt;\n>> +\tint n = 0;\n>> +\tint n_bufs = 0;\n>> +\tu64 old_scratch;\n>> +\n>> +\tcxt = container_of(napi, struct octeon3_rx, napi);\n>> +\tpriv = cxt->parent;\n>> +\n>> +\t/* Get the amount of work pending */\n>> +\taq_cnt = oct_csr_read(SSO_GRP_AQ_CNT(priv->node, cxt->rx_grp));\n>> +\taq_cnt &= GENMASK_ULL(32, 0);\n>> +\n>> +\tif (likely(USE_ASYNC_IOBDMA)) {\n>> +\t\t/* Save scratch in case userspace is using it */\n>> +\t\tCVMX_SYNCIOBDMA;\n>> +\t\told_scratch = scratch_read64(SCR_SCRATCH);\n>> +\n>> +\t\tocteon3_core_get_work_async(cxt->rx_grp);\n>> +\t}\n>> +\n>> +\twhile (rx_count < budget) {\n>> +\t\tn = 0;\n>> +\n>> +\t\tif (likely(USE_ASYNC_IOBDMA)) {\n>> +\t\t\tbool req_next = rx_count < (budget - 1) ? true : false;\n>> +\n>> +\t\t\tn = octeon3_eth_rx_one(cxt, true, req_next);\n>> +\t\t} else {\n>> +\t\t\tn = octeon3_eth_rx_one(cxt, false, false);\n>> +\t\t}\n>> +\n>> +\t\tif (n == 0)\n>> +\t\t\tbreak;\n>> +\n>> +\t\tn_bufs += n;\n>> +\t\trx_count++;\n>> +\t}\n>> +\n>> +\t/* Wake up worker threads */\n>> +\tn_bufs = atomic64_add_return(n_bufs, &priv->buffers_needed);\n>> +\tif (n_bufs >= 32) {\n>> +\t\tstruct octeon3_ethernet_node *oen;\n>> +\n>> +\t\toen = octeon3_eth_node + priv->node;\n>> +\t\tatomic_set(&oen->workers[0].kick, 1);\n>> +\t\twake_up(&oen->workers[0].queue);\n>> +\t}\n>> +\n>> +\t/* Stop the thread when no work is pending */\n>> +\tif (rx_count < budget) {\n>> +\t\tnapi_complete(napi);\n>> +\t\tocteon3_sso_irq_set(cxt->parent->node, cxt->rx_grp, true);\n>> +\t}\n>> +\n>> +\tif (likely(USE_ASYNC_IOBDMA)) {\n>> +\t\t/* Restore the scratch area */\n>> +\t\tscratch_write64(SCR_SCRATCH, old_scratch);\n>> +\t}\n>> +\n>> +\treturn rx_count;\n>> +}\n>> +\n>> +#undef BROKEN_SIMULATOR_CSUM\n>> +\n>> +static void ethtool_get_drvinfo(struct net_device *netdev,\n>> +\t\t\t\tstruct ethtool_drvinfo *info)\n>> +{\n>> +\tstrcpy(info->driver, \"octeon3-ethernet\");\n>> +\tstrcpy(info->version, \"1.0\");\n>> +\tstrcpy(info->bus_info, \"Builtin\");\n> \n> I believe the correct way to specify that type of bus is to use \"platform\".\n\nOK.\n\n> \n> [snip]\n> \n>> +static int octeon3_eth_common_ndo_stop(struct net_device *netdev)\n>> +{\n>> +\tstruct octeon3_ethernet *priv = netdev_priv(netdev);\n>> +\tvoid **w;\n>> +\tstruct sk_buff *skb;\n>> +\tstruct octeon3_rx *rx;\n>> +\tint i;\n>> +\n>> +\t/* Allow enough time for ingress in transit packets to be drained */\n>> +\tmsleep(20);\n> \n> Can you find a better way to do that? You can put a hard disable on the\n> hardware, and then wait until a particular condition to indicate full\n> drainage?\n\nWe are doing the \"hard disable\", we must wait a non-zero (but bounded) \nabount of time before we can reliably do the polling for the backlog to \nreach zero. Perhaps the comment is all that needs improving.\n\n> \n> [snip]\n> \n>> +static int octeon3_eth_ndo_start_xmit(struct sk_buff *skb,\n>> +\t\t\t\t struct net_device *netdev)\n>> +{\n>> +\tstruct sk_buff *skb_tmp;\n>> +\tstruct octeon3_ethernet *priv = netdev_priv(netdev);\n>> +\tu64 scr_off = LMTDMA_SCR_OFFSET;\n>> +\tu64 pko_send_desc;\n>> +\tu64 lmtdma_data;\n>> +\tu64 aq_cnt = 0;\n>> +\tstruct octeon3_ethernet_node *oen;\n>> +\tlong backlog;\n>> +\tint frag_count;\n>> +\tu64 head_len;\n>> +\tint i;\n>> +\tu64 *dma_addr;\n> \n> dma_addr_t?\n\nNope.\n\nPerhaps we should rename the variable to:\n\n u64 *lmtdma_addr;\n\nIt is a very special virtual address that must have the command word \nwritten into it.\n\n> \n>> +\tvoid **work;\n>> +\tunsigned int mss;\n>> +\tint grp;\n>> +\n>> +\tfrag_count = 0;\n>> +\tif (skb_has_frag_list(skb))\n>> +\t\tskb_walk_frags(skb, skb_tmp)\n>> +\t\t\tfrag_count++;\n>> +\n>> +\t/* Stop the queue if pko or sso are not keeping up */\n>> +\toen = octeon3_eth_node + priv->node;\n>> +\taq_cnt = oct_csr_read(SSO_GRP_AQ_CNT(oen->node, oen->tx_complete_grp));\n>> +\taq_cnt &= GENMASK_ULL(32, 0);\n>> +\tbacklog = atomic64_inc_return(&priv->tx_backlog);\n>> +\tif (unlikely(backlog > MAX_TX_QUEUE_DEPTH || aq_cnt > 100000))\n>> +\t\tnetif_stop_queue(netdev);\n>> +\n>> +\t/* We have space for 11 segment pointers, If there will be\n>> +\t * more than that, we must linearize. The count is: 1 (base\n>> +\t * SKB) + frag_count + nr_frags.\n>> +\t */\n>> +\tif (unlikely(skb_shinfo(skb)->nr_frags + frag_count > 10)) {\n>> +\t\tif (unlikely(__skb_linearize(skb)))\n>> +\t\t\tgoto skip_xmit;\n>> +\t\tfrag_count = 0;\n>> +\t}\n> \n> What's so special about 10? The maximum the network stack could pass is\n> SKB_MAX_FRAGS, what would happen in that case?\n\n\nThe comment attempts to answer this question.\n\nThe command block to the PKO consists of between 1 and 16 64-bit command \nwords. 5 of these command words are needed for non-segment-pointer use, \nleaving 11 available for segment pointers.\n\n\n> \n>> +\n>> +\twork = (void **)skb->cb;\n>> +\twork[0] = netdev;\n>> +\twork[1] = NULL;\n>> +\n>> +\t/* Adjust the port statistics. */\n>> +\tatomic64_inc(&priv->tx_packets);\n>> +\tatomic64_add(skb->len, &priv->tx_octets);\n> \n> Do this in the TX completion worker, there is no guarantee the packet\n> will be transmitted that early in this function.\n\nWhen we start doing XDP based forwarding, there is no TX completion \nevent to software, so the simplest thing to do is account for things here.\n\n> \n>> +\n>> +\t/* Make sure packet data writes are committed before\n>> +\t * submitting the command below\n>> +\t */\n>> +\twmb();\n> \n> That seems just wrong here, if your goal is to make sure that e.g:\n> skb_linearize() did finish its pending writes to DRAM, you need to use\n> DMA-API towards that goal. If the device is cache coherent, DMA-API will\n> know that and do nothing.\n\nIt is a problem of write ordering, not cache coherency (OCTEON is fully \ncoherent). That said, the DMA-API does take care of ordering also.\n\nThis is really an optimization that skips a bunch of function calls in \nthe hot path.\n\n> \n>> +\n>> +\t/* Build the pko command */\n>> +\tpko_send_desc = build_pko_send_hdr_desc(skb);\n>> +\tpreempt_disable();\n> \n> Why do you disable preemption here?\n\nSo we don't have the overhead of having to save and restore the CPU \nlocal memory on each interrupt and task switch.\n\n\n> \n>> +\tscratch_write64(scr_off, pko_send_desc);\n>> +\tscr_off += sizeof(pko_send_desc);\n>> +\n>> +\t/* Request packet to be ptp timestamped */\n>> +\tif ((unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) &&\n>> +\t unlikely(priv->tx_timestamp_hw)) {\n>> +\t\tpko_send_desc = build_pko_send_ext_desc(skb);\n>> +\t\tscratch_write64(scr_off, pko_send_desc);\n>> +\t\tscr_off += sizeof(pko_send_desc);\n>> +\t}\n>> +\n>> +\t/* Add the tso descriptor if needed */\n>> +\tmss = skb_shinfo(skb)->gso_size;\n>> +\tif (unlikely(mss)) {\n>> +\t\tpko_send_desc = build_pko_send_tso(skb, netdev->mtu);\n>> +\t\tscratch_write64(scr_off, pko_send_desc);\n>> +\t\tscr_off += sizeof(pko_send_desc);\n>> +\t}\n>> +\n>> +\t/* Add a gather descriptor for each segment. See PKO_SEND_GATHER_S for\n>> +\t * the send gather descriptor format.\n>> +\t */\n>> +\tpko_send_desc = 0;\n>> +\tpko_send_desc |= (u64)PKO_SENDSUBDC_GATHER << 45;\n>> +\thead_len = skb_headlen(skb);\n>> +\tif (head_len > 0) {\n>> +\t\tpko_send_desc |= head_len << 48;\n>> +\t\tpko_send_desc |= virt_to_phys(skb->data);\n>> +\t\tscratch_write64(scr_off, pko_send_desc);\n>> +\t\tscr_off += sizeof(pko_send_desc);\n>> +\t}\n>> +\tfor (i = 1; i <= skb_shinfo(skb)->nr_frags; i++) {\n>> +\t\tstruct skb_frag_struct *fs = skb_shinfo(skb)->frags + i - 1;\n>> +\n>> +\t\tpko_send_desc &= ~(GENMASK_ULL(63, 48) | GENMASK_ULL(41, 0));\n>> +\t\tpko_send_desc |= (u64)fs->size << 48;\n>> +\t\tpko_send_desc |= virt_to_phys((u8 *)page_address(fs->page.p) + fs->page_offset);\n>> +\t\tscratch_write64(scr_off, pko_send_desc);\n>> +\t\tscr_off += sizeof(pko_send_desc);\n>> +\t}\n>> +\tskb_walk_frags(skb, skb_tmp) {\n>> +\t\tpko_send_desc &= ~(GENMASK_ULL(63, 48) | GENMASK_ULL(41, 0));\n>> +\t\tpko_send_desc |= (u64)skb_tmp->len << 48;\n>> +\t\tpko_send_desc |= virt_to_phys(skb_tmp->data);\n>> +\t\tscratch_write64(scr_off, pko_send_desc);\n>> +\t\tscr_off += sizeof(pko_send_desc);\n>> +\t}\n>> +\n>> +\t/* Subtract 1 from the tx_backlog. */\n>> +\tpko_send_desc = build_pko_send_mem_sub(virt_to_phys(&priv->tx_backlog));\n>> +\tscratch_write64(scr_off, pko_send_desc);\n>> +\tscr_off += sizeof(pko_send_desc);\n>> +\n>> +\t/* Write the ptp timestamp in the skb itself */\n>> +\tif ((unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) &&\n>> +\t unlikely(priv->tx_timestamp_hw)) {\n>> +\t\tpko_send_desc = build_pko_send_mem_ts(virt_to_phys(&work[1]));\n>> +\t\tscratch_write64(scr_off, pko_send_desc);\n>> +\t\tscr_off += sizeof(pko_send_desc);\n>> +\t}\n>> +\n>> +\t/* Send work when finished with the packet. */\n>> +\tgrp = octeon3_eth_lgrp_to_ggrp(priv->node, priv->tx_complete_grp);\n>> +\tpko_send_desc = build_pko_send_work(grp, virt_to_phys(work));\n>> +\tscratch_write64(scr_off, pko_send_desc);\n>> +\tscr_off += sizeof(pko_send_desc);\n>> +\n>> +\t/* See PKO_SEND_DMA_S in the HRM for the lmtdam data format */\n>> +\tlmtdma_data = 0;\n>> +\tlmtdma_data |= (u64)(LMTDMA_SCR_OFFSET >> 3) << 56;\n>> +\tif (wait_pko_response)\n>> +\t\tlmtdma_data |= 1ull << 48;\n>> +\tlmtdma_data |= 0x51ull << 40;\n>> +\tlmtdma_data |= (u64)priv->node << 36;\n>> +\tlmtdma_data |= priv->pko_queue << 16;\n>> +\n>> +\tdma_addr = (u64 *)(LMTDMA_ORDERED_IO_ADDR | ((scr_off & 0x78) - 8));\n>> +\t*dma_addr = lmtdma_data;\n>> +\n>> +\tpreempt_enable();\n>> +\n>> +\tif (wait_pko_response) {\n>> +\t\tu64\tquery_rtn;\n>> +\n>> +\t\tCVMX_SYNCIOBDMA;\n>> +\n>> +\t\t/* See PKO_QUERY_RTN_S in the HRM for the return format */\n>> +\t\tquery_rtn = scratch_read64(LMTDMA_SCR_OFFSET);\n>> +\t\tquery_rtn >>= 60;\n>> +\t\tif (unlikely(query_rtn != PKO_DQSTATUS_PASS)) {\n>> +\t\t\tnetdev_err(netdev, \"PKO enqueue failed %llx\\n\",\n>> +\t\t\t\t (unsigned long long)query_rtn);\n>> +\t\t\tdev_kfree_skb_any(skb);\n>> +\t\t}\n>> +\t}\n> \n> So I am not sure I fully understand how sending packets works, although\n> it seems to be like you are building a work element (pko_send_desc)\n> which references either a full-size Ethernet frame, or that frame and\n> its fragments (multiple pko_send_desc). In that case, I don't see why\n> you can't juse dma_map_single()/dma_unmap_single() against skb->data and\n> its potential fragments instead of using virt_to_phys() like you\n> currently do, which is absolutely not portable.\n> \n> dma_map_single() on the kernel linear address space should be equivalent\n> to virt_to_phys() anyway, and you would get the nice things about\n> DMA-API like its portability.\n> \n> I could imagine that, for coherency purposes, there may be a requirement\n> to keep tskb->data and frieds to be within XKSEG0/1, if that's the case,\n> DMA-API should know that too.\n> \n> I might be completely off, but using virt_to_phys() sure does sound non\n> portable here.\n\n\nThe PKO command block with all of its gather dma pointers is written \ninto a special CPU local memory region. The whole thing it atomically \ntransmitted via a store to a special CPU local address window.\n\nWe need to keep everything on a single CPU, thus the preempt disable/enable.\n\nThe whole mechanism is highly OCTEON specific, and as such it works to \nuse the wmb() and virt_to_phys() macros instead of calling all the \ndma_map_*() funcitons. Would it be more clear to use dma_map_*()? \nPerhaps. Would it be slower? Yes.\n\n\n> \n>> +\n>> +\treturn NETDEV_TX_OK;\n>> +skip_xmit:\n>> +\tatomic64_inc(&priv->tx_dropped);\n>> +\tdev_kfree_skb_any(skb);\n>> +\treturn NETDEV_TX_OK;\n>> +}\n>> +\n>> +static void octeon3_eth_ndo_get_stats64(struct net_device *netdev,\n>> +\t\t\t\t\tstruct rtnl_link_stats64 *s)\n>> +{\n>> +\tstruct octeon3_ethernet *priv = netdev_priv(netdev);\n>> +\tu64 packets, octets, dropped;\n>> +\tu64 delta_packets, delta_octets, delta_dropped;\n>> +\n>> +\tspin_lock(&priv->stat_lock);\n> \n> Consider using u64_stats_sync to get rid of this lock...\n\nMy timer went missing. This also has to be called periodically from a \ntimer to catch wraparound in the 48 bit counters.\n\nLocking is still necessary to synchronize between the timer and calls to \nthe get_stat function.\n\nI will sort this out.\n\n\n> \n>> +\n>> +\tocteon3_pki_get_stats(priv->node, priv->pknd, &packets, &octets, &dropped);\n>> +\n>> +\tdelta_packets = (packets - priv->last_packets) & ((1ull << 48) - 1);\n>> +\tdelta_octets = (octets - priv->last_octets) & ((1ull << 48) - 1);\n>> +\tdelta_dropped = (dropped - priv->last_dropped) & ((1ull << 48) - 1);\n>> +\n>> +\tpriv->last_packets = packets;\n>> +\tpriv->last_octets = octets;\n>> +\tpriv->last_dropped = dropped;\n>> +\n>> +\tspin_unlock(&priv->stat_lock);\n>> +\n>> +\tatomic64_add(delta_packets, &priv->rx_packets);\n>> +\tatomic64_add(delta_octets, &priv->rx_octets);\n>> +\tatomic64_add(delta_dropped, &priv->rx_dropped);\n> \n> and summing up these things as well.\n> \n>> +\n>> +\ts->rx_packets = atomic64_read(&priv->rx_packets);\n>> +\ts->rx_bytes = atomic64_read(&priv->rx_octets);\n>> +\ts->rx_dropped = atomic64_read(&priv->rx_dropped);\n>> +\ts->rx_errors = atomic64_read(&priv->rx_errors);\n>> +\ts->rx_length_errors = atomic64_read(&priv->rx_length_errors);\n>> +\ts->rx_crc_errors = atomic64_read(&priv->rx_crc_errors);\n>> +\n>> +\ts->tx_packets = atomic64_read(&priv->tx_packets);\n>> +\ts->tx_bytes = atomic64_read(&priv->tx_octets);\n>> +\ts->tx_dropped = atomic64_read(&priv->tx_dropped);\n>> +}\n> \n> [snip]\n> \n>> +enum port_mode {\n>> +\tPORT_MODE_DISABLED,\n>> +\tPORT_MODE_SGMII,\n>> +\tPORT_MODE_RGMII,\n>> +\tPORT_MODE_XAUI,\n>> +\tPORT_MODE_RXAUI,\n>> +\tPORT_MODE_XLAUI,\n>> +\tPORT_MODE_XFI,\n>> +\tPORT_MODE_10G_KR,\n>> +\tPORT_MODE_40G_KR4\n>> +};\n> \n> Can you use phy_interface_t values for this?\n\nThey have many of the same names, but this enum contains only things we \nsupport, and maps to values in register fields. using phy_interface_t \nmight falsly imply we support everything in there.\n\n\n> \n>> +\n>> +enum lane_mode {\n>> +\tR_25G_REFCLK100,\n>> +\tR_5G_REFCLK100,\n>> +\tR_8G_REFCLK100,\n>> +\tR_125G_REFCLK15625_KX,\n>> +\tR_3125G_REFCLK15625_XAUI,\n>> +\tR_103125G_REFCLK15625_KR,\n>> +\tR_125G_REFCLK15625_SGMII,\n>> +\tR_5G_REFCLK15625_QSGMII,\n>> +\tR_625G_REFCLK15625_RXAUI,\n>> +\tR_25G_REFCLK125,\n>> +\tR_5G_REFCLK125,\n>> +\tR_8G_REFCLK125\n>> +};\n>> +\n>> +struct port_status {\n>> +\tint\tlink;\n>> +\tint\tduplex;\n>> +\tint\tspeed;\n>> +};\n> \n> Likewise, using phy_device would give you this information.\n\nI will look at doing that.\n\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@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=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"ZkptetqG\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=David.Daney@cavium.com; "],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySgCr63RTz9sRg\n\tfor ;\n\tFri, 3 Nov 2017 09:45:44 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S934662AbdKBWpe (ORCPT );\n\tThu, 2 Nov 2017 18:45:34 -0400","from mail-by2nam01on0064.outbound.protection.outlook.com\n\t([104.47.34.64]:17810\n\t\"EHLO NAM01-BY2-obe.outbound.protection.outlook.com\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S934438AbdKBWpc (ORCPT );\n\tThu, 2 Nov 2017 18:45:32 -0400","from ddl.caveonetworks.com (50.233.148.156) by\n\tCY4PR07MB3493.namprd07.prod.outlook.com (10.171.252.150) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.197.13; Thu, 2 Nov 2017 22:45:28 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=OLTtz8FVkOsRUPYI+8ty3LdDvWhZBrErwA60Xwq8TH4=;\n\tb=ZkptetqGdyTT5EOLo99Cza/wKu9PsStXJT+UBj8DN8irBjPpzrFyUTSwGodTv45i8fXwnJlrAYStwyH17VES6DUzn+6u2HhvEVK6iQRYlQID0QiUsEEgY/DVTSeS+6ASID8wzYGigMqbtNOOseuwx+GaFkn2HHjLD8B+sEozCIs=","Subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","To":"Florian Fainelli ,\n\tDavid Daney ,\n\tlinux-mips@linux-mips.org, ralf@linux-mips.org,\n\tJames Hogan , netdev@vger.kernel.org,\n\t\"David S. Miller\" ,\n\tRob Herring , Mark Rutland ","Cc":"linux-kernel@vger.kernel.org, \"Steven J. Hill\" ,\n\tdevicetree@vger.kernel.org, Carlos Munoz ","References":"<20171102003606.19913-1-david.daney@cavium.com>\n\t<20171102003606.19913-7-david.daney@cavium.com>\n\t<55d6cf88-7444-42ea-02f1-27efdee2be4b@gmail.com>","From":"David Daney ","Message-ID":"","Date":"Thu, 2 Nov 2017 15:45:26 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<55d6cf88-7444-42ea-02f1-27efdee2be4b@gmail.com>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[50.233.148.156]","X-ClientProxiedBy":"SN4PR0701CA0018.namprd07.prod.outlook.com (10.161.192.156)\n\tTo CY4PR07MB3493.namprd07.prod.outlook.com (10.171.252.150)","X-MS-PublicTrafficType":"Email","X-MS-Office365-Filtering-Correlation-Id":"31a5ad10-10d2-48c0-bd0a-08d522436b37","X-Microsoft-Antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603238);\n\tSRVR:CY4PR07MB3493; ","X-Microsoft-Exchange-Diagnostics":["1; CY4PR07MB3493;\n\t3:ouNjewfKiFva0XVx8qdefsaOto3OJgIieHxbdhqlb9QIydVAHKqsr8nwk47VgvxfeZT+dM51PlSwu/gDRGG82epJUSGy0LTsoV8ShMdWoBaP/MwK8sTs9JjdsaYmPiVrQxgM30awgrHpWFSz05wahdJEJ5hYrVES5UvYCB5hiP510s+15sm+Qf2TZUhCnrsLkrJI8azQzCr+9UTT6IEq6ukCO0hOr6ZPRq4BssQ18LbAfcF6k4eyi25wI8CUE2bM;\n\t25:fHZVI/Ozgzr+IO6z+7C4+WXMMaaVzzIW83FffS4rtPqiBwGveYG94OjEyVvjDb7rQ0pAZb3vEyjAc5HN4vS4MfYAgSQRgIm61CK2E8kHV4bcmyQtDqZoe+CvKwiooniJ8Ty1kWRo8ngIiTDRDBrbg1/1hPDu/cVHuoGo19tOig5K1yC8tOE91rHM6htzrbB7Z2XF6ROKozYFGrbyjBHmRbUySmBiJQnl5gckF0FODCx/k+hadwnU4sfNDbM3ApcZ5VG/CQn0PmcGvZ5PxT6tkmbj9odvFobVLeqEekp4Q6W/C/BzC+mwcaUHFWpYWwjuOK1ehPUMueJZFxtRAfNkhA==;\n\t31:WCUxoIeM+gfIybu9U2ZybNffMwdqgNmV4oR/VALAY14ROPI7syYz86ARQULY+Mdblvoa6pXRc4pDB5JijYtEodLz0jR1Dud4niCjkbtZ4VrHCsj+Aj/dNUgA2V30huvXqSxTJUHoE4t3TOcv/MfBaK/K4AdvivWf2QQRqBAvlMtABPIYyQQLI7AJYyoAu2r7Vhey+TAOgvdYNkELq3ff4SqxXfdWNVb2p+ZB5iMK2bM=","1; CY4PR07MB3493;\n\t20:QVekUmaJJre5A7fU/T/EQEY7eAncEllLcHfDq7JtiTb8Hux3ErLYstgzCZGd63gPbfqMi4Q3EXFzb2Myi2BvD+ZnVUR9ehu3AwgrJ4rtfCiDS8rK8+Npu0BkCGyk0SB8gvoK7xxjkT3Pn/lis9J+YOGbihlJ6c3Ch2TvLjVFylgTVd26rDVoWOTjbl+sRXhLlxXT04g/dWmL10qQdG6HFgrBncXBbAvh5Uhw1OY1Q/cqJS9XpiN+KUVZ9Vkk/A6puNYXX8n6UOEVKGDCTkttt5jD6aG+Bm4tPZrDM7FdAxT6/ICaWRrZoxhCfA8Qg3C9tlIq2tx2d59sAE/UnfbKOe860KxL/HjCBVwOGOCXWAYpLSzp+nLP5FV2uyvWA9zDWEHmUK7iRauN8AMrCX0wmzIHkJKNExZzWC9hixVzk4JJ/60heEXwM/DQTfItSzJKN4rJ3gNec5W1tLjGm8Gk/FOn1m4j7pzSiBNiEkddmiG4NOojnvAxASVnAMVju92WqawVKChWAs3awbkaPXLlNNASzIb9nlnuwEq3OiHA/9KljeN/FLn0xmnzWsCvDaDcVWvOpj+N/ZKZmrcDtu7Qv7RHCUKbxJmd8vO5hukOIPQ=;\n\t4:xwhQe4p8L5QOWvSyMZwa4huKI/bvH2y5ywfuAPxHLv0BA0bygJhGLsdr3J5QNN8xvEHVy14TngwNHxLZFqbHZHkb9319Gz7WxOvkfcmeEC+02BIQeJUrIDseXZlBuCO8d/5vFQBRTJbzTJzO1R7M9kx46xRaZZV3nyumLIYQ+dyYTTZqnH+MC3BQvRnmXZkThv9WNBn5etb6bJ858OWB2/W3vhw0jMbUaPDjvNly1qlqY34ABCEXmrjT7AF5O+M6+TslhZzkyyUDCYsLeM1e585IrsNliR16pi2wzp20MIZnwt+zE+mvAwzAcuz1kMNf","=?utf-8?q?1=3BCY4PR07MB3493=3B23=3AUxug?=\n\t=?utf-8?q?hl2ovRRcn9nxXL0z8RiQ6OjXHgj/y5QFqD9lS10Jmry4TKS4LS2q/qwL?=\n\t=?utf-8?q?nbn5agHtgzDQgzlEp+nwCd4iu7mXCDSCEet48AAUKJknUNiqbtRQ1F89?=\n\t=?utf-8?q?MlkDVh+w5Ps7TLKEgQT43SjeKAReSIFrbHO29HK/75heePaoLyi0aFfr?=\n\t=?utf-8?q?qG1brW2omVyC4JvI2wloBCCLEqKb6/n9VBJbOtw/wWwXnA3T3slZmQlL?=\n\t=?utf-8?q?aBxYp9Oq3BMJ5AYms8ULAnGgfAo2jiIvnNnXISixcWUB1BtBU0MisMkA?=\n\t=?utf-8?q?4YNjIk+95EAgQBYf20gv3YXaJAuS2FfnKjm2LoivaypskF3bLZ1W4iJG?=\n\t=?utf-8?q?6UM6qkN9+GZCwAN7pEAcEDJc5ID50bC/oSJbq65Pve1iV5L0XiXjR/N5?=\n\t=?utf-8?q?ymgnkEDivxmjCh2HK9RBVeicmqFf4X/zCIpaBrzctBEg4OUmZG1EJHox?=\n\t=?utf-8?q?KNhZo5O257UGjBeX+xR9n0fFgNP5yOAhHL+4AUbOh1lzIpq5wHgttqoP?=\n\t=?utf-8?q?MibYGQtL0NHMzvBVgXXaU/CbtlvhtgIHX63dHcSFhKOB7w+SXshUxevb?=\n\t=?utf-8?q?6KpbvPcYRH1jNN53C+WZ+zkCKFDiHHa8YL7RRmSkIv+e3ZBxVV5ZJwOG?=\n\t=?utf-8?q?8wDvbTxHtY4wL+vJrWV/WZ+ayUaaK95i/1TOo3EfF8z95arxvV7x4kc8?=\n\t=?utf-8?q?2086Rgl7ppG2eWxT8YnEN61QHp3H/KABWYk3EP7BT2GATNJaviug4I6R?=\n\t=?utf-8?q?tJhYF5KhcRkl1ee9FnD5D+fQdjF5eyyWL+mX4wujIpkRFCofTo80tPiP?=\n\t=?utf-8?q?RpGSVMy1kzy/tCmZKY0LbFWFchwPYMfr6MDjNPAMpQM4Drle2Jr67TDB?=\n\t=?utf-8?q?g/EY/zmPMmELRvUvJTawgTohogjcmcA5xcJXkwGj6h4Ng6FLF9Isn59+?=\n\t=?utf-8?q?/E/+KW4JdpMyzCVum48Jw8ABl4HGPDpJdc8fV3NokL8IfYd5Qy8GfhK9?=\n\t=?utf-8?q?OJeqoffhxh0c37gfTL4qBQr7+x5K4NMn2gGUVO4Msswa5tAn6UkrjawV?=\n\t=?utf-8?q?g8t5GhppKPWl5qcrtN1USkARhd+097+yoEEYmd+tu0lgWUAqqErLVtpR?=\n\t=?utf-8?q?UtureMRK3YGYBEFrnnAugoCNKd8Qcw5fkyCISyc5F/tL0um/HQ9bjOpL?=\n\t=?utf-8?q?hjKEXNjMS8rsjYmxIBhoczbm1aGizsFKlJ5+wTL5xouwOCeWb2ikFDDf?=\n\t=?utf-8?q?gs6AzKvr3OYF38Wlo/zbWdYrC4DyzYM13dXc/0RoFCilof7mbcD3jrec?=\n\t=?utf-8?q?lYyDYk6SXDAIrIKADupT0Vlna9VS93ISC25v+bcYyGgfKIXu+0pdiqjl?=\n\t=?utf-8?q?kc7zf6f96iaDiGtrNXYqH9wKUswFncUa1sDhh4yxN6LkEFOgSL5WqaAG?=\n\t=?utf-8?q?QkU3Gg/7jmiwcUrzz+BwKs3PFrbfvrFDFiYkNIve6HHWL0Ey9FKKVYlA?=\n\t=?utf-8?q?xnjAvwqMoiJPZqdd1Jkx3XiR/Za0jLdqmptCHsWxpn7GV2nlyG2pJBqK?=\n\t=?utf-8?q?rzRUXvVeY30oOAgXuEiCFV8XlKpgXeGPLC61Q4OvRnhB3/i7M7IM/Sc?=\n\t=?utf-8?q?=3D?=","1; CY4PR07MB3493;\n\t6:f6I5Yo8AB55ORv2yVEXRoOedBqt8f0roZZnsPdH0OAAhpGVvEenR3QUlSfkP64gEkEyz/9S79lubhjYZUu/thOsjHwsEFTpBtxhQTUnI4M6FMl5KSUHGCW+CE7ypVoIJwxE6oCrvuEtBdIZ2aniaajVd3id+7SNSafQbkoEM3byZ0ysmLbV8VlpmTAEu8UE79HoKKG1vDeTzyX21sSwgUPMpkhRf5l3UxDU5TlVP2b7ua4VKAYfvAsBTJ2Rinul9YwZL5ALy89IksMLByNf8gYe48S6NpI96HNTbKKKQe9p2B0I4O/oOS64FlJIKZwnU1DxdscoWxyjwI/JLwj2XccHzD1NZZocxLf3v0Mdaibw=;\n\t5:SRo8JVguU6mVLljXAfJ8INUo1e97tTJ9elqxJdKaUjeMlwPpVnucab3W6DPZc6dbsnM4Q6kErsoFhxpJ8scjpDQvgpuZqIj/WVU3UqwI/F6GtJGtM3VWFilO1ZLqImKVf6SP3TkCt89cY8saWWLJ0CYGSVeIKyKQwPwXQwOY1/0=;\n\t24:p9GXk+trbgF6qIEgfFzxtZpQSl/Plf7DYvM35xGezEwC/tMcpRv6wDxs6J+nUxnzuxG6oIk/O/jmVCKsFSQlKrT+jXX9X22Z4BdrQZk45HE=;\n\t7:pXqc38ZzNiymcs5ANVhWyrFUVSZIbNuE3dslD4zinlaF8pRC0IHlL24DMyz7SXPIWcx916ZcNK9JkVfn4U/vledroEWNANngryHnL6oZX1yGXqfXNWk7YHR1dVpq8oHU3aClsK3wRAjbpdxuedNfgBCHONtuOurGqfJR5S0XcMPSY0Ut4q3JU2dp145eMQR2YU6zhTE8dWM0Ms3tuAdUFLFOxTRUlIaSg3GsCCgXkg7uyNGDqEJBn5mgYwZ8Aigo"],"X-MS-TrafficTypeDiagnostic":"CY4PR07MB3493:","X-Exchange-Antispam-Report-Test":"UriScan:(21532816269658);","X-Microsoft-Antispam-PRVS":"","X-Exchange-Antispam-Report-CFA-Test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(3231020)(10201501046)(100000703101)(100105400095)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:CY4PR07MB3493; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:CY4PR07MB3493; ","X-Forefront-PRVS":"047999FF16","X-Forefront-Antispam-Report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(346002)(376002)(199003)(24454002)(189002)(52314003)(43544003)(76176999)(8676002)(6512007)(16526018)(7736002)(64126003)(31686004)(53946003)(53546010)(8936002)(305945005)(101416001)(4326008)(7416002)(39060400002)(107886003)(53936002)(47776003)(66066001)(6246003)(65806001)(6116002)(69596002)(3846002)(81156014)(25786009)(65956001)(54356999)(50986999)(81166006)(58126008)(54906003)(110136005)(6506006)(68736007)(42882006)(2950100002)(229853002)(2906002)(97736004)(230700001)(67846002)(23676003)(6486002)(478600001)(33646002)(83506002)(65826007)(5660300001)(31696002)(316002)(50466002)(53416004)(189998001)(36756003)(106356001)(72206003)(105586002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR07MB3493;\n\tH:ddl.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords;\n\tA:1; MX:1; LANG:en; ","Received-SPF":"None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)","SpamDiagnosticOutput":"1:99","SpamDiagnosticMetadata":"NSPM","X-OriginatorOrg":"caviumnetworks.com","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"02 Nov 2017 22:45:28.9448\n\t(UTC)","X-MS-Exchange-CrossTenant-Network-Message-Id":"31a5ad10-10d2-48c0-bd0a-08d522436b37","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"711e4ccf-2e9b-4bcf-a551-4094005b6194","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"CY4PR07MB3493","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1798694,"web_url":"http://patchwork.ozlabs.org/comment/1798694/","msgid":"<20171103154811.GS24320@lunn.ch>","list_archive_url":null,"date":"2017-11-03T15:48:11","subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> >>+static char *mix_port;\n> >>+module_param(mix_port, charp, 0444);\n> >>+MODULE_PARM_DESC(mix_port, \"Specifies which ports connect to MIX interfaces.\");\n> >\n> >Can you derive this from Device Tree /platform data configuration?\n> >\n> >>+\n> >>+static char *pki_port;\n> >>+module_param(pki_port, charp, 0444);\n> >>+MODULE_PARM_DESC(pki_port, \"Specifies which ports connect to the PKI.\");\n> >\n> >Likewise\n> \n> The SoC is flexible in how it is configured. Technically the device tree\n> should only be used to specify information about the physical configuration\n> of the system that cannot be probed for, and this is about policy rather\n> that physical wiring. That said, we do take the default configuration from\n> the device tree, but give the option here to override via the module command\n> line.\n\nModule parameters are pretty much frowned upon. \n\nYou should really try to remove them all, if possible.\n\n> >>+/* Registers are accessed via xkphys */\n> >>+#define SSO_BASE\t\t\t0x1670000000000ull\n> >>+#define SSO_ADDR(node)\t\t\t(SET_XKPHYS + NODE_OFFSET(node) + \\\n> >>+\t\t\t\t\t SSO_BASE)\n> >>+#define GRP_OFFSET(grp)\t\t\t((grp) << 16)\n> >>+#define GRP_ADDR(n, g)\t\t\t(SSO_ADDR(n) + GRP_OFFSET(g))\n> >>+#define SSO_GRP_AQ_CNT(n, g)\t\t(GRP_ADDR(n, g)\t\t + 0x20000700)\n> >>+\n> >>+#define MIO_PTP_BASE\t\t\t0x1070000000000ull\n> >>+#define MIO_PTP_ADDR(node)\t\t(SET_XKPHYS + NODE_OFFSET(node) + \\\n> >>+\t\t\t\t\t MIO_PTP_BASE)\n> >>+#define MIO_PTP_CLOCK_CFG(node)\t\t(MIO_PTP_ADDR(node)\t\t+ 0xf00)\n> >>+#define MIO_PTP_CLOCK_HI(node)\t\t(MIO_PTP_ADDR(node)\t\t+ 0xf10)\n> >>+#define MIO_PTP_CLOCK_COMP(node)\t(MIO_PTP_ADDR(node)\t\t+ 0xf18)\n> >\n> >I am sure this will work great on anything but MIPS64 ;)\n> \n> Sarcasm duly noted.\n> \n> That said, by definition it is exactly an OCTEON-III/MIPS64, and can never\n> be anything else. It is known a priori that the hardware and this driver\n> will never be used anywhere else.\n\nPlease make sure your Kconfig really enforces this. Generally, we\nsuggest allowing the driver to be compiled when COMPILE_TEST is set.\nThat gives you better compiler test coverage. But it seems like this\ndriver won't compile under such conditions.\n\n> >>+static int num_packet_buffers = 768;\n> >>+module_param(num_packet_buffers, int, 0444);\n> >>+MODULE_PARM_DESC(num_packet_buffers,\n> >>+\t\t \"Number of packet buffers to allocate per port.\");\n> >\n> >Consider implementing ethtool -g/G for this.\n> \n> That may be work for a follow-on patch.\n\nThen please remove the module parameter now.\n\n> >>+static int rx_queues = 1;\n> >>+module_param(rx_queues, int, 0444);\n> >>+MODULE_PARM_DESC(rx_queues, \"Number of RX threads per port.\");\n> >\n> >Same thing, can you consider using an ethtool knob for that?\n> \n> Also may be work for a follow-on patch.\n\nDitto\n\n> >>+/**\n> >>+ * Reads a 64 bit value from the processor local scratchpad memory.\n> >>+ *\n> >>+ * @param offset byte offset into scratch pad to read\n> >>+ *\n> >>+ * @return value read\n> >>+ */\n> >>+static inline u64 scratch_read64(u64 offset)\n> >>+{\n> >>+\treturn *(u64 *)((long)SCRATCH_BASE + offset);\n> >>+}\n> >\n> >No barriers needed whatsoever?\n> \n> Nope.\n\nThen it would be good to add a comment about why no barrier is\nneeded. Otherwise people are going to ask why there is no barrier,\nsubmit patches adding barriers, etc.\n\n Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@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=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yT5w42Z72z9s5L\n\tfor ;\n\tSat, 4 Nov 2017 02:48:36 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755690AbdKCPsZ (ORCPT );\n\tFri, 3 Nov 2017 11:48:25 -0400","from vps0.lunn.ch ([185.16.172.187]:41007 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752354AbdKCPsX (ORCPT );\n\tFri, 3 Nov 2017 11:48:23 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1eAeCZ-0000YU-Ol; Fri, 03 Nov 2017 16:48:11 +0100"],"Date":"Fri, 3 Nov 2017 16:48:11 +0100","From":"Andrew Lunn ","To":"David Daney ","Cc":"Florian Fainelli ,\n\tDavid Daney ,\n\tlinux-mips@linux-mips.org, ralf@linux-mips.org,\n\tJames Hogan , netdev@vger.kernel.org,\n\t\"David S. Miller\" ,\n\tRob Herring , Mark Rutland ,\n\tlinux-kernel@vger.kernel.org, \"Steven J. Hill\" ,\n\tdevicetree@vger.kernel.org, Carlos Munoz ","Subject":"Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III\n\tsupport.","Message-ID":"<20171103154811.GS24320@lunn.ch>","References":"<20171102003606.19913-1-david.daney@cavium.com>\n\t<20171102003606.19913-7-david.daney@cavium.com>\n\t<55d6cf88-7444-42ea-02f1-27efdee2be4b@gmail.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]