> -----Original Message-----
> From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
> Sent: Wednesday, April 26, 2023 4:25 PM
> To: Ping-Ke Shih <pkshih@xxxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Kalle Valo <kvalo@xxxxxxxxxx>
> Cc: netdev@xxxxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx
> Subject: Re: pull-request: wireless-next-2023-04-21
>
> 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.
Right. If all elements are the same type (e.g. __le32), it would be much easier.
The difficulty I want to say is backward compatibility.
>
> > > 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?
Yes, this is my point, and I think 6.5 _must_ deal with v1 file.
Considering below artificial drama:
1. kernel 6.4, driver support 2GHz channels only (table v1)
__le32 channel_tx_power_v1[2GHz_NUM]
2. kernel 6.5, driver support 2 + 5GHz channels (table v2)
__le32 channel_tx_power_v2[2GHz_NUM + 5GHz_NUM]
A user could not install v2, so I need a conversion, like
convert_v1_to_v2(struct table_v1 *v1, struct table_v2 *v2) // also disable 5GHz channels
3. kernel 6.6, driver support 2 + 5 + 6GHz channels (table v3)
__le32 channel_tx_power_v2[2GHz_NUM + 5GHz_NUM + 6GHz_NUM]
A user could not install v3, so I need an additional conversion, like
convert_v2_to_v3(struct table_v2 *v2, struct table_v3 *v3) // also disable 6GHz channels
If more table versions are introduced, more conversions are needed. Also,
I'm not sure how these tables can change in the future, so the conversion
may be complicated if they have a big change for certain reason.
My point is that this work is possible, but introduce some extra works that
maybe look a little dirty.
Ping-Ke
