All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>,
	John Allen <jallen@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org,
	Santiago Leon <santi_leon@yahoo.com>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, Lijun Pan <ljp@linux.ibm.com>,
	Dany Madden <drt@linux.ibm.com>,
	Paul Mackerras <paulus@samba.org>,
	Sukadev Bhattiprolu <sukadev@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 5/8] net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours
Date: Mon, 30 Nov 2020 09:04:30 +0000	[thread overview]
Message-ID: <20201130090430.GD4801@dell> (raw)
In-Reply-To: <20201129184354.GL2234159@lunn.ch>

On Sun, 29 Nov 2020, Andrew Lunn wrote:

> Hi Lee
> 
> >  /**
> >   * build_hdr_data - creates L2/L3/L4 header data buffer
> > - * @hdr_field - bitfield determining needed headers
> > - * @skb - socket buffer
> > - * @hdr_len - array of header lengths
> > - * @tot_len - total length of data
> > + * @hdr_field: bitfield determining needed headers
> > + * @skb: socket buffer
> > + * @hdr_len: array of header lengths
> > + * @tot_len: total length of data
> >   *
> >   * Reads hdr_field to determine which headers are needed by firmware.
> >   * Builds a buffer containing these headers.  Saves individual header
> 
> The code is:
> 
> static int build_hdr_data(u8 hdr_field, struct sk_buff *skb,
>                           int *hdr_len, u8 *hdr_data)
> {
> 
> What about hdr_data? 
> 
> >  /**
> >   * create_hdr_descs - create header and header extension descriptors
> > - * @hdr_field - bitfield determining needed headers
> > - * @data - buffer containing header data
> > - * @len - length of data buffer
> > - * @hdr_len - array of individual header lengths
> > - * @scrq_arr - descriptor array
> > + * @hdr_field: bitfield determining needed headers
> > + * @data: buffer containing header data
> > + * @len: length of data buffer
> > + * @hdr_len: array of individual header lengths
> > + * @scrq_arr: descriptor array
> 
> static int create_hdr_descs(u8 hdr_field, u8 *hdr_data, int len, int *hdr_len,
>                             union sub_crq *scrq_arr)
> 
> There is no data parameter.
> 
> It looks like you just changes - to :, but did not validate the
> parameters are actually correct.

Right.  This is a 'quirk' of my current process.

I build once, then use a script to parse the output, fixing each
issue in the order the compiler presents them.  Then, either after
fixing a reasonable collection, or all issues, I re-run the compile
and fix the next batch (if any).

This patch is only fixing the formatting issue(s).  As you've seen,
there is a subsequent patch in the series which fixes the disparity.

I can squash them though.  No problem.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: linux-kernel@vger.kernel.org, Dany Madden <drt@linux.ibm.com>,
	Lijun Pan <ljp@linux.ibm.com>,
	Sukadev Bhattiprolu <sukadev@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Santiago Leon <santi_leon@yahoo.com>,
	Thomas Falcon <tlfalcon@linux.vnet.ibm.com>,
	John Allen <jallen@linux.vnet.ibm.com>,
	netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/8] net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours
Date: Mon, 30 Nov 2020 09:04:30 +0000	[thread overview]
Message-ID: <20201130090430.GD4801@dell> (raw)
In-Reply-To: <20201129184354.GL2234159@lunn.ch>

On Sun, 29 Nov 2020, Andrew Lunn wrote:

> Hi Lee
> 
> >  /**
> >   * build_hdr_data - creates L2/L3/L4 header data buffer
> > - * @hdr_field - bitfield determining needed headers
> > - * @skb - socket buffer
> > - * @hdr_len - array of header lengths
> > - * @tot_len - total length of data
> > + * @hdr_field: bitfield determining needed headers
> > + * @skb: socket buffer
> > + * @hdr_len: array of header lengths
> > + * @tot_len: total length of data
> >   *
> >   * Reads hdr_field to determine which headers are needed by firmware.
> >   * Builds a buffer containing these headers.  Saves individual header
> 
> The code is:
> 
> static int build_hdr_data(u8 hdr_field, struct sk_buff *skb,
>                           int *hdr_len, u8 *hdr_data)
> {
> 
> What about hdr_data? 
> 
> >  /**
> >   * create_hdr_descs - create header and header extension descriptors
> > - * @hdr_field - bitfield determining needed headers
> > - * @data - buffer containing header data
> > - * @len - length of data buffer
> > - * @hdr_len - array of individual header lengths
> > - * @scrq_arr - descriptor array
> > + * @hdr_field: bitfield determining needed headers
> > + * @data: buffer containing header data
> > + * @len: length of data buffer
> > + * @hdr_len: array of individual header lengths
> > + * @scrq_arr: descriptor array
> 
> static int create_hdr_descs(u8 hdr_field, u8 *hdr_data, int len, int *hdr_len,
>                             union sub_crq *scrq_arr)
> 
> There is no data parameter.
> 
> It looks like you just changes - to :, but did not validate the
> parameters are actually correct.

Right.  This is a 'quirk' of my current process.

I build once, then use a script to parse the output, fixing each
issue in the order the compiler presents them.  Then, either after
fixing a reasonable collection, or all issues, I re-run the compile
and fix the next batch (if any).

This patch is only fixing the formatting issue(s).  As you've seen,
there is a subsequent patch in the series which fixes the disparity.

I can squash them though.  No problem.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2020-11-30  9:06 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26 13:38 [PATCH 0/8] Rid W=1 warnings in Net Lee Jones
2020-11-26 13:38 ` Lee Jones
2020-11-26 13:38 ` [PATCH 1/8] net: ethernet: smsc: smc91x: Demote non-conformant kernel function header Lee Jones
2020-11-29 18:33   ` Andrew Lunn
2020-11-30  8:59     ` Lee Jones
2020-11-26 13:38 ` [PATCH 2/8] net: xen-netback: xenbus: Demote nonconformant kernel-doc headers Lee Jones
2020-11-29 18:34   ` Andrew Lunn
2020-11-26 13:38 ` [PATCH 3/8] net: ethernet: ti: am65-cpsw-qos: Demote non-conformant function header Lee Jones
2020-11-29 18:35   ` Andrew Lunn
2020-11-26 13:38 ` [PATCH 4/8] net: ethernet: ti: am65-cpts: Document am65_cpts_rx_enable()'s 'en' parameter Lee Jones
2020-11-29 18:37   ` Andrew Lunn
2020-11-26 13:38 ` [PATCH 5/8] net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours Lee Jones
2020-11-26 13:38   ` Lee Jones
2020-11-29 18:43   ` Andrew Lunn
2020-11-29 18:43     ` Andrew Lunn
2020-11-30  9:04     ` Lee Jones [this message]
2020-11-30  9:04       ` Lee Jones
2020-11-26 13:38 ` [PATCH 6/8] net: ethernet: toshiba: ps3_gelic_net: " Lee Jones
2020-11-26 13:38   ` Lee Jones
2020-11-29 18:45   ` Andrew Lunn
2020-11-29 18:45     ` Andrew Lunn
2020-11-26 13:38 ` [PATCH 7/8] net: ethernet: toshiba: spider_net: Document a whole bunch of function parameters Lee Jones
2020-11-29 19:08   ` Andrew Lunn
2020-11-26 13:38 ` [PATCH 8/8] net: ethernet: ibm: ibmvnic: Fix some kernel-doc issues Lee Jones
2020-11-26 13:38   ` Lee Jones
2020-11-29 19:10   ` Andrew Lunn
2020-11-29 19:10     ` Andrew Lunn
2020-11-30  8:59     ` Lee Jones
2020-11-30  8:59       ` Lee Jones
2020-11-27 17:39 ` [PATCH 0/8] Rid W=1 warnings in Net Jakub Kicinski
2020-11-27 17:39   ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201130090430.GD4801@dell \
    --to=lee.jones@linaro.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=drt@linux.ibm.com \
    --cc=jallen@linux.vnet.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=ljp@linux.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=santi_leon@yahoo.com \
    --cc=sukadev@linux.ibm.com \
    --cc=tlfalcon@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.