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 10:24:53 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Ping-Ke Shih <pkshih@...ltek.com>,
        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

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