public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Luka Gejak <luka.gejak@linux.dev>
To: Dan Carpenter <error27@gmail.com>
Cc: Linus Probert <linus.probert@gmail.com>,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	linux-staging@lists.linux.dev, luka.gejak@linux.dev
Subject: Re: [PATCH 0/8] staging: rtl8723bs: remove warnings in rtw_btcoex.h
Date: Wed, 29 Apr 2026 14:18:55 +0200	[thread overview]
Message-ID: <5103B748-E9AE-4164-B81F-CB24326F3F7D@linux.dev> (raw)
In-Reply-To: <afH0RlRIDQdC08dV@stanley.mountain>

On April 29, 2026 2:06:30 PM GMT+02:00, Dan Carpenter <error27@gmail.com> wrote:
>On Wed, Apr 29, 2026 at 01:34:41PM +0200, Luka Gejak wrote:
>> On April 29, 2026 12:46:27 PM GMT+02:00, Linus Probert <linus.probert@gmail.com> wrote:
>> >On 2026-04-29 12:24:53+02:00, Luka Gejak wrote:
>> >> On April 29, 2026 12:18:12 PM GMT+02:00, Luka Gejak <luka.gejak@linux.dev> wrote:
>> >> 
>> >> >> This series eliminates all remaining checkpatch warnings in
>> >> >
>> >> >LGTM, so for the patch series:
>> >> >
>> >> >Reviewed-by: Luka Gejak <luka.gejak@linux.dev>
>> >> >
>> >> >Best regards,
>> >> >Luka Gejak
>> >> 
>> >> One note:
>> >> For the future cleanup series, feel free to squash identical logical 
>> >> changes into a single patch to keep the commit history concise. It's 
>> >> up to Greg if he wants v2 but logic is sound as is.
>> >> Best regards,
>> >> Luka Gejak
>> >
>> >I will make a note of that. In this case what do you consider an
>> >identical logical change? What would you suggest that I squash?
>> >
>> >Br,
>> >Linus
>> >
>> 
>> A logical change refers to the type of cleanup being done. In your 
>> series, patches 3-8 all do the exact same thing: fix CamelCase names 
>> for functions defined in rtw_btcoex.h. Instead of 6 separate commits, 
>> those could be squashed into a single patch. But as I already said it 
>> is up to Greg if he wants v2 or if he wants to keep v1 as is. Either 
>> way code itself is good.
>
>Greg has said in the past he prefers them all as separate changes the
>way this patchset does it.  He recently asked somone to split up a
>typedef patch into one typedef per patch.
>
>regards,
>dan carpenter
>

Thanks for that information Dan, I wasn't awear of that.
Best regards,
Luka Gejak

  reply	other threads:[~2026-04-29 12:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27 17:38 [PATCH 0/8] staging: rtl8723bs: remove warnings in rtw_btcoex.h Linus Probert
2026-04-27 17:38 ` [PATCH 1/8] staging: rtl8723bs: remove blank line " Linus Probert
2026-04-27 17:38 ` [PATCH 2/8] staging: rtl8723bs: add function definition arg names to rtw_btcoex.h Linus Probert
2026-04-27 17:38 ` [PATCH 3/8] staging: rtl8723bs: rename rtw_btcoex_MediaStatusNotify() Linus Probert
2026-04-27 17:38 ` [PATCH 4/8] staging: rtl8723bs: rename rtw_btcoex_media_status_notify definition arg Linus Probert
2026-04-27 17:38 ` [PATCH 5/8] staging: rtl8723bs: rtw_btcoex_HaltNotify() -> rtw_btcoex_halt_notify() Linus Probert
2026-04-27 17:38 ` [PATCH 6/8] staging: rtl8723bs: rename rtw_btcoex_RejectApAggregatedPacket() Linus Probert
2026-04-27 17:38 ` [PATCH 7/8] staging: rtl8723bs: rtw_btcoex_LPS_Enter() -> rtw_btcoex_lps_enter() Linus Probert
2026-04-27 17:38 ` [PATCH 8/8] staging: rtl8723bs: rename rtw_btcoex_LPS_Leave to rtw_btcoex_lps_leave Linus Probert
2026-04-29 10:18 ` [PATCH 0/8] staging: rtl8723bs: remove warnings in rtw_btcoex.h Luka Gejak
2026-04-29 10:24   ` Luka Gejak
2026-04-29 10:46     ` Linus Probert
2026-04-29 11:34       ` Luka Gejak
2026-04-29 12:06         ` Dan Carpenter
2026-04-29 12:18           ` Luka Gejak [this message]
2026-04-29 12:51             ` Linus Probert
2026-05-04 14:22               ` Greg KH

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=5103B748-E9AE-4164-B81F-CB24326F3F7D@linux.dev \
    --to=luka.gejak@linux.dev \
    --cc=error27@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linus.probert@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    /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