RE: [PATCH v2 1/4] rtw89: fill regd field of limit/limit_ru tables by enum

[Pkshih <pkshih@realtek.com>]

> -----Original Message-----
> From: Brian Norris <briannorris@chromium.org>
> Sent: Tuesday, November 2, 2021 10:07 AM
> To: Pkshih <pkshih@realtek.com>
> Cc: kvalo@codeaurora.org; linux-wireless@vger.kernel.org; Kevin Yang <kevin_yang@realtek.com>
> Subject: Re: [PATCH v2 1/4] rtw89: fill regd field of limit/limit_ru tables by enum
> 
> On Mon, Nov 01, 2021 at 05:31:03PM +0800, Ping-Ke Shih wrote:
> > From: Zong-Zhe Yang <kevin_yang@realtek.com>
> >
> > This modification just replaces the number filled in the regd field
> > with the corresponding enum. No assignment of a value in a table is
> > changed. Doing this first is because the follow-up patches may adjust
> > the order of enum declarations.
> >
> > Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
> > Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> > ---
> >  .../wireless/realtek/rtw89/rtw8852a_table.c   | 10458 ++++++++--------
> >  1 file changed, 5229 insertions(+), 5229 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852a_table.c
> b/drivers/net/wireless/realtek/rtw89/rtw8852a_table.c
> > index 3a4fe7207420..c7ebeed043c5 100644
> > --- a/drivers/net/wireless/realtek/rtw89/rtw8852a_table.c
> > +++ b/drivers/net/wireless/realtek/rtw89/rtw8852a_table.c
> > @@ -43384,5248 +43384,5248 @@ static const u8 _txpwr_track_delta_swingidx_2g_cck_a_p[] = {
> >  const s8 rtw89_8852a_txpwr_lmt_2g[RTW89_2G_BW_NUM][RTW89_NTX_NUM]
> >  				 [RTW89_RS_LMT_NUM][RTW89_BF_NUM]
> >  				 [RTW89_REGD_NUM][RTW89_2G_CH_NUM] = {
> > -	[0][0][0][0][0][0] = 56,
> 
> FWIW, these transformations worked out for me:
> 
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> 
> These files are still enormous though, which an enormous amount of
> repetition. I can't help but think there's a better way to do these
> things. For instance, if there's a repeated/shared pattern, one could
> just save that array once, and generate the repeated copies at runtime.
> Or instead of exposing an enormous const array directly to the "core",
> add some kind of abstraction function, where the function can perform
> more custom (and presumably more targeted, with less duplication?) logic
> to determine the answer.
> 

Our RF team measure the combinations of output power one by one for each
regulatory domain, so I think there is no a rule or pattern to generate
one from another one.

More, if we convert it to a reduced table and use the table, it will
be hard to align with our internal tables. Even, it becomes harder
to understand the patch if we "compress" the table in some ways.

I will discuss with our RF team if we can have any improvement of the size,
but still readable.

--
Ping-Ke