| Message ID | 20210114010950.3316-1-pkshih@realtek.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | rtw88: improve TX performance in field | expand |
Ping-Ke Shih <pkshih@realtek.com> writes: > 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 Please avoid using "RESEND", instead just increase the version (in this case you should have used v4). Makes my sorting easier and it's not like we are running out of numbers for versions :) And mailing lists and patchwork can be slow sometimes (recently more often), so please wait at least 12h before resubmitting any patches. Now both v3 and "v3 RESEND" are in patchwork.
On Thu, 2021-01-14 at 07:21 +0000, Kalle Valo wrote: > Ping-Ke Shih <pkshih@realtek.com> writes: > > > 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 > > Please avoid using "RESEND", instead just increase the version (in this > case you should have used v4). Makes my sorting easier and it's not like > we are running out of numbers for versions :) > > And mailing lists and patchwork can be slow sometimes (recently more > often), so please wait at least 12h before resubmitting any patches. Now > both v3 and "v3 RESEND" are in patchwork. > Sorry for the mess. I'll follow your guides for further submission. 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? --- Ping-Ke
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?
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.
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(-)