lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lhtklncbcyphq2ljxn6w5p7wk4rdj5wxzskmlly4mrr664b2lj@w5clch5uzvd3>
Date: Mon, 7 Apr 2025 13:14:56 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Lorenzo Pieralisi <lpieralisi@...nel.org>, 
	Krzysztof Wilczyński <kw@...ux.com>, Rob Herring <robh@...nel.org>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Jingoo Han <jingoohan1@...il.com>, linux-pci@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v2 1/3] PCI: Add sysfs support for exposing PTM context

On Mon, Mar 24, 2025 at 11:28:54AM -0500, Bjorn Helgaas wrote:
> On Mon, Mar 24, 2025 at 03:34:35PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> > 
> > Precision Time Management (PTM) mechanism defined in PCIe spec r6.0,
> > sec 6.22 allows precise coordination of timing information across multiple
> > components in a PCIe hierarchy with independent local time clocks.
> > 
> > PCI core already supports enabling PTM in the root port and endpoint
> > devices through PTM Extended Capability registers. But the PTM context
> > supported by the PTM capable components such as Root Complex (RC) and
> > Endpoint (EP) controllers were not exposed as of now.
> > 
> > Hence, add the sysfs support to expose the PTM context to userspace from
> > both PCIe RC and EP controllers. Controller drivers are expected to call
> > pcie_ptm_create_sysfs() to create the sysfs attributes for the PTM context
> > and call pcie_ptm_destroy_sysfs() to destroy them. The drivers should also
> > populate the relevant callbacks in the 'struct pcie_ptm_ops' structure
> > based on the controller implementation.
> 
> Can we include some motivation here, e.g., what is the value of
> exposing this information?  Is this for debugging or bringup purposes?
> Can users or administrators use this for something?  Obviously they
> can read and update some internal PTM state, but it would be nice to
> know what that's good for.
> 

This was a request from one of the Qualcomm customers, but they didn't share how
they are using these context. They just said that they want to collect the PTM
timestamps for comparing with PTP timestamps from a different PCIe switch. That
was not a worth of information to be mentioned in the cover letter, so I skipped
it intentionally.

Also, the spec itself didn't mention any specific usecases unfortunately.

> It looks like this requires device-specific support, i.e., the context
> itself, context update modes, access to the clock values, etc., is not
> specified by the generic PCIe spec.

Right.

>  Consequently this probably can't
> be done by generic drivers like ACPI, and maybe this is a candidate
> for debugfs instead of sysfs.
>

Well, we can still create syfs ABI for vendor specific features. Problem with
debugfs is that the customers cannot use debugfs in a production environment.
Moreover, I cannot strictly classify PTM context as a debugging information.
 
- Mani

-- 
மணிவண்ணன் சதாசிவம்

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ