From: Kalle Valo <kvalo@codeaurora.org>
To: Pkshih <pkshih@realtek.com>
Cc: "linux-wireless\@vger.kernel.org"
<linux-wireless@vger.kernel.org>,
"tony0620emma\@gmail.com" <tony0620emma@gmail.com>,
Bernie Huang <phhuang@realtek.com>
Subject: Re: [PATCH RESEND v3 0/8] rtw88: improve TX performance in field
Date: Mon, 18 Jan 2021 16:44:21 +0200 [thread overview]
Message-ID: <87a6t6gv96.fsf@codeaurora.org> (raw)
In-Reply-To: <1610698027.2741.26.camel@realtek.com> (pkshih@realtek.com's message of "Fri, 15 Jan 2021 08:07:43 +0000")
Pkshih <pkshih@realtek.com> writes:
> On Fri, 2021-01-15 at 09:52 +0200, Kalle Valo wrote:
>> Pkshih <pkshih@realtek.com> writes:
>>
>> > To avoid frequently submitting patches results from exceeding patch size
>> limit.
>> > I'd like to know the patch size limit accepted by patchwork.
>> > As I know, the limit is about 512k, so it is expected that below patches
>> > don't appear in patchwork
>> > 1. patch 5/5 of v1 (978K)
>> > 2. patch 6/7 of v2 (532K)
>> >
>> > But, I don't know why the table file (patch 16/18) of rtw89 whose size is
>> > 772k can appear in patchwork. Does patchwork have different limits of
>> > existing and new file? Moreover, if new file exceeds the limit someday,
>> > how can I deal with it? Can I split the new file into two or more patches?
>>
>> I suspect the mailing list limits the size, not patchwork. I did
>> directly get "[PATCH 5/5] rtw88: 8822c: update phy parameter tables to
>> v60" (Message-ID 20210113092312.13809-6-pkshih@realtek.com) as you added
>> me to CC. But I don't see it in lore, which points that linux-wireless
>> dropped it.
>>
>> Normally these huge patches would not be applied being to big, but
>> updating parameter tables is a good exception to the rule and I can
>> commit those manually directly from my INBOX. So for huge patches I
>> recommend:
>>
>> * move the patch as the last patch in the patchset
>>
>> * the huge patch should only have changes to parameter variables, ie.
>> refactor changes to the actual code to a separate patch
>>
>> * add kvalo@codeaurora.org to CC
>>
>> * add a big warning to the cover letter (or reply afterwards) so that I
>> notice the huge patch is missing from patchwork
>>
>> Would this work?
>>
>
> Yes, it works. Many thanks.
>
> I would like to know if it is accepted to split the big one into two or
> more patches, like my v3? Or, I should recall v1 style when I submit v4?
For me splitting the patch into smaller patches (which are visible in
patchwork) is easier as then I don't need to do any manual work. When
splitting patches just make sure that the requirement of every patch
compiling without warnings is fulfilled.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2021-01-18 14:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-14 1:09 [PATCH RESEND v3 0/8] rtw88: improve TX performance in field Ping-Ke Shih
2021-01-14 1:09 ` [PATCH RESEND v3 1/8] rtw88: add dynamic rrsr configuration Ping-Ke Shih
2021-01-14 1:09 ` [PATCH RESEND v3 2/8] rtw88: add rts condition Ping-Ke Shih
2021-01-14 1:09 ` [PATCH RESEND v3 3/8] rtw88: add napi support Ping-Ke Shih
2021-01-14 1:09 ` [PATCH RESEND v3 4/8] rtw88: replace tx tasklet with tx work Ping-Ke Shih
2021-01-14 18:34 ` Brian Norris
2021-01-14 18:41 ` Kalle Valo
2021-01-14 1:09 ` [PATCH RESEND v3 5/8] rtw88: 8822c: update MAC/BB parameter tables to v60 Ping-Ke Shih
2021-01-14 1:09 ` [PATCH RESEND v3 6/8] rtw88: 8822c: update RF_A " Ping-Ke Shih
2021-01-14 1:09 ` [PATCH RESEND v3 7/8] rtw88: 8822c: update RF_B (1/2) " Ping-Ke Shih
2021-01-14 1:09 ` [PATCH RESEND v3 8/8] rtw88: 8822c: update RF_B (2/2) " Ping-Ke Shih
2021-01-14 7:21 ` [PATCH RESEND v3 0/8] rtw88: improve TX performance in field Kalle Valo
2021-01-15 1:17 ` Pkshih
2021-01-15 7:52 ` Kalle Valo
2021-01-15 8:07 ` Pkshih
2021-01-18 14:44 ` Kalle Valo [this message]
2021-01-19 2:15 ` Pkshih
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=87a6t6gv96.fsf@codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=phhuang@realtek.com \
--cc=pkshih@realtek.com \
--cc=tony0620emma@gmail.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).