Messages in this thread | | | From | Arnd Bergmann <> | Date | Mon, 20 Apr 2020 20:57:05 +0200 | Subject | Re: [PATCH] net: cpts: Condition WARN_ON on PTP_1588_CLOCK |
| |
On Mon, Apr 20, 2020 at 7:00 PM Richard Cochran <richardcochran@gmail.com> wrote: > > On Mon, Apr 20, 2020 at 04:38:32PM +0200, Arnd Bergmann wrote: > > > > I suspect we should move all of them back. This was an early user > > of 'imply', but the meaning of that keyword has now changed > > in the latest Kconfig. > > Can you please explain the justification for changing the meaning? > > It was a big PITA for me to support this in the first place, and now > we are back to square one?
I don't understand it either. Apparently it didn't always do what users expected, though the new definition seems less useful to me, as it only changes the default.
> > Something else is wrong if you need IS_ERR_OR_NULL(). Any > > kernel interface should either return an negative error code when > > something goes wrong, or should return NULL for all errors, but > > not mix the two. > > On the contrary, this is exactly what the whole "imply" thing > demanded. > > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 172) #if IS_REACHABLE(CONFIG_PTP_1588_CLOCK) > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 173) > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 174) /** > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 175) * ptp_clock_register() - register a PTP hardware clock driver > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 176) * > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 177) * @info: Structure describing the new clock. > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 178) * @parent: Pointer to the parent device of the new clock. > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 179) * > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 180) * Returns a valid pointer on success or PTR_ERR on failure. If PHC > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 181) * support is missing at the configuration level, this function > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 182) * returns NULL, and drivers are expected to gracefully handle that > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 183) * case separately. > d1cbfd771ce82 (Nicolas Pitre 2016-11-11 184) */
The key here is "gracefully". The second patch from Clay just turns NULL into -EOPNOTSUPP and treats the compile-time condition into a runtime error. I don't see a point in allowing the driver to compile if it just always returns an error. The two callers then go on to print a message for any error and just keep going.
Arnd
| |