Received: by 2002:a05:7412:2a91:b0:fc:a2b0:25d7 with SMTP id u17csp731152rdh; Wed, 14 Feb 2024 09:36:35 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUW7UX/BnQ9b1R1WAxZAQ/sHFhmmwP/6Ur/HI/R2vVgXVhRLHi0Zm4Xd4gkuh2+3L2vbdZIqgqMzvigqitoByzaR80M86d5nJxM2hblRA== X-Google-Smtp-Source: AGHT+IFMS/mYYgqKZp/h1r4Lk7expdqatSSfVAhx1cvMHTUiqyLQnE6cIKLDznf3F5A1UzaARfhB X-Received: by 2002:a17:902:b909:b0:1d6:fe11:2642 with SMTP id bf9-20020a170902b90900b001d6fe112642mr2936891plb.27.1707932194936; Wed, 14 Feb 2024 09:36:34 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707932194; cv=pass; d=google.com; s=arc-20160816; b=QOwapY9SOaVAb8Gbj6Ja9xUFINvlnUGW550xHeJBiWRDkxyOh5rYXTqGmFCte9t00P Y/I31mPHS0j6/yf+gsj6+3Z1icHS7/kd69y8zrskwFtBqH+/w4D6JxUCmYAhcFnv4qPo cE36Oseoj+xalnhi1aUmNCuUMu+aHjEJHrpI77sElAfo2vAVQ4+S+3JtbB6d8rJbtgMX 9jfHBt/AgrFvFi58F3Wd9T/3inKTSYknogfHQhf7fK9nkBnw0wx2KBS2WXuFZjfy/jvf /u3P+cRTnoIs1DHVO9026IoPxkY8PbOHwvsZpDEB2OxUlfyPBIYWWFTdAKqKxxgQkhou 93hA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:subject:cc:to:from :date:dkim-signature; bh=PYG21NIF2mZ8YOFYjvrjoRGJLggOuhkjBMy4PNTv6FI=; fh=s2WaEhZJPQrsXscAc82EeVqqLPQlIA10Bte0EdFcJR8=; b=PsZyLcZK348KUgx2VkZRJkau4zSXTNu9dLs98g5tyj2RNse58rSXwvhjJ0PVYl3UCB 6vIX3jeh2QN5h37xE+GexvAURGW5VJIGrPxMOvNHLGdkzbm4Xl2NPCLvQ6zK63Kf0OFZ penhgR8k+5XS89ZtPwJjsS+J4G+ntaVsVwtoF7qw+YwRGqOplv/6ae/VsMSrSMOs2n6e /P+PT23KNtIkesdraV75ToLYTXhqz6E0XjOsxthdSmjZl/kWRofRCiSvs+a3DECJRt1h vrSICUaDJk47JPthDGRcB/Cb6FNJLdjamkE4OxiBOHe0N4BIhaUtHwUnMcbfy5yQM+FQ lZNQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Z3PYMsdV; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-65679-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-65679-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Forwarded-Encrypted: i=2; AJvYcCVE5A3PJXMa0jY2Jm5HNfGn7Xdu2SopBsMmD7jHHokRVHc7mGosNKlDwiaoRrd7O6haSNtDwSWaFO5Tw4TvbvfDu9PS8bSe0kee3ioQ8Q== Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id t6-20020a170902e84600b001d783acb2bfsi4098186plg.363.2024.02.14.09.36.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Feb 2024 09:36:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-65679-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Z3PYMsdV; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-65679-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-65679-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id BA533287265 for ; Wed, 14 Feb 2024 17:31:26 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 20CFD86652; Wed, 14 Feb 2024 17:28:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z3PYMsdV" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D26957C0BF; Wed, 14 Feb 2024 17:28:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707931733; cv=none; b=V9W83z5EFU1tx0HHxe1uGsW0Eq6Lk/0r4Pp0LgXHgrQAlYFU2O2R2ItGgjHmJzrWeIfiWO5fCVYRXdWBJsnr07lKDIzbgu57dmVolUhTNdEKIudjDiSQLzasrcO/LRtybyuU5ujUDrwl8o5skP7anAy5k8Quw0N7C5aCLSYoCcY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707931733; c=relaxed/simple; bh=z/Z3tUAhkNPM1isKp5PxN2lNkWklpFN1TdodOMmS8Fo=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=XP4rYTXdGhVtsIwNGVsa6jVXhnY9VM21gtsIXTOt/NEbS+TYsM8I2CKjqYWcXztBmtFF6zL7dW3imLsn4b2J9EEtDJKUbDZA/jO0tqgOCUEFDzV1eaRVu7zBeh80CqLe7iRkgN/RoqC9np+NhyrX9JfK5PLVwwUehlLl78zGKkE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z3PYMsdV; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28C8FC433F1; Wed, 14 Feb 2024 17:28:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707931733; bh=z/Z3tUAhkNPM1isKp5PxN2lNkWklpFN1TdodOMmS8Fo=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=Z3PYMsdVlDSq8wn9D611pcLUcO29LG0YdLKdDPDkPLb0wGbxZ8Iql6JKonfStLOZm mysp/+4SEys+bCmXCBrujjpUbzu3NvPg+G8H282PtGTamEIsr9oqx8pVkFqWU2XANS Tm2uP7GybEG09qzknssirkrAT6oJgEBAOaPtPK7HCiUOC6Si23j1BQnw5qhvQM4ZGp B3vsLjF+UfhIDECpBeZCdpH4oXGbaDOdqU08bodZwaGMKjjl+s9L6xcgA52mbl5Wap vhyzXFHHS4rFXoCzFMaqYq7gYYEEvUif/xAhJXnDs25IEhomFqKgRB52dPabeF9ALv oE4ZY/2Q2lvKg== Date: Wed, 14 Feb 2024 11:28:51 -0600 From: Bjorn Helgaas To: Sai Krishna Cc: bhelgaas@google.com, linux-pci@vger.kernel.org, richardcochran@gmail.com, horms@kernel.org, vinicius.gomes@intel.com, vadim.fedorenko@linux.dev, davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, sgoutham@marvell.com, gakula@marvell.com, lcherian@marvell.com, hkelam@marvell.com, sbhatta@marvell.com, Naveen Mamindlapalli Subject: Re: [net-next PATCH v2] octeontx2: Add PTP clock driver for Octeon PTM clock. Message-ID: <20240214172851.GA1258497@bhelgaas> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240214130853.1321836-1-saikrishnag@marvell.com> On Wed, Feb 14, 2024 at 06:38:53PM +0530, Sai Krishna wrote: > The PCIe PTM(Precision time measurement) protocol provides precise > coordination of events across multiple components like PCIe host > clock, PCIe EP PHC local clocks of PCIe devices. This patch adds > support for ptp clock based PTM clock. We can use this PTP device > to sync the PTM time with CLOCK_REALTIME or other PTP PHC > devices using phc2sys. s/PTM(/PTM (/ # space before open paren is conventional as in file comment s/ptp/PTP/ # not sure if you intend "ptp" to be different from "PTP"? Perhaps expand "PTP"? I guess it must be "Precision Time Protocol", which obviously would be well-known to all clock people since it's in "drivers/ptp/" :) > Signed-off-by: Sai Krishna > Signed-off-by: Naveen Mamindlapalli > Signed-off-by: Sunil Kovvuri Goutham Strictly speaking, I think the sender's Signed-off-by should be last here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=v6.6#n396 > --- > v2: > - Addressed review comments given by Vadim Fedorenko, Vinicius, Simon Horman > 1. Driver build restricted to ARM64 and COMPILE_TEST+64BIT > 2. Fixed Sparse complaints by using readq/writeq like else where > 3. Modified error conditions, clode cleanup > 4. Forwarding to linux-pci maintainers as suggested by Jakub > > drivers/ptp/Kconfig | 11 ++ > drivers/ptp/Makefile | 1 + > drivers/ptp/ptp_octeon_ptm.c | 243 +++++++++++++++++++++++++++++++++++ > 3 files changed, 255 insertions(+) > create mode 100644 drivers/ptp/ptp_octeon_ptm.c > > diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig > index 604541dcb320..3256b12842a6 100644 > --- a/drivers/ptp/Kconfig > +++ b/drivers/ptp/Kconfig > @@ -224,4 +224,15 @@ config PTP_DFL_TOD > To compile this driver as a module, choose M here: the module > will be called ptp_dfl_tod. > > +config PTP_CLOCK_OCTEON > + tristate "OCTEON PTM PTP clock" > + depends on PTP_1588_CLOCK I guess this can't even be compile-tested without PTP_1588_CLOCK? Some subsystems supply stubs to allow compile testing even when the subsystem is not enabled, but maybe ptp does not. > + depends on (64BIT && COMPILE_TEST) || ARM64 Why the 64BIT dependency? Is it not even compile-testable without it? > + default n > + help > + This driver adds support for using Octeon PTM device clock as > + a PTP clock. Another possible place to expand PTM and/or PTP. > + To compile this driver as a module, choose M here: the module > + will be called ptp_octeon_ptm. > endmenu > diff --git a/drivers/ptp/Makefile b/drivers/ptp/Makefile > index 68bf02078053..19e2ab4c7f1b 100644 > --- a/drivers/ptp/Makefile > +++ b/drivers/ptp/Makefile > @@ -21,3 +21,4 @@ obj-$(CONFIG_PTP_1588_CLOCK_MOCK) += ptp_mock.o > obj-$(CONFIG_PTP_1588_CLOCK_VMW) += ptp_vmw.o > obj-$(CONFIG_PTP_1588_CLOCK_OCP) += ptp_ocp.o > obj-$(CONFIG_PTP_DFL_TOD) += ptp_dfl_tod.o > +obj-$(CONFIG_PTP_CLOCK_OCTEON) += ptp_octeon_ptm.o > diff --git a/drivers/ptp/ptp_octeon_ptm.c b/drivers/ptp/ptp_octeon_ptm.c > new file mode 100644 > index 000000000000..6867c1d28f17 > --- /dev/null > +++ b/drivers/ptp/ptp_octeon_ptm.c > @@ -0,0 +1,243 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* Marvell PTP PHC clock driver for PCIe PTM (Precision Time Measurement) EP > + * > + * Copyright (c) 2024 Marvell. > + * Spurious blank line. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#include "ptp_private.h" > + > +#define PEMX_PFX_CSX_PFCFGX(pem, pf, _offset) ({typeof(_offset) (offset) = (_offset); \ > + ((0x8e0000008000 | (u64)(pem) << 36 \ > + | (pf) << 18 \ > + | (((offset) >> 16) & 1) << 16 \ > + | ((offset) >> 3) << 3) \ > + + ((((offset) >> 2) & 1) << 2)); }) > + > +#define PEMX_CFG_WR(a) (0x8E0000000018ull | (u64)(a) << 36) > +#define PEMX_CFG_RD(a) (0x8E0000000020ull | (u64)(a) << 36) > + > +/* Octeon CSRs */ > +#define PEMX_CFG 0x8e00000000d8ULL > +#define PEMX_PTM_CTL 0x8e0000000098ULL > +#define PEMX_PTM_CTL_CAP BIT_ULL(10) > +#define PEMX_PTM_LCL_TIME 0x8e00000000a0ULL /* PTM time */ > +#define PEMX_PTM_MAS_TIME 0x8e00000000a8ULL /* PTP time */ > + > +struct oct_ptp_clock { > + struct ptp_clock *ptp_clock; > + struct ptp_clock_info caps; > + bool cn10k_variant; > +}; > + > +static struct oct_ptp_clock oct_ptp_clock; > +static void __iomem *ptm_ctl_addr; > +static void __iomem *ptm_lcl_addr; > + > +/* Config space registers */ Spurious spaces at end of comment. > +#define PCIEEPX_PTM_REQ_STAT (oct_ptp_clock.cn10k_variant ? 0x3a8 : 0x474) > +#define PCIEEPX_PTM_REQ_T1L (oct_ptp_clock.cn10k_variant ? 0x3b4 : 0x480) > +#define PCIEEPX_PTM_REQ_T1M (oct_ptp_clock.cn10k_variant ? 0x3b8 : 0x484) > +#define PCIEEPX_PTM_REQ_T4L (oct_ptp_clock.cn10k_variant ? 0x3c4 : 0x490) > +#define PCIEEPX_PTM_REQ_T4M (oct_ptp_clock.cn10k_variant ? 0x3c8 : 0x494) > + > +#define PCI_VENDOR_ID_CAVIUM 0x177d > +#define PCI_DEVID_OCTEONTX2_PTP 0xA00C > +#define PCI_SUBSYS_DEVID_95XX 0xB300 > +#define PCI_SUBSYS_DEVID_95XXN 0xB400 > +#define PCI_SUBSYS_DEVID_95XXMM 0xB500 > +#define PCI_SUBSYS_DEVID_96XX 0xB200 > +#define PCI_SUBSYS_DEVID_98XX 0xB100 > +#define PCI_SUBSYS_DEVID_CN10K_A 0xB900 > +#define PCI_SUBSYS_DEVID_CN10K_B 0xBD00 > +#define PCI_SUBSYS_DEVID_CNF10K_A 0xBA00 > +#define PCI_SUBSYS_DEVID_CNF10K_B 0xBC00 Random mixture of upper-case and lower-case hex above. Also random usage of "ull" vs "ULL". > +static bool is_otx2_support_ptm(struct pci_dev *pdev) > +{ > + return (pdev->subsystem_device == PCI_SUBSYS_DEVID_96XX || > + pdev->subsystem_device == PCI_SUBSYS_DEVID_95XX || > + pdev->subsystem_device == PCI_SUBSYS_DEVID_95XXN || > + pdev->subsystem_device == PCI_SUBSYS_DEVID_98XX || > + pdev->subsystem_device == PCI_SUBSYS_DEVID_95XXMM); > +} > + > +static bool is_cn10k_support_ptm(struct pci_dev *pdev) > +{ > + return (pdev->subsystem_device == PCI_SUBSYS_DEVID_CN10K_A || > + pdev->subsystem_device == PCI_SUBSYS_DEVID_CNF10K_A || > + pdev->subsystem_device == PCI_SUBSYS_DEVID_CN10K_B || > + pdev->subsystem_device == PCI_SUBSYS_DEVID_CNF10K_B); > +} > + > +static int ptp_oct_ptm_adjtime(struct ptp_clock_info *ptp, s64 delta) > +{ > + return -EOPNOTSUPP; > +} > + > +static int ptp_oct_ptm_settime(struct ptp_clock_info *ptp, > + const struct timespec64 *ts) > +{ > + return -EOPNOTSUPP; > +} > + > +static u32 read_pcie_config32(int ep_pem, int cfg_addr) > +{ > + void __iomem *addr; > + u64 val; > + > + if (oct_ptp_clock.cn10k_variant) { > + addr = ioremap(PEMX_PFX_CSX_PFCFGX(ep_pem, 0, cfg_addr), 8); These ioremap()s look like things that should be done at probe-time and retained for the life of the module since (I assume) this will be called many times. > + if (!addr) { > + pr_err("PTM_EP: Failed to ioremap Octeon CSR space\n"); > + return -1U; > + } > + val = readl(addr); > + iounmap(addr); > + } else { > + addr = ioremap(PEMX_CFG_RD(ep_pem), 8); > + if (!addr) { > + pr_err("PTM_EP: Failed to ioremap Octeon CSR space\n"); > + return -1U; > + } > + val = ((1 << 15) | (cfg_addr & 0xfff)); > + writeq(val, addr); > + val = readq(addr) >> 32; > + iounmap(addr); > + } > + return (val & 0xffffffff); > +} > + > +static uint64_t octeon_csr_read(u64 csr_addr) > +{ > + void __iomem *addr; > + u64 val; > + > + addr = ioremap(csr_addr, 8); > + if (!addr) { > + pr_err("PTM_EP: Failed to ioremap CSR space\n"); > + return -1UL; > + } > + val = readq(addr); > + iounmap(addr); > + return val; > +} > + > +static int ptp_oct_ptm_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts) > +{ > + u64 ptp_time, val64; > + u32 val32; > + > + /* Check for valid PTM context */ > + val32 = read_pcie_config32(0, PCIEEPX_PTM_REQ_STAT); > + if (!(val32 & 0x1)) { > + pr_err("PTM_EP: ERROR: PTM context not valid: 0x%x\n", val32); > + > + ts->tv_sec = 0; > + ts->tv_nsec = 0; > + > + return -EINVAL; > + } > + > + /* Trigger PTM/PTP capture */ > + val64 = readq(ptm_ctl_addr); > + val64 |= PEMX_PTM_CTL_CAP; > + writeq(val64, ptm_ctl_addr); > + /* Read PTM/PTP clocks */ > + ptp_time = readq(ptm_lcl_addr); > + > + *ts = ns_to_timespec64(ptp_time); > + > + return 0; > +} > + > +static int ptp_oct_ptm_enable(struct ptp_clock_info *ptp, > + struct ptp_clock_request *rq, int on) > +{ > + return -EOPNOTSUPP; > +} > + > +static const struct ptp_clock_info ptp_oct_caps = { > + .owner = THIS_MODULE, > + .name = "OCTEON PTM PHC", > + .max_adj = 0, > + .n_ext_ts = 0, > + .n_pins = 0, > + .pps = 0, Initialization to zero is unnecessary, but maybe it's the local drivers/ptp/ style. > + .adjtime = ptp_oct_ptm_adjtime, > + .gettime64 = ptp_oct_ptm_gettime, > + .settime64 = ptp_oct_ptm_settime, > + .enable = ptp_oct_ptm_enable, > +}; > + > +static void __exit ptp_oct_ptm_exit(void) > +{ > + iounmap(ptm_ctl_addr); > + iounmap(ptm_lcl_addr); > + ptp_clock_unregister(oct_ptp_clock.ptp_clock); > +} > + > +static int __init ptp_oct_ptm_init(void) > +{ > + struct pci_dev *pdev = NULL; > + > + pdev = pci_get_device(PCI_VENDOR_ID_CAVIUM, > + PCI_DEVID_OCTEONTX2_PTP, pdev); pci_get_device() is a sub-optimal method for a driver to claim a device. pci_register_driver() is the preferred method. If you can't use that, a comment here explaining why not would be helpful. > + if (!pdev) > + return 0; > + > + if (octeon_csr_read(PEMX_CFG) & 0x1ULL) { > + pr_err("PEM0 is configured as RC\n"); pci_err() or dev_err() etc. when possible. Maybe #define dev_fmt or pr_fmt as appropriate. > + return 0; > + } > + > + if (is_otx2_support_ptm(pdev)) { > + oct_ptp_clock.cn10k_variant = 0; > + } else if (is_cn10k_support_ptm(pdev)) { > + oct_ptp_clock.cn10k_variant = 1; > + } else { > + /* PTM_EP: unsupported processor */ > + return 0; > + } > + > + ptm_ctl_addr = ioremap(PEMX_PTM_CTL, 8); Hard-coded register addresses? That can't be right. Shouldn't this be discoverable either as a PCI BAR or via DT or similar firmware interface? > + if (!ptm_ctl_addr) { > + pr_err("PTM_EP: Failed to ioremap CSR space\n"); > + return 0; > + } > + > + ptm_lcl_addr = ioremap(PEMX_PTM_LCL_TIME, 8); > + if (!ptm_lcl_addr) { > + pr_err("PTM_EP: Failed to ioremap CSR space\n"); > + return 0; > + } > + > + oct_ptp_clock.caps = ptp_oct_caps; > + > + oct_ptp_clock.ptp_clock = ptp_clock_register(&oct_ptp_clock.caps, NULL); > + if (IS_ERR(oct_ptp_clock.ptp_clock)) > + return PTR_ERR(oct_ptp_clock.ptp_clock); > + > + pr_info("PTP device index for PTM clock:%d\n", oct_ptp_clock.ptp_clock->index); > + pr_info("cn10k_variant %d\n", oct_ptp_clock.cn10k_variant); Combine into single line; otherwise there's no hint in the dmesg log of what "cn10k_variant" is connected to (though dev_fmt/pr_fmt would also help with this). > + return 0; > +} > + > +module_init(ptp_oct_ptm_init); > +module_exit(ptp_oct_ptm_exit); > + > +MODULE_AUTHOR("Marvell Inc."); > +MODULE_DESCRIPTION("PTP PHC clock using PTM"); > +MODULE_LICENSE("GPL"); > -- > 2.25.1 >