Message ID | 20230713121907.3249291-1-vladimir.oltean@nxp.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a6b2:0:b0:3e4:2afc:c1 with SMTP id c18csp1798047vqm; Thu, 13 Jul 2023 05:47:30 -0700 (PDT) X-Google-Smtp-Source: APBJJlEnzyxRwiIZ5mSlm3NgTfavjJfkCKwsp4xmfMT/67RP0ukdZNPG/pKYvyZ860fogGO+Jhj1 X-Received: by 2002:a05:6512:39d4:b0:4fb:cab9:ddf with SMTP id k20-20020a05651239d400b004fbcab90ddfmr1565418lfu.57.1689252449964; Thu, 13 Jul 2023 05:47:29 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1689252449; cv=pass; d=google.com; s=arc-20160816; b=XnIO2vTDjLUOQ2QyFjZYEexz5yprlIJL6K+8xpCzJsRT2l/2TS8Io9FdmoUL+mWVcr rn1Fi//ONu3xg2X3mlj0vfIZM042NiSZyt/a/0lDPNadUFSGNoRE1DyHlQU9+ok1wpWl EvfjoY6cnjJfDMt4ZxuNBmPhjAePh+VbQVoibaUV3EpgDvne0w3MKXrqMFjICbhqo03I FvbaB0+yeSJHueRffVD0sIW+7r8hRlO3iWqTRmujUqB0mZ1hEz31EBLH5PHufdX3XmyG fkc0n7U8n8C01m1681SGl7IMmGqNU6vXvav9uSmzcVZbjhDB+X65/cPBNN6hzxYHZqqh RNHQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :message-id:date:subject:cc:to:from:dkim-signature; bh=eIdP5O4JigGuuPyoOYxAGk4KKsGKBGJHukSXxI6GkxU=; fh=FsMQszZnVnFY8qNtbSjbSaNEHoVHbK+Q/xK98QB7OPs=; b=bKUA14dMgiHieCmz5ysrVjb8A6Bw/bUwc29eeU7bX3d1nk7tTk/RqQRitx8ymvOOes YSDLIBN1fxr53eY4DKmHp78xyLVFMxlfXMdyLI/jKoW0QF295sAM6fT6T4kXi/DNqz9P CNxN2Iq2MfIWz+X2Eix+63QPF7hPoHocvsNIJ/o1YioZIaI4fgJzC0XXgRdItc5l9Iyx Af5SnutdLD/ubQ1ZpZfrqoyhfZW3ov9odLwEK+CLSKPkdjPxSx+VAVuJPV4gAS7Bef8i sFZDjJj7dAr61Y1VaBYS8FM7+g2eIuGPxMPKfSH1ObSVqbC1WTA5tSgF+10dX+YRPObw vcnA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@nxp.com header.s=selector2 header.b=E80aB2RO; arc=pass (i=1 spf=pass spfdomain=nxp.com dkim=pass dkdomain=nxp.com dmarc=pass fromdomain=nxp.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f11-20020a170906824b00b0098dfdc3f2e6si7021079ejx.982.2023.07.13.05.47.06; Thu, 13 Jul 2023 05:47:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@nxp.com header.s=selector2 header.b=E80aB2RO; arc=pass (i=1 spf=pass spfdomain=nxp.com dkim=pass dkdomain=nxp.com dmarc=pass fromdomain=nxp.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234659AbjGMMTn (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Thu, 13 Jul 2023 08:19:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234663AbjGMMTi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 13 Jul 2023 08:19:38 -0400 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on2075.outbound.protection.outlook.com [40.107.14.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1A302706; Thu, 13 Jul 2023 05:19:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ROCa0DarMt3sv8UUjrTGWWrTN1olq0X6150GwQiKsn0RpMpo4l2UR9OQtZfqt6iARsgFXsWsX/7uwSf7YjqDThI+mLOVmGdqhv9rh6GSUQ3Am2ahzXoLjSb1meiTdoy+p27XboeIDxlMaW1ndjDXFSxZlOPJrhnF9bHcqKpw481TF+M+j06rxLcWCOK71iq1gRAJXhO4dRkDLFotpr1WWyiFxWPmkL/cS98R7WNWTOGcIQMhIhgKN5SoD0Gk2uczJzxU204JEq0IV6+NyQDWt3V/7St6vvAGaPOK9fa0d6kKmLrfRix2ugRsvWWw1Aw98nvb20BQLAxP5FNu+kd0QQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eIdP5O4JigGuuPyoOYxAGk4KKsGKBGJHukSXxI6GkxU=; b=FrfTDi6vNS0ieTAPg2938HmiqkAIC5r074RdEkORDNy6Zuv662eixtI8T3GYljRyATPREiXXIci3Y15M3+FmLo24EzJWZBT0kzGwBXCFr8YE2rNFswZtIPpZzTJQb/JK5kgNA0KTZ5CLN4/dFNfZ7xNK/NmQNMdbWXOh/w7ZYYZ4R20Ps/Dy4j3l/UvnZHfwGC0OH+l9Uc9Em1naq0oILztAFv0vT0ZJAsKbBxWFV1BFjK0X6V+o5K0CzFiRqDbmpB171jYJoQ4q1khJQq83LDMgbfPM+y6IccScBaBhnkRLn/JJClgQwGwmq2ab+tPZWWptfWrPM1c62NPTbCPvtQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eIdP5O4JigGuuPyoOYxAGk4KKsGKBGJHukSXxI6GkxU=; b=E80aB2ROItEkpLtShuNr1VNcRmd/ZA92cKj2pU806ijNVKw3GlUcAdzRlxOr7QWXaaly1MzjGUOki9gK4UfxAPeDss6iYZvUhqx3HQpgscT5dIHDEsa+rq2vcpRCuOMM+xY9TcHZZXxXQFvDsZk0GSdNQYEpm3ceAaIN++KaNfM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nxp.com; Received: from AM0PR04MB6452.eurprd04.prod.outlook.com (2603:10a6:208:16d::21) by DB8PR04MB6971.eurprd04.prod.outlook.com (2603:10a6:10:113::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6588.24; Thu, 13 Jul 2023 12:19:30 +0000 Received: from AM0PR04MB6452.eurprd04.prod.outlook.com ([fe80::cc2a:5d80:9dbd:d850]) by AM0PR04MB6452.eurprd04.prod.outlook.com ([fe80::cc2a:5d80:9dbd:d850%7]) with mapi id 15.20.6588.017; Thu, 13 Jul 2023 12:19:29 +0000 From: Vladimir Oltean <vladimir.oltean@nxp.com> To: netdev@vger.kernel.org Cc: "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, Maxim Georgiev <glipus@gmail.com>, Horatiu Vultur <horatiu.vultur@microchip.com>, =?utf-8?q?K=C3=B6ry_Maincent?= <kory.maincent@bootlin.com>, Maxime Chevallier <maxime.chevallier@bootlin.com>, Richard Cochran <richardcochran@gmail.com>, Vadim Fedorenko <vadim.fedorenko@linux.dev>, Gerhard Engleder <gerhard@engleder-embedded.com>, Hangbin Liu <liuhangbin@gmail.com>, Russell King <linux@armlinux.org.uk>, Heiner Kallweit <hkallweit1@gmail.com>, Jacob Keller <jacob.e.keller@intel.com>, Jay Vosburgh <j.vosburgh@gmail.com>, Andy Gospodarek <andy@greyhouse.net>, Wei Fang <wei.fang@nxp.com>, Shenwei Wang <shenwei.wang@nxp.com>, Clark Wang <xiaoning.wang@nxp.com>, NXP Linux Team <linux-imx@nxp.com>, UNGLinuxDriver@microchip.com, Lars Povlsen <lars.povlsen@microchip.com>, Steen Hegelund <Steen.Hegelund@microchip.com>, Daniel Machon <daniel.machon@microchip.com>, Simon Horman <simon.horman@corigine.com>, Casper Andersson <casper.casan@gmail.com>, Sergey Organov <sorganov@gmail.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v7 net-next 00/10] Introduce ndo_hwtstamp_get() and ndo_hwtstamp_set() Date: Thu, 13 Jul 2023 15:18:57 +0300 Message-Id: <20230713121907.3249291-1-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.34.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR2P281CA0157.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:99::18) To AM0PR04MB6452.eurprd04.prod.outlook.com (2603:10a6:208:16d::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM0PR04MB6452:EE_|DB8PR04MB6971:EE_ X-MS-Office365-Filtering-Correlation-Id: dce14071-d807-4a0b-6cd7-08db839b6864 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Wws0bIpOCWnvsCbRydkhqJFRSgUqbJMzVBVOqybZDvJBrEiPUwYA7cpthEJddp50ncQH8DI29FDvjiTj3aQ/JraXx121e9rtrr9jpL9E8Wb/INYPuBQJPFw/puDLKJ7ew5gsGFjCPFi7HOcWXCeREvYo/H7dTuAmZnZBy5vU1vmR/7DF67+/vF2Seie4oaNdqHI4vT/W9xOAze5mEd5pgVzdRvFR7seV8TcdXnYFDtV9APSQ4mJFGcupyaLazD74wkkkyJLrfNiQT800fsMEUE+zo9iYBlUpdbXafEhmoPa2xjnQvqr6QGcYP8SsFYeZTWfvhz5ZRieA/9BxCcqiNLejslvDJZo6x72/ZUDtawdw49PjC+MLU1o/LEdFVlrLfY2FVZqQeAjRLqsHW2LxIwA/S0Emg181FpgEBqvHV4xb+gzdf6rMm6D9giwQH3rfIp6UJWEBA4diByUp21CTovdr2fYixA6Y0/UArH89fCDSLO82algpTET2VUhm+X56Spajr1+uD5BiIAvWWS7cAJCRq/G0vNSnjfAXv6i3YMZr//MAyVoAAP6yxxsShJ3dtewScss107OZ7dZ97Ikqxcb5LP2nTkQfcHVWCyvDSXgEydtMMvV2NwFEohWpGVasgItj1f5c126narrrZT8pDw== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR04MB6452.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(346002)(396003)(136003)(366004)(39860400002)(376002)(451199021)(54906003)(316002)(6666004)(52116002)(186003)(66946007)(6916009)(4326008)(6486002)(66556008)(66476007)(478600001)(966005)(41300700001)(6512007)(8676002)(8936002)(7416002)(86362001)(1076003)(6506007)(26005)(5660300002)(44832011)(83380400001)(2616005)(36756003)(66574015)(2906002)(38350700002)(38100700002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?KLqfoRnbiveM6gnFSSqXznNyZLjh?= =?utf-8?q?j6H8X06ihhWOJNH0DTJvimiUomLVJP0oy8czyrcuur3ZFWkMMvt3SDKIWujtpIT6v?= =?utf-8?q?ucl6SHtu+t5zLUzuV5U5n1z40J9vMihksOWud9grIOqvRujWbvPLH4D5kAbAczGbM?= =?utf-8?q?g4xTM1bBwXu6iNsfWCj6uLOPFzcrW/7Qlod524MYxXcpiUvydfnIDF+j4zQQucaG2?= =?utf-8?q?wAF+MawJU1xiJprig8BlRoIU7Mkzkn1sl4j90JU/EjoefSaKt+fMLBJ6X9dPUOZQ8?= =?utf-8?q?KJ1tCcjF6XvFjNOdprpac1DkuP1D9GubLvYItkr3rihVJb0IuxLBmtjuFR9aV6SnT?= =?utf-8?q?YI8qURQoJITv7nSST1k/cXeY+b80zZfnBVHUFXzBqCmmSXvL6xiDeNrXh7siuIUSJ?= =?utf-8?q?9BQDgMgSIznwZCqBT/e85AYNU3fljibdRfccXPQg8hWMMM0heZhhkkvW+DhkU5G5h?= =?utf-8?q?5vTk1LVl+m3CFySzWFv2YyCrHsRIYgkDe5gQpRrs2w4QgBf/CHF/t2bZ4PGL43iLn?= =?utf-8?q?jxMRRay/W27aPp5TF2qvGRjUf5qD/EGhX/mdf1Po+l8gllRFEfojCKCqRA0/mB+Tn?= =?utf-8?q?28RauyXDQga3OG8+z1+r7QJ75eArCqhKrk5r6UeV4PL03N+VLcr5r6gm84HL+Gj4s?= =?utf-8?q?ducrJFpAvbMn4kTYp6IvdIRuw2sLiZyC8sPo/X2I2i3xbbeL8cBFmevH7qV/pk739?= =?utf-8?q?sgaRc5Ln9mV9AtiTVWS/NdhsghzsY2gDPCfZk2prJk8aya21ATabMK2Z+cEm6ac6j?= =?utf-8?q?bqsNQ8y2PLpCmb0+kusemtupCgwpAfwCy0oz+PAXzNKLq8KkwKwrH0Y3pR64G4u0J?= =?utf-8?q?gf0T8OwUFq+jal3bqOCSIGwM+5QIjJt30z5Og82qTsLyXOuEr2MfVpNlNnA92x974?= =?utf-8?q?ihO7JACS+nYMzylMax1xqDDjEmlZ1aVjiu8aPmj+FH6og3XsW9/MO52uKyRAgj6SE?= =?utf-8?q?dPs09y1jw0gFiBsI1hpmHQuynzJChJ8Q/tF8oKx4kwbtWw1+NnNjm6TKo9y2HIAhY?= =?utf-8?q?ETl7b+zWulYuZZU/aXvrIFbxVQgAR9dnIfP2rd92xWuweq7txYLYgfmqriik3SOvg?= =?utf-8?q?ruym/sDIeFUV9ln1aM/djuFmIV29nVT+pzv//pZCgjqaUdKN/nNGdM0QvJBNoyuNT?= =?utf-8?q?GSb49isGmDgHEhoSrt54owES3i+ManrXyMKGpHI7rm6qSBXb0kXhsfZwkMLmaX3HR?= =?utf-8?q?z/lteqobCJ4qwZ4zIzwlcc7fiSeZaVhfbwgw4/1B3zRn7l10ASAKSU+hhVHks32wC?= =?utf-8?q?7o/jgSt6ILjKQGKXzWJfCuEwRZu2k55JXhLDzbjY8dRw3Cg0ADlVZ3z12s+yfUraQ?= =?utf-8?q?AX5mi2f4HSTVF/iIebyXPLrmNDqWOZHVJGj5hX4wYBhKpICEOl1YithzpMoElHeVm?= =?utf-8?q?wfsrCFkWKhsQyLzEyPsDjNZCKI646tT4N5Ai5iGOb9WDCfRI1w6kY5ozrV9bhpW02?= =?utf-8?q?kdd8gtgYGyUCM1PZHpaXuu7cOdzvvsYS85QfOLKdR4d07Auq0IZASxDx4CkDLljmY?= =?utf-8?q?bdZg8i//Oxvrx1uSD/x3SfBW6fSh/hpidw=3D=3D?= X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: dce14071-d807-4a0b-6cd7-08db839b6864 X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB6452.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jul 2023 12:19:29.9316 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: x4G1CqvrOFY0Ryq6u7JTpQltPRXD+kOZUCBIFEWUrxW5bCRxOBow4JTjw78AZU4TV1I2pM7pTxUqCoxx4M7hhA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR04MB6971 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771309576955103516 X-GMAIL-MSGID: 1771309576955103516 |
Series |
Introduce ndo_hwtstamp_get() and ndo_hwtstamp_set()
|
|
Message
Vladimir Oltean
July 13, 2023, 12:18 p.m. UTC
Based on previous RFCs from Maxim Georgiev: https://lore.kernel.org/netdev/20230502043150.17097-1-glipus@gmail.com/ this series attempts to introduce new API for the hardware timestamping control path (SIOCGHWTSTAMP and SIOCSHWTSTAMP handling). I don't have any board with phylib hardware timestamping, so I would appreciate testing (especially on lan966x, the most intricate conversion). I was, however, able to test netdev level timestamping, because I also have some more unsubmitted conversions in progress: https://github.com/vladimiroltean/linux/commits/ndo-hwtstamp-v7 I hope that the concerns expressed in the comments of previous series were addressed, and that Köry Maincent's series: https://lore.kernel.org/netdev/20230406173308.401924-1-kory.maincent@bootlin.com/ can make progress in parallel with the conversion of the rest of drivers. Maxim Georgiev (5): net: add NDOs for configuring hardware timestamping net: add hwtstamping helpers for stackable net devices net: vlan: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() net: macvlan: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() net: bonding: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() Vladimir Oltean (5): net: fec: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() net: fec: delete fec_ptp_disable_hwts() net: sparx5: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() net: lan966x: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() net: remove phy_has_hwtstamp() -> phy_mii_ioctl() decision from converted drivers drivers/net/bonding/bond_main.c | 105 ++++++---- drivers/net/ethernet/freescale/fec.h | 6 +- drivers/net/ethernet/freescale/fec_main.c | 41 ++-- drivers/net/ethernet/freescale/fec_ptp.c | 43 ++-- .../ethernet/microchip/lan966x/lan966x_main.c | 61 ++++-- .../ethernet/microchip/lan966x/lan966x_main.h | 12 +- .../ethernet/microchip/lan966x/lan966x_ptp.c | 34 ++-- .../ethernet/microchip/sparx5/sparx5_main.h | 9 +- .../ethernet/microchip/sparx5/sparx5_netdev.c | 35 +++- .../ethernet/microchip/sparx5/sparx5_ptp.c | 24 ++- drivers/net/macvlan.c | 34 ++-- include/linux/net_tstamp.h | 28 +++ include/linux/netdevice.h | 25 +++ net/8021q/vlan_dev.c | 27 ++- net/core/dev_ioctl.c | 183 +++++++++++++++++- 15 files changed, 480 insertions(+), 187 deletions(-)
Comments
On 7/13/2023 5:18 AM, Vladimir Oltean wrote: > Based on previous RFCs from Maxim Georgiev: > https://lore.kernel.org/netdev/20230502043150.17097-1-glipus@gmail.com/ > > this series attempts to introduce new API for the hardware timestamping > control path (SIOCGHWTSTAMP and SIOCSHWTSTAMP handling). > > I don't have any board with phylib hardware timestamping, so I would > appreciate testing (especially on lan966x, the most intricate > conversion). I was, however, able to test netdev level timestamping, > because I also have some more unsubmitted conversions in progress: > > https://github.com/vladimiroltean/linux/commits/ndo-hwtstamp-v7 > > I hope that the concerns expressed in the comments of previous series > were addressed, and that Köry Maincent's series: > https://lore.kernel.org/netdev/20230406173308.401924-1-kory.maincent@bootlin.com/ > can make progress in parallel with the conversion of the rest of drivers. > This series looks good to me, nice cleanup and reducing some boiler plate code is excellent. I'd like to convert the Intel drivers too, but I am not sure when I can commit to doing that as I have a lot on my plate presently. Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> > Maxim Georgiev (5): > net: add NDOs for configuring hardware timestamping > net: add hwtstamping helpers for stackable net devices > net: vlan: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() > net: macvlan: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() > net: bonding: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() > > Vladimir Oltean (5): > net: fec: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() > net: fec: delete fec_ptp_disable_hwts() > net: sparx5: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() > net: lan966x: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() > net: remove phy_has_hwtstamp() -> phy_mii_ioctl() decision from > converted drivers > > drivers/net/bonding/bond_main.c | 105 ++++++---- > drivers/net/ethernet/freescale/fec.h | 6 +- > drivers/net/ethernet/freescale/fec_main.c | 41 ++-- > drivers/net/ethernet/freescale/fec_ptp.c | 43 ++-- > .../ethernet/microchip/lan966x/lan966x_main.c | 61 ++++-- > .../ethernet/microchip/lan966x/lan966x_main.h | 12 +- > .../ethernet/microchip/lan966x/lan966x_ptp.c | 34 ++-- > .../ethernet/microchip/sparx5/sparx5_main.h | 9 +- > .../ethernet/microchip/sparx5/sparx5_netdev.c | 35 +++- > .../ethernet/microchip/sparx5/sparx5_ptp.c | 24 ++- > drivers/net/macvlan.c | 34 ++-- > include/linux/net_tstamp.h | 28 +++ > include/linux/netdevice.h | 25 +++ > net/8021q/vlan_dev.c | 27 ++- > net/core/dev_ioctl.c | 183 +++++++++++++++++- > 15 files changed, 480 insertions(+), 187 deletions(-) >
On Thu, Jul 13, 2023 at 02:50:39PM -0700, Jacob Keller wrote: > On 7/13/2023 5:18 AM, Vladimir Oltean wrote: > > Based on previous RFCs from Maxim Georgiev: > > https://lore.kernel.org/netdev/20230502043150.17097-1-glipus@gmail.com/ > > > > this series attempts to introduce new API for the hardware timestamping > > control path (SIOCGHWTSTAMP and SIOCSHWTSTAMP handling). > > > > I don't have any board with phylib hardware timestamping, so I would > > appreciate testing (especially on lan966x, the most intricate > > conversion). I was, however, able to test netdev level timestamping, > > because I also have some more unsubmitted conversions in progress: > > > > https://github.com/vladimiroltean/linux/commits/ndo-hwtstamp-v7 > > > > I hope that the concerns expressed in the comments of previous series > > were addressed, and that Köry Maincent's series: > > https://lore.kernel.org/netdev/20230406173308.401924-1-kory.maincent@bootlin.com/ > > can make progress in parallel with the conversion of the rest of drivers. > > > > This series looks good to me, nice cleanup and reducing some boiler > plate code is excellent. > > I'd like to convert the Intel drivers too, but I am not sure when I can > commit to doing that as I have a lot on my plate presently. > > Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Thanks for the review. The conversion of Intel drivers is in the Github link I had posted.
On 7/13/2023 3:33 PM, Vladimir Oltean wrote: > On Thu, Jul 13, 2023 at 02:50:39PM -0700, Jacob Keller wrote: >> On 7/13/2023 5:18 AM, Vladimir Oltean wrote: >>> Based on previous RFCs from Maxim Georgiev: >>> https://lore.kernel.org/netdev/20230502043150.17097-1-glipus@gmail.com/ >>> >>> this series attempts to introduce new API for the hardware timestamping >>> control path (SIOCGHWTSTAMP and SIOCSHWTSTAMP handling). >>> >>> I don't have any board with phylib hardware timestamping, so I would >>> appreciate testing (especially on lan966x, the most intricate >>> conversion). I was, however, able to test netdev level timestamping, >>> because I also have some more unsubmitted conversions in progress: >>> >>> https://github.com/vladimiroltean/linux/commits/ndo-hwtstamp-v7 >>> >>> I hope that the concerns expressed in the comments of previous series >>> were addressed, and that Köry Maincent's series: >>> https://lore.kernel.org/netdev/20230406173308.401924-1-kory.maincent@bootlin.com/ >>> can make progress in parallel with the conversion of the rest of drivers. >>> >> >> This series looks good to me, nice cleanup and reducing some boiler >> plate code is excellent. >> >> I'd like to convert the Intel drivers too, but I am not sure when I can >> commit to doing that as I have a lot on my plate presently. >> >> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> > > Thanks for the review. The conversion of Intel drivers is in the Github > link I had posted. Oh nice!
The 07/13/2023 15:18, Vladimir Oltean wrote: Hi Vladimir, > > Based on previous RFCs from Maxim Georgiev: > https://lore.kernel.org/netdev/20230502043150.17097-1-glipus@gmail.com/ > > this series attempts to introduce new API for the hardware timestamping > control path (SIOCGHWTSTAMP and SIOCSHWTSTAMP handling). > > I don't have any board with phylib hardware timestamping, so I would > appreciate testing (especially on lan966x, the most intricate > conversion). I was, however, able to test netdev level timestamping, > because I also have some more unsubmitted conversions in progress: > > https://github.com/vladimiroltean/linux/commits/ndo-hwtstamp-v7 I have tested this patch series on lan966x. In both cases, when there is a PHY that supports HW timestamping and when the isn't a PHY that supports HW timestamping. In both cases it behaves as expected. Thanks! Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com> > > I hope that the concerns expressed in the comments of previous series > were addressed, and that Köry Maincent's series: > https://lore.kernel.org/netdev/20230406173308.401924-1-kory.maincent@bootlin.com/ > can make progress in parallel with the conversion of the rest of drivers. > > Maxim Georgiev (5): > net: add NDOs for configuring hardware timestamping > net: add hwtstamping helpers for stackable net devices > net: vlan: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() > net: macvlan: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() > net: bonding: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() > > Vladimir Oltean (5): > net: fec: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() > net: fec: delete fec_ptp_disable_hwts() > net: sparx5: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() > net: lan966x: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() > net: remove phy_has_hwtstamp() -> phy_mii_ioctl() decision from > converted drivers > > drivers/net/bonding/bond_main.c | 105 ++++++---- > drivers/net/ethernet/freescale/fec.h | 6 +- > drivers/net/ethernet/freescale/fec_main.c | 41 ++-- > drivers/net/ethernet/freescale/fec_ptp.c | 43 ++-- > .../ethernet/microchip/lan966x/lan966x_main.c | 61 ++++-- > .../ethernet/microchip/lan966x/lan966x_main.h | 12 +- > .../ethernet/microchip/lan966x/lan966x_ptp.c | 34 ++-- > .../ethernet/microchip/sparx5/sparx5_main.h | 9 +- > .../ethernet/microchip/sparx5/sparx5_netdev.c | 35 +++- > .../ethernet/microchip/sparx5/sparx5_ptp.c | 24 ++- > drivers/net/macvlan.c | 34 ++-- > include/linux/net_tstamp.h | 28 +++ > include/linux/netdevice.h | 25 +++ > net/8021q/vlan_dev.c | 27 ++- > net/core/dev_ioctl.c | 183 +++++++++++++++++- > 15 files changed, 480 insertions(+), 187 deletions(-) > > -- > 2.34.1 >
On Thu, Jul 13, 2023 at 6:19 AM Vladimir Oltean <vladimir.oltean@nxp.com> wrote: > > Based on previous RFCs from Maxim Georgiev: > https://lore.kernel.org/netdev/20230502043150.17097-1-glipus@gmail.com/ > > this series attempts to introduce new API for the hardware timestamping > control path (SIOCGHWTSTAMP and SIOCSHWTSTAMP handling). > > I don't have any board with phylib hardware timestamping, so I would > appreciate testing (especially on lan966x, the most intricate > conversion). I was, however, able to test netdev level timestamping, > because I also have some more unsubmitted conversions in progress: > > https://github.com/vladimiroltean/linux/commits/ndo-hwtstamp-v7 > > I hope that the concerns expressed in the comments of previous series > were addressed, and that Köry Maincent's series: > https://lore.kernel.org/netdev/20230406173308.401924-1-kory.maincent@bootlin.com/ > can make progress in parallel with the conversion of the rest of drivers. > > Maxim Georgiev (5): > net: add NDOs for configuring hardware timestamping > net: add hwtstamping helpers for stackable net devices > net: vlan: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() > net: macvlan: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() > net: bonding: convert to ndo_hwtstamp_get() / ndo_hwtstamp_set() > > Vladimir Oltean (5): > net: fec: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() > net: fec: delete fec_ptp_disable_hwts() > net: sparx5: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() > net: lan966x: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() > net: remove phy_has_hwtstamp() -> phy_mii_ioctl() decision from > converted drivers > > drivers/net/bonding/bond_main.c | 105 ++++++---- > drivers/net/ethernet/freescale/fec.h | 6 +- > drivers/net/ethernet/freescale/fec_main.c | 41 ++-- > drivers/net/ethernet/freescale/fec_ptp.c | 43 ++-- > .../ethernet/microchip/lan966x/lan966x_main.c | 61 ++++-- > .../ethernet/microchip/lan966x/lan966x_main.h | 12 +- > .../ethernet/microchip/lan966x/lan966x_ptp.c | 34 ++-- > .../ethernet/microchip/sparx5/sparx5_main.h | 9 +- > .../ethernet/microchip/sparx5/sparx5_netdev.c | 35 +++- > .../ethernet/microchip/sparx5/sparx5_ptp.c | 24 ++- > drivers/net/macvlan.c | 34 ++-- > include/linux/net_tstamp.h | 28 +++ > include/linux/netdevice.h | 25 +++ > net/8021q/vlan_dev.c | 27 ++- > net/core/dev_ioctl.c | 183 +++++++++++++++++- > 15 files changed, 480 insertions(+), 187 deletions(-) > > -- > 2.34.1 > Vladimir, thank you for taking over and improving this patch stack! I see you dropped the netdevsim patch: https://www.spinics.net/lists/netdev/msg901378.html Do you believe it's not useful any more since the rest of the patches in the stack were tested through other means?
Hi Maxim, On Sun, Jul 16, 2023 at 07:22:23PM -0600, Max Georgiev wrote: > Vladimir, thank you for taking over and improving this patch stack! > > I see you dropped the netdevsim patch: > https://www.spinics.net/lists/netdev/msg901378.html > Do you believe it's not useful any more since the rest of the > patches in the stack were tested through other means? I just didn't consider that adding mock hardware timestamping support to netdevsim was necessary or useful, considering the number of other driver conversions that will have to be submitted. Just an extra, avoidable effort for me.
On Fri, Jul 14, 2023 at 10:00:59AM +0200, Horatiu Vultur wrote: > The 07/13/2023 15:18, Vladimir Oltean wrote: > > Hi Vladimir, > > > > > Based on previous RFCs from Maxim Georgiev: > > https://lore.kernel.org/netdev/20230502043150.17097-1-glipus@gmail.com/ > > > > this series attempts to introduce new API for the hardware timestamping > > control path (SIOCGHWTSTAMP and SIOCSHWTSTAMP handling). > > > > I don't have any board with phylib hardware timestamping, so I would > > appreciate testing (especially on lan966x, the most intricate > > conversion). I was, however, able to test netdev level timestamping, > > because I also have some more unsubmitted conversions in progress: > > > > https://github.com/vladimiroltean/linux/commits/ndo-hwtstamp-v7 > > I have tested this patch series on lan966x. In both cases, when there is > a PHY that supports HW timestamping and when the isn't a PHY that > supports HW timestamping. In both cases it behaves as expected. Thanks! > Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com> Thanks for testing! I'll apply this tag to patches: net: add NDOs for configuring hardware timestamping net: lan966x: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() net: remove phy_has_hwtstamp() -> phy_mii_ioctl() decision from converted drivers
On 7/17/2023 4:25 AM, Vladimir Oltean wrote: > Hi Maxim, > > On Sun, Jul 16, 2023 at 07:22:23PM -0600, Max Georgiev wrote: >> Vladimir, thank you for taking over and improving this patch stack! >> >> I see you dropped the netdevsim patch: >> https://www.spinics.net/lists/netdev/msg901378.html >> Do you believe it's not useful any more since the rest of the >> patches in the stack were tested through other means? > > I just didn't consider that adding mock hardware timestamping support to > netdevsim was necessary or useful, considering the number of other driver > conversions that will have to be submitted. Just an extra, avoidable effort > for me. FWIW I think its unnecessary as well. I read through the implementation and noticed that it also used the .get_ts_info callback by directly reporting whatever type and filter was set via SIOCSHWTSTAMP, rather than reporting some device capability. Obviously as a mock device there is no real capability, and that was likely done for testing purposes. However, it would still leave the kernel with an implementation that does not follow the expected rules for these ioctls. For a mock device thats not really an issue. However, I'd prefer to avoid such in the kernel so that its not available for copying when someone without such knowledge comes along to write a new driver.
On Mon, Jul 17, 2023 at 01:23:02PM -0700, Jacob Keller wrote: > For a mock device thats not really an issue. However, I'd prefer to > avoid such in the kernel so that its not available for copying when > someone without such knowledge comes along to write a new driver. +1