| Message ID | 20210114010950.3316-1-pkshih@realtek.com |
|---|---|
| Headers | show |
| Series | rtw88: improve TX performance in field | expand |
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? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
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? -- Ping-Ke
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
On Mon, 2021-01-18 at 14:44 +0000, Kalle Valo wrote: > 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. > OK. Thanks for your patience to answer my questions. -- Ping-Ke
Improve TX performance in aspects of protocol and software design. Also, update PHY parameters to fix incorrect RSSI report. v2: Since 5/5 of v1 is too large, I split it into three patches. v3: Since 6/7 of v2 is still too large for patchwork, I split parameter into four patches. --- RESEND v3 due to no appearance of patchwork --- Po-Hao Huang (8): rtw88: add dynamic rrsr configuration rtw88: add rts condition rtw88: add napi support rtw88: replace tx tasklet with tx work rtw88: 8822c: update MAC/BB parameter tables to v60 rtw88: 8822c: update RF_A parameter tables to v60 rtw88: 8822c: update RF_B (1/2) parameter tables to v60 rtw88: 8822c: update RF_B (2/2) parameter tables to v60 drivers/net/wireless/realtek/rtw88/mac80211.c | 2 +- drivers/net/wireless/realtek/rtw88/main.c | 10 +- drivers/net/wireless/realtek/rtw88/main.h | 8 +- drivers/net/wireless/realtek/rtw88/pci.c | 108 +- drivers/net/wireless/realtek/rtw88/pci.h | 5 + drivers/net/wireless/realtek/rtw88/phy.c | 62 +- drivers/net/wireless/realtek/rtw88/phy.h | 3 + drivers/net/wireless/realtek/rtw88/reg.h | 2 + drivers/net/wireless/realtek/rtw88/rtw8822c.h | 2 - .../wireless/realtek/rtw88/rtw8822c_table.c | 32755 ++++++++++++---- drivers/net/wireless/realtek/rtw88/tx.c | 11 +- drivers/net/wireless/realtek/rtw88/tx.h | 6 +- drivers/net/wireless/realtek/rtw88/util.c | 20 + drivers/net/wireless/realtek/rtw88/util.h | 54 + 14 files changed, 24667 insertions(+), 8381 deletions(-)