mbox series

[net,v2,0/7] octeontx2-af: Fix klockwork issues in AF driver

Message ID 20240625173350.1181194-1-sumang@marvell.com (mailing list archive)
Headers show
Series octeontx2-af: Fix klockwork issues in AF driver | expand

Message

Suman Ghosh June 25, 2024, 5:33 p.m. UTC
This patchset fixes minor klockwork issues in multiple files in AF driver

Patch #1: octeontx2-af: Fix klockwork issue in cgx.c

Patch #2: octeontx2-af: Fix klockwork issues in mcs_rvu_if.c

Patch #3: octeontx2-af: Fixes klockwork issues in ptp.c

Patch #4: octeontx2-af: Fixes klockwork issues in rvu_cpt.c

Patch #5: octeontx2-af: Fixes klockwork issues in rvu_debugfs.c

Patch #6: octeontx2-af: Fix klockwork issue in rvu_nix.c

Patch #7: octeontx2-af: Fix klockwork issue in rvu_npc.c

Suman Ghosh (7):
  octeontx2-af: Fix klockwork issue in cgx.c
  octeontx2-af: Fix klockwork issue in mcs_rvu_if.c
  octeontx2-af: Fixes klockwork issues in ptp.c
  octeontx2-af: Fixes klockwork issues in rvu_cpt.c
  octeontx2-af: Fixes klockwork issues in rvu_debugfs.c
  octeontx2-af: Fix klockwork issue in rvu_nix.c
  octeontx2-af: Fix klockwork issue in rvu_npc.c

v2 changes:
  - Updated description for all the patchsets to address comment from Markus
  - Removed variable initialization from cgx.c(patch #1) to avoid fix of different
    klockwork issues

 drivers/net/ethernet/marvell/octeontx2/af/cgx.c       |  7 +++++++
 .../net/ethernet/marvell/octeontx2/af/mcs_rvu_if.c    |  6 ++++--
 drivers/net/ethernet/marvell/octeontx2/af/ptp.c       | 11 ++++++++++-
 drivers/net/ethernet/marvell/octeontx2/af/rvu_cpt.c   |  2 +-
 .../net/ethernet/marvell/octeontx2/af/rvu_debugfs.c   |  8 +++++++-
 drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c   |  2 +-
 drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c   |  1 +
 7 files changed, 31 insertions(+), 6 deletions(-)

Comments

Markus Elfring June 25, 2024, 6:17 p.m. UTC | #1
>   octeontx2-af: Fix klockwork issue in rvu_npc.c
>
> v2 changes:
>   - Updated description for all the patchsets to address comment from Markus
…

* Why did you not directly respond to the recurring patch review concern
  about better summary phrases (or message subjects)?
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.10-rc5#n646

* Would you like to explain any more here which development concern categories
  were picked up from the mentioned source code analysis tool?

* How much do you care for the grouping of logical changes into
  consistent patch series?


Regards,
Markus
Markus Elfring June 25, 2024, 7:50 p.m. UTC | #2
> > * Why did you not directly respond to the recurring patch review concern
> >   about better summary phrases (or message subjects)?> [Suman] I thought the “summery phrase” is per patch.

Summaries are obviously important parts for patch subjects.


> The cover letter is mentioning the reason for the change

I would like to read an improved overview for your change approach.


> and each patch set is adding the summery for the change.

I have got understanding difficulties for such information somehow.


> Since it is not some actual ‘fix’ I am not sure what more to add other

It seems that there is a temporary conflict according to expected explanation quality.


> than mentioning klockwork fixes.

Source code analysis tools can provide more helpful information.
Do I need to remind you for the published software documentation
around “C checkers”?


> I am not sure what more can be added for a variable initialization to zero
> or adding a NULL check.

* Common vulnerability enumeration?

* CERT reference?


> Can you suggest some?

* Please take another look at linked information sources.

* Can you get sufficient inspirations from published patches?


> > * Would you like to explain any more here which development concern categories
> >   were picked up from the mentioned source code analysis tool?
>
> [Suman]  Development concerns are mentioned in individual patch sets.

* Grouping?

* Outlines?

* Taxonomy?


> > * How much do you care for the grouping of logical changes into
> >   consistent patch series?
>
> [Suman] I thought about it but then I was not sure
>         how to add fix tags for a unified patch set.

Why did you not ask before sending another questionable patch series?


> Hence went with per file approach.

It can occasionally be helpful for change preparations.


> Do you see any problem with the approach?

Obviously, yes.

I hope that you can take several patch review issues better into account finally.

Regards,
Markus
Jakub Kicinski June 26, 2024, 1:04 a.m. UTC | #3
On Tue, 25 Jun 2024 18:34:55 +0000 Suman Ghosh wrote:
> * Why did you not directly respond to the recurring patch review concern
> 
>   about better summary phrases (or message subjects)?
> 
>   https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_Documentation_process_submitting-2Dpatches.rst-3Fh-3Dv6.10-2Drc5-23n646&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=7si3Xn9Ly-Se1a655kvEPIYU0nQ9HPeN280sEUv5ROU&m=tyo7VgAvJ4PW3onftljYvIjrznQ9gYDoeBImOruW9-jUya4QuUMNK2qYOPd2dJK3&s=wYjJjR6jScQdlXWCRWzeG3SidVq0MRYYjMlDPBGMJI8&e=
> 
> [Suman] I thought the “summery phrase” is per patch. The cover letter is mentioning the reason for the change and each patch set is adding the summery for the change. Since it is not some actual ‘fix’ I am not sure what more to add other than mentioning klockwork fixes. I am not sure what more can be added for a variable initialization to zero or adding a NULL check. Can you suggest some?
> 
> 
> 
> * Would you like to explain any more here which development concern categories
> 
>   were picked up from the mentioned source code analysis tool?
> 
> [Suman]  Development concerns are mentioned in individual patch sets. Having junk value in the variable if not initialized or accessing a NULL pointer, etc.
> 
> 
> 
> * How much do you care for the grouping of logical changes into
> 
>   consistent patch series?
> 
> [Suman] I thought about it but then I was not sure how to add fix tags for a unified patch set. Hence went with per file approach. Do you see any problem with the approach?

Please configure your MUA to quote correctly, with > characters.