> -----Original Message-----
> From: Ping-Ke Shih <pkshih@xxxxxxxxxxx>
> Sent: Wednesday, April 26, 2023 11:16 AM
> To: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Kalle Valo
> <kvalo@xxxxxxxxxx>
> Cc: netdev@xxxxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx
> Subject: RE: pull-request: wireless-next-2023-04-21
>
> > -----Original Message-----
> > From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
> > Sent: Wednesday, April 26, 2023 1:09 AM
> > To: Jakub Kicinski <kuba@xxxxxxxxxx>; Kalle Valo <kvalo@xxxxxxxxxx>
> > Cc: Ping-Ke Shih <pkshih@xxxxxxxxxxx>; netdev@xxxxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx
> > Subject: Re: pull-request: wireless-next-2023-04-21
> >
> > On Tue, 2023-04-25 at 07:18 -0700, Jakub Kicinski wrote:
> > > On Tue, 25 Apr 2023 08:38:17 +0300 Kalle Valo wrote:
> > > > IIRC we discussed this back in initial rtw88 or rtw89 driver review (not
> > > > sure which one). At the time I pushed for the current solution to have
> > > > the initvals in static variables just to avoid any backwards
> > > > compatibility issues. I agree that the initvals in .c files are ugly but
> > > > is it worth all the extra effort and complexity to move them outside the
> > > > kernel? I'm starting to lean towards it's not worth all the extra work.
> > >
> > > I don't think it's that much extra work, the driver requires FW
> > > according to modinfo, anyway, so /lib/firmware is already required.
> >
> > If the firmware is sufficiently unique to a device (which is likely) it
> > could even just be appended to that same file, assuming the file format
> > has any kind of container layout. But even that could be done fairly
> > easily.
> >
>
> 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.
>
> 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.
>
>
> 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?
>
> Ping-Ke
>
>
> ------Please consider the environment before printing this e-mail.
