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]

Message-ID: <c69f151c77f34ae594dc2106bc68f2ac@realtek.com>
Date:   Wed, 26 Apr 2023 03:15:41 +0000
From:   Ping-Ke Shih <pkshih@...ltek.com>
To:     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: 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 data[10];
};

struct table_v2 { // from file
   __le32 data[20];
};

struct table {    // from file, the latest version of current use
   __le32 data[30];
};

struct table_cpu {  // current table in cpu order
   u32 data[30];
};

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