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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.