There's a race with runtime PM getting enabled by userspace:
- we rescan the PCI bus
- this creates the new PCI device including its sysfs
representation
- udev sees the new device, and the (OS-specific?) scripting
enables runtime PM by writing to power/control; this can
happen _before_ the next step - this will runtime-suspend
the device which saves the config space, including the BAR0
that wasn't assigned yet
- the bus rescan assigns resources to the devices and writes
them to the config space of the device
(but not the runtime-pm saved copy)
- the driver binds and this disallows runtime PM, so the device
is resumed, restoring the (incomplete!) config space
- the driver cannot work due to BAR0 not being configured
Fixing the actual race is hard and deep in the PCI layer,
though probably should be done for upstream as well; perhaps
runtime PM should only be allowed after resource assignment,
or some other TBD way.
Work around this in the driver for now by simply (re-)assigning
BAR0 when the driver initializes, if it's unset.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230921110726.5f5f782a4e97.I4b7bf5c52ba44a8c7f9878009021689bbfa9c5ef@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
set_antenna() is supported only when the device is not started in
mac80211 which translates to the firmware not being loaded in iwlwifi.
The tricky part is that iwlwifi populates the sband data during its boot
and doesn't touch this data afterwards, but if the antenna settings
forbid MIMO, we need to update the sband data.
Rework the nvm parsing code to allow to get an existing nvm_data and
modify the sband with additional constraints (tx / rx chains masks).
Suggested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230921110726.81d94d630c95.I9473da818cbeeb51b2f89dcc59b00019113e7f55@changeid
[add bugfix from Benjamin for iwl_mvm_get_valid_rx_ant()]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When one of the links (other than the assoc_link) is misconfigured
and cannot work the association will fail. However, userspace was not
able to tell that the operation only failed because of a problem with
one of the links. Fix this, by allowing the driver to set a per-link
error code and reporting the (first) offending link by setting the
bad_attr accordingly.
This only allows us to report the first error, but that is sufficient
for userspace to e.g. remove the offending link and retry.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230920211508.ebe63c0bd513.I40799998f02bf987acee1501a2522dc98bb6eb5a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Support antenna control for injection by parsing the antenna
radiotap field (which may be presented multiple times) and
telling the driver about the resulting antenna bitmap. Of
course there's no guarantee the driver will actually honour
this, just like any other injection control.
If misconfigured, i.e. the injected HT/VHT MCS needs more
chains than antennas are configured, the bitmap is reset to
zero, indicating no selection.
For now this is only set up for two anntenas so we keep more
free bits, but that can be trivially extended if any driver
implements support for it that can deal with hardware with
more antennas.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230920211508.f71001aa4da9.I00ccb762a806ea62bc3d728fa3a0d29f4f285eeb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Using the full struct cfg80211_ap_settings for an update is
misleading, since most settings cannot be updated. Split the
update case off into a new struct cfg80211_ap_update.
Change-Id: I3ba4dd9280938ab41252f145227a7005edf327e4
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Drivers should really be able to rely on the wiphy mutex
being held all the time, unless otherwise documented. For
ethtool, that wasn't quite right. Fix and clarify this in
both code and documentation.
Reported-by: syzbot+c12a771b218dcbba32e1@syzkaller.appspotmail.com
Fixes: 0e8185ce1d ("wifi: mac80211: check wiphy mutex in ops")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The following FW elements are recognized, and then the valid entries
in them are loaded into SW struct case by case.
* TX power by rate
* TX power limit 2 GHz
* TX power limit 5 GHz
* TX power limit 6 GHz
* TX power limit RU 2 GHz
* TX power limit RU 5 GHz
* TX power limit RU 6 GHz
* TX shape limit
* TX shape limit RU
One single firmware file can contain multiples of each of the above FW
elements. Each of them is configured with a target RFE (RF front end)
type. We choose one of the multiples to load based on RFE type. If there
are multiples of the same FW elements with the same target RFE type. The
last one will be applied.
We don't want to have many loading variants for above FW elements. Even if
between different chips or between different generations, we would like to
maintain only one single set of loadings. So, the loadings are designed to
consider compatibility. The main concepts are listed below.
* The driver structures, which are used to cast binary entry from FW,
cannot insert new members in the middle. If there are something new,
they should always be appended at the tail.
* Each binary entry from FW uses a dictionary way containing a key set
and a data. The keys in the key set indicate where to put the data.
* If size of driver struct and size of binary entry do not match when
loading, it means the number of keys in the key set are different.
Then, we deal with compatibility. No matter which one has more keys,
we take/use zero on those mismatched keys.
If driver struct is bigger (backward compatibility):
e.g. SW uses two keys, but FW is built with one key.
Then, put the data of FW(keyX) into SW[keyX][0].
If binary entry is bigger (forward compatibility):
e.g. FW is built with two keys, but SW uses one key.
Then, only take the data of FW(keyX, keyY = 0) into SW[keyX]
Besides, chip info setup flow is tweaked a bit for the following.
* Before loading FW elements, we need to determine chip RFE via efuse.
* Setting up RFE parameters depends on loading FW elements ahead.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230920074322.42898-8-pkshih@realtek.com
The following are introduced for Wi-Fi 7 chips.
1. take BW/OFDMA into account on TX power by rate
2. increase TX power offset types up to EHT
3. split TX shape into tx_shape_lmt and tx_shape_lmt_ru
If functions which are only for AX, they always access TX power by rate
with BW/OFDMA = 0/0, and they don't access tx_shape's lmt_ru section.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230920074322.42898-7-pkshih@realtek.com
For next-generation chips, TX power by rate table comes from RFE (RF
front end) parameter. It can be different according to RFE type. So,
we indicate TX power by rate table inside RFE parameter ahead. For
current chips, even with different RFE types, a chip is configured
with a single TX power by rate table. So, this commit doesn't really
affect these currently supported chips.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230920074322.42898-4-pkshih@realtek.com
For next-generation chips, TX shape table comes from RFE (RF front end)
parameter. It can be different according to RFE type. So, we indicate
TX shape table inside RFE parameter ahead. For current chips, even with
different RFE types, a chip is configured with a single TX shape table.
So, this commit doesn't really affect these currently supported chips.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230920074322.42898-3-pkshih@realtek.com
The subband index is a hardware value of relationship between primary
channel and bandwidth, and it is used by setting channel/bandwidth to
specify the primary channel.
Because this index is only needed when bandwidth >= 20 MHz, adjust
order of enumerator bandwidth to access offsets array easier. To prevent
misuse RTW89_CHANNEL_WIDTH_NUM as size, change it to
RTW89_CHANNEL_WIDTH_ORDINARY_NUM that will be the size of array. The
enumerator values of bandwidth (before ordinary number) will be also
used by upcoming TX power table built in firmware file, so add a comment
to remind keeping the order.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230920074322.42898-2-pkshih@realtek.com
Since 'mwifiex_write_reg()' just issues void 'iowrite32()',
convert the former to 'void' and simplify all related users
(with the only exception of 'read_poll_timeout()' which
explicitly requires a non-void function argument).
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230919132804.73340-1-dmantipov@yandex.ru
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
wlcore_remove() returned zero unconditionally. With that converted to
return void instead, the wl12xx and wl18xx driver can be converted to
.remove_new trivially.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230912171249.755901-1-u.kleine-koenig@pengutronix.de
The format v2 of TX descriptor contains 8-word body and 8-word info, and
fields include packet size, MAC_ID, security key ID and etc.
By design, it can possibly only fill body to reduce overhead, but this
driver keeps thing simple, so always fill body and info currently.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230911082049.33541-4-pkshih@realtek.com
