[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 6 Jul 2021 17:26:30 -0700
From: Jonathan Lemon <jonathan.lemon@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Richard Cochran <richardcochran@...il.com>, netdev@...r.kernel.org,
kernel-team@...com
Subject: Re: [PATCH] ptp: Set lookup cookie when creating a PTP PPS source.
On Fri, Jul 02, 2021 at 03:39:36AM +0300, Vladimir Oltean wrote:
> On Mon, Jun 28, 2021 at 04:38:35PM -0700, Richard Cochran wrote:
> > On Mon, Jun 28, 2021 at 11:25:33AM -0700, Jonathan Lemon wrote:
> > > When creating a PTP device, the configuration block allows
> > > creation of an associated PPS device. However, there isn't
> > > any way to associate the two devices after creation.
> > >
> > > Set the PPS cookie, so pps_lookup_dev(ptp) performs correctly.
> >
> > Setting lookup_cookie is harmless, AFAICT, but I wonder about the use
> > case. The doc for pps_lookup_dev() says,
>
> Harmless you say?
>
> Let's look at the code in a larger context:
>
> struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
> struct device *parent)
> {
> struct ptp_clock *ptp;
>
> ...
> ptp = kzalloc(...);
> ...
> ptp->info = info;
> ...
>
> if (ptp->info->do_aux_work) {
> ...
> + ptp->pps_source->lookup_cookie = ptp;
> }
>
> /* Register a new PPS source. */
> if (info->pps) {
> struct pps_source_info pps;
> ...
> ptp->pps_source = pps_register_source(&pps, PTP_PPS_DEFAULTS);
> ...
> }
>
> Notice anything out of the ordinary?
> Like perhaps the fact that ptp->pps_source is an arbitrary NULL pointer
> at the time the assignment to ->lookup_cookie is being made, because it
> is being created later?
>
> How on earth is this patch supposed to work?
It was added to the wrong code block. Checking my tree, I seem to have
it located twice - probably a bad patch that I didn't notice, and since
I don't have an do_aux_work, the first one didn't trigger.
Correction follows.
--
Jonathan
Powered by blists - more mailing lists