Messages in this thread | | | Date | Sat, 25 Apr 2020 19:41:48 -0700 | From | Clay McClure <> | Subject | Re: [PATCH] net: cpts: Condition WARN_ON on PTP_1588_CLOCK |
| |
On Wed, Apr 22, 2020 at 02:16:11PM +0300, Grygorii Strashko wrote: > > On 21/04/2020 00:42, Arnd Bergmann wrote: > > > > On Mon, Apr 20, 2020 at 11:34 PM Richard Cochran > > > > > > To be clear, do you all see a need to change the stubbed version of > > > ptp_clock_register() or not? > > > > No, if the NULL return is only meant to mean "nothing wrong, keep going > > wihtout an object", that's fine with me. It does occasionally confuse driver > > writers (as seen here), so it's not a great interface, but there is no general > > solution to make it better.
That's why in my first patch I condition the WARN_ON() on PTP_1588_CLOCK, since without that the null pointer here is not an error:
void cpts_unregister(struct cpts *cpts) { if (WARN_ON(!cpts->clock)) return;
Grygorii's question (paraphrasing: "why would you ever do that?") prompted my second patch, making the broken configuration obvious by emitting an error during `ifup`, instead of just a warning during `ifdown`.
But I think Grygorii is on to something here:
> Another question is that CPTS completely nonfunctional in this case and > it was never expected that somebody will even try to use/run such > configuration (except for random build purposes).
So, let's not allow it. In my view, commit d1cbfd771ce8 ("ptp_clock: Allow for it to be optional") went a bit too far, and converted even clearly PTP-specific modules from `select` to `imply` PTP_1588_CLOCK, which is what made this broken configuration possible. I suggest reverting that change, just for the PTP-specific modules under drivers/net/ethernet.
I audited all drivers that call `ptp_clock_register()`; it looks like these should `select` (instead of merely `imply`) PTP_1588_CLOCK:
NET_DSA_MV88E6XXX_PTP NET_DSA_SJA1105_PTP MACB_USE_HWSTAMP CAVIUM_PTP TI_CPTS_MOD PTP_1588_CLOCK_IXP46X
Note how they all reference PTP or timestamping in their name, which is a clue that they depend on PTP_1588_CLOCK.
I have a patch for this, but first, a procedural question: does mailing list etiquette dictate that I reply to this thread with the new patch, or does it begin a new thread?
-- Clay
| |