| Message ID | 20230421104726.800BCC433D2@smtp.kernel.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | pull-request: wireless-next-2023-04-21 | expand |
On Fri, 21 Apr 2023 10:47:26 +0000 (UTC) Kalle Valo wrote: > Hi, > > here's a pull request to net-next tree, more info below. Please let me know if > there are any problems. Sparse warning to follow up on: drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: warning: invalid assignment: |= drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: left side has type restricted __le32 drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: right side has type unsigned long
On Fri, 21 Apr 2023 10:47:26 +0000 (UTC) Kalle Valo wrote: > .../net/wireless/realtek/rtw89/rtw8851b_table.c | 14824 +++++++++++++++++++ > .../net/wireless/realtek/rtw89/rtw8851b_table.h | 21 + We should load these like FW, see the proposal outlined in https://lore.kernel.org/all/20221116222339.54052a83@kernel.org/ for example. Would that not work? The huge register tables in C sources makes it look like a Windows drivers :(
Hello: This pull request was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba@kernel.org>: On Fri, 21 Apr 2023 10:47:26 +0000 (UTC) you wrote: > Hi, > > here's a pull request to net-next tree, more info below. Please let me know if > there are any problems. > > Kalle > > [...] Here is the summary with links: - pull-request: wireless-next-2023-04-21 https://git.kernel.org/netdev/net-next/c/ca2889658015 You are awesome, thank you!
Jakub Kicinski <kuba@kernel.org> writes: > On Fri, 21 Apr 2023 10:47:26 +0000 (UTC) Kalle Valo wrote: >> Hi, >> >> here's a pull request to net-next tree, more info below. Please let me know if >> there are any problems. > > Sparse warning to follow up on: > > drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: warning: > invalid assignment: |= > drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: left side has > type restricted __le32 > drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: right side > has type unsigned long Ah, sorry about that. We still have some sparse warnings left so I don't check them for each pull request. We should fix all the remaining sparse warnings in drivers/net/wireless, any volunteers? :) Would be a good task for a newcomer. Felix, could you submit a fix for this? I can then apply it to wireless tree and send a pull request to net tree in two weeks or so.
> -----Original Message----- > From: Jakub Kicinski <kuba@kernel.org> > Sent: Friday, April 21, 2023 10:54 PM > To: Kalle Valo <kvalo@kernel.org> > Cc: netdev@vger.kernel.org; linux-wireless@vger.kernel.org > Subject: Re: pull-request: wireless-next-2023-04-21 > > On Fri, 21 Apr 2023 10:47:26 +0000 (UTC) Kalle Valo wrote: > > .../net/wireless/realtek/rtw89/rtw8851b_table.c | 14824 +++++++++++++++++++ > > .../net/wireless/realtek/rtw89/rtw8851b_table.h | 21 + > > We should load these like FW, see the proposal outlined in > https://lore.kernel.org/all/20221116222339.54052a83@kernel.org/ > for example. Would that not work? > That would work, and I think struct fields addr and val should be __le32. And, I have some draft ideas to handle some situations we will face: 1. upgrading to newer driver without built-in tables will break user space if people don't download table file from linux-firmware.git. Maybe, we can keep the built-in tables and support loading from files for couple years at least. 2. c code can do changes along with these tables, so driver should do some compatibility things for register version. 3. The file contains not only simple registers tables but also TX power tables and power tracking tables. These tables are multiple dimensions, and dimensions can be changed due to more channels are supported, for example. To be backward compatible, we need to add conversion function from v1, v2 ... to current. I will think further to make this change smooth. Ping-Ke
Could this be expressed in a /proc structure of files and directories? Gregg Wonderly > On Apr 24, 2023, at 9:41 PM, Ping-Ke Shih <pkshih@realtek.com> wrote: > > > >> -----Original Message----- >> From: Jakub Kicinski <kuba@kernel.org> >> Sent: Friday, April 21, 2023 10:54 PM >> To: Kalle Valo <kvalo@kernel.org> >> Cc: netdev@vger.kernel.org; linux-wireless@vger.kernel.org >> Subject: Re: pull-request: wireless-next-2023-04-21 >> >> On Fri, 21 Apr 2023 10:47:26 +0000 (UTC) Kalle Valo wrote: >>> .../net/wireless/realtek/rtw89/rtw8851b_table.c | 14824 +++++++++++++++++++ >>> .../net/wireless/realtek/rtw89/rtw8851b_table.h | 21 + >> >> We should load these like FW, see the proposal outlined in >> https://lore.kernel.org/all/20221116222339.54052a83@kernel.org/ >> for example. Would that not work? >> > > That would work, and I think struct fields addr and val should be __le32. > And, I have some draft ideas to handle some situations we will face: > > 1. upgrading to newer driver without built-in tables will break user space > if people don't download table file from linux-firmware.git. > Maybe, we can keep the built-in tables and support loading from files > for couple years at least. > > 2. c code can do changes along with these tables, so driver should do some > compatibility things for register version. > > 3. The file contains not only simple registers tables but also TX power tables > and power tracking tables. These tables are multiple dimensions, and > dimensions can be changed due to more channels are supported, for example. > To be backward compatible, we need to add conversion function from > v1, v2 ... to current. > > I will think further to make this change smooth. > > Ping-Ke >
Hi Gregg, (no top posting for wireless mailing list, so I move your post to bottom) > -----Original Message----- > From: Gregg Wonderly <greggwonderly@seqtechllc.com> > Sent: Tuesday, April 25, 2023 12:15 PM > To: Ping-Ke Shih <pkshih@realtek.com> > Cc: Jakub Kicinski <kuba@kernel.org>; Kalle Valo <kvalo@kernel.org>; netdev@vger.kernel.org; > linux-wireless@vger.kernel.org > Subject: Re: pull-request: wireless-next-2023-04-21 > > > On Apr 24, 2023, at 9:41 PM, Ping-Ke Shih <pkshih@realtek.com> wrote: > > > > > > > >> -----Original Message----- > >> From: Jakub Kicinski <kuba@kernel.org> > >> Sent: Friday, April 21, 2023 10:54 PM > >> To: Kalle Valo <kvalo@kernel.org> > >> Cc: netdev@vger.kernel.org; linux-wireless@vger.kernel.org > >> Subject: Re: pull-request: wireless-next-2023-04-21 > >> > >> On Fri, 21 Apr 2023 10:47:26 +0000 (UTC) Kalle Valo wrote: > >>> .../net/wireless/realtek/rtw89/rtw8851b_table.c | 14824 +++++++++++++++++++ > >>> .../net/wireless/realtek/rtw89/rtw8851b_table.h | 21 + > >> > >> We should load these like FW, see the proposal outlined in > >> https://lore.kernel.org/all/20221116222339.54052a83@kernel.org/ > >> for example. Would that not work? > >> > > > > That would work, and I think struct fields addr and val should be __le32. > > And, I have some draft ideas to handle some situations we will face: > > > > 1. upgrading to newer driver without built-in tables will break user space > > if people don't download table file from linux-firmware.git. > > Maybe, we can keep the built-in tables and support loading from files > > for couple years at least. > > > > 2. c code can do changes along with these tables, so driver should do some > > compatibility things for register version. > > > > 3. The file contains not only simple registers tables but also TX power tables > > and power tracking tables. These tables are multiple dimensions, and > > dimensions can be changed due to more channels are supported, for example. > > To be backward compatible, we need to add conversion function from > > v1, v2 ... to current. > > > > I will think further to make this change smooth. > > > > Could this be expressed in a /proc structure of files and directories? > I'm not clear what you meant. Could you please give me an example for reference? Ping-Ke
Ping-Ke Shih <pkshih@realtek.com> writes: >> -----Original Message----- >> From: Jakub Kicinski <kuba@kernel.org> >> Sent: Friday, April 21, 2023 10:54 PM >> To: Kalle Valo <kvalo@kernel.org> >> Cc: netdev@vger.kernel.org; linux-wireless@vger.kernel.org >> Subject: Re: pull-request: wireless-next-2023-04-21 >> >> On Fri, 21 Apr 2023 10:47:26 +0000 (UTC) Kalle Valo wrote: >> > .../net/wireless/realtek/rtw89/rtw8851b_table.c | 14824 +++++++++++++++++++ >> > .../net/wireless/realtek/rtw89/rtw8851b_table.h | 21 + >> >> We should load these like FW, see the proposal outlined in >> https://lore.kernel.org/all/20221116222339.54052a83@kernel.org/ >> for example. Would that not work? >> > > That would work, and I think struct fields addr and val should be __le32. > And, I have some draft ideas to handle some situations we will face: > > 1. upgrading to newer driver without built-in tables will break user space > if people don't download table file from linux-firmware.git. > Maybe, we can keep the built-in tables and support loading from files > for couple years at least. > > 2. c code can do changes along with these tables, so driver should do some > compatibility things for register version. > > 3. The file contains not only simple registers tables but also TX power tables > and power tracking tables. These tables are multiple dimensions, and > dimensions can be changed due to more channels are supported, for example. > To be backward compatible, we need to add conversion function from > v1, v2 ... to current. > > I will think further to make this change smooth. 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. For me most important is that backwards compatibility is not broken, that would be bad for the users. So whatever we decide let's keep that in mind.
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. And on smaller systems with few hundred MB of RAM it'd be nice to not hold all the stuff in kernel memory, I'd think. We have a rule against putting FW as a static table in the driver source, right? Or did we abandon that? Isn't this fundamentally similar? > For me most important is that backwards compatibility is not broken, > that would be bad for the users. So whatever we decide let's keep that > in mind. Right, not for existing devices, only when new device is added.
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. johannes
On Mon, 2023-04-24 at 20:34 +0300, Kalle Valo wrote: > External email : Please do not click links or open attachments until > you have verified the sender or the content. > > > Jakub Kicinski <kuba@kernel.org> writes: > > > On Fri, 21 Apr 2023 10:47:26 +0000 (UTC) Kalle Valo wrote: > > > Hi, > > > > > > here's a pull request to net-next tree, more info below. Please > > > let me know if > > > there are any problems. > > > > Sparse warning to follow up on: > > > > drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: warning: > > invalid assignment: |= > > drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: left side > > has > > type restricted __le32 > > drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: right side > > has type unsigned long > > Ah, sorry about that. We still have some sparse warnings left so I > don't > check them for each pull request. We should fix all the remaining > sparse > warnings in drivers/net/wireless, any volunteers? :) Would be a good > task for a newcomer. > > Felix, could you submit a fix for this? I can then apply it to > wireless > tree and send a pull request to net tree in two weeks or so. > My bad. I've posted a fix for that. [1/2] wifi: mt76: mt7996: fix endianness of MT_TXD6_TX_RATE Ryder
> -----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
> -----Original Message----- > From: Ping-Ke Shih <pkshih@realtek.com> > Sent: Wednesday, April 26, 2023 11:16 AM > To: Johannes Berg <johannes@sipsolutions.net>; Jakub Kicinski <kuba@kernel.org>; Kalle Valo > <kvalo@kernel.org> > Cc: netdev@vger.kernel.org; linux-wireless@vger.kernel.org > Subject: RE: pull-request: wireless-next-2023-04-21 > > > -----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 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.
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
> -----Original Message----- > From: Johannes Berg <johannes@sipsolutions.net> > Sent: Wednesday, April 26, 2023 4:25 PM > To: Ping-Ke Shih <pkshih@realtek.com>; Jakub Kicinski <kuba@kernel.org>; Kalle Valo <kvalo@kernel.org> > Cc: netdev@vger.kernel.org; linux-wireless@vger.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. Right. If all elements are the same type (e.g. __le32), it would be much easier. The difficulty I want to say is backward compatibility. > > > > 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? Yes, this is my point, and I think 6.5 _must_ deal with v1 file. Considering below artificial drama: 1. kernel 6.4, driver support 2GHz channels only (table v1) __le32 channel_tx_power_v1[2GHz_NUM] 2. kernel 6.5, driver support 2 + 5GHz channels (table v2) __le32 channel_tx_power_v2[2GHz_NUM + 5GHz_NUM] A user could not install v2, so I need a conversion, like convert_v1_to_v2(struct table_v1 *v1, struct table_v2 *v2) // also disable 5GHz channels 3. kernel 6.6, driver support 2 + 5 + 6GHz channels (table v3) __le32 channel_tx_power_v2[2GHz_NUM + 5GHz_NUM + 6GHz_NUM] A user could not install v3, so I need an additional conversion, like convert_v2_to_v3(struct table_v2 *v2, struct table_v3 *v3) // also disable 6GHz channels If more table versions are introduced, more conversions are needed. Also, I'm not sure how these tables can change in the future, so the conversion may be complicated if they have a big change for certain reason. My point is that this work is possible, but introduce some extra works that maybe look a little dirty. Ping-Ke
Jakub Kicinski <kuba@kernel.org> writes: > On Fri, 21 Apr 2023 10:47:26 +0000 (UTC) Kalle Valo wrote: >> Hi, >> >> here's a pull request to net-next tree, more info below. Please let me know if >> there are any problems. > > Sparse warning to follow up on: > > drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: warning: invalid assignment: |= > drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: left side has type restricted __le32 > drivers/net/wireless/mediatek/mt76/mt7996/mac.c:1091:25: right side has type unsigned long This patch should fix it: https://patchwork.kernel.org/project/linux-wireless/patch/16fa938373e3b145cb07a2c98d2428fea2abadba.1682285873.git.ryder.lee@mediatek.com/
Ping-Ke Shih <pkshih@realtek.com> writes: >> > > 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? > > Yes, this is my point, and I think 6.5 _must_ deal with v1 file. I agree. In this example the time between v6.4 and v6.5 is roughly three months, so we can't drop v1 support that fast as there will be people upgrading their kernels but don't have the v2 firmware file yet. I would say supporting one year is too short (think LTS distros etc) so to be on the safe side we should support old firmware files at least for two years. That's a long time. > Considering below artificial drama: > > 1. kernel 6.4, driver support 2GHz channels only (table v1) > __le32 channel_tx_power_v1[2GHz_NUM] > > 2. kernel 6.5, driver support 2 + 5GHz channels (table v2) > __le32 channel_tx_power_v2[2GHz_NUM + 5GHz_NUM] > > A user could not install v2, so I need a conversion, like > convert_v1_to_v2(struct table_v1 *v1, struct table_v2 *v2) // also > disable 5GHz channels > > 3. kernel 6.6, driver support 2 + 5 + 6GHz channels (table v3) > __le32 channel_tx_power_v2[2GHz_NUM + 5GHz_NUM + 6GHz_NUM] > A user could not install v3, so I need an additional conversion, like > convert_v2_to_v3(struct table_v2 *v2, struct table_v3 *v3) // also > disable 6GHz channels This is exactly what I'm worried about. And we have also the case that user space doesn't have the initval.bin file at all so we need to have initvals in kernel for something like two years. > If more table versions are introduced, more conversions are needed. Also, > I'm not sure how these tables can change in the future, so the conversion > may be complicated if they have a big change for certain reason. > > My point is that this work is possible, but introduce some extra works that > maybe look a little dirty. Also I agree here. This creates complexity and that of course increases the risk of bugs. Even if it sounds simple, in practise it's not. Of course if the initvals don't change then it's easier, but I would not rely on that.
Jakub Kicinski <kuba@kernel.org> writes: > 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. > And on smaller systems with few hundred MB of RAM it'd be nice to not > hold all the stuff in kernel memory, I'd think. Later in this thread Ping explained pretty well the challenges here, that sums exactly what I'm worried about. > We have a rule against putting FW as a static table in the driver > source, right? Or did we abandon that? Isn't this fundamentally similar? My understanding is that these are just initialisation values for hardware, not executable code. (Ping, please correct me if I misunderstood.) So that's why I thought these are ok to have in kernel. So I took practicality over elegance here.
On Fri, 28 Apr 2023 13:43:16 +0300 Kalle Valo wrote: > > I don't think it's that much extra work, the driver requires FW > > according to modinfo, anyway, so /lib/firmware is already required. > > And on smaller systems with few hundred MB of RAM it'd be nice to not > > hold all the stuff in kernel memory, I'd think. > > Later in this thread Ping explained pretty well the challenges here, > that sums exactly what I'm worried about. > > > We have a rule against putting FW as a static table in the driver > > source, right? Or did we abandon that? Isn't this fundamentally similar? > > My understanding is that these are just initialisation values for > hardware, not executable code. (Ping, please correct me if I > misunderstood.) So that's why I thought these are ok to have in kernel. > So I took practicality over elegance here. Alright, I'll try to make someone else do this outside of wireless, and come back with real life experience disproving the concerns :)
Hi, here's a pull request to net-next tree, more info below. Please let me know if there are any problems. Kalle The following changes since commit b536f32b5b034f592df0f0ba129ad59fa0f3e532: net: stmmac: dwmac-imx: use platform specific reset for imx93 SoCs (2023-04-05 19:01:22 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git tags/wireless-next-2023-04-21 for you to fetch changes up to 3288ee5844b74cebb94ed15bc9b5b9d3223ae038: Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2023-04-20 19:43:45 +0300) ---------------------------------------------------------------- wireless-next patches for v6.4 Most likely the last -next pull request for v6.4. We have changes all over. rtw88 now supports SDIO bus and iwlwifi continues to work on Wi-Fi 7 support. Not much stack changes this time. Major changes: cfg80211/mac80211 * fix some Fine Time Measurement (FTM) frames not being bufferable * flush frames before key removal to avoid potential unencrypted transmission depending on the hardware design iwlwifi * preparation for Wi-Fi 7 EHT and multi-link support rtw88 * SDIO bus support * RTL8822BS, RTL8822CS and RTL8821CS SDIO chipset support rtw89 * framework firmware backwards compatibility brcmfmac * Cypress 43439 SDIO support mt76 * mt7921 P2P support * mt7996 mesh A-MSDU support * mt7996 EHT support * mt7996 coredump support wcn36xx * support for pronto v3 hardware ath11k * PCIe DeviceTree bindings * WCN6750: enable SAR support ath10k * convert DeviceTree bindings to YAML ---------------------------------------------------------------- Aaradhana Sahu (1): wifi: ath12k: fix packets are sent in native wifi mode while we set raw mode Aditya Kumar Singh (2): wifi: ath11k: fix deinitialization of firmware resources wifi: ath12k: fix firmware assert during channel switch for peer sta Aloka Dixit (1): wifi: mac80211: set EHT support flag in AP mode Alon Giladi (2): wifi: iwlwifi: acpi: support modules with high antenna gain wifi: iwlwifi: fw: fix argument to efi.get_variable Arnd Bergmann (1): wifi: airo: remove ISA_DMA_API dependency Avraham Stern (10): wifi: iwlwifi: mvm: use OFDM rate if IEEE80211_TX_CTL_NO_CCK_RATE is set wifi: iwlwifi: trans: don't trigger d3 interrupt twice wifi: iwlwifi: mvm: don't set CHECKSUM_COMPLETE for unsupported protocols wifi: iwlwifi: mvm: fix shift-out-of-bounds wifi: iwlwifi: mvm: make HLTK configuration for PASN station optional wifi: iwlwifi: mvm: avoid iterating over an un-initialized list wifi: iwlwifi: modify scan request and results when in link protection wifi: iwlwifi: mei: make mei filtered scan more aggressive wifi: iwlwifi: mei: re-ask for ownership after it was taken by CSME wifi: iwlwifi: mvm: fix RFKILL report when driver is going down Ayala Beker (2): wifi: iwlwifi: mvm: don't drop unencrypted MCAST frames wifi: iwlwifi: mvm: scan legacy bands and UHB channels with same antenna Baochen Qiang (2): wifi: ath12k: Identify DFS channel when sending scan channel list command wifi: ath12k: Enable IMPS for WCN7850 Bastian Germann (1): wifi: ath9k: Remove Qwest/Actiontec 802AIN ID Bhagavathi Perumal S (1): wifi: ath11k: Fix invalid management rx frame length issue Bitterblue Smith (5): wifi: rtl8xxxu: Clean up some messy ifs wifi: rtl8xxxu: Support devices with 5-6 out endpoints wifi: rtl8xxxu: Don't print the vendor/product/serial wifi: rtl8xxxu: Add rtl8xxxu_write{8,16,32}_{set,clear} wifi: rtl8xxxu: Simplify setting the initial gain Bo Jiao (1): wifi: mt76: mt7996: enable full system reset support Cai Huoqing (3): wifi: ath11k: Remove redundant pci_clear_master wifi: ath10k: Remove redundant pci_clear_master wifi: ath12k: Remove redundant pci_clear_master Chih-Kang Chang (2): wifi: rtw89: fix power save function in WoWLAN mode wifi: rtw89: prohibit enter IPS during HW scan Chin-Yen Lee (1): wifi: rtw89: support WoWLAN mode for 8852be Ching-Te Ku (3): wifi: rtw89: coex: Enable Wi-Fi RX gain control for free run solution wifi: rtw89: coex: Add path control register to monitor list wifi: rtw89: coex: Update function to get BT RSSI and hardware counter Colin Ian King (2): wifi: iwlwifi: Fix spelling mistake "upto" -> "up to" wifi: iwlwifi: mvm: Fix spelling mistake "Gerenal" -> "General" Dan Carpenter (1): wifi: mt76: mt7915: unlock on error in mt7915_thermal_temp_store() Daniel Gabay (4): wifi: iwlwifi: nvm: Update HE capabilities on 6GHz band for EHT device wifi: iwlwifi: pcie: fix possible NULL pointer dereference wifi: iwlwifi: yoyo: skip dump correctly on hw error wifi: iwlwifi: yoyo: Fix possible division by zero Deren Wu (3): wifi: mt76: remove redundent MCU_UNI_CMD_* definitions wifi: mt76: mt7921: fix wrong command to set STA channel wifi: mt76: mt7921: fix PCI DMA hang after reboot Emmanuel Grumbach (2): wifi: iwlwifi: make the loop for card preparation effective wifi: iwlwifi: mvm: adopt the latest firmware API Eric Dumazet (1): wifi: mac80211_hwsim: fix potential NULL deref in hwsim_pmsr_report_nl() Eric Huang (2): wifi: rtw89: use hardware CFO to improve performance wifi: rtw89: correct 5 MHz mask setting Felix Fietkau (5): wifi: mt76: add missing locking to protect against concurrent rx/status calls wifi: mac80211: remove ieee80211_tx_status_8023 wifi: mt76: mt7615: increase eeprom size for mt7663 wifi: mt76: dma: use napi_build_skb wifi: mt76: set NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 on supported drivers Frank Wunderlich (1): dt-bindings: mt76: add active-low property for led Ganesh Babu Jothiram (1): wifi: ath11k: Configure the FTM responder role using firmware capability flag Golan Ben Ami (2): wifi: iwlwifi: mvm: enable bz hw checksum from c step wifi: iwlwifi: move debug buffer allocation failure to info verbosity Gregory Greenman (7): wifi: iwlwifi: mvm: fix the order of TIMING_MEASUREMENT notifications wifi: iwlwifi: fix duplicate entry in iwl_dev_info_table wifi: iwlwifi: call napi_synchronize() before freeing rx/tx queues wifi: iwlwifi: bump FW API to 77 for AX devices wifi: iwlwifi: mvm: update mac id management wifi: iwlwifi: bump FW API to 78 for AX devices wifi: iwlwifi: mvm: enable support for MLO APIs Gustavo A. R. Silva (5): wifi: ath11k: Replace fake flex-array with flexible-array member wifi: carl9170: Fix multiple -Warray-bounds warnings wifi: carl9170: Replace fake flex-array with flexible-array member wifi: mt76: Replace zero-length array with flexible-array member wifi: mt76: mt7921: Replace fake flex-arrays with flexible-array members Haim Dreyfuss (1): wifi: iwlwifi: mvm: support wowlan info notification version 2 Hans de Goede (1): wifi: iwlwifi: dvm: Fix memcpy: detected field-spanning write backtrace Harshit Mogalapalli (1): wifi: ath12k: Add missing unwind goto in ath12k_pci_probe() Harshitha Prem (8): wifi: ath11k: fix BUFFER_DONE read on monitor ring rx buffer wifi: ath12k: fix incorrect handling of AMSDU frames wifi: ath12k: incorrect channel survey dump wifi: ath11k: Ignore frags from uninitialized peer in dp. wifi: ath11k: fix undefined behavior with __fls in dp wifi: ath11k: fix double free of peer rx_tid during reo cmd failure wifi: ath11k: Prevent REO cmd failures wifi: ath11k: add peer mac information in failure cases Howard Hsu (1): wifi: mt76: mt7915: rework init flow in mt7915_thermal_init() Hyunwoo Kim (1): wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf Ilan Peer (2): wifi: iwlwifi: mvm: Fix setting the rate for non station cases wifi: iwlwifi: mvm: Fix _iwl_mvm_get_scan_type() Jernej Skrabec (1): wifi: rtw88: Add support for the SDIO based RTL8822BS chipset Jiefeng Li (1): wifi: mt76: mt7921: fix missing unwind goto in `mt7921u_probe` Johan Hovold (1): dt-bindings: net: wireless: add ath11k pcie bindings Johannes Berg (43): wifi: iwlwifi: debug: fix crash in __iwl_err() wifi: iwlwifi: nvm-parse: enable 160/320 MHz for AP mode wifi: iwlwifi: mvm: convert TID to FW value on queue remove wifi: iwlwifi: mvm: fix A-MSDU checks wifi: iwlwifi: mvm: refactor TX csum mode check wifi: ieee80211: clean up public action codes wifi: ieee80211: correctly mark FTM frames non-bufferable wifi: mac80211: flush queues on STA removal wifi: mac80211: add flush_sta method wifi: iwlwifi: mvm: request limiting to 8 MSDUs per A-MSDU wifi: iwlwifi: mvm: add DSM_FUNC_ENABLE_6E value to debugfs wifi: iwlwifi: pcie: work around ROM bug on AX210 integrated wifi: iwlwifi: mvm: track AP STA pointer and use it for MFP wifi: iwlwifi: mvm: make iwl_mvm_mac_ctxt_send_beacon() static wifi: iwlwifi: mvm: fix ptk_pn memory leak wifi: iwlwifi: mvm: set STA mask for keys in MLO wifi: iwlwifi: mvm: validate station properly in flush wifi: iwlwifi: mvm: tx: remove misleading if statement wifi: iwlwifi: nvm-parse: add full BW UL MU-MIMO support wifi: iwlwifi: mvm: fix getting lowest TX rate for MLO wifi: iwlwifi: mvm: properly implement HE AP support wifi: iwlwifi: mvm: factor out iwl_mvm_sta_fw_id_mask() wifi: iwlwifi: mvm: use correct sta mask to remove queue wifi: iwlwifi: mvm: track station mask for BAIDs wifi: iwlwifi: mvm: implement BAID link switching wifi: iwlwifi: mvm: implement key link switching wifi: iwlwifi: mvm: allow number of beacons from FW wifi: iwlwifi: mvm: use BSSID when building probe requests wifi: iwlwifi: mvm: allow NL80211_EXT_FEATURE_SCAN_MIN_PREQ_CONTENT wifi: iwlwifi: mvm: remove per-STA MFP setting wifi: iwlwifi: mvm: fix iwl_mvm_sta_rc_update for MLO wifi: iwlwifi: mvm: only clients can be 20MHz-only wifi: iwlwifi: mvm: rs-fw: properly access sband->iftype_data wifi: iwlwifi: mvm: initialize per-link STA ratescale data wifi: iwlwifi: mvm: remove RS rate init update argument wifi: iwlwifi: fix iwl_mvm_max_amsdu_size() for MLO wifi: iwlwifi: mvm: configure TLC on link activation wifi: iwlwifi: mvm: add MLO support to SF - use sta pointer wifi: iwlwifi: mvm: check firmware response size wifi: iwlwifi: fw: fix memory leak in debugfs wifi: iwlwifi: mvm: fix MIC removal confusion wifi: iwlwifi: mvm: fix potential memory leak wifi: iwlwifi: mvm: prefer RCU_INIT_POINTER() Jonas Jelonek (1): wifi: ath9k: fix per-packet TX-power cap for TPC Kalle Valo (3): wifi: ath11k: print a warning when crypto_alloc_shash() fails Merge tag 'mt76-for-kvalo-2023-04-18' of https://github.com/nbd168/wireless Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git Kang Chen (1): wifi: mt76: handle failure of vzalloc in mt7615_coredump_work Konrad Dybcio (1): dt-bindings: net: Convert ath10k to YAML Larry Finger (1): wifi: rtw88: Fix memory leak in rtw88_usb Lorenz Brun (1): wifi: mt76: mt7915: expose device tree match table Lorenzo Bianconi (8): wifi: mt76: mt7921: introduce mt7921_get_mac80211_ops utility routine wifi: mt76: move irq_tasklet in mt76_dev struct wifi: mt76: add mt76_connac_irq_enable utility routine wifi: mt76: get rid of unused sta_ps callbacks wifi: mt76: add mt76_connac_gen_ppe_thresh utility routine wifi: mt76: mt7921: get rid of eeprom.h wifi: mt76: move shared mac definitions in mt76_connac2_mac.h wifi: mt76: move mcu_uni_event and mcu_reg_event in common code Manikanta Pubbisetty (2): wifi: ath11k: Optimize 6 GHz scan time wifi: ath11k: Send 11d scan start before WMI_START_SCAN_CMDID Marek Vasut (1): wifi: brcmfmac: add Cypress 43439 SDIO ids Mario Limonciello (1): wifi: mt76: mt7921e: Set memory space enable in PCI_COMMAND if unset Martin Blumenstingl (8): wifi: rtw88: Clear RTW_FLAG_POWERON early in rtw_mac_power_switch() wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets wifi: rtw88: mac: Support SDIO specific bits in the power on sequence wifi: rtw88: main: Add the {cpwm,rpwm}_addr for SDIO based chipsets wifi: rtw88: main: Reserve 8 bytes of extra TX headroom for SDIO cards mmc: sdio: add Realtek SDIO vendor ID and various wifi device IDs wifi: rtw88: Add support for the SDIO based RTL8822CS chipset wifi: rtw88: Add support for the SDIO based RTL8821CS chipset Ming Yen Hsieh (1): wifi: mt76: fix 6GHz high channel not be scanned Miri Korenblit (3): wifi: iwlwifi: add a validity check of queue_id in iwl_txq_reclaim wifi: iwlwifi: mvm: cleanup beacon_inject_active during hw restart wifi: iwlwifi: mvm: enable new MLD FW API Mukesh Sisodiya (9): wifi: iwlwifi: Update configuration for SO,SOF MAC and HR RF wifi: iwlwifi: mvm: move function sequence wifi: iwlwifi: Update init sequence if tx diversity supported wifi: iwlwifi: Update configurations for Bnj-a0 and specific rf devices wifi: iwlwifi: dbg: print pc register data once fw dump occurred wifi: iwlwifi: Fix the duplicate dump name wifi: iwlwifi: Add RF Step Type for BZ device wifi: iwlwifi: add a new PCI device ID for BZ device wifi: iwlwifi: Update support for b0 version Muna Sinada (1): wifi: ath11k: Remove disabling of 80+80 and 160 MHz Nagarajan Maran (1): wifi: ath11k: Fix SKB corruption in REO destination ring Neil Chen (1): wifi: mt76: mt7921: use driver flags rather than mac80211 flags to mcu P Praneesh (3): wifi: ath12k: fill peer meta data during reo_reinject wifi: ath11k: fix rssi station dump not updated in QCN9074 wifi: ath11k: fix writing to unintended memory region Peter Chiu (4): wifi: mt76: drop the incorrect scatter and gather frame wifi: mt76: mt7996: fix pointer calculation in ie countdown event wifi: mt76: mt7996: init mpdu density cap wifi: mt76: mt7996: remove mt7996_mcu_set_pm() Ping-Ke Shih (13): wifi: rtw89: use schedule_work to request firmware wifi: rtw89: add firmware format version to backward compatible with older drivers wifi: rtw89: read version of analog hardware wifi: rtw89: 8851b: fix TX path to path A for one RF path chip wifi: rtw89: mac: update MAC settings to support 8851b wifi: rtw89: pci: update PCI related settings to support 8851B wifi: rtw89: 8851b: add BB and RF tables (1 of 2) wifi: rtw89: 8851b: add BB and RF tables (2 of 2) wifi: rtw89: 8851b: add tables for RFK wifi: rtw89: fix crash due to null pointer of sta in AP mode wifi: rtw89: coex: send more hardware module info to firmware for 8851B wifi: rtw89: use struct instead of macros to set H2C command of hardware scan wifi: rtw89: mac: use regular int as return type of DLE buffer request Po-Hao Huang (17): wifi: rtw89: 8852c: add beacon filter and CQM support wifi: rtw89: add function to wait for completion of TX skbs wifi: rtw89: add ieee80211::remain_on_channel ops wifi: rtw89: add flag check for power state wifi: rtw89: fix authentication fail during scan wifi: rtw89: refine scan function after chanctx wifi: rtw89: update statistics to FW for fine-tuning performance wifi: rtw89: Disallow power save with multiple stations wifi: rtw89: add support of concurrent mode wifi: rtw88: add bitmap for dynamic port settings wifi: rtw88: add port switch for AP mode wifi: rtw88: 8822c: extend reserved page number wifi: rtw88: disallow PS during AP mode wifi: rtw88: refine reserved page flow for AP mode wifi: rtw88: prevent scan abort with other VIFs wifi: rtw88: handle station mode concurrent scan with AP mode wifi: rtw88: 8822c: add iface combination Pradeep Kumar Chitrapu (2): wifi: ath11k: fix tx status reporting in encap offload mode wifi: ath11k: Fix incorrect update of radiotap fields Quan Zhou (3): wifi: mt76: mt7921e: fix probe timeout after reboot wifi: mt76: mt7921e: improve reliability of dma reset wifi: mt76: mt7921e: stop chip reset worker in unregister hook Rajat Soni (1): wifi: ath12k: fix memory leak in ath12k_qmi_driver_event_work() Reese Russell (1): wifi: mt76: mt7921: add Netgear AXE3000 (A8000) support Rob Herring (1): bcma: Add explicit of_device.h include Ryder Lee (15): wifi: mt76: mt7996: fix radiotap bitfield wifi: mt76: dynamic channel bandwidth changes in AP mode wifi: mt76: connac: refresh tx session timer for WED device wifi: mt76: mt7915: remove mt7915_mcu_beacon_check_caps() wifi: mt76: mt7996: remove mt7996_mcu_beacon_check_caps() wifi: mt76: mt7915: drop redundant prefix of mt7915_txpower_puts() wifi: mt76: mt7996: add full system reset knobs into debugfs wifi: mt76: mt7996: enable coredump support wifi: mt76: connac: fix txd multicast rate setting wifi: mt76: connac: add nss calculation into mt76_connac2_mac_tx_rate_val() wifi: mt76: mt7996: enable BSS_CHANGED_BASIC_RATES support wifi: mt76: mt7996: enable BSS_CHANGED_MCAST_RATE support wifi: mt76: mt7996: enable configured beacon tx rate wifi: mt76: mt7996: enable mesh HW amsdu/de-amsdu support wifi: mt76: mt7996: fill txd by host driver Sascha Hauer (4): wifi: rtw88: usb: fix priority queue to endpoint mapping wifi: rtw88: rtw8821c: Fix rfe_option field width wifi: rtw88: set pkg_type correctly for specific rtw8821c variants wifi: rtw88: call rtw8821c_switch_rf_set() according to chip variant Sean Wang (2): wifi: mt76: mt7921: enable p2p support mt76: mt7921: fix kernel panic by accessing unallocated eeprom.data Shayne Chen (3): wifi: mt76: mt7996: add eht rx rate support wifi: mt76: mt7996: let non-bufferable MMPDUs use correct hw queue wifi: mt76: mt7996: remove unused eeprom band selection Simon Horman (1): wifi: rtw88: Update spelling in main.h StanleyYP Wang (1): wifi: mt76: mt7996: fix eeprom tx path bitfields Sujuan Chen (1): wifi: mt76: mt7915: add dev->hif2 support for mt7916 WED device Takashi Iwai (1): wifi: ath11k: pci: Add more MODULE_FIRMWARE() entries Tamizh Chelvam Raja (1): wifi: ath11k: Disable Spectral scan upon removing interface Toke Høiland-Jørgensen (1): wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels() Tom Rix (3): wifi: ath10k: remove unused ath10k_get_ring_byte function wifi: iwlwifi: mvm: initialize seq variable wifi: iwlwifi: fw: move memset before early return Vladimir Lypak (1): wifi: wcn36xx: add support for pronto-v3 Yang Li (1): wifi: mt76: mt7996: Remove unneeded semicolon Yingsha Xu (1): wifi: mac80211: remove return value check of debugfs_create_dir() Youghandhar Chintala (1): wifi: ath11k: enable SAR support on WCN6750 Zong-Zhe Yang (2): wifi: rtw89: fw: use generic flow to set/check features wifi: rtw89: support parameter tables by RFE type .../bindings/net/wireless/mediatek,mt76.yaml | 5 + .../bindings/net/wireless/qcom,ath10k.txt | 215 - .../bindings/net/wireless/qcom,ath10k.yaml | 358 + .../bindings/net/wireless/qcom,ath11k-pci.yaml | 58 + MAINTAINERS | 2 +- drivers/bcma/main.c | 1 + drivers/net/wireless/ath/ath10k/ce.c | 7 - drivers/net/wireless/ath/ath10k/pci.c | 6 +- drivers/net/wireless/ath/ath11k/ahb.c | 6 + drivers/net/wireless/ath/ath11k/core.c | 10 +- drivers/net/wireless/ath/ath11k/dbring.c | 12 +- .../net/wireless/ath/ath11k/debugfs_htt_stats.h | 73 +- drivers/net/wireless/ath/ath11k/dp.c | 4 +- drivers/net/wireless/ath/ath11k/dp.h | 6 +- drivers/net/wireless/ath/ath11k/dp_rx.c | 140 +- drivers/net/wireless/ath/ath11k/dp_tx.c | 33 +- drivers/net/wireless/ath/ath11k/dp_tx.h | 1 + drivers/net/wireless/ath/ath11k/hal_rx.c | 14 +- drivers/net/wireless/ath/ath11k/hal_rx.h | 20 +- drivers/net/wireless/ath/ath11k/hw.c | 28 +- drivers/net/wireless/ath/ath11k/hw.h | 3 +- drivers/net/wireless/ath/ath11k/mac.c | 50 +- drivers/net/wireless/ath/ath11k/pci.c | 14 +- drivers/net/wireless/ath/ath11k/peer.h | 1 + drivers/net/wireless/ath/ath11k/wmi.c | 48 +- drivers/net/wireless/ath/ath11k/wmi.h | 5 + drivers/net/wireless/ath/ath12k/core.h | 1 + drivers/net/wireless/ath/ath12k/dp_rx.c | 15 +- drivers/net/wireless/ath/ath12k/dp_tx.c | 4 + drivers/net/wireless/ath/ath12k/hw.c | 2 +- drivers/net/wireless/ath/ath12k/mac.c | 117 +- drivers/net/wireless/ath/ath12k/pci.c | 8 +- drivers/net/wireless/ath/ath12k/qmi.c | 4 +- drivers/net/wireless/ath/ath12k/wmi.c | 6 + drivers/net/wireless/ath/ath9k/hif_usb.c | 2 - drivers/net/wireless/ath/ath9k/mci.c | 4 +- drivers/net/wireless/ath/ath9k/xmit.c | 30 +- drivers/net/wireless/ath/carl9170/cmd.c | 2 +- drivers/net/wireless/ath/carl9170/fwcmd.h | 4 +- drivers/net/wireless/ath/wcn36xx/dxe.c | 23 +- drivers/net/wireless/ath/wcn36xx/dxe.h | 4 +- drivers/net/wireless/ath/wcn36xx/main.c | 1 + drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 + .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 9 +- drivers/net/wireless/cisco/Kconfig | 2 +- drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 104 +- drivers/net/wireless/intel/iwlwifi/dvm/sta.c | 5 +- drivers/net/wireless/intel/iwlwifi/fw/acpi.c | 41 +- drivers/net/wireless/intel/iwlwifi/fw/api/d3.h | 37 +- .../net/wireless/intel/iwlwifi/fw/api/mac-cfg.h | 14 +- drivers/net/wireless/intel/iwlwifi/fw/api/scan.h | 3 + drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 10 +- drivers/net/wireless/intel/iwlwifi/fw/debugfs.c | 4 +- drivers/net/wireless/intel/iwlwifi/fw/dump.c | 11 + drivers/net/wireless/intel/iwlwifi/fw/file.h | 4 + drivers/net/wireless/intel/iwlwifi/fw/img.h | 1 + drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 1 + drivers/net/wireless/intel/iwlwifi/fw/uefi.c | 2 +- drivers/net/wireless/intel/iwlwifi/iwl-config.h | 9 + drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 4 + drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c | 8 +- drivers/net/wireless/intel/iwlwifi/iwl-debug.c | 3 +- drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 18 +- .../net/wireless/intel/iwlwifi/iwl-eeprom-parse.h | 5 +- drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 25 +- drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 7 + drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 21 +- drivers/net/wireless/intel/iwlwifi/mei/iwl-mei.h | 4 +- drivers/net/wireless/intel/iwlwifi/mei/main.c | 40 +- drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 36 +- drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 32 + .../net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 25 +- .../net/wireless/intel/iwlwifi/mvm/ftm-responder.c | 19 +- drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 236 +- drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 69 +- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 76 +- drivers/net/wireless/intel/iwlwifi/mvm/mld-key.c | 114 +- drivers/net/wireless/intel/iwlwifi/mvm/mld-mac.c | 21 +- .../net/wireless/intel/iwlwifi/mvm/mld-mac80211.c | 29 +- drivers/net/wireless/intel/iwlwifi/mvm/mld-sta.c | 139 +- drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 76 +- drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 12 +- drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 81 +- drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 13 +- drivers/net/wireless/intel/iwlwifi/mvm/rs.h | 21 +- drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 5 +- drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 71 +- drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 107 +- drivers/net/wireless/intel/iwlwifi/mvm/sf.c | 29 +- drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 35 +- drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 4 + drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 77 +- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 422 +- drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 1 + drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 18 +- .../net/wireless/intel/iwlwifi/pcie/trans-gen2.c | 73 +- drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 15 +- drivers/net/wireless/intel/iwlwifi/queue/tx.c | 10 +- drivers/net/wireless/mediatek/mt76/dma.c | 10 +- drivers/net/wireless/mediatek/mt76/dma.h | 1 + drivers/net/wireless/mediatek/mt76/mac80211.c | 17 +- drivers/net/wireless/mediatek/mt76/mt76.h | 19 +- drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 5 +- drivers/net/wireless/mediatek/mt76/mt7615/dma.c | 5 +- drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c | 7 +- drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h | 2 +- drivers/net/wireless/mediatek/mt76/mt7615/init.c | 1 + drivers/net/wireless/mediatek/mt76/mt7615/mac.c | 18 +- drivers/net/wireless/mediatek/mt76/mt7615/mac.h | 12 - drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 11 +- drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 11 - drivers/net/wireless/mediatek/mt76/mt7615/mmio.c | 11 +- drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h | 11 +- drivers/net/wireless/mediatek/mt76/mt7615/pci.c | 2 +- .../net/wireless/mediatek/mt76/mt7615/pci_init.c | 2 +- drivers/net/wireless/mediatek/mt76/mt7615/sdio.c | 1 - drivers/net/wireless/mediatek/mt76/mt7615/usb.c | 1 - drivers/net/wireless/mediatek/mt76/mt76_connac.h | 21 + .../net/wireless/mediatek/mt76/mt76_connac2_mac.h | 22 + .../net/wireless/mediatek/mt76/mt76_connac_mac.c | 78 +- .../net/wireless/mediatek/mt76/mt76_connac_mcu.c | 21 +- .../net/wireless/mediatek/mt76/mt76_connac_mcu.h | 19 +- drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 5 +- .../net/wireless/mediatek/mt76/mt7915/debugfs.c | 36 +- drivers/net/wireless/mediatek/mt76/mt7915/dma.c | 10 +- drivers/net/wireless/mediatek/mt76/mt7915/init.c | 35 +- drivers/net/wireless/mediatek/mt76/mt7915/mac.c | 6 +- drivers/net/wireless/mediatek/mt76/mt7915/mac.h | 33 +- drivers/net/wireless/mediatek/mt76/mt7915/main.c | 1 - drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 115 +- drivers/net/wireless/mediatek/mt76/mt7915/mmio.c | 17 +- drivers/net/wireless/mediatek/mt76/mt7915/mt7915.h | 18 +- drivers/net/wireless/mediatek/mt76/mt7915/soc.c | 2 + .../net/wireless/mediatek/mt76/mt7921/acpi_sar.h | 10 +- .../net/wireless/mediatek/mt76/mt7921/debugfs.c | 1 - drivers/net/wireless/mediatek/mt76/mt7921/dma.c | 50 +- drivers/net/wireless/mediatek/mt76/mt7921/eeprom.h | 30 - drivers/net/wireless/mediatek/mt76/mt7921/init.c | 43 +- drivers/net/wireless/mediatek/mt76/mt7921/mac.c | 18 +- drivers/net/wireless/mediatek/mt76/mt7921/mac.h | 53 - drivers/net/wireless/mediatek/mt76/mt7921/main.c | 42 +- drivers/net/wireless/mediatek/mt76/mt7921/mcu.c | 31 +- drivers/net/wireless/mediatek/mt76/mt7921/mcu.h | 11 - drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h | 23 +- drivers/net/wireless/mediatek/mt76/mt7921/pci.c | 64 +- .../net/wireless/mediatek/mt76/mt7921/pci_mac.c | 2 +- drivers/net/wireless/mediatek/mt76/mt7921/sdio.c | 23 +- .../net/wireless/mediatek/mt76/mt7921/sdio_mac.c | 2 +- .../net/wireless/mediatek/mt76/mt7921/sdio_mcu.c | 2 +- drivers/net/wireless/mediatek/mt76/mt7921/usb.c | 27 +- .../net/wireless/mediatek/mt76/mt7921/usb_mac.c | 2 +- drivers/net/wireless/mediatek/mt76/mt7996/Kconfig | 1 + drivers/net/wireless/mediatek/mt76/mt7996/Makefile | 2 + .../net/wireless/mediatek/mt76/mt7996/coredump.c | 268 + .../net/wireless/mediatek/mt76/mt7996/coredump.h | 97 + .../net/wireless/mediatek/mt76/mt7996/debugfs.c | 149 +- drivers/net/wireless/mediatek/mt76/mt7996/dma.c | 64 + drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c | 4 - drivers/net/wireless/mediatek/mt76/mt7996/eeprom.h | 9 +- drivers/net/wireless/mediatek/mt76/mt7996/init.c | 72 +- drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 501 +- drivers/net/wireless/mediatek/mt76/mt7996/mac.h | 62 +- drivers/net/wireless/mediatek/mt76/mt7996/main.c | 78 +- drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 222 +- drivers/net/wireless/mediatek/mt76/mt7996/mcu.h | 30 +- drivers/net/wireless/mediatek/mt76/mt7996/mmio.c | 23 +- drivers/net/wireless/mediatek/mt76/mt7996/mt7996.h | 76 +- drivers/net/wireless/mediatek/mt76/mt7996/regs.h | 51 +- drivers/net/wireless/mediatek/mt76/tx.c | 6 +- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 19 +- .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c | 5 +- .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c | 8 +- .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 5 - .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 54 - .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8710b.c | 9 + .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c | 4 - .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 6 +- .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 113 +- drivers/net/wireless/realtek/rtw88/Kconfig | 36 + drivers/net/wireless/realtek/rtw88/Makefile | 12 + drivers/net/wireless/realtek/rtw88/debug.h | 1 + drivers/net/wireless/realtek/rtw88/fw.c | 20 +- drivers/net/wireless/realtek/rtw88/fw.h | 2 +- drivers/net/wireless/realtek/rtw88/mac.c | 55 +- drivers/net/wireless/realtek/rtw88/mac.h | 1 - drivers/net/wireless/realtek/rtw88/mac80211.c | 40 +- drivers/net/wireless/realtek/rtw88/main.c | 157 +- drivers/net/wireless/realtek/rtw88/main.h | 23 +- drivers/net/wireless/realtek/rtw88/reg.h | 12 + drivers/net/wireless/realtek/rtw88/rtw8723d.c | 1 + drivers/net/wireless/realtek/rtw88/rtw8821c.c | 26 +- drivers/net/wireless/realtek/rtw88/rtw8821cs.c | 36 + drivers/net/wireless/realtek/rtw88/rtw8822b.c | 1 + drivers/net/wireless/realtek/rtw88/rtw8822bs.c | 36 + drivers/net/wireless/realtek/rtw88/rtw8822c.c | 1 + drivers/net/wireless/realtek/rtw88/rtw8822cs.c | 36 + drivers/net/wireless/realtek/rtw88/sdio.c | 1394 ++ drivers/net/wireless/realtek/rtw88/sdio.h | 178 + drivers/net/wireless/realtek/rtw88/usb.c | 71 +- drivers/net/wireless/realtek/rtw89/chan.c | 35 + drivers/net/wireless/realtek/rtw89/chan.h | 3 + drivers/net/wireless/realtek/rtw89/core.c | 362 +- drivers/net/wireless/realtek/rtw89/core.h | 155 +- drivers/net/wireless/realtek/rtw89/debug.c | 13 +- drivers/net/wireless/realtek/rtw89/fw.c | 456 +- drivers/net/wireless/realtek/rtw89/fw.h | 311 +- drivers/net/wireless/realtek/rtw89/mac.c | 144 +- drivers/net/wireless/realtek/rtw89/mac.h | 5 +- drivers/net/wireless/realtek/rtw89/mac80211.c | 92 +- drivers/net/wireless/realtek/rtw89/pci.c | 38 +- drivers/net/wireless/realtek/rtw89/pci.h | 4 +- drivers/net/wireless/realtek/rtw89/phy.c | 92 +- drivers/net/wireless/realtek/rtw89/ps.c | 12 +- drivers/net/wireless/realtek/rtw89/ps.h | 19 +- drivers/net/wireless/realtek/rtw89/reg.h | 3 + .../wireless/realtek/rtw89/rtw8851b_rfk_table.c | 534 + .../wireless/realtek/rtw89/rtw8851b_rfk_table.h | 38 + .../net/wireless/realtek/rtw89/rtw8851b_table.c | 14824 +++++++++++++++++++ .../net/wireless/realtek/rtw89/rtw8851b_table.h | 21 + drivers/net/wireless/realtek/rtw89/rtw8852a.c | 22 +- .../net/wireless/realtek/rtw89/rtw8852a_table.c | 15 + .../net/wireless/realtek/rtw89/rtw8852a_table.h | 11 +- drivers/net/wireless/realtek/rtw89/rtw8852b.c | 55 +- .../net/wireless/realtek/rtw89/rtw8852b_table.c | 15 + .../net/wireless/realtek/rtw89/rtw8852b_table.h | 11 +- drivers/net/wireless/realtek/rtw89/rtw8852c.c | 40 +- .../net/wireless/realtek/rtw89/rtw8852c_table.c | 21 + .../net/wireless/realtek/rtw89/rtw8852c_table.h | 16 +- drivers/net/wireless/realtek/rtw89/wow.c | 2 +- drivers/net/wireless/virtual/mac80211_hwsim.c | 3 + include/linux/ieee80211.h | 63 +- include/linux/mmc/sdio_ids.h | 14 +- include/net/mac80211.h | 26 +- net/mac80211/cfg.c | 4 + net/mac80211/debugfs.c | 4 - net/mac80211/driver-ops.h | 15 + net/mac80211/sta_info.c | 12 + net/mac80211/status.c | 24 - net/mac80211/trace.h | 7 + net/mac80211/tx.c | 4 +- 240 files changed, 23374 insertions(+), 2874 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml delete mode 100644 drivers/net/wireless/mediatek/mt76/mt7921/eeprom.h delete mode 100644 drivers/net/wireless/mediatek/mt76/mt7921/mac.h create mode 100644 drivers/net/wireless/mediatek/mt76/mt7996/coredump.c create mode 100644 drivers/net/wireless/mediatek/mt76/mt7996/coredump.h create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8821cs.c create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8822bs.c create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8822cs.c create mode 100644 drivers/net/wireless/realtek/rtw88/sdio.c create mode 100644 drivers/net/wireless/realtek/rtw88/sdio.h create mode 100644 drivers/net/wireless/realtek/rtw89/rtw8851b_rfk_table.c create mode 100644 drivers/net/wireless/realtek/rtw89/rtw8851b_rfk_table.h create mode 100644 drivers/net/wireless/realtek/rtw89/rtw8851b_table.c create mode 100644 drivers/net/wireless/realtek/rtw89/rtw8851b_table.h