netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: Johannes Berg <johannes@sipsolutions.net>,
	Jakub Kicinski <kuba@kernel.org>, Kalle Valo <kvalo@kernel.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: pull-request: wireless-next-2023-04-21
Date: Wed, 26 Apr 2023 03:15:41 +0000	[thread overview]
Message-ID: <c69f151c77f34ae594dc2106bc68f2ac@realtek.com> (raw)
In-Reply-To: <77cf7fa9de20be55d50f03ccbdd52e3c8682b2b3.camel@sipsolutions.net>



> -----Original Message-----
> From: Johannes Berg <johannes@sipsolutions.net>
> Sent: Wednesday, April 26, 2023 1:09 AM
> To: Jakub Kicinski <kuba@kernel.org>; Kalle Valo <kvalo@kernel.org>
> Cc: Ping-Ke Shih <pkshih@realtek.com>; netdev@vger.kernel.org; linux-wireless@vger.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


  reply	other threads:[~2023-04-26  3:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-21 10:47 pull-request: wireless-next-2023-04-21 Kalle Valo
2023-04-21 14:39 ` Jakub Kicinski
2023-04-24 17:34   ` Kalle Valo
2023-04-25 20:52     ` Ryder Lee
2023-04-28  8:50   ` Kalle Valo
2023-04-21 14:54 ` Jakub Kicinski
2023-04-25  2:41   ` Ping-Ke Shih
2023-04-25  4:14     ` Gregg Wonderly
2023-04-25  4:42       ` Ping-Ke Shih
2023-04-25  5:38     ` Kalle Valo
2023-04-25 14:18       ` Jakub Kicinski
2023-04-25 17:08         ` Johannes Berg
2023-04-26  3:15           ` Ping-Ke Shih [this message]
2023-04-26  3:30             ` Ping-Ke Shih
2023-04-26  8:24               ` Johannes Berg
2023-04-27  0:38                 ` Ping-Ke Shih
2023-04-28 10:37                   ` Kalle Valo
2023-04-28 10:43         ` Kalle Valo
2023-05-01 22:08           ` Jakub Kicinski
2023-04-21 15:00 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c69f151c77f34ae594dc2106bc68f2ac@realtek.com \
    --to=pkshih@realtek.com \
    --cc=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).