Re: [PATCH 5/5] bus: mhi: host: mhi_phc: Add support for PHC over MHI

On 9/16/2025 2:47 PM, Imran Shaik wrote:

On 8/22/2025 6:32 AM, Jakub Kicinski wrote:

quoted

On Mon, 18 Aug 2025 12:25:50 +0530 Krishna Chaitanya Chundru wrote:

quoted

This patch introduces the MHI PHC (PTP Hardware Clock) driver, which
registers a PTP (Precision Time Protocol) clock and communicates with
the MHI core to get the device side timestamps. These timestamps are
then exposed to the PTP subsystem, enabling precise time synchronization
between the host and the device.

quoted

+static struct ptp_clock_info qcom_ptp_clock_info = {
+	.owner    = THIS_MODULE,
+	.gettimex64 =  qcom_ptp_gettimex64,
+};

Yet another device to device clock sync driver. Please see the
discussion here:
https://lore.kernel.org/all/20250815113814.5e135318@kernel.org/ (local)
I think we have a consensus within the community that we should 
stop cramming random clocks into the PTP subsystem.

Exporting read-only clocks from another processor is not what PTP
is for.

Hi Jakub,
 
Thank you for the review and for sharing the link to the ongoing discussion.

I understand the concerns about using the PTP subsystem for read-only clocks.
The idea behind this patch was to use a standard interface for syncing time
between the host and device, and also to make use of existing tools like
phc2sys from userspace.
 
I have looked into the on going discussion you pointed, and we’re facing
a similar challenge. Based on internal discussion with the PCIe team, we’ve
confirmed that PCIe PTM isn’t applicable for this hardware use case.
 
That said, since it seems the community prefers not to use PTP for such
requirement, could you please suggest any other way to support this time
sync requirement that would be acceptable upstream?

Appreciate your guidance!
 

Hi, Could you please share your thoughts on other approaches or directions we could
take to support the above requirement in a way that’s acceptable upstream?

Thanks,
Imran