On Wed, 2023-04-26 at 03:30 +0000, Ping-Ke Shih wrote:
> > >
> >
> > I think the extra work Kalle meant is what I mentioned previously --
> > need functions to convert old tables v1, v2, ... to current. Like,
> >
>
> struct table_v1 { // from file
> __le32 channel_tx_power[10];
> };
>
> struct table_v2 { // from file
> __le32 channel_tx_power[20];
> };
>
> struct table { // from file, the latest version of current use
> __le32 channel_tx_power[30];
> };
>
> struct table_cpu { // current table in cpu order
> u32 channel_tx_power[30];
> };
>
> To make example clearer, I change the name of fields, because the thing I
> want to mention is not register table that wouldn't need conversion.
Right, the file format would have to be __le32 (or __be32), but that's
pretty easy to handle while writing it to the device?
Not sure I understand the other thing about conversion.
> > If loading a table_v1 table, for example, we need to convert to table_cpu by
> > some rules. Also, maybe we need to disable some features relay on the values
> > introduced by table_cpu. I think it will work, but just add some flags and
> > rules to handle them.
But wouldn't this basically be tied to a driver? I mean you could have a
file called "rtlwifi/rtlxyz.v1.tables" that the driver in kernel 6.4
loads, and ...v2... that the driver in 6.5 loads, and requires for
operation?
Then again - it'd be better if the driver in 6.5 can deal with it if a
user didn't install the v2 file yet, is that what you meant?
> > Another question is about number of files for single device. Since firmware and
> > tables (e.g. TX power, registers) are released by different people, and they
> > maintain their own version, if I append tables to firmware, it's a little hard
> > to have a clear version code. So, I would like to know the rule if I can just
> > add additional one file for these tables?
Oh, I certainly wasn't trying to say that it should be done by combining
the file, just that it might be _easier_ to distribute this stuff then.
If not, then not!
johannes
