Message ID | 20221021054111.25852-1-sarath.babu.naidu.gaddam@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp507379wrr; Thu, 20 Oct 2022 22:56:39 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5wcKXOcRjHOYH/HIOoKSFmODmbqOSQedFRnLpFlnumU8k0MTVm+lacCMXHx0NeEKfsJOa3 X-Received: by 2002:a17:902:db0b:b0:185:51cc:811a with SMTP id m11-20020a170902db0b00b0018551cc811amr17594011plx.85.1666331788232; Thu, 20 Oct 2022 22:56:28 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1666331788; cv=pass; d=google.com; s=arc-20160816; b=Q852ty94dVPCPGcaRC6pmb0zWBALRQ6oB4V9qeOmsFDW763cbN20FxQ9ICasu4VpwG 707YBJyyDWoFaelhqiuOy6SU4JpgMpNkNIFdd7Tra2nRK12Zs+m4swb9RM8fepIz5ZN+ YMZfDdx5WrvJauY7h/9JG923wgAFuiww+76TORniR0TRcQQL7eiwKm10NNvNm26e7/Xc 40JVLecMoy7+BRo2eEUIJSOEUUSQ0PRbyWUv/xhnbg+MeRSmvPEhSbzOt7PB27p6KkO+ BP+Ds7HVhkqAUwovCST7OK/oK1QM7lPhDQ2H2Px3RSrUNL1qVPLgkLxxug3Ic+wXoZ0e TtAA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=N0cYYs1TKbLRxbPxeCGvBUp8VK5ipygXGkgTebj9Oro=; b=Y2nbk1fhsrIBU3PiihRxSF1bFfvgVoBK95ug2/FNSlLjThsizSEBrVGkOTKsagfq+k PWYxV6LlNJRLZENU4LjxsR0z9xfpN1+JxUTEKExtX9AYyBUg02W8AhNaT1o26BdRJQwV rCJGGvcD6eHmzv529f1tztwDds2QLtXPdnINr0+EFqatUMH2uuJDqYMzFM5lIuzbTCSB DyMAkbNPzscTDS1kkzBZffK2Y4+rE5tkB40OAhyGLfG8CojFF0HFSW0dS+m/7OQmiHkg dy1e0iumIACT1tnxDapcsesOMex8bFk98UcUYY6eCsoNz5BUCv3rDWCYM/5QMgzhS1b7 S3dQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=p+XxgQwa; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l23-20020a637017000000b004607f6b2586si25005387pgc.736.2022.10.20.22.56.15; Thu, 20 Oct 2022 22:56:28 -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=@amd.com header.s=selector1 header.b=p+XxgQwa; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229616AbiJUFlW (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Fri, 21 Oct 2022 01:41:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229476AbiJUFlV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 21 Oct 2022 01:41:21 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2040.outbound.protection.outlook.com [40.107.236.40]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8F301D93D6; Thu, 20 Oct 2022 22:41:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ka8Sw/8IKbm4rh9oWThw073MU+kSbXMud3JAypGZM8k2+Qgj9JAdw/kQtFxUz2AzMD80lZRCHk9jr+9ltAOvTxcmNmbZQTh+m+YVte9tOMkifyhDMrhgrSu4S1Bi5EQm18QqLLAISio2ptcXD6jQASaPyRHmQFrdp1cQabxpZOYxV0h0QvBKCJBTKzQm16mewCrc46sU7+WYFLEZhU6CgIwty26Hux3R4juNMIdS0gn8DWO5LCPyqQhdnPojonXmCOXrddRXhDPXD0Bp1p1H6PFCKbarCrlnU2jfzCdNethTMKDd8oj+JJOAGmtL7G1WGQ4WQMweIT9owL9fvC3QIA== 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=N0cYYs1TKbLRxbPxeCGvBUp8VK5ipygXGkgTebj9Oro=; b=G3TbGcHnpByiws0+TXw8F9ZnJ9EMEaG25Q/DseZ2OvcvLHMiCXRnavoFk8F+pMCqJG6lt9WTwxuKNIZHtLbmc1edboYi80dlfZM6QmhYJbSvIWSrUG6WFP+EFQnUnhNX71SGixm3zx5uk4IrqsrnJZWanSK2Y+SckiL7bCC7CNzhCUf7rElfep6OGw4Rl2yJ5xOYuGO6TsHXEJ8CvR2i6VFMO1854kqEAUERpfdZfYM/5XEJuqDJ7fCq56TZerAID8+RFv6Ps10ftvPH8YTyyVtsWew+uRX0mFuhYglThLLiCRw0gqAATYiEmriy1IPqX+h61vJJ3R9NtT//vBTevw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=davemloft.net smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N0cYYs1TKbLRxbPxeCGvBUp8VK5ipygXGkgTebj9Oro=; b=p+XxgQwacbdSZydXuTormEERfySTE/TSVfmQFEZhX1CW9DmikHS6DRGquMUsKUMr8JLzuEVzqHtl8B8BNqjqkZlN7jxJoEn1Fber2JzTl9GbbCsQ9U4O+YTN0ttJin0VCaO6/ReWKTv8ok11vR8f1Y8OPSWIs+L6UaLaHQhrQZ0= Received: from DS7PR06CA0041.namprd06.prod.outlook.com (2603:10b6:8:54::10) by SN7PR12MB7369.namprd12.prod.outlook.com (2603:10b6:806:298::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.29; Fri, 21 Oct 2022 05:41:17 +0000 Received: from DM6NAM11FT092.eop-nam11.prod.protection.outlook.com (2603:10b6:8:54:cafe::45) by DS7PR06CA0041.outlook.office365.com (2603:10b6:8:54::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.35 via Frontend Transport; Fri, 21 Oct 2022 05:41:17 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Received: from SATLEXMB03.amd.com (165.204.84.17) by DM6NAM11FT092.mail.protection.outlook.com (10.13.173.44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5746.16 via Frontend Transport; Fri, 21 Oct 2022 05:41:16 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 21 Oct 2022 00:41:15 -0500 Received: from xhdpranavis40.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2375.31 via Frontend Transport; Fri, 21 Oct 2022 00:41:11 -0500 From: Sarath Babu Naidu Gaddam <sarath.babu.naidu.gaddam@amd.com> To: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>, <robh+dt@kernel.org>, <richardcochran@gmail.com> CC: <krzysztof.kozlowski+dt@linaro.org>, <netdev@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <yangbo.lu@nxp.com>, <radhey.shyam.pandey@amd.com>, <anirudha.sarangi@amd.com>, <harini.katakam@amd.com>, <sarath.babu.naidu.gaddam@amd.com>, <git@amd.com> Subject: [PATCH net-next V2] dt-bindings: net: ethernet-controller: Add ptp-hardware-clock Date: Thu, 20 Oct 2022 23:41:10 -0600 Message-ID: <20221021054111.25852-1-sarath.babu.naidu.gaddam@amd.com> X-Mailer: git-send-email 2.36.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM11FT092:EE_|SN7PR12MB7369:EE_ X-MS-Office365-Filtering-Correlation-Id: 7237ce4c-209e-4b0b-1696-08dab326df9b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BdBJ5MiS+5YvnplbRD/tsVsJEP9p5crNmPyVxb79zvri7gIW/ODzDGd3TkEXnbSPV8sXL+KktX184B6VL9JOH1N/QOdZG02vt22JZ3YqB5YPSFnFYAhDGHXzH/sergOEg8II0eIAYdCfqc0LBztDiOjdBQ7IIkODzlSVHAaWGmDbknxNr+8txXs9bii6Hnzbb+fFgKmq52VealfsJPlzE3+pWW3kOX4vVdCBV19uIy87IMlaRTJ4cUqi7kOyVAPknLlY0Vz7cBNhkpc0adhQjGVM9+CGnCgOpevaRAdJH4pOJfE9/FrkCcIJdSzx0s+HxdaPDFb081/dgT44ck8RW1yvol5CHZ1ev2nbP3481Vt+zhJPM4nyZJL/i/eFx+elOYifrshSSPWIK1/RuSaKl61yBXQsLUDtH4xyxCK1qgn6iHXy1eQeKTOJ0nNSmb7no2G5Qg8s561kBubFBmfFiR8uRsWUf7qiBwOFmp7cPzGUyTjEnEGe5E8Y5GSUXPH7/XHhV5EMacN9R1nvAQ0ntiwSpF51hsB4esnOmJAvL7HMoO4iK8iQYBoHF7tlxHMLmjab+ZMQRMttV75LDTTDoOyi4P6p1a3PRCs8zg/ts5pM66Z3bRPGooxVP5i5GqCv8nZGb01xlUT9utYFOj1tz6Q+FfkIlCFbdZYkuUCugA70lYfc6M0EBSTCYTpJ38qjeAmAabsx1TCYe9nCrbx9oaW4p8AQFjiK5ecNceR0XLp2PclAsswNkWT9DO98avroEluGb4iBa7SDGw8jlgDL4OVwhaNVRu+Pek9gODe5g+U6fjtv2C3EH0a0OZVusDGnT7i6HxCbgJWSkYF9Xy8xzmlos/zo2v09WNUuTGOWYyE= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230022)(4636009)(396003)(136003)(39860400002)(346002)(376002)(451199015)(40470700004)(36840700001)(46966006)(82740400003)(186003)(2616005)(1076003)(426003)(36860700001)(316002)(47076005)(336012)(26005)(40460700003)(83380400001)(2906002)(7416002)(40480700001)(5660300002)(8936002)(110136005)(478600001)(41300700001)(82310400005)(54906003)(70206006)(8676002)(70586007)(4326008)(966005)(103116003)(36756003)(86362001)(356005)(81166007)(36900700001)(2101003);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2022 05:41:16.7177 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7237ce4c-209e-4b0b-1696-08dab326df9b X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT092.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7369 X-Spam-Status: No, score=0.6 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED autolearn=no 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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747275520765720687?= X-GMAIL-MSGID: =?utf-8?q?1747275520765720687?= |
Series |
[net-next,V2] dt-bindings: net: ethernet-controller: Add ptp-hardware-clock
|
|
Commit Message
Sarath Babu Naidu Gaddam
Oct. 21, 2022, 5:41 a.m. UTC
There is currently no standard property to pass PTP device index
information to ethernet driver when they are independent.
ptp-hardware-clock property will contain phandle to PTP clock node.
Freescale driver currently has this implementation but it will be
good to agree on a generic (optional) property name to link to PTP
phandle to Ethernet node. In future or any current ethernet driver
wants to use this method of reading the PHC index,they can simply use
this generic name and point their own PTP clock node, instead of
creating separate property names in each ethernet driver DT node.
axiethernet driver uses this method when PTP support is integrated.
Example:
fman0: fman@1a00000 {
ptp-hardware-clock = <&ptp_timer0>;
}
ptp_timer0: ptp-timer@1afe000 {
compatible = "fsl,fman-ptp-timer";
reg = <0x0 0x1afe000 0x0 0x1000>;
}
Signed-off-by: Sarath Babu Naidu Gaddam <sarath.babu.naidu.gaddam@amd.com>
---
We want binding to be reviewed/accepted and then make changes in freescale
binding documentation to use this generic binding.
DT information:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
tree/arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi#n23
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
tree/Documentation/devicetree/bindings/net/fsl-fman.txt#n320
Freescale driver:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
tree/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c#n467
Changes in V2:
1) Changed the ptimer-handle to ptp-hardware-clock based on
Richard Cochran's comment.
2) Updated commit description.
---
.../devicetree/bindings/net/ethernet-controller.yaml | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Thu, Oct 20, 2022 at 11:41:10PM -0600, Sarath Babu Naidu Gaddam wrote: > There is currently no standard property to pass PTP device index > information to ethernet driver when they are independent. > > ptp-hardware-clock property will contain phandle to PTP clock node. > > Freescale driver currently has this implementation but it will be > good to agree on a generic (optional) property name to link to PTP > phandle to Ethernet node. In future or any current ethernet driver > wants to use this method of reading the PHC index,they can simply use > this generic name and point their own PTP clock node, instead of > creating separate property names in each ethernet driver DT node. > > axiethernet driver uses this method when PTP support is integrated. > > Example: > fman0: fman@1a00000 { > ptp-hardware-clock = <&ptp_timer0>; > } > > ptp_timer0: ptp-timer@1afe000 { > compatible = "fsl,fman-ptp-timer"; > reg = <0x0 0x1afe000 0x0 0x1000>; > } > > Signed-off-by: Sarath Babu Naidu Gaddam <sarath.babu.naidu.gaddam@amd.com> Acked-by: Richard Cochran <richardcochran@gmail.com>
On 21/10/2022 01:41, Sarath Babu Naidu Gaddam wrote: > There is currently no standard property to pass PTP device index > information to ethernet driver when they are independent. > > ptp-hardware-clock property will contain phandle to PTP clock node. > > Freescale driver currently has this implementation but it will be > good to agree on a generic (optional) property name to link to PTP > phandle to Ethernet node. In future or any current ethernet driver > wants to use this method of reading the PHC index,they can simply use > this generic name and point their own PTP clock node, instead of > creating separate property names in each ethernet driver DT node. > > axiethernet driver uses this method when PTP support is integrated. > > Example: > fman0: fman@1a00000 { > ptp-hardware-clock = <&ptp_timer0>; > } > > ptp_timer0: ptp-timer@1afe000 { > compatible = "fsl,fman-ptp-timer"; > reg = <0x0 0x1afe000 0x0 0x1000>; > } > > Signed-off-by: Sarath Babu Naidu Gaddam <sarath.babu.naidu.gaddam@amd.com> > --- > We want binding to be reviewed/accepted and then make changes in freescale > binding documentation to use this generic binding. No, send entire set. We need to see the users of it. > > DT information: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > tree/arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi#n23 Don't wrap links. It's not possible to click them... > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > tree/Documentation/devicetree/bindings/net/fsl-fman.txt#n320 > > Freescale driver: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > tree/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c#n467 > > Changes in V2: > 1) Changed the ptimer-handle to ptp-hardware-clock based on > Richard Cochran's comment. > 2) Updated commit description. > --- > .../devicetree/bindings/net/ethernet-controller.yaml | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml > index 3aef506fa158..d2863c1dd585 100644 > --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml > +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml > @@ -161,6 +161,11 @@ properties: > - auto > - in-band-status > > + ptp-hardware-clock: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: > + Specifies a reference to a node representing a IEEE1588 timer. Drop "Specifies a reference to". It's obvious from the schema. Aren't you expecting here some specific Devicetree node of IEEE1588 timer? IOW, you expect to point to timer, but what this timer must provide? How is this generic? In your commit msg you use multiple times "driver", so are you adding it only to satisfy Linux driver requirements? What about other drivers, e.g. on BSD or U-Boot? Best regards, Krzysztof
On Thu, Oct 20, 2022 at 11:41:10PM -0600, Sarath Babu Naidu Gaddam wrote: > There is currently no standard property to pass PTP device index > information to ethernet driver when they are independent. > > ptp-hardware-clock property will contain phandle to PTP clock node. > > Freescale driver currently has this implementation but it will be > good to agree on a generic (optional) property name to link to PTP > phandle to Ethernet node. In future or any current ethernet driver > wants to use this method of reading the PHC index,they can simply use > this generic name and point their own PTP clock node, instead of > creating separate property names in each ethernet driver DT node. Seems like this does the same thing as Documentation/devicetree/bindings/ptp/timestamper.txt. Or perhaps what we have in bindings/timestamp/ which unfortunately does about the same thing. The latter one is more flexible and follows standard provider/consumer patterns. So timestamper.txt should probably be deprecated. > > axiethernet driver uses this method when PTP support is integrated. > > Example: > fman0: fman@1a00000 { > ptp-hardware-clock = <&ptp_timer0>; > } > > ptp_timer0: ptp-timer@1afe000 { > compatible = "fsl,fman-ptp-timer"; > reg = <0x0 0x1afe000 0x0 0x1000>; > } > > Signed-off-by: Sarath Babu Naidu Gaddam <sarath.babu.naidu.gaddam@amd.com> > --- > We want binding to be reviewed/accepted and then make changes in freescale > binding documentation to use this generic binding. If you want a common binding, I want to see multiple users and preferrably ones that have some differing requirements. It can be something existing with a 'this is what it would look like if we had used this new common binding'. Rob
On Mon, Oct 24, 2022 at 11:57:23AM -0500, Rob Herring wrote: > On Thu, Oct 20, 2022 at 11:41:10PM -0600, Sarath Babu Naidu Gaddam wrote: > > There is currently no standard property to pass PTP device index > > information to ethernet driver when they are independent. > > > > ptp-hardware-clock property will contain phandle to PTP clock node. > > > > Freescale driver currently has this implementation but it will be > > good to agree on a generic (optional) property name to link to PTP > > phandle to Ethernet node. In future or any current ethernet driver > > wants to use this method of reading the PHC index,they can simply use > > this generic name and point their own PTP clock node, instead of > > creating separate property names in each ethernet driver DT node. > > Seems like this does the same thing as > Documentation/devicetree/bindings/ptp/timestamper.txt. That is different. It goes from: MAC -> time stamp generator The proposed binding goes from: MAC (with built in time stamp generator) -> PTP Hardware Clock (with get/settime etc) Thanks, Richard
On Tue, Oct 25, 2022 at 02:46:08PM -0700, Richard Cochran wrote: > On Mon, Oct 24, 2022 at 11:57:23AM -0500, Rob Herring wrote: > > On Thu, Oct 20, 2022 at 11:41:10PM -0600, Sarath Babu Naidu Gaddam wrote: > > > There is currently no standard property to pass PTP device index > > > information to ethernet driver when they are independent. > > > > > > ptp-hardware-clock property will contain phandle to PTP clock node. > > > > > > Freescale driver currently has this implementation but it will be > > > good to agree on a generic (optional) property name to link to PTP > > > phandle to Ethernet node. In future or any current ethernet driver > > > wants to use this method of reading the PHC index,they can simply use > > > this generic name and point their own PTP clock node, instead of > > > creating separate property names in each ethernet driver DT node. > > > > Seems like this does the same thing as > > Documentation/devicetree/bindings/ptp/timestamper.txt. > > That is different. It goes from: > > MAC -> time stamp generator actually: PHY -> time stamp generator > The proposed binding goes from: > > MAC (with built in time stamp generator) -> PTP Hardware Clock (with get/settime etc) > > > Thanks, > Richard
On Mon, Oct 24, 2022 at 11:57:23AM -0500, Rob Herring wrote: > On Thu, Oct 20, 2022 at 11:41:10PM -0600, Sarath Babu Naidu Gaddam wrote: > > There is currently no standard property to pass PTP device index > > information to ethernet driver when they are independent. > > > > ptp-hardware-clock property will contain phandle to PTP clock node. > > > > Freescale driver currently has this implementation but it will be > > good to agree on a generic (optional) property name to link to PTP > > phandle to Ethernet node. In future or any current ethernet driver > > wants to use this method of reading the PHC index,they can simply use > > this generic name and point their own PTP clock node, instead of > > creating separate property names in each ethernet driver DT node. > > Seems like this does the same thing as > Documentation/devicetree/bindings/ptp/timestamper.txt. > > Or perhaps what we have in bindings/timestamp/ which unfortunately does > about the same thing. > > The latter one is more flexible and follows standard provider/consumer > patterns. So timestamper.txt should probably be deprecated. I don't see how you can do that. The provider/consumer semantics are completely opposite. The three (including present patch) bindings specify three different relationships. Thanks, Richard
> -----Original Message----- > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Sent: Sunday, October 23, 2022 9:12 PM > To: Gaddam, Sarath Babu Naidu <sarath.babu.naidu.gaddam@amd.com>; > davem@davemloft.net; edumazet@google.com; kuba@kernel.org; > pabeni@redhat.com; robh+dt@kernel.org; richardcochran@gmail.com > Cc: krzysztof.kozlowski+dt@linaro.org; netdev@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; > yangbo.lu@nxp.com; Pandey, Radhey Shyam > <radhey.shyam.pandey@amd.com>; Sarangi, Anirudha > <anirudha.sarangi@amd.com>; Katakam, Harini > <harini.katakam@amd.com>; git (AMD-Xilinx) <git@amd.com> > Subject: Re: [PATCH net-next V2] dt-bindings: net: ethernet-controller: Add > ptp-hardware-clock > > On 21/10/2022 01:41, Sarath Babu Naidu Gaddam wrote: > > There is currently no standard property to pass PTP device index > > information to ethernet driver when they are independent. > > > > ptp-hardware-clock property will contain phandle to PTP clock node. > > > > Freescale driver currently has this implementation but it will be good > > to agree on a generic (optional) property name to link to PTP phandle > > to Ethernet node. In future or any current ethernet driver wants to > > use this method of reading the PHC index,they can simply use this > > generic name and point their own PTP clock node, instead of creating > > separate property names in each ethernet driver DT node. > > > > axiethernet driver uses this method when PTP support is integrated. > > > > Example: > > fman0: fman@1a00000 { > > ptp-hardware-clock = <&ptp_timer0>; > > } > > > > ptp_timer0: ptp-timer@1afe000 { > > compatible = "fsl,fman-ptp-timer"; > > reg = <0x0 0x1afe000 0x0 0x1000>; > > } > > > > Signed-off-by: Sarath Babu Naidu Gaddam > > <sarath.babu.naidu.gaddam@amd.com> > > --- > > We want binding to be reviewed/accepted and then make changes in > > freescale binding documentation to use this generic binding. > > No, send entire set. We need to see the users of it. > > > > > DT information: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > > tree/arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi#n23 > > Don't wrap links. It's not possible to click them... > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > > tree/Documentation/devicetree/bindings/net/fsl-fman.txt#n320 > > > > Freescale driver: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > > tree/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c#n467 > > > > Changes in V2: > > 1) Changed the ptimer-handle to ptp-hardware-clock based on > > Richard Cochran's comment. > > 2) Updated commit description. > > --- > > .../devicetree/bindings/net/ethernet-controller.yaml | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/net/ethernet-controller.yaml > > b/Documentation/devicetree/bindings/net/ethernet-controller.yaml > > index 3aef506fa158..d2863c1dd585 100644 > > --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml > > +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml > > @@ -161,6 +161,11 @@ properties: > > - auto > > - in-band-status > > > > + ptp-hardware-clock: > > + $ref: /schemas/types.yaml#/definitions/phandle > > + description: > > + Specifies a reference to a node representing a IEEE1588 timer. > > Drop "Specifies a reference to". It's obvious from the schema. > > Aren't you expecting here some specific Devicetree node of IEEE1588 timer? > IOW, you expect to point to timer, but what this timer must provide? How is > this generic? Thanks for review comments. Format can be as documented by users Documentation/devicetree/bindings/ptp/ members. The node should be accessible to derive the index but the format of the PTP clock node is upto the vendor. > > In your commit msg you use multiple times "driver", so are you adding it only > to satisfy Linux driver requirements? What about other drivers, e.g. on BSD > or U-Boot? AFAIK this is for Linux. It is not relevant to uboot as there's no PTP support there. Thanks, Sarath
On 10/11/2022 10:57, Gaddam, Sarath Babu Naidu wrote: >>> >>> + ptp-hardware-clock: >>> + $ref: /schemas/types.yaml#/definitions/phandle >>> + description: >>> + Specifies a reference to a node representing a IEEE1588 timer. >> >> Drop "Specifies a reference to". It's obvious from the schema. >> >> Aren't you expecting here some specific Devicetree node of IEEE1588 timer? >> IOW, you expect to point to timer, but what this timer must provide? How is >> this generic? > > Thanks for review comments. > Format can be as documented by users Documentation/devicetree/bindings/ptp/ members. The node should be accessible to derive the index but the format of the PTP clock node is upto the vendor. I am not sure what do you mean here. Anyway description might need something more specific. > > >> >> In your commit msg you use multiple times "driver", so are you adding it only >> to satisfy Linux driver requirements? What about other drivers, e.g. on BSD >> or U-Boot? > > AFAIK this is for Linux. It is not relevant to uboot as there's no PTP support there. And BSD? Bindings are not for Linux only. Please abstract from any OS specifics. Also your messages needs wrapping. Use mailing list reply style. Best regards, Krzysztof
> -----Original Message----- > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Sent: Thursday, November 10, 2022 7:36 PM > To: Gaddam, Sarath Babu Naidu > <sarath.babu.naidu.gaddam@amd.com>; davem@davemloft.net; > edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; > robh+dt@kernel.org; richardcochran@gmail.com > Cc: krzysztof.kozlowski+dt@linaro.org; netdev@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; > yangbo.lu@nxp.com; Pandey, Radhey Shyam > <radhey.shyam.pandey@amd.com>; Sarangi, Anirudha > <anirudha.sarangi@amd.com>; Katakam, Harini > <harini.katakam@amd.com>; git (AMD-Xilinx) <git@amd.com> > Subject: Re: [PATCH net-next V2] dt-bindings: net: ethernet-controller: > Add ptp-hardware-clock > > On 10/11/2022 10:57, Gaddam, Sarath Babu Naidu wrote: > >>> > >>> + ptp-hardware-clock: > >>> + $ref: /schemas/types.yaml#/definitions/phandle > >>> + description: > >>> + Specifies a reference to a node representing a IEEE1588 timer. > >> > >> Drop "Specifies a reference to". It's obvious from the schema. > >> > >> Aren't you expecting here some specific Devicetree node of IEEE1588 > timer? > >> IOW, you expect to point to timer, but what this timer must provide? > >> How is this generic? > > > > Thanks for review comments. > > Format can be as documented by users > Documentation/devicetree/bindings/ptp/ members. The node should be > accessible to derive the index but the format of the PTP clock node is > upto the vendor. > > I am not sure what do you mean here. Anyway description might need > something more specific. Apologies for picking up on this thread after a long time. PTP clock node(timer) is upto the vendor. Driver which needs a reference to this node can be accessed by this new property. I will update the description. > > > > > >> > >> In your commit msg you use multiple times "driver", so are you > adding > >> it only to satisfy Linux driver requirements? What about other > >> drivers, e.g. on BSD or U-Boot? > > > > AFAIK this is for Linux. It is not relevant to uboot as there's no PTP > support there. > > And BSD? Bindings are not for Linux only. Please abstract from any OS > specifics. This new binding is a generic property. It can be used in other drivers also if they want to access the PTP device node in the current driver and It's an optional property. I will change the commit description as below. If this is fine, I will send another version with updated commit description. "There is currently no standard property to pass PTP device index information to ethernet driver when they are independent. ptp-hardware-clock property will contain phandle to PTP clock node. Its a generic (optional) property name to link to PTP phandle to Ethernet node. Any future or current ethernet drivers that need a reference to the PHC used on their system can simply use this generic property name instead of using custom property implementation in their device tree nodes." Thanks, Sarath > Also your messages needs wrapping. Use mailing list reply style. > > Best regards, > Krzysztof
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index 3aef506fa158..d2863c1dd585 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -161,6 +161,11 @@ properties: - auto - in-band-status + ptp-hardware-clock: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Specifies a reference to a node representing a IEEE1588 timer. + fixed-link: oneOf: - $ref: /schemas/types.yaml#/definitions/uint32-array