public inbox for linux-kernel-mentees@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: David Hunter <david.hunter.linux@gmail.com>
To: Clint George <clintbgeorge@gmail.com>,
	stern@rowland.harvard.edu, gregkh@linuxfoundation.org
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kernel-mentees@lists.linux.dev, skhan@linuxfoundation.org,
	khalid@kernel.org
Subject: Re: [PATCH 0/8] usb: gadget: dummy_hcd: coding style improvements and error handling change
Date: Thu, 27 Nov 2025 15:35:37 -0500	[thread overview]
Message-ID: <70565b52-d42d-4808-84cd-ac8587c75b10@gmail.com> (raw)
In-Reply-To: <20251119130840.14309-1-clintbgeorge@gmail.com>

On 11/19/25 08:08, Clint George wrote:
> This patch series focuses on addressing various coding style issues in
> the dummy_hcd USB gadget driver. The changes include simplifying error
> handling by preventing kernel-space crashes, improving readability, and
> ensuring consistency with kernel coding conventions.
> 
> Clint George (8):
>   usb: gadget: dummy_hcd: replace BUG() with WARN_ON_ONCE()

Hey Clint,

Regarding our discussion on Discord, I wanted to give you advice and
have it be closer to the code, so you could see what I was talking
about. You asked about Greg's feedback regarding the "Bug()". Here is
some context so that you can understand Greg's feedback a little better.

In Kernel development, there are thousands of people writing code. As a
result, developers will write something like "Bug()" or "Warn()" if a
particular path/condition is met.This is to create a signal for future
developers about situations that should not occur. A later developer
might do something that causes that faulty condition to be met. When
debugging, your goal is not to simply remove that line. Your goal is to
find out what caused the faulty condition, and fix that.

If all you do is eliminate the signal that there is an error, you are
just "papering over" instead of addressing the actual issue.


>   usb: gadget: dummy_hcd: replace symbolic permissions (S_IRUGO) with
>     octal (0444)
>   usb: gadget: dummy_hcd: use 'unsigned int' instead of bare 'unsigned'
>   usb: gadget: dummy_hcd: fix block comments, blank lines and function
>     braces

As we discussed, you can break your patches into something more focused
on one type of fix. For example, one patch could be to just remove code
and put in a more meaningful comment. Another patch could be removing
unnecessary spaces.

>   usb: gadget: dummy_hcd: merge multi-line quoted strings into one line
>   usb: gadget: dummy_hcd: use sizeof(*ptr) instead of sizeof *ptr
>   usb: gadget: dummy_hcd: remove unnecessary 'else' after return

Also, some things like your changing of the "else if" are things that
you do not need to change. Some of the knowledge of what to change and
what to ignore will come with experience. For that particular one, most
developers are used to seeing "else if".

>   usb: gadget: dummy_hcd: fix miscellaneous coding style warnings
> 
>  drivers/usb/gadget/udc/dummy_hcd.c | 139 ++++++++++++++---------------
>  1 file changed, 67 insertions(+), 72 deletions(-)
> 

Overall, my recommendation for you is to reduce the amount you are
trying to tackle at once. You can work over a longer period of time on
the file. Not everything needs to be accepted all at once.

Also, feel free to continue reaching out on discord. I just wrote here
to closer tie my feedback to particular patches.

Good attempt at submitting your first patch series, and don't get
discouraged. Getting feedback is a part of the process.

Thanks,
David Hunter



  parent reply	other threads:[~2025-11-27 20:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-19 13:08 [PATCH 0/8] usb: gadget: dummy_hcd: coding style improvements and error handling change Clint George
2025-11-19 13:08 ` [PATCH 1/8] usb: gadget: dummy_hcd: replace BUG() with WARN_ON_ONCE() Clint George
2025-11-19 15:27   ` Greg KH
2025-11-19 13:08 ` [PATCH 2/8] usb: gadget: dummy_hcd: replace symbolic permissions (S_IRUGO) with octal (0444) Clint George
2025-11-19 13:08 ` [PATCH 3/8] usb: gadget: dummy_hcd: use 'unsigned int' instead of bare 'unsigned' Clint George
2025-11-19 13:08 ` [PATCH 4/8] usb: gadget: dummy_hcd: fix block comments, blank lines and function braces Clint George
2025-11-19 15:29   ` Greg KH
2025-11-19 15:36     ` Alan Stern
2025-11-19 13:08 ` [PATCH 5/8] usb: gadget: dummy_hcd: merge multi-line quoted strings into one line Clint George
2025-11-19 13:08 ` [PATCH 6/8] usb: gadget: dummy_hcd: use sizeof(*ptr) instead of sizeof *ptr Clint George
2025-11-19 13:08 ` [PATCH 7/8] usb: gadget: dummy_hcd: remove unnecessary 'else' after return Clint George
2025-11-19 15:25   ` Greg KH
2025-11-19 13:08 ` [PATCH 8/8] usb: gadget: dummy_hcd: fix miscellaneous coding style warnings Clint George
2025-11-27 20:35 ` David Hunter [this message]
2025-12-01 20:37 ` [PATCH v2 0/6] usb: gadget: dummy_hcd: coding style improvements Clint George
2025-12-01 20:37   ` [PATCH v2 1/6] usb: gadget: dummy_hcd: replace symbolic permissions (S_IRUGO) with octal (0444) Clint George
2025-12-01 20:37   ` [PATCH v2 2/6] usb: gadget: dummy_hcd: use 'unsigned int' instead of bare 'unsigned' Clint George
2025-12-02  5:29     ` Greg KH
2025-12-01 20:37   ` [PATCH v2 3/6] usb: gadget: dummy_hcd: document ISO endpoint allocation pattern Clint George
2025-12-01 20:37   ` [PATCH v2 4/6] usb: gadget: dummy_hcd: use sizeof(*ptr) instead of sizeof *ptr Clint George
2025-12-01 20:37   ` [PATCH v2 5/6] usb: gadget: dummy_hcd: remove unnecessary parentheses Clint George
2025-12-01 20:37   ` [PATCH v2 6/6] usb: gadget: dummy_hcd: move function braces Clint George
2025-12-02  5:27   ` [PATCH v2 0/6] usb: gadget: dummy_hcd: coding style improvements Greg KH
2025-12-02 15:53     ` Alan Stern
2025-12-02 16:28       ` Robert P. J. Day
2025-12-04  1:01         ` David Hunter
2025-12-04  0:52       ` David Hunter
2025-12-04  0:43   ` David Hunter

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=70565b52-d42d-4808-84cd-ac8587c75b10@gmail.com \
    --to=david.hunter.linux@gmail.com \
    --cc=clintbgeorge@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=khalid@kernel.org \
    --cc=linux-kernel-mentees@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=stern@rowland.harvard.edu \
    /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