From: Jakub Kicinski <kuba@kernel.org>
To: "Linga, Pavan Kumar" <pavan.kumar.linga@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>, <davem@davemloft.net>,
<pabeni@redhat.com>, <edumazet@google.com>,
<netdev@vger.kernel.org>, <emil.s.tantilov@intel.com>,
<jesse.brandeburg@intel.com>, <sridhar.samudrala@intel.com>,
<shiraz.saleem@intel.com>, <sindhu.devale@intel.com>,
<willemb@google.com>, <decot@google.com>, <andrew@lunn.ch>,
<leon@kernel.org>, <mst@redhat.com>, <simon.horman@corigine.com>,
<shannon.nelson@amd.com>, <stephen@networkplumber.org>
Subject: Re: [PATCH net-next v4 00/15][pull request] Introduce Intel IDPF driver
Date: Tue, 8 Aug 2023 19:08:53 -0700 [thread overview]
Message-ID: <20230808190853.3edc88f4@kernel.org> (raw)
In-Reply-To: <e1beeb14-fbb5-216c-f661-2bb9a84ba724@intel.com>
On Tue, 8 Aug 2023 17:35:27 -0700 Linga, Pavan Kumar wrote:
> On 8/8/2023 1:32 PM, Jakub Kicinski wrote:
> > On Mon, 7 Aug 2023 17:34:01 -0700 Tony Nguyen wrote:
> >> This patch series introduces the Intel Infrastructure Data Path Function
> >> (IDPF) driver. It is used for both physical and virtual functions. Except
> >> for some of the device operations the rest of the functionality is the
> >> same for both PF and VF. IDPF uses virtchnl version2 opcodes and
> >> structures defined in the virtchnl2 header file which helps the driver
> >> to learn the capabilities and register offsets from the device
> >> Control Plane (CP) instead of assuming the default values.
> >
> > Patches 4 and 10 add kdoc warnings, please fix those.
> > And double check all the checkpatch warning about lines > 80 chars.
>
> Thanks for the feedback.
>
> Will review the warnings regarding 80char limit. Are you wanting them
> all removed or is it okay to leave the ones that help readability?
For some definition of helps readability, yes.
I glanced at the warnings on one of the first patches and most of them
were just comments.
> > drivers/net/ethernet/intel/idpf/idpf.h:123: warning: Enum value
> 'csum_caps' not described in enum 'idpf_cap_field'
> > drivers/net/ethernet/intel/idpf/idpf.h:123: warning: Enum value
> 'seg_caps' not described in enum 'idpf_cap_field'
> > drivers/net/ethernet/intel/idpf/idpf.h:123: warning: Enum value
> 'rss_caps' not described in enum 'idpf_cap_field'
> > drivers/net/ethernet/intel/idpf/idpf.h:123: warning: Enum value
> 'hsplit_caps' not described in enum 'idpf_cap_field'
> > drivers/net/ethernet/intel/idpf/idpf.h:123: warning: Enum value
> 'rsc_caps' not described in enum 'idpf_cap_field'
> > drivers/net/ethernet/intel/idpf/idpf.h:123: warning: Enum value
> 'other_caps' not described in enum 'idpf_cap_field'
> > drivers/net/ethernet/intel/idpf/idpf_txrx.h:153: warning: Function
> parameter or member 'DEFINE_DMA_UNMAP_ADDR(dma' not described in
> 'idpf_tx_buf'
> > drivers/net/ethernet/intel/idpf/idpf_txrx.h:153: warning: Function
> parameter or member 'DEFINE_DMA_UNMAP_LEN(len' not described in
> 'idpf_tx_buf'
>
> /**
> * enum idpf_cap_field - Offsets into capabilities struct for specific caps
> * @IDPF_BASE_CAPS: generic base capabilities
> * @IDPF_CSUM_CAPS: checksum offload capabilities
> ...
> */
> enum idpf_cap_field {
> IDPF_BASE_CAPS = -1,
> IDPF_CSUM_CAPS = offsetof(struct virtchnl2_get_capabilities,
> csum_caps),
> IDPF_SEG_CAPS = offsetof(struct
> ...
> }
>
>
> /**
> * struct idpf_tx_buf
> * @next_to_watch: Next descriptor to clean
> * @skb: Pointer to the skb
> * @dma: DMA address
> * @len: DMA length
> ...
> */
> struct idpf_tx_buf {
> void *next_to_watch;
> struct sk_buff *skb;
> DEFINE_DMA_UNMAP_ADDR(dma);
> DEFINE_DMA_UNMAP_LEN(len);
> ...
> }
>
> The script is parsing the offsetof() argument as part of the enum, which
> is not true. I believe it to be a false positive. Same for the second
> one where it parses 'DEFINE_DMA_UNMAP_ADDR(dma'. Is it okay to use 'dma'
> and 'len' in the kdoc header as-is or please suggest if you prefer
> something?
The parser is in scripts/kernel-doc, it's not very complicated.
You can teach it new tricks.
prev parent reply other threads:[~2023-08-09 2:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 0:34 [PATCH net-next v4 00/15][pull request] Introduce Intel IDPF driver Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 01/15] virtchnl: add virtchnl version 2 ops Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 02/15] idpf: add module register and probe functionality Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 03/15] idpf: add controlq init and reset checks Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 04/15] idpf: add core init and interrupt request Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 05/15] idpf: add create vport and netdev configuration Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 06/15] idpf: add ptypes and MAC filter support Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 07/15] idpf: configure resources for TX queues Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 08/15] idpf: configure resources for RX queues Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 09/15] idpf: initialize interrupts and enable vport Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 10/15] idpf: add splitq start_xmit Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 11/15] idpf: add TX splitq napi poll support Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 12/15] idpf: add RX " Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 13/15] idpf: add singleq start_xmit and napi poll Tony Nguyen
2023-08-08 0:34 ` [PATCH net-next v4 14/15] idpf: add ethtool callbacks Tony Nguyen
2023-08-09 10:33 ` Simon Horman
2023-08-14 17:51 ` Linga, Pavan Kumar
2023-08-08 0:34 ` [PATCH net-next v4 15/15] idpf: configure SRIOV and add other ndo_ops Tony Nguyen
2023-08-08 0:51 ` [PATCH net-next v4 00/15][pull request] Introduce Intel IDPF driver Tony Nguyen
2023-08-08 20:32 ` Jakub Kicinski
2023-08-09 0:35 ` Linga, Pavan Kumar
2023-08-09 2:08 ` Jakub Kicinski [this message]
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=20230808190853.3edc88f4@kernel.org \
--to=kuba@kernel.org \
--cc=andrew@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=decot@google.com \
--cc=edumazet@google.com \
--cc=emil.s.tantilov@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=leon@kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.kumar.linga@intel.com \
--cc=shannon.nelson@amd.com \
--cc=shiraz.saleem@intel.com \
--cc=simon.horman@corigine.com \
--cc=sindhu.devale@intel.com \
--cc=sridhar.samudrala@intel.com \
--cc=stephen@networkplumber.org \
--cc=willemb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).