Message ID | 20230807110048.2611456-1-danishanwar@ti.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c44e:0:b0:3f2:4152:657d with SMTP id w14csp1406014vqr; Mon, 7 Aug 2023 05:18:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF5sl0dWxjeqSJaVyyAqU7RkYEgcLKiopwRjojC3nB1CMi68ybpZq/cTMJNfbiLzzOLnEl5 X-Received: by 2002:a19:5f19:0:b0:4fe:279b:7607 with SMTP id t25-20020a195f19000000b004fe279b7607mr5765747lfb.20.1691410682947; Mon, 07 Aug 2023 05:18:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691410682; cv=none; d=google.com; s=arc-20160816; b=fs68P7T/LWJ3CmDyF7iTz6XiYqjBuhjXMyu2ih2A/Qin1FSo0s278YnuZuxB+0Bj4K DW49YRcpZgeTix+OsUoepBStQacXgGbYcsusqkVO54YATEKjlEvsUAhXO4qAAranPEtV Gl1jjRVfsU+QJiTa+DL5Zlcuh/J42FSLuhBePZNyFjTQ0A7F1+Cd5Hx9YknVzQUa+lNn Aeto5K779ULIACYhFI83ZNp+r42wQ1Ed4D0OtHvvNxG7Ukg9QbzId9YyHxCp9ps30Egi mPvMSBpVwdN7Vj5JotI5xDLwUnukidmuvREIFIm6bJxRDQtXRDYYt3szPdyq9VpLCkul YGoA== ARC-Message-Signature: i=1; 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=ZPjBvlXzHvxA+tZyjo1EWAU6idpL4b02GPU7dEiciNc=; fh=TO4fkcEI9b5r/wMetIII7RIVPqbK0XaoWpj6Tf2aW8M=; b=uzmmLl4CGUZ/D1ebzzPY5wu/DfP1HyIMftGWWZpOMPWjKaqrteLtfkyAwk6bbH9Ild BuODBBWoaCQV3kUKgiRGi/IPBEIoZEtn0ToqhuM7kSpxaYrQCNr7gBqh2bUt4vAjH2LV vlFhvR2NOo4kUrn3oWP8c03kiQnpBp61+bmRenGGzGRNsaQj52KlX8f/aCyJKIYHwmGK s60D1CoL/yzGOWj/vqkgt34bXHIvoJ2WYrnNxMe6nIj7UfcHkPh86fUTDercs0HciGc4 w058xH+k6/KX9D3V3mZOtfzy/WqhUB7ybMhY3WnfPW93G7RByeVSKChinAMrQVXBUtX9 AuLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=JJfi7OJe; 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=NONE dis=NONE) header.from=ti.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a7-20020aa7d907000000b0051e28ec9d30si5775858edr.665.2023.08.07.05.17.24; Mon, 07 Aug 2023 05:18:02 -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=@ti.com header.s=ti-com-17Q1 header.b=JJfi7OJe; 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=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231814AbjHGLBW (ORCPT <rfc822;aaronkmseo@gmail.com> + 99 others); Mon, 7 Aug 2023 07:01:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231784AbjHGLBS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 7 Aug 2023 07:01:18 -0400 Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73E4E1721; Mon, 7 Aug 2023 04:01:16 -0700 (PDT) Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 377B0sv8054566; Mon, 7 Aug 2023 06:00:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1691406054; bh=ZPjBvlXzHvxA+tZyjo1EWAU6idpL4b02GPU7dEiciNc=; h=From:To:CC:Subject:Date; b=JJfi7OJe4hTq6PPVdSKngRhg6A5ETI2B85fyTTkbpt325FLpe0oSWhri0dalRgyHa y9A2NMUnKxIDm9fImSJF2ek8hpnxvIsW4TrZt4+xJENJitEoXpPyVwrjkZuVbjGfVo MnA0m0aNQ555zY9DnMIa1PNDutcDKk7Qq7VxeINg= Received: from DFLE115.ent.ti.com (dfle115.ent.ti.com [10.64.6.36]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 377B0sZc074768 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 7 Aug 2023 06:00:54 -0500 Received: from DFLE111.ent.ti.com (10.64.6.32) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 7 Aug 2023 06:00:54 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DFLE111.ent.ti.com (10.64.6.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 7 Aug 2023 06:00:54 -0500 Received: from fllv0122.itg.ti.com (fllv0122.itg.ti.com [10.247.120.72]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 377B0shg031533; Mon, 7 Aug 2023 06:00:54 -0500 Received: from localhost (uda0501179.dhcp.ti.com [172.24.227.217]) by fllv0122.itg.ti.com (8.14.7/8.14.7) with ESMTP id 377B0rUG028356; Mon, 7 Aug 2023 06:00:54 -0500 From: MD Danish Anwar <danishanwar@ti.com> To: Randy Dunlap <rdunlap@infradead.org>, Roger Quadros <rogerq@kernel.org>, Simon Horman <simon.horman@corigine.com>, Vignesh Raghavendra <vigneshr@ti.com>, Andrew Lunn <andrew@lunn.ch>, Richard Cochran <richardcochran@gmail.com>, Conor Dooley <conor+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Rob Herring <robh+dt@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>, Eric Dumazet <edumazet@google.com>, "David S. Miller" <davem@davemloft.net>, MD Danish Anwar <danishanwar@ti.com> CC: <nm@ti.com>, <srk@ti.com>, <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>, <netdev@vger.kernel.org>, <linux-omap@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org> Subject: [PATCH v2 0/5] Introduce IEP driver and packet timestamping support Date: Mon, 7 Aug 2023 16:30:43 +0530 Message-ID: <20230807110048.2611456-1-danishanwar@ti.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_PASS,SPF_PASS 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: 1773572648294788238 X-GMAIL-MSGID: 1773572648294788238 |
Series |
Introduce IEP driver and packet timestamping support
|
|
Message
MD Danish Anwar
Aug. 7, 2023, 11 a.m. UTC
This series introduces Industrial Ethernet Peripheral (IEP) driver to support timestamping of ethernet packets and thus support PTP and PPS for PRU ICSSG ethernet ports. This series also adds 10M full duplex support for ICSSG ethernet driver. There are two IEP instances. IEP0 is used for packet timestamping while IEP1 is used for 10M full duplex support. This is v2 of the series [v1]. It addresses comments made on [v1]. This series is based on linux-next(#next-20230807). Changes from v1 to v2: *) Addressed Simon's comment to fix reverse xmas tree declaration. Some APIs in patch 3 and 4 were not following reverse xmas tree variable declaration. Fixed it in this version. *) Addressed Conor's comments and removed unsupported SoCs from compatible comment in patch 1. *) Addded patch 2 which was not part of v1. Patch 2, adds IEP node to dt bindings for ICSSG. [v1] https://lore.kernel.org/all/20230803110153.3309577-1-danishanwar@ti.com/ Thanks and Regards, Md Danish Anwar Grygorii Strashko (1): net: ti: icssg-prueth: am65x SR2.0 add 10M full duplex support MD Danish Anwar (1): dt-bindings: net: Add iep node in ICSSG driver dt binding Md Danish Anwar (1): dt-bindings: net: Add ICSS IEP Roger Quadros (2): net: ti: icss-iep: Add IEP driver net: ti: icssg-prueth: add packet timestamping and ptp support .../devicetree/bindings/net/ti,icss-iep.yaml | 37 + .../bindings/net/ti,icssg-prueth.yaml | 7 + drivers/net/ethernet/ti/Kconfig | 12 + drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/icssg/icss_iep.c | 961 ++++++++++++++++++ drivers/net/ethernet/ti/icssg/icss_iep.h | 41 + drivers/net/ethernet/ti/icssg/icssg_config.c | 6 + drivers/net/ethernet/ti/icssg/icssg_ethtool.c | 21 + drivers/net/ethernet/ti/icssg/icssg_prueth.c | 433 +++++++- drivers/net/ethernet/ti/icssg/icssg_prueth.h | 28 +- 10 files changed, 1540 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/ti,icss-iep.yaml create mode 100644 drivers/net/ethernet/ti/icssg/icss_iep.c create mode 100644 drivers/net/ethernet/ti/icssg/icss_iep.h
Comments
On Mon, Aug 07, 2023 at 04:30:43PM +0530, MD Danish Anwar wrote: > This series introduces Industrial Ethernet Peripheral (IEP) driver to > support timestamping of ethernet packets and thus support PTP and PPS > for PRU ICSSG ethernet ports. > > This series also adds 10M full duplex support for ICSSG ethernet driver. > > There are two IEP instances. IEP0 is used for packet timestamping while IEP1 > is used for 10M full duplex support. > > This is v2 of the series [v1]. It addresses comments made on [v1]. > This series is based on linux-next(#next-20230807). > > Changes from v1 to v2: > *) Addressed Simon's comment to fix reverse xmas tree declaration. Some APIs > in patch 3 and 4 were not following reverse xmas tree variable declaration. > Fixed it in this version. > *) Addressed Conor's comments and removed unsupported SoCs from compatible > comment in patch 1. I'm sorry I missed responding there before you sent v2, it was a bank holiday yesterday. I'm curious why you removed them, rather than just added them with a fallback to the ti,am654-icss-iep compatible, given your comment that "the same compatible currently works for all these 3 SoCs". Thanks, Conor. > *) Addded patch 2 which was not part of v1. Patch 2, adds IEP node to dt > bindings for ICSSG. > > [v1] https://lore.kernel.org/all/20230803110153.3309577-1-danishanwar@ti.com/ > > Thanks and Regards, > Md Danish Anwar > > Grygorii Strashko (1): > net: ti: icssg-prueth: am65x SR2.0 add 10M full duplex support > > MD Danish Anwar (1): > dt-bindings: net: Add iep node in ICSSG driver dt binding > > Md Danish Anwar (1): > dt-bindings: net: Add ICSS IEP > > Roger Quadros (2): > net: ti: icss-iep: Add IEP driver > net: ti: icssg-prueth: add packet timestamping and ptp support > > .../devicetree/bindings/net/ti,icss-iep.yaml | 37 + > .../bindings/net/ti,icssg-prueth.yaml | 7 + > drivers/net/ethernet/ti/Kconfig | 12 + > drivers/net/ethernet/ti/Makefile | 1 + > drivers/net/ethernet/ti/icssg/icss_iep.c | 961 ++++++++++++++++++ > drivers/net/ethernet/ti/icssg/icss_iep.h | 41 + > drivers/net/ethernet/ti/icssg/icssg_config.c | 6 + > drivers/net/ethernet/ti/icssg/icssg_ethtool.c | 21 + > drivers/net/ethernet/ti/icssg/icssg_prueth.c | 433 +++++++- > drivers/net/ethernet/ti/icssg/icssg_prueth.h | 28 +- > 10 files changed, 1540 insertions(+), 7 deletions(-) > create mode 100644 Documentation/devicetree/bindings/net/ti,icss-iep.yaml > create mode 100644 drivers/net/ethernet/ti/icssg/icss_iep.c > create mode 100644 drivers/net/ethernet/ti/icssg/icss_iep.h > > -- > 2.34.1 >
On 08/08/23 5:38 pm, Conor Dooley wrote: > On Mon, Aug 07, 2023 at 04:30:43PM +0530, MD Danish Anwar wrote: >> This series introduces Industrial Ethernet Peripheral (IEP) driver to >> support timestamping of ethernet packets and thus support PTP and PPS >> for PRU ICSSG ethernet ports. >> >> This series also adds 10M full duplex support for ICSSG ethernet driver. >> >> There are two IEP instances. IEP0 is used for packet timestamping while IEP1 >> is used for 10M full duplex support. >> >> This is v2 of the series [v1]. It addresses comments made on [v1]. >> This series is based on linux-next(#next-20230807). >> >> Changes from v1 to v2: >> *) Addressed Simon's comment to fix reverse xmas tree declaration. Some APIs >> in patch 3 and 4 were not following reverse xmas tree variable declaration. >> Fixed it in this version. >> *) Addressed Conor's comments and removed unsupported SoCs from compatible >> comment in patch 1. > > I'm sorry I missed responding there before you sent v2, it was a bank > holiday yesterday. I'm curious why you removed them, rather than just > added them with a fallback to the ti,am654-icss-iep compatible, given > your comment that "the same compatible currently works for all these > 3 SoCs". I removed them as currently the driver is being upstreamed only for AM654x, once I start up-streaming the ICSSG driver for AM64 and any other SoC. I will add them here. If at that time we are still using same compatible, then I will modify the comment otherwise add new compatible. As of now, I don't see the need of adding other SoCs in iep binding as IEP driver up-streaming is only planned for AM654x as of now. > > Thanks, > Conor. > >> *) Addded patch 2 which was not part of v1. Patch 2, adds IEP node to dt >> bindings for ICSSG. >> >> [v1] https://lore.kernel.org/all/20230803110153.3309577-1-danishanwar@ti.com/ >> >> Thanks and Regards, >> Md Danish Anwar >> >> Grygorii Strashko (1): >> net: ti: icssg-prueth: am65x SR2.0 add 10M full duplex support >> >> MD Danish Anwar (1): >> dt-bindings: net: Add iep node in ICSSG driver dt binding >> >> Md Danish Anwar (1): >> dt-bindings: net: Add ICSS IEP >> >> Roger Quadros (2): >> net: ti: icss-iep: Add IEP driver >> net: ti: icssg-prueth: add packet timestamping and ptp support >> >> .../devicetree/bindings/net/ti,icss-iep.yaml | 37 + >> .../bindings/net/ti,icssg-prueth.yaml | 7 + >> drivers/net/ethernet/ti/Kconfig | 12 + >> drivers/net/ethernet/ti/Makefile | 1 + >> drivers/net/ethernet/ti/icssg/icss_iep.c | 961 ++++++++++++++++++ >> drivers/net/ethernet/ti/icssg/icss_iep.h | 41 + >> drivers/net/ethernet/ti/icssg/icssg_config.c | 6 + >> drivers/net/ethernet/ti/icssg/icssg_ethtool.c | 21 + >> drivers/net/ethernet/ti/icssg/icssg_prueth.c | 433 +++++++- >> drivers/net/ethernet/ti/icssg/icssg_prueth.h | 28 +- >> 10 files changed, 1540 insertions(+), 7 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/net/ti,icss-iep.yaml >> create mode 100644 drivers/net/ethernet/ti/icssg/icss_iep.c >> create mode 100644 drivers/net/ethernet/ti/icssg/icss_iep.h >> >> -- >> 2.34.1 >>
On 08/08/2023 15:18, Md Danish Anwar wrote: > On 08/08/23 5:38 pm, Conor Dooley wrote: >> On Mon, Aug 07, 2023 at 04:30:43PM +0530, MD Danish Anwar wrote: >>> This series introduces Industrial Ethernet Peripheral (IEP) driver to >>> support timestamping of ethernet packets and thus support PTP and PPS >>> for PRU ICSSG ethernet ports. >>> >>> This series also adds 10M full duplex support for ICSSG ethernet driver. >>> >>> There are two IEP instances. IEP0 is used for packet timestamping while IEP1 >>> is used for 10M full duplex support. >>> >>> This is v2 of the series [v1]. It addresses comments made on [v1]. >>> This series is based on linux-next(#next-20230807). >>> >>> Changes from v1 to v2: >>> *) Addressed Simon's comment to fix reverse xmas tree declaration. Some APIs >>> in patch 3 and 4 were not following reverse xmas tree variable declaration. >>> Fixed it in this version. >>> *) Addressed Conor's comments and removed unsupported SoCs from compatible >>> comment in patch 1. >> >> I'm sorry I missed responding there before you sent v2, it was a bank >> holiday yesterday. I'm curious why you removed them, rather than just >> added them with a fallback to the ti,am654-icss-iep compatible, given >> your comment that "the same compatible currently works for all these >> 3 SoCs". > > I removed them as currently the driver is being upstreamed only for AM654x, > once I start up-streaming the ICSSG driver for AM64 and any other SoC. I will > add them here. If at that time we are still using same compatible, then I will > modify the comment otherwise add new compatible. > > As of now, I don't see the need of adding other SoCs in iep binding as IEP > driver up-streaming is only planned for AM654x as of now. But, is there any difference in IEP hardware/driver for the other SoCs? AFAIK the same IP is used on all SoCs. If there is no hardware/code change then we don't need to introduce a new compatible. The comment for all SoCs can already be there right from the start.
On 08/08/23 5:52 pm, Roger Quadros wrote: > > > On 08/08/2023 15:18, Md Danish Anwar wrote: >> On 08/08/23 5:38 pm, Conor Dooley wrote: >>> On Mon, Aug 07, 2023 at 04:30:43PM +0530, MD Danish Anwar wrote: >>>> This series introduces Industrial Ethernet Peripheral (IEP) driver to >>>> support timestamping of ethernet packets and thus support PTP and PPS >>>> for PRU ICSSG ethernet ports. >>>> >>>> This series also adds 10M full duplex support for ICSSG ethernet driver. >>>> >>>> There are two IEP instances. IEP0 is used for packet timestamping while IEP1 >>>> is used for 10M full duplex support. >>>> >>>> This is v2 of the series [v1]. It addresses comments made on [v1]. >>>> This series is based on linux-next(#next-20230807). >>>> >>>> Changes from v1 to v2: >>>> *) Addressed Simon's comment to fix reverse xmas tree declaration. Some APIs >>>> in patch 3 and 4 were not following reverse xmas tree variable declaration. >>>> Fixed it in this version. >>>> *) Addressed Conor's comments and removed unsupported SoCs from compatible >>>> comment in patch 1. >>> >>> I'm sorry I missed responding there before you sent v2, it was a bank >>> holiday yesterday. I'm curious why you removed them, rather than just >>> added them with a fallback to the ti,am654-icss-iep compatible, given >>> your comment that "the same compatible currently works for all these >>> 3 SoCs". >> >> I removed them as currently the driver is being upstreamed only for AM654x, >> once I start up-streaming the ICSSG driver for AM64 and any other SoC. I will >> add them here. If at that time we are still using same compatible, then I will >> modify the comment otherwise add new compatible. >> >> As of now, I don't see the need of adding other SoCs in iep binding as IEP >> driver up-streaming is only planned for AM654x as of now. > > But, is there any difference in IEP hardware/driver for the other SoCs? > AFAIK the same IP is used on all SoCs. > > If there is no hardware/code change then we don't need to introduce a new compatible. > The comment for all SoCs can already be there right from the start. > There is no code change. The same compatible is used for other SoCs. Even if the code is same I was thinking to keep the compatible as below now - ti,am654-icss-iep # for K3 AM65x SoCs and once other SoCs are introduced, I will just modify the comment, - ti,am654-icss-iep # for K3 AM65x, AM64x SoCs But we can also keep the all SoCs in comment right from start as well. I am fine with both. Conor / Roger, Please let me know which approach should I go with in next revision?
On Tue, Aug 08, 2023 at 06:06:11PM +0530, Md Danish Anwar wrote: > On 08/08/23 5:52 pm, Roger Quadros wrote: > > > > > > On 08/08/2023 15:18, Md Danish Anwar wrote: > >> On 08/08/23 5:38 pm, Conor Dooley wrote: > >>> On Mon, Aug 07, 2023 at 04:30:43PM +0530, MD Danish Anwar wrote: > >>>> This series introduces Industrial Ethernet Peripheral (IEP) driver to > >>>> support timestamping of ethernet packets and thus support PTP and PPS > >>>> for PRU ICSSG ethernet ports. > >>>> > >>>> This series also adds 10M full duplex support for ICSSG ethernet driver. > >>>> > >>>> There are two IEP instances. IEP0 is used for packet timestamping while IEP1 > >>>> is used for 10M full duplex support. > >>>> > >>>> This is v2 of the series [v1]. It addresses comments made on [v1]. > >>>> This series is based on linux-next(#next-20230807). > >>>> > >>>> Changes from v1 to v2: > >>>> *) Addressed Simon's comment to fix reverse xmas tree declaration. Some APIs > >>>> in patch 3 and 4 were not following reverse xmas tree variable declaration. > >>>> Fixed it in this version. > >>>> *) Addressed Conor's comments and removed unsupported SoCs from compatible > >>>> comment in patch 1. > >>> > >>> I'm sorry I missed responding there before you sent v2, it was a bank > >>> holiday yesterday. I'm curious why you removed them, rather than just > >>> added them with a fallback to the ti,am654-icss-iep compatible, given > >>> your comment that "the same compatible currently works for all these > >>> 3 SoCs". > >> > >> I removed them as currently the driver is being upstreamed only for AM654x, > >> once I start up-streaming the ICSSG driver for AM64 and any other SoC. I will > >> add them here. If at that time we are still using same compatible, then I will > >> modify the comment otherwise add new compatible. > >> > >> As of now, I don't see the need of adding other SoCs in iep binding as IEP > >> driver up-streaming is only planned for AM654x as of now. > > > > But, is there any difference in IEP hardware/driver for the other SoCs? > > AFAIK the same IP is used on all SoCs. > > > > If there is no hardware/code change then we don't need to introduce a new compatible. > > The comment for all SoCs can already be there right from the start. > > > > There is no code change. The same compatible is used for other SoCs. Even if > the code is same I was thinking to keep the compatible as below now > > - ti,am654-icss-iep # for K3 AM65x SoCs > > and once other SoCs are introduced, I will just modify the comment, > > - ti,am654-icss-iep # for K3 AM65x, AM64x SoCs > > But we can also keep the all SoCs in comment right from start as well. I am > fine with both. > Conor / Roger, Please let me know which approach should I go with in next revision? IMO, "ti,am564-icss-iep" goes in the driver and the other SoCs get specific compatibles in the binding with "ti,am564-icss-iep" as a fallback.
On 08/08/23 6:15 pm, Conor Dooley wrote: > On Tue, Aug 08, 2023 at 06:06:11PM +0530, Md Danish Anwar wrote: >> On 08/08/23 5:52 pm, Roger Quadros wrote: >>> >>> >>> On 08/08/2023 15:18, Md Danish Anwar wrote: >>>> On 08/08/23 5:38 pm, Conor Dooley wrote: >>>>> On Mon, Aug 07, 2023 at 04:30:43PM +0530, MD Danish Anwar wrote: >>>>>> This series introduces Industrial Ethernet Peripheral (IEP) driver to >>>>>> support timestamping of ethernet packets and thus support PTP and PPS >>>>>> for PRU ICSSG ethernet ports. >>>>>> >>>>>> This series also adds 10M full duplex support for ICSSG ethernet driver. >>>>>> >>>>>> There are two IEP instances. IEP0 is used for packet timestamping while IEP1 >>>>>> is used for 10M full duplex support. >>>>>> >>>>>> This is v2 of the series [v1]. It addresses comments made on [v1]. >>>>>> This series is based on linux-next(#next-20230807). >>>>>> >>>>>> Changes from v1 to v2: >>>>>> *) Addressed Simon's comment to fix reverse xmas tree declaration. Some APIs >>>>>> in patch 3 and 4 were not following reverse xmas tree variable declaration. >>>>>> Fixed it in this version. >>>>>> *) Addressed Conor's comments and removed unsupported SoCs from compatible >>>>>> comment in patch 1. >>>>> >>>>> I'm sorry I missed responding there before you sent v2, it was a bank >>>>> holiday yesterday. I'm curious why you removed them, rather than just >>>>> added them with a fallback to the ti,am654-icss-iep compatible, given >>>>> your comment that "the same compatible currently works for all these >>>>> 3 SoCs". >>>> >>>> I removed them as currently the driver is being upstreamed only for AM654x, >>>> once I start up-streaming the ICSSG driver for AM64 and any other SoC. I will >>>> add them here. If at that time we are still using same compatible, then I will >>>> modify the comment otherwise add new compatible. >>>> >>>> As of now, I don't see the need of adding other SoCs in iep binding as IEP >>>> driver up-streaming is only planned for AM654x as of now. >>> >>> But, is there any difference in IEP hardware/driver for the other SoCs? >>> AFAIK the same IP is used on all SoCs. >>> >>> If there is no hardware/code change then we don't need to introduce a new compatible. >>> The comment for all SoCs can already be there right from the start. >>> >> >> There is no code change. The same compatible is used for other SoCs. Even if >> the code is same I was thinking to keep the compatible as below now >> >> - ti,am654-icss-iep # for K3 AM65x SoCs >> >> and once other SoCs are introduced, I will just modify the comment, >> >> - ti,am654-icss-iep # for K3 AM65x, AM64x SoCs >> >> But we can also keep the all SoCs in comment right from start as well. I am >> fine with both. > >> Conor / Roger, Please let me know which approach should I go with in next revision? > > IMO, "ti,am564-icss-iep" goes in the driver and the other SoCs get > specific compatibles in the binding with "ti,am564-icss-iep" as a > fallback. Sure. Then as for now, "ti,am654-icss-iep" goes in the driver, I will keep the dt binding compatible as below (as it was earlier in v1.) - ti,am654-icss-iep # for K3 AM65x, J721E and AM64x SoCs When new SoCs are introduced I can add specific bindings for them with "ti,am654-icss-iep" being the fallback.
Hi Conor, On 09/08/23 10:31 am, Md Danish Anwar wrote: > On 08/08/23 6:15 pm, Conor Dooley wrote: >> On Tue, Aug 08, 2023 at 06:06:11PM +0530, Md Danish Anwar wrote: >>> On 08/08/23 5:52 pm, Roger Quadros wrote: >>>> >>>> >>>> On 08/08/2023 15:18, Md Danish Anwar wrote: >>>>> On 08/08/23 5:38 pm, Conor Dooley wrote: >>>>>> On Mon, Aug 07, 2023 at 04:30:43PM +0530, MD Danish Anwar wrote: >>>>>>> This series introduces Industrial Ethernet Peripheral (IEP) driver to >>>>>>> support timestamping of ethernet packets and thus support PTP and PPS >>>>>>> for PRU ICSSG ethernet ports. >>>>>>> >>>>>>> This series also adds 10M full duplex support for ICSSG ethernet driver. >>>>>>> >>>>>>> There are two IEP instances. IEP0 is used for packet timestamping while IEP1 >>>>>>> is used for 10M full duplex support. >>>>>>> >>>>>>> This is v2 of the series [v1]. It addresses comments made on [v1]. >>>>>>> This series is based on linux-next(#next-20230807). >>>>>>> >>>>>>> Changes from v1 to v2: >>>>>>> *) Addressed Simon's comment to fix reverse xmas tree declaration. Some APIs >>>>>>> in patch 3 and 4 were not following reverse xmas tree variable declaration. >>>>>>> Fixed it in this version. >>>>>>> *) Addressed Conor's comments and removed unsupported SoCs from compatible >>>>>>> comment in patch 1. >>>>>> >>>>>> I'm sorry I missed responding there before you sent v2, it was a bank >>>>>> holiday yesterday. I'm curious why you removed them, rather than just >>>>>> added them with a fallback to the ti,am654-icss-iep compatible, given >>>>>> your comment that "the same compatible currently works for all these >>>>>> 3 SoCs". >>>>> >>>>> I removed them as currently the driver is being upstreamed only for AM654x, >>>>> once I start up-streaming the ICSSG driver for AM64 and any other SoC. I will >>>>> add them here. If at that time we are still using same compatible, then I will >>>>> modify the comment otherwise add new compatible. >>>>> >>>>> As of now, I don't see the need of adding other SoCs in iep binding as IEP >>>>> driver up-streaming is only planned for AM654x as of now. >>>> >>>> But, is there any difference in IEP hardware/driver for the other SoCs? >>>> AFAIK the same IP is used on all SoCs. >>>> >>>> If there is no hardware/code change then we don't need to introduce a new compatible. >>>> The comment for all SoCs can already be there right from the start. >>>> >>> >>> There is no code change. The same compatible is used for other SoCs. Even if >>> the code is same I was thinking to keep the compatible as below now >>> >>> - ti,am654-icss-iep # for K3 AM65x SoCs >>> >>> and once other SoCs are introduced, I will just modify the comment, >>> >>> - ti,am654-icss-iep # for K3 AM65x, AM64x SoCs >>> >>> But we can also keep the all SoCs in comment right from start as well. I am >>> fine with both. >> >>> Conor / Roger, Please let me know which approach should I go with in next revision? >> >> IMO, "ti,am564-icss-iep" goes in the driver and the other SoCs get >> specific compatibles in the binding with "ti,am564-icss-iep" as a >> fallback. > > Sure. Then as for now, "ti,am654-icss-iep" goes in the driver, I will keep the > dt binding compatible as below (as it was earlier in v1.) > > - ti,am654-icss-iep # for K3 AM65x, J721E and AM64x SoCs > > When new SoCs are introduced I can add specific bindings for them with > "ti,am654-icss-iep" being the fallback. > I checked internally and IEP hardware / driver is same across all TI K3 SoCs. Compatible "ti,am654-icss-iep" will be same for all SoCs. I don't think we need to introduce different compatibles for different SoCs in future as they will be using same hardware / driver. For now I will have below as compatible in dt bindings. This will not change in future. When new SoCs are added, they can just use this compatible itself. The driver will always use "ti,am654-icss-iep" as compatible. - ti,am654-icss-iep # for all TI K3 SoCs