netdev - RE: pull-request: wireless-next-2023-04-21

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Apr 2023 03:30:55 +0000
From:   Ping-Ke Shih <pkshih@...ltek.com>
To:     Ping-Ke Shih <pkshih@...ltek.com>,
        Johannes Berg <johannes@...solutions.net>,
        Jakub Kicinski <kuba@...nel.org>, Kalle Valo <kvalo@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Subject: RE: pull-request: wireless-next-2023-04-21



> -----Original Message-----
> From: Ping-Ke Shih <pkshih@...ltek.com>
> Sent: Wednesday, April 26, 2023 11:16 AM
> To: Johannes Berg <johannes@...solutions.net>; Jakub Kicinski <kuba@...nel.org>; Kalle Valo
> <kvalo@...nel.org>
> Cc: netdev@...r.kernel.org; linux-wireless@...r.kernel.org
> Subject: RE: pull-request: wireless-next-2023-04-21
> 
> > -----Original Message-----
> > From: Johannes Berg <johannes@...solutions.net>
> > Sent: Wednesday, April 26, 2023 1:09 AM
> > To: Jakub Kicinski <kuba@...nel.org>; Kalle Valo <kvalo@...nel.org>
> > Cc: Ping-Ke Shih <pkshih@...ltek.com>; netdev@...r.kernel.org; linux-wireless@...r.kernel.org
> > 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.