netdev - Re: [PATCH net v3 2/2] phy: mscc: Fix PTP for VSC8574 and VSC8572

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: <20250930070359.sjeqsgluwyt23ry2@DEN-DL-M31836.microchip.com>
Date: Tue, 30 Sep 2025 09:03:59 +0200
From: Horatiu Vultur <horatiu.vultur@...rochip.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
CC: <andrew@...n.ch>, <hkallweit1@...il.com>, <davem@...emloft.net>,
	<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<richardcochran@...il.com>, <vladimir.oltean@....com>,
	<vadim.fedorenko@...ux.dev>, <rosenp@...il.com>,
	<christophe.jaillet@...adoo.fr>, <steen.hegelund@...rochip.com>,
	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net v3 2/2] phy: mscc: Fix PTP for VSC8574 and VSC8572

The 09/29/2025 14:33, Russell King (Oracle) wrote:

Hi Russell,

> 
> On Mon, Sep 29, 2025 at 11:13:02AM +0200, Horatiu Vultur wrote:
> > The PTP initialization is two-step. First part are the function
> > vsc8584_ptp_probe_once() and vsc8584_ptp_probe() at probe time which
> > initialize the locks, queues, creates the PTP device. The second part is
> > the function vsc8584_ptp_init() at config_init() time which initialize
> > PTP in the HW.
> 
> So, to summarise, you register the PTP clock at probe time? At that
> point, you get a /dev/ptp* device. Is that device functional without
> the config_init() initialisation?

That is correct. I register the PTP clock at probe time.
It is not fully functional, for example calling "phc_ctl /dev/ptp0 get", I
always get "clock time is 0.000000000 or Thu Jan  1 00:00:00 1970"

# phc_ctl /dev/ptp0 get
phc_ctl[414.412]: clock time is 0.000000000 or Thu Jan  1 00:00:00 1970

# phc_ctl /dev/ptp0 get
phc_ctl[418.453]: clock time is 0.000000000 or Thu Jan  1 00:00:00 1970

Then after setting up, I can see the time increasing:

# phc_ctl /dev/ptp0 get
phc_ctl[511.841]: clock time is 2.232610928 or Thu Jan  1 00:00:02 1970

# phc_ctl /dev/ptp0 get
phc_ctl[515.113]: clock time is 5.504853240 or Thu Jan  1 00:00:05 1970

> 
> I would hope it is, because one of the fundamental concepts in kernel
> programming is... don't publish devices to userspace that are not
> completely ready for operation.
> 
> Conversely, don't tear down a published device without first
> unpublishing it from userspace.

Thanks for reminding me about this. Unfortunately, the same behaviour is for
all the devices that this driver is covering. So, then maybe I would
need to create a patch in the future to change this to have the correct
behaviour.

> 
> Thanks.
> 
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

-- 
/Horatiu