Search Linux Wireless

Re: [PATCH 01/12] rtwlan: main files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 04, 2018 at 11:19:59AM -0500, Larry Finger wrote:
> On 10/4/18 8:42 AM, Stanislaw Gruszka wrote:
> >On Thu, Oct 04, 2018 at 03:39:55PM +0300, Kalle Valo wrote:
> >>>>Can we put the configuration file in the firmware directory?
> >>>>Should we package them into binary files? Or just put the raw data.
> >>>>
> >>>>We can test the performance for it. After we got the result, we will make a decision
> >>>>about it. And if we decide to put them in the firmware directory, will send a patch.
> >>>>For now, I think we can just leave them in the .c.
> >>>
> >>>Yes, you could put the configuration files in the firmware directory.
> >>>I would put them in binary form, not as text files. That way the size
> >>>would be smaller, and it would not be possible to alter them,
> >>>particularly if the binary file is checksummed.
> >>>
> >>>It would likely be OK if only the agc table was stored in this way.
> >>>That would take away about half of the lines in the 8822b table file.
> >>
> >>So what's the worry here? The lines of source code, binary size or what?
> >>
> >>  .../net/wireless/realtek/rtw88/rtw8822b_table.c    | 20783 +++++++++++++++++++
> >>
> >>Looking at the diffstat rtw8822b_table.c seems to be 20 kLOC, IMHO it's
> >>not that bad as it's just data. But of course I might be missing
> >>something as I haven't checked patches yet.
> >
> >My concern was it's plenty of redundant data, for example:
> >
> >         0x81C, 0xFF000003,
> >         0x81C, 0xFE000003,
> >         0x81C, 0xFD020003,
> >         0x81C, 0xFC040003,
> >         0x81C, 0xFB060003,
> >         0x81C, 0xFA080003,
> >         0x81C, 0xF90A0003,
> >         0x81C, 0xF80C0003,
> >         0x81C, 0xF70E0003,
> >         0x81C, 0xF6100003,
> >
> >Approx 10000 lines like this, braked by lines like this
> >
> >         0x90000012,     0x00000000,     0x40000000,     0x00000000,
> >
> >in more or less regular way.
> >
> >Not big deal, but perhaps this could be coded in much more compact way.
> 
> What should be the tradeoff between large tables of redundant data
> and complicated generation and interpretation? I think this table
> should be converted to binary in its present form and added to the
> "firmware", the way that is done for b43. That way the source is
> smaller, and the loading will be only a bit more time consuming.

If at stake is bigger data and simpler parsing/processing I would take
that. But processing is already complex (see RTW_DECL_TABLE* and
related functions) and I hope rearranging the data structures could
even lead to simplified processing.

Thanks
Stanislaw 



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux