Re: [PATCH 02/13] cpufreq: cpufreq: Demote lots of function headers unworthy of kerneldoc status

Viresh Kumar
2020-07-15T07:09:45Z

On 15-07-20, 07:47, Lee Jones wrote:
> On Wed, 15 Jul 2020, Viresh Kumar wrote:
>
> > On 14-07-20, 15:50, Lee Jones wrote:
> > > -/**
> > > +/*
> > > * cpufreq_remove_dev - remove a CPU device
> >
> > Because cpufreq_add_dev() is part of kernel doc, we better keep it.
> >
> > > *
> > > * Removes the cpufreq interface for a CPU device.
> > > @@ -2373,6 +2374,7 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
> > > * cpufreq_get_policy - get the current cpufreq_policy
> > > * @policy: struct cpufreq_policy into which the current cpufreq_policy
> > > * is written
> > > + * @cpu: CPU to find the policy for
> > > *
> > > * Reads the current cpufreq policy.
> > > */
> > > @@ -2759,7 +2761,7 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data)
> > > }
> > > EXPORT_SYMBOL_GPL(cpufreq_register_driver);
> > >
> > > -/**
> > > +/*
> > > * cpufreq_unregister_driver - unregister the current CPUFreq driver
> >
> > And this should be there for sure.
>
> Where is the *.rst file that references this kerneldoc entry?
>
> Also, what do you mean by "there"? We're not removing the function
> header. It's still documented, it's just not kerneldoc.

Yeah, I meant from kernel-doc by "there".

Lets conclude the discussion on the other patch for what should be in
kernel-doc.

> > > *
> > > * Unregister the current CPUFreq driver. Only call this if you have
> >
>
> --
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog

--
viresh