diff mbox series

[RESEND,v3,2/3] phy: core: Update documentation syntax

Message ID 20220407102108.24211-3-jmaselbas@kalray.eu (mailing list archive)
State Accepted
Commit bd5bd02e1517352ff215879362624f4ca6575bdc
Headers show
Series Cleanup the call ordering of phy_init and phy_power_on | expand

Commit Message

Jules Maselbas April 7, 2022, 10:21 a.m. UTC
Update the syntax used by the documentation of phy operation functions.
This is to unify the syntax with the newly added documentation.

Signed-off-by: Jules Maselbas <jmaselbas@kalray.eu>
---
v2: new patch
v3: no change

 drivers/phy/phy-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Vinod Koul April 13, 2022, 6:02 a.m. UTC | #1
On 07-04-22, 12:21, Jules Maselbas wrote:
> Update the syntax used by the documentation of phy operation functions.
> This is to unify the syntax with the newly added documentation.

Is there any reason for using this sytax, is it documented somewhere..?
How does this syntax help?

> 
> Signed-off-by: Jules Maselbas <jmaselbas@kalray.eu>
> ---
> v2: new patch
> v3: no change
> 
>  drivers/phy/phy-core.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index d1817a0f2d09..d11b517e283a 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -467,7 +467,7 @@ EXPORT_SYMBOL_GPL(phy_reset);
>   * runtime, which are otherwise lost after host controller reset and cannot
>   * be applied in phy_init() or phy_power_on().
>   *
> - * Returns: 0 if successful, an negative error code otherwise
> + * Return: %0 if successful, a negative error code otherwise
>   */
>  int phy_calibrate(struct phy *phy)
>  {
> @@ -493,7 +493,7 @@ EXPORT_SYMBOL_GPL(phy_calibrate);
>   * on the phy. The configuration will be applied on the current phy
>   * mode, that can be changed using phy_set_mode().
>   *
> - * Returns: 0 if successful, an negative error code otherwise
> + * Return: %0 if successful, a negative error code otherwise
>   */
>  int phy_configure(struct phy *phy, union phy_configure_opts *opts)
>  {
> @@ -527,7 +527,7 @@ EXPORT_SYMBOL_GPL(phy_configure);
>   * PHY, so calling it as many times as deemed fit will have no side
>   * effect.
>   *
> - * Returns: 0 if successful, an negative error code otherwise
> + * Return: %0 if successful, a negative error code otherwise
>   */
>  int phy_validate(struct phy *phy, enum phy_mode mode, int submode,
>  		 union phy_configure_opts *opts)
> -- 
> 2.17.1
> 
> 
> -- 
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
Jules Maselbas April 13, 2022, 9:53 a.m. UTC | #2
On Wed, Apr 13, 2022 at 11:32:23AM +0530, Vinod Koul wrote:
> On 07-04-22, 12:21, Jules Maselbas wrote:
> > Update the syntax used by the documentation of phy operation functions.
> > This is to unify the syntax with the newly added documentation.
> 
> Is there any reason for using this sytax, is it documented somewhere..?
> How does this syntax help?

I don't have any particular reason for this syntax, this syntax have been
suggested by Randy Dunlap.

> 
> > 
> > Signed-off-by: Jules Maselbas <jmaselbas@kalray.eu>
> > ---
> > v2: new patch
> > v3: no change
> > 
> >  drivers/phy/phy-core.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> > index d1817a0f2d09..d11b517e283a 100644
> > --- a/drivers/phy/phy-core.c
> > +++ b/drivers/phy/phy-core.c
> > @@ -467,7 +467,7 @@ EXPORT_SYMBOL_GPL(phy_reset);
> >   * runtime, which are otherwise lost after host controller reset and cannot
> >   * be applied in phy_init() or phy_power_on().
> >   *
> > - * Returns: 0 if successful, an negative error code otherwise
> > + * Return: %0 if successful, a negative error code otherwise
> >   */
> >  int phy_calibrate(struct phy *phy)
> >  {
> > @@ -493,7 +493,7 @@ EXPORT_SYMBOL_GPL(phy_calibrate);
> >   * on the phy. The configuration will be applied on the current phy
> >   * mode, that can be changed using phy_set_mode().
> >   *
> > - * Returns: 0 if successful, an negative error code otherwise
> > + * Return: %0 if successful, a negative error code otherwise
> >   */
> >  int phy_configure(struct phy *phy, union phy_configure_opts *opts)
> >  {
> > @@ -527,7 +527,7 @@ EXPORT_SYMBOL_GPL(phy_configure);
> >   * PHY, so calling it as many times as deemed fit will have no side
> >   * effect.
> >   *
> > - * Returns: 0 if successful, an negative error code otherwise
> > + * Return: %0 if successful, a negative error code otherwise
> >   */
> >  int phy_validate(struct phy *phy, enum phy_mode mode, int submode,
> >  		 union phy_configure_opts *opts)
> > -- 
> > 2.17.1
> > 
> > 
> > -- 
> > linux-phy mailing list
> > linux-phy@lists.infradead.org
> > https://lists.infradead.org/mailman/listinfo/linux-phy
> 
> -- 
> ~Vinod
Vinod Koul April 13, 2022, 9:59 a.m. UTC | #3
On 13-04-22, 11:53, Jules Maselbas wrote:
> On Wed, Apr 13, 2022 at 11:32:23AM +0530, Vinod Koul wrote:
> > On 07-04-22, 12:21, Jules Maselbas wrote:
> > > Update the syntax used by the documentation of phy operation functions.
> > > This is to unify the syntax with the newly added documentation.
> > 
> > Is there any reason for using this sytax, is it documented somewhere..?
> > How does this syntax help?
> 
> I don't have any particular reason for this syntax, this syntax have been
> suggested by Randy Dunlap.

Is this documented somewhere?
Jules Maselbas April 13, 2022, 11:13 a.m. UTC | #4
On Wed, Apr 13, 2022 at 03:29:30PM +0530, Vinod Koul wrote:
> On 13-04-22, 11:53, Jules Maselbas wrote:
> > On Wed, Apr 13, 2022 at 11:32:23AM +0530, Vinod Koul wrote:
> > > On 07-04-22, 12:21, Jules Maselbas wrote:
> > > > Update the syntax used by the documentation of phy operation functions.
> > > > This is to unify the syntax with the newly added documentation.
> > > 
> > > Is there any reason for using this sytax, is it documented somewhere..?
> > > How does this syntax help?
> > 
> > I don't have any particular reason for this syntax, this syntax have been
> > suggested by Randy Dunlap.
> 
> Is this documented somewhere?
Yes this is documented in Documentation/doc-guide/kernel-doc.rst:

``%CONST``
  Name of a constant. (No cross-referencing, just formatting.)

My understanding is that this formating should be used for the constant
NULL and not for literal values, such as 0.

What you do think? Should I revert to using a straight 0 in the return
value doc?

--
Jules
diff mbox series

Patch

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index d1817a0f2d09..d11b517e283a 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -467,7 +467,7 @@  EXPORT_SYMBOL_GPL(phy_reset);
  * runtime, which are otherwise lost after host controller reset and cannot
  * be applied in phy_init() or phy_power_on().
  *
- * Returns: 0 if successful, an negative error code otherwise
+ * Return: %0 if successful, a negative error code otherwise
  */
 int phy_calibrate(struct phy *phy)
 {
@@ -493,7 +493,7 @@  EXPORT_SYMBOL_GPL(phy_calibrate);
  * on the phy. The configuration will be applied on the current phy
  * mode, that can be changed using phy_set_mode().
  *
- * Returns: 0 if successful, an negative error code otherwise
+ * Return: %0 if successful, a negative error code otherwise
  */
 int phy_configure(struct phy *phy, union phy_configure_opts *opts)
 {
@@ -527,7 +527,7 @@  EXPORT_SYMBOL_GPL(phy_configure);
  * PHY, so calling it as many times as deemed fit will have no side
  * effect.
  *
- * Returns: 0 if successful, an negative error code otherwise
+ * Return: %0 if successful, a negative error code otherwise
  */
 int phy_validate(struct phy *phy, enum phy_mode mode, int submode,
 		 union phy_configure_opts *opts)