| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If the structure is not initialized then boolean types might be copied
into the tracing data without being initialised. This causes data from
the stack to leak into the trace and also triggers a UBSAN failure which
can easily be avoided here.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://lore.kernel.org/r/20230925171855.a9271ef53b05.I8180bae663984c91a3e036b87f36a640ba409817@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Lower layer device driver stop/wake TX by calling ieee80211_stop_queue()/
ieee80211_wake_queue() while hw scan. Sometimes hw scan and PTK rekey are
running in parallel, when M4 sent from wpa_supplicant arrive while the TX
queue is stopped, then the M4 will pending send, and then new key install
from wpa_supplicant. After TX queue wake up by lower layer device driver,
the M4 will be dropped by below call stack.
When key install started, the current key flag is set KEY_FLAG_TAINTED in
ieee80211_pairwise_rekey(), and then mac80211 wait key install complete by
lower layer device driver. Meanwhile ieee80211_tx_h_select_key() will return
TX_DROP for the M4 in step 12 below, and then ieee80211_free_txskb() called
by ieee80211_tx_dequeue(), so the M4 will not send and free, then the rekey
process failed becaue AP not receive M4. Please see details in steps below.
There are a interval between KEY_FLAG_TAINTED set for current key flag and
install key complete by lower layer device driver, the KEY_FLAG_TAINTED is
set in this interval, all packet including M4 will be dropped in this
interval, the interval is step 8~13 as below.
issue steps:
TX thread install key thread
1. stop_queue -idle-
2. sending M4 -idle-
3. M4 pending -idle-
4. -idle- starting install key from wpa_supplicant
5. -idle- =>ieee80211_key_replace()
6. -idle- =>ieee80211_pairwise_rekey() and set
currently key->flags |= KEY_FLAG_TAINTED
7. -idle- =>ieee80211_key_enable_hw_accel()
8. -idle- =>drv_set_key() and waiting key install
complete from lower layer device driver
9. wake_queue -waiting state-
10. re-sending M4 -waiting state-
11. =>ieee80211_tx_h_select_key() -waiting state-
12. drop M4 by KEY_FLAG_TAINTED -waiting state-
13. -idle- install key complete with success/fail
success: clear flag KEY_FLAG_TAINTED
fail: start disconnect
Hence add check in step 11 above to allow the EAPOL send out in the
interval. If lower layer device driver use the old key/cipher to encrypt
the M4, then AP received/decrypt M4 correctly, after M4 send out, lower
layer device driver install the new key/cipher to hardware and return
success.
If lower layer device driver use new key/cipher to send the M4, then AP
will/should drop the M4, then it is same result with this issue, AP will/
should kick out station as well as this issue.
issue log:
kworker/u16:4-5238 [000] 6456.108926: stop_queue: phy1 queue:0, reason:0
wpa_supplicant-961 [003] 6456.119737: rdev_tx_control_port: wiphy_name=phy1 name=wlan0 ifindex=6 dest=ARRAY[9e, 05, 31, 20, 9b, d0] proto=36488 unencrypted=0
wpa_supplicant-961 [003] 6456.119839: rdev_return_int_cookie: phy1, returned 0, cookie: 504
wpa_supplicant-961 [003] 6456.120287: rdev_add_key: phy1, netdev:wlan0(6), key_index: 0, mode: 0, pairwise: true, mac addr: 9e:05:31:20:9b:d0
wpa_supplicant-961 [003] 6456.120453: drv_set_key: phy1 vif:wlan0(2) sta:9e:05:31:20:9b:d0 cipher:0xfac04, flags=0x9, keyidx=0, hw_key_idx=0
kworker/u16:9-3829 [001] 6456.168240: wake_queue: phy1 queue:0, reason:0
kworker/u16:9-3829 [001] 6456.168255: drv_wake_tx_queue: phy1 vif:wlan0(2) sta:9e:05:31:20:9b:d0 ac:0 tid:7
kworker/u16:9-3829 [001] 6456.168305: cfg80211_control_port_tx_status: wdev(1), cookie: 504, ack: false
wpa_supplicant-961 [003] 6459.167982: drv_return_int: phy1 - -110
issue call stack:
nl80211_frame_tx_status+0x230/0x340 [cfg80211]
cfg80211_control_port_tx_status+0x1c/0x28 [cfg80211]
ieee80211_report_used_skb+0x374/0x3e8 [mac80211]
ieee80211_free_txskb+0x24/0x40 [mac80211]
ieee80211_tx_dequeue+0x644/0x954 [mac80211]
ath10k_mac_tx_push_txq+0xac/0x238 [ath10k_core]
ath10k_mac_op_wake_tx_queue+0xac/0xe0 [ath10k_core]
drv_wake_tx_queue+0x80/0x168 [mac80211]
__ieee80211_wake_txqs+0xe8/0x1c8 [mac80211]
_ieee80211_wake_txqs+0xb4/0x120 [mac80211]
ieee80211_wake_txqs+0x48/0x80 [mac80211]
tasklet_action_common+0xa8/0x254
tasklet_action+0x2c/0x38
__do_softirq+0xdc/0x384
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Link: https://lore.kernel.org/r/20230801064751.25803-1-quic_wgong@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Cisco AP module 9115 with FW 17.3 has a bug and sends a too
large maximum MPDU length in the association response
(indicating 12k) that it cannot actually process.
Work around that by taking the minimum between what's in the
association response and the BSS elements (from beacon or
probe response).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230918140607.d1966a9a532e.I090225babb7cd4d1081ee9acd40e7de7e41c15ae@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When the scan request includes a non broadcast BSSID, when adding the
scan parameters for 6GHz collocated scanning, do not include entries
that do not match the given BSSID.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230918140607.6d31d2a96baf.I6c4e3e3075d1d1878ee41f45190fdc6b86f18708@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When returning from ieee80211_key_link(), the key needs to
have been freed or successfully installed. This was missed
in a number of error paths, fix it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
but returns 0 due to KRACK protection (identical key reinstall),
ieee80211_gtk_rekey_add() will still return a pointer into the
key, in a potential use-after-free. This normally doesn't happen
since it's only called by iwlwifi in case of WoWLAN rekey offload
which has its own KRACK protection, but still better to fix, do
that by returning an error code and converting that to success on
the cfg80211 boundary only, leaving the error for bad callers of
ieee80211_gtk_rekey_add().
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
On MT76x0, LNA gain should be applied for both external and internal LNA.
On MT76x2, LNA gain should be treated as 0 for external LNA.
Move the LNA type based logic to mt76x2 in order to fix mt76x0.
Fixes: 2daa67588f34 ("mt76x0: unify lna_gain parsing")
Reported-by: Shiji Yang <yangshiji66@outlook.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230919194747.31647-1-nbd@nbd.name
|
|
Since commit 2d47c6956ab3 ("ubsan: Tighten UBSAN_BOUNDS on GCC"),
UBSAN_BOUNDS no longer pretends 1-element arrays are unbounded. Walking
'element' and 'channel_list' will trigger warnings, so make them proper
flexible arrays.
False positive warnings were:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:6984:20
index 1 is out of range for type '__le32 [1]'
UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1126:27
index 1 is out of range for type '__le16 [1]'
for these lines of code:
6884 ch.chspec = (u16)le32_to_cpu(list->element[i]);
1126 params_le->channel_list[i] = cpu_to_le16(chanspec);
Cc: stable@vger.kernel.org # 6.5+
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230914070227.12028-1-juerg.haefliger@canonical.com
|
|
Only skip the code path trying to access the rfc1042 headers when the
buffer is too small, so the driver can still process packets without
rfc1042 headers.
Fixes: 119585281617 ("wifi: mwifiex: Fix OOB and integer underflow when rx packets")
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Acked-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Matthew Wang <matthewmwang@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230908104308.1546501-1-treapking@chromium.org
|
|
The MAC address is stored at offset 0x107 in the EEPROM, like correctly
stated in the comment. Add a two bytes reserved field right before the
MAC address to shift it from offset 0x105 to 0x107.
With this the MAC address returned from my RTL8723du wifi stick can be
correctly decoded as "Shenzhen Four Seas Global Link Network Technology
Co., Ltd."
Fixes: 87caeef032fc ("wifi: rtw88: Add rtw8723du chipset support")
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reported-by: Yanik Fuchs <Yanik.fuchs@mbv.ch>
Cc: stable@vger.kernel.org
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230907071614.2032404-1-s.hauer@pengutronix.de
|
|
If userspace quickly opens /dev/rfkill after a new
instance was created, it might see the old state of
the instance from before the sync work runs and may
even _change_ the state, only to have the sync work
change it again.
Fix this by doing the sync inline where needed, not
just for /dev/rfkill but also for sysfs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Since the changed field size was increased to u64, mesh_bss_info_changed
pulls invalid bits from the first 3 bytes of the mesh id, clears them, and
passes them on to ieee80211_link_info_change_notify, because
ifmsh->mbss_changed was not updated to match its size.
Fix this by turning into ifmsh->mbss_changed into an unsigned long array with
64 bit size.
Fixes: 15ddba5f4311 ("wifi: mac80211: consistently use u64 for BSS changes")
Reported-by: Thomas Hühn <thomas.huehn@hs-nordhausen.de>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230913050134.53536-1-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
As reported by Stephen, I neglected to add the kernel-doc
for the new struct member. Fix that.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: 37c20b2effe9 ("wifi: cfg80211: fix cqm_config access race")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Max Schulze reports crashes with brcmfmac. The reason seems
to be a race between userspace removing the CQM config and
the driver calling cfg80211_cqm_rssi_notify(), where if the
data is freed while cfg80211_cqm_rssi_notify() runs it will
crash since it assumes wdev->cqm_config is set. This can't
be fixed with a simple non-NULL check since there's nothing
we can do for locking easily, so use RCU instead to protect
the pointer, but that requires pulling the updates out into
an asynchronous worker so they can sleep and call back into
the driver.
Since we need to change the free anyway, also change it to
go back to the old settings if changing the settings fails.
Reported-and-tested-by: Max Schulze <max.schulze@online.de>
Closes: https://lore.kernel.org/r/ac96309a-8d8d-4435-36e6-6d152eb31876@online.de
Fixes: 4a4b8169501b ("cfg80211: Accept multiple RSSI thresholds for CQM")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
A few lines above, space is kzalloc()'ed for:
sizeof(struct iwl_nvm_data) +
sizeof(struct ieee80211_channel) +
sizeof(struct ieee80211_rate)
'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine.
At the end of this structure, there is the 'channels' flex array.
Each element is of type 'struct ieee80211_channel'.
So only 1 element is allocated in this array.
When doing:
mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels;
We point at the first element of the 'channels' flex array.
So this is fine.
However, when doing:
mvm->nvm_data->bands[0].bitrates =
(void *)((u8 *)mvm->nvm_data->channels + 1);
because of the "(u8 *)" cast, we add only 1 to the address of the beginning
of the flex array.
It is likely that we want point at the 'struct ieee80211_rate' allocated
just after.
Remove the spurious casting so that the pointer arithmetic works as
expected.
Fixes: 8ca151b568b6 ("iwlwifi: add the MVM driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/23f0ec986ef1529055f4f93dcb3940a6cf8d9a94.1690143750.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Debugging indicates that nothing else is clearing the info->flags,
so some frames were flagged as ACKed when they should not be.
Explicitly clear the ack flag to ensure this does not happen.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Acked-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230808205605.4105670-1-greearb@candelatech.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The iwl_fw_ini_error_dump_range structure has conflicting alignment
requirements for the inner union and the outer struct:
In file included from drivers/net/wireless/intel/iwlwifi/fw/dbg.c:9:
drivers/net/wireless/intel/iwlwifi/fw/error-dump.h:312:2: error: field within 'struct iwl_fw_ini_error_dump_range' is less aligned than 'union iwl_fw_ini_error_dump_range::(anonymous at drivers/net/wireless/intel/iwlwifi/fw/error-dump.h:312:2)' and is usually due to 'struct iwl_fw_ini_error_dump_range' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]
union {
As the original intention was apparently to make the entire structure
unaligned, mark the innermost members the same way so the union
becomes packed as well.
Fixes: 973193554cae6 ("iwlwifi: dbg_ini: dump headers cleanup")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230616090343.2454061-1-arnd@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Handling of BSS_CHANGED_PS was missing in vif_cfg_changed
callback. Fix it.
Fixes: 22c588343529 ("wifi: iwlwifi: mvm: replace bss_info_changed() with vif_cfg/link_info_changed()")
Reported-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230905162939.5ef0c8230de6.Ieed265014988c50ec68fbff6d33821e4215f987f@changeid
[note: patch looks bigger than it is due to reindentation]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Many regulatories can have HE/EHT Operation as not permitted. In such
cases, AP should not be allowed to start if it is using a channel
having the no operation flag set. However, currently there is no such
check in place.
Fix this issue by validating such IEs sent during start AP against the
channel flags.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20230905064857.1503-1-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When connect to MLO AP with more than one link, and the assoc response of
AP is not success, then cfg80211_unhold_bss() is not called for all the
links' cfg80211_bss except the primary link which means the link used by
the latest successful association request. Thus the hold value of the
cfg80211_bss is not reset to 0 after the assoc fail, and then the
__cfg80211_unlink_bss() will not be called for the cfg80211_bss by
__cfg80211_bss_expire().
Then the AP always looks exist even the AP is shutdown or reconfigured
to another type, then it will lead error while connecting it again.
The detail info are as below.
When connect with muti-links AP, cfg80211_hold_bss() is called by
cfg80211_mlme_assoc() for each cfg80211_bss of all the links. When
assoc response from AP is not success(such as status_code==1), the
ieee80211_link_data of non-primary link(sdata->link[link_id]) is NULL
because ieee80211_assoc_success()->ieee80211_vif_update_links() is
not called for the links.
Then struct cfg80211_rx_assoc_resp resp in cfg80211_rx_assoc_resp() and
struct cfg80211_connect_resp_params cr in __cfg80211_connect_result()
will only have the data of the primary link, and finally function
cfg80211_connect_result_release_bsses() only call cfg80211_unhold_bss()
for the primary link. Then cfg80211_bss of the other links will never free
because its hold is always > 0 now.
Hence assign value for the bss and status from assoc_data since it is
valid for this case. Also assign value of addr from assoc_data when the
link is NULL because the addrs of assoc_data and link both represent the
local link addr and they are same value for success connection.
Fixes: 81151ce462e5 ("wifi: mac80211: support MLO authentication/association with one link")
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Link: https://lore.kernel.org/r/20230825070055.28164-1-quic_wgong@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add sanity checks for both `tlv_len` and `tlv_bitmap_len` before
decoding data from `event_buf`.
This prevents any malicious or buggy firmware from overflowing
`event_buf` through large values for `tlv_len` and `tlv_bitmap_len`.
Suggested-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/d4f8780527d551552ee96f17a0229e02e1c200d1.1692931954.git.gustavoars@kernel.org
|
|
One-element and zero-length arrays are deprecated. So, replace
one-element array in struct mwifiex_ie_types_rxba_sync with
flexible-array member, and refactor the rest of the code, accordingly.
This results in no differences in binary output.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/79c801c69c8beece2f80502c60166036d3c047cc.1692931954.git.gustavoars@kernel.org
|
|
In a TLV encoding scheme, the Length part represents the length after
the header containing the values for type and length. In this case,
`tlv_len` should be:
tlv_len == (sizeof(*tlv_rxba) - 1) - sizeof(tlv_rxba->header) + tlv_bitmap_len
Notice that the `- 1` accounts for the one-element array `bitmap`, which
1-byte size is already included in `sizeof(*tlv_rxba)`.
So, if the above is correct, there is a double-counting of some members
in `struct mwifiex_ie_types_rxba_sync`, when `tlv_buf_left` and `tmp`
are calculated:
968 tlv_buf_left -= (sizeof(*tlv_rxba) + tlv_len);
969 tmp = (u8 *)tlv_rxba + tlv_len + sizeof(*tlv_rxba);
in specific, members:
drivers/net/wireless/marvell/mwifiex/fw.h:777
777 u8 mac[ETH_ALEN];
778 u8 tid;
779 u8 reserved;
780 __le16 seq_num;
781 __le16 bitmap_len;
This is clearly wrong, and affects the subsequent decoding of data in
`event_buf` through `tlv_rxba`:
970 tlv_rxba = (struct mwifiex_ie_types_rxba_sync *)tmp;
Fix this by using `sizeof(tlv_rxba->header)` instead of `sizeof(*tlv_rxba)`
in the calculation of `tlv_buf_left` and `tmp`.
This results in the following binary differences before/after changes:
| drivers/net/wireless/marvell/mwifiex/11n_rxreorder.o
| @@ -4698,11 +4698,11 @@
| drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c:968
| tlv_buf_left -= (sizeof(tlv_rxba->header) + tlv_len);
| - 1da7: lea -0x11(%rbx),%edx
| + 1da7: lea -0x4(%rbx),%edx
| 1daa: movzwl %bp,%eax
| drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c:969
| tmp = (u8 *)tlv_rxba + sizeof(tlv_rxba->header) + tlv_len;
| - 1dad: lea 0x11(%r15,%rbp,1),%r15
| + 1dad: lea 0x4(%r15,%rbp,1),%r15
The above reflects the desired change: avoid counting 13 too many bytes;
which is the total size of the double-counted members in
`struct mwifiex_ie_types_rxba_sync`:
$ pahole -C mwifiex_ie_types_rxba_sync drivers/net/wireless/marvell/mwifiex/11n_rxreorder.o
struct mwifiex_ie_types_rxba_sync {
struct mwifiex_ie_types_header header; /* 0 4 */
|-----------------------------------------------------------------------
| u8 mac[6]; /* 4 6 */ |
| u8 tid; /* 10 1 */ |
| u8 reserved; /* 11 1 */ |
| __le16 seq_num; /* 12 2 */ |
| __le16 bitmap_len; /* 14 2 */ |
| u8 bitmap[1]; /* 16 1 */ |
|----------------------------------------------------------------------|
| 13 bytes|
-----------
/* size: 17, cachelines: 1, members: 7 */
/* last cacheline: 17 bytes */
} __attribute__((__packed__));
Fixes: 99ffe72cdae4 ("mwifiex: process rxba_sync event")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/06668edd68e7a26bbfeebd1201ae077a2a7a8bce.1692931954.git.gustavoars@kernel.org
|
|
The ath12k wireless driver now has a wiki, so advertise it.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230829-ath12kwiki-v1-1-df37127527a1@quicinc.com
|
|
As hostap is marked as obsolete there's no need to have a maintainer. Also
remove the link to the web page.
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230828123603.87621-5-kvalo@kernel.org
|
|
Luca's tree hasn't been used for 10 years so remove it.
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230828123603.87621-4-kvalo@kernel.org
|
|
Jes' tree hasn't been used for six years so remove it.
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230828123603.87621-3-kvalo@kernel.org
|
|
Linville's tree hasn't been used for something like 10 years so remove it.
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230828123603.87621-2-kvalo@kernel.org
|
|
The top level entry for wireless drivers already contains to the wiki so no
need to duplicate that in driver entries:
NETWORKING DRIVERS (WIRELESS)
[...]
W: https://wireless.wiki.kernel.org/
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230828123603.87621-1-kvalo@kernel.org
|
|
Fix the following kernel depency lock holding wed_lock with BH disabled.
[ 40.579696] mt798x-wmac 18000000.wifi: attaching wed device 0 version 2
[ 40.604648] platform 15010000.wed: MTK WED WO Firmware Version: DEV_000000, Build Time: 20221208202138
[ 40.613972] platform 15010000.wed: MTK WED WO Chip ID 00 Region 3
[ 40.943617]
[ 40.945118] ========================================================
[ 40.951457] WARNING: possible irq lock inversion dependency detected
[ 40.957797] 5.15.127 #0 Not tainted
[ 40.961276] --------------------------------------------------------
[ 40.967614] insmod/2329 just changed the state of lock:
[ 40.972827] ffffff8004003b08 (&dev->wed_lock){+.+.}-{2:2}, at: mt76_get_rxwi+0x1c/0xac [mt76]
[ 40.981387] but this lock was taken by another, SOFTIRQ-safe lock in the past:
[ 40.988592] (&q->lock){+.-.}-{2:2}
[ 40.988602]
[ 40.988602]
[ 40.988602] and interrupts could create inverse lock ordering between them.
[ 40.988602]
[ 41.003445]
[ 41.003445] other info that might help us debug this:
[ 41.009957] Possible interrupt unsafe locking scenario:
[ 41.009957]
[ 41.016729] CPU0 CPU1
[ 41.021245] ---- ----
[ 41.025761] lock(&dev->wed_lock);
[ 41.029241] local_irq_disable();
[ 41.035145] lock(&q->lock);
[ 41.040620] lock(&dev->wed_lock);
[ 41.046616] <Interrupt>
[ 41.049223] lock(&q->lock);
[ 41.052356]
[ 41.052356] *** DEADLOCK ***
[ 41.052356]
[ 41.058260] 1 lock held by insmod/2329:
[ 41.062085] #0: ffffff80003b9988 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x88/0x190
[ 41.070442]
[ 41.070442] the shortest dependencies between 2nd lock and 1st lock:
[ 41.078257] -> (&q->lock){+.-.}-{2:2} {
[ 41.082177] HARDIRQ-ON-W at:
[ 41.085396] lock_acquire+0xfc/0x2c0
[ 41.090787] _raw_spin_lock_bh+0x84/0xa0
[ 41.096525] mt76_dma_cleanup+0x24c/0x650 [mt76]
[ 41.102977] mt76_dma_cleanup+0x614/0x650 [mt76]
[ 41.109428] mt7915_eeprom_get_power_delta+0x1168/0x2464 [mt7915e]
[ 41.117435] mt7915_eeprom_init+0x40/0x340 [mt7915e]
[ 41.124222] cleanup_module+0x94/0xb28 [mt7915e]
[ 41.130662] platform_probe+0x64/0xbc
[ 41.136139] really_probe.part.0+0x98/0x2f4
[ 41.142134] __driver_probe_device+0x94/0x16c
[ 41.148303] driver_probe_device+0x40/0x120
[ 41.154299] __driver_attach+0x94/0x190
[ 41.159947] bus_for_each_dev+0x5c/0x94
[ 41.165594] driver_attach+0x20/0x30
[ 41.170983] bus_add_driver+0x104/0x1f4
[ 41.176631] driver_register+0x74/0x120
[ 41.182280] __platform_driver_register+0x24/0x30
[ 41.188797] 0xffffffc000cb1074
[ 41.193754] do_one_initcall+0x70/0x2cc
[ 41.199403] do_init_module+0x44/0x240
[ 41.204968] load_module+0x1f5c/0x2874
[ 41.210532] __do_sys_init_module+0x1d8/0x2ac
[ 41.216702] __arm64_sys_init_module+0x18/0x20
[ 41.222958] invoke_syscall.constprop.0+0x4c/0xe0
[ 41.229474] do_el0_svc+0x50/0xf0
[ 41.234602] el0_svc+0x4c/0xcc
[ 41.239471] el0t_64_sync_handler+0xe0/0x110
[ 41.245556] el0t_64_sync+0x15c/0x160
[ 41.251029] IN-SOFTIRQ-W at:
[ 41.254249] lock_acquire+0xfc/0x2c0
[ 41.259638] _raw_spin_lock_bh+0x84/0xa0
[ 41.265372] mt76_queue_tx_complete+0x34/0x70 [mt76]
[ 41.272170] mt76_free_pending_rxwi+0x36c/0x5d0 [mt76]
[ 41.279140] mt76_free_pending_rxwi+0x5c0/0x5d0 [mt76]
[ 41.286111] mt7915_eeprom_get_power_delta+0x620/0x2464 [mt7915e]
[ 41.294026] __napi_poll.constprop.0+0x5c/0x230
[ 41.300372] net_rx_action+0xe4/0x294
[ 41.305847] _stext+0x154/0x4cc
[ 41.310801] do_softirq+0xa4/0xbc
[ 41.315930] __local_bh_enable_ip+0x168/0x174
[ 41.322097] napi_threaded_poll+0xbc/0x140
[ 41.328007] kthread+0x13c/0x150
[ 41.333049] ret_from_fork+0x10/0x20
[ 41.338437] INITIAL USE at:
[ 41.341568] lock_acquire+0xfc/0x2c0
[ 41.346869] _raw_spin_lock_bh+0x84/0xa0
[ 41.352519] mt76_dma_cleanup+0x24c/0x650 [mt76]
[ 41.358882] mt76_dma_cleanup+0x614/0x650 [mt76]
[ 41.365245] mt7915_eeprom_get_power_delta+0x1168/0x2464 [mt7915e]
[ 41.373160] mt7915_eeprom_init+0x40/0x340 [mt7915e]
[ 41.379860] cleanup_module+0x94/0xb28 [mt7915e]
[ 41.386213] platform_probe+0x64/0xbc
[ 41.391602] really_probe.part.0+0x98/0x2f4
[ 41.397511] __driver_probe_device+0x94/0x16c
[ 41.403594] driver_probe_device+0x40/0x120
[ 41.409502] __driver_attach+0x94/0x190
[ 41.415063] bus_for_each_dev+0x5c/0x94
[ 41.420625] driver_attach+0x20/0x30
[ 41.425926] bus_add_driver+0x104/0x1f4
[ 41.431487] driver_register+0x74/0x120
[ 41.437049] __platform_driver_register+0x24/0x30
[ 41.443479] 0xffffffc000cb1074
[ 41.448346] do_one_initcall+0x70/0x2cc
[ 41.453907] do_init_module+0x44/0x240
[ 41.459383] load_module+0x1f5c/0x2874
[ 41.464860] __do_sys_init_module+0x1d8/0x2ac
[ 41.470944] __arm64_sys_init_module+0x18/0x20
[ 41.477113] invoke_syscall.constprop.0+0x4c/0xe0
[ 41.483542] do_el0_svc+0x50/0xf0
[ 41.488582] el0_svc+0x4c/0xcc
[ 41.493364] el0t_64_sync_handler+0xe0/0x110
[ 41.499361] el0t_64_sync+0x15c/0x160
[ 41.504748] }
[ 41.506489] ... key at: [<ffffffc000c65ba0>] __this_module+0x3e0/0xffffffffffffa840 [mt76]
[ 41.515371] ... acquired at:
[ 41.518413] _raw_spin_lock+0x60/0x74
[ 41.522240] mt76_get_rxwi+0x1c/0xac [mt76]
[ 41.526608] mt76_dma_cleanup+0x3e0/0x650 [mt76]
[ 41.531410] mt76_dma_cleanup+0x614/0x650 [mt76]
[ 41.536211] mt7915_dma_init+0x408/0x7b0 [mt7915e]
[ 41.541177] mt7915_register_device+0x310/0x620 [mt7915e]
[ 41.546749] mt7915_mmio_probe+0xcec/0x1d44 [mt7915e]
[ 41.551973] platform_probe+0x64/0xbc
[ 41.555802] really_probe.part.0+0x98/0x2f4
[ 41.560149] __driver_probe_device+0x94/0x16c
[ 41.564670] driver_probe_device+0x40/0x120
[ 41.569017] __driver_attach+0x94/0x190
[ 41.573019] bus_for_each_dev+0x5c/0x94
[ 41.577018] driver_attach+0x20/0x30
[ 41.580758] bus_add_driver+0x104/0x1f4
[ 41.584758] driver_register+0x74/0x120
[ 41.588759] __platform_driver_register+0x24/0x30
[ 41.593628] init_module+0x74/0x1000 [mt7915e]
[ 41.598248] do_one_initcall+0x70/0x2cc
[ 41.602248] do_init_module+0x44/0x240
[ 41.606162] load_module+0x1f5c/0x2874
[ 41.610078] __do_sys_init_module+0x1d8/0x2ac
[ 41.614600] __arm64_sys_init_module+0x18/0x20
[ 41.619209] invoke_syscall.constprop.0+0x4c/0xe0
[ 41.624076] do_el0_svc+0x50/0xf0
[ 41.627555] el0_svc+0x4c/0xcc
[ 41.630776] el0t_64_sync_handler+0xe0/0x110
[ 41.635211] el0t_64_sync+0x15c/0x160
[ 41.639037]
[ 41.640517] -> (&dev->wed_lock){+.+.}-{2:2} {
[ 41.644872] HARDIRQ-ON-W at:
[ 41.648003] lock_acquire+0xfc/0x2c0
[ 41.653219] _raw_spin_lock+0x60/0x74
[ 41.658520] mt76_free_pending_rxwi+0xc0/0x5d0 [mt76]
[ 41.665232] mt76_dma_cleanup+0x1dc/0x650 [mt76]
[ 41.671508] mt7915_eeprom_get_power_delta+0x1830/0x2464 [mt7915e]
[ 41.679336] mt7915_unregister_device+0x5b4/0x910 [mt7915e]
[ 41.686555] mt7915_eeprom_get_target_power+0xb8/0x230 [mt7915e]
[ 41.694209] mt7986_wmac_enable+0xc30/0xcd0 [mt7915e]
[ 41.700909] platform_remove+0x4c/0x64
[ 41.706298] __device_release_driver+0x194/0x240
[ 41.712554] driver_detach+0xc0/0x100
[ 41.717857] bus_remove_driver+0x54/0xac
[ 41.723418] driver_unregister+0x2c/0x54
[ 41.728980] platform_driver_unregister+0x10/0x20
[ 41.735323] mt7915_ops+0x244/0xffffffffffffed58 [mt7915e]
[ 41.742457] __arm64_sys_delete_module+0x170/0x23c
[ 41.748887] invoke_syscall.constprop.0+0x4c/0xe0
[ 41.755229] do_el0_svc+0x50/0xf0
[ 41.760183] el0_svc+0x4c/0xcc
[ 41.764878] el0t_64_sync_handler+0xe0/0x110
[ 41.770788] el0t_64_sync+0x15c/0x160
[ 41.776088] SOFTIRQ-ON-W at:
[ 41.779220] lock_acquire+0xfc/0x2c0
[ 41.784435] _raw_spin_lock+0x60/0x74
[ 41.789737] mt76_get_rxwi+0x1c/0xac [mt76]
[ 41.795580] mt7915_debugfs_rx_log+0x804/0xb74 [mt7915e]
[ 41.802540] mtk_wed_start+0x970/0xaa0
[ 41.807929] mt7915_dma_start+0x26c/0x630 [mt7915e]
[ 41.814455] mt7915_dma_start+0x5a4/0x630 [mt7915e]
[ 41.820981] mt7915_dma_init+0x45c/0x7b0 [mt7915e]
[ 41.827420] mt7915_register_device+0x310/0x620 [mt7915e]
[ 41.834467] mt7915_mmio_probe+0xcec/0x1d44 [mt7915e]
[ 41.841167] platform_probe+0x64/0xbc
[ 41.846469] really_probe.part.0+0x98/0x2f4
[ 41.852291] __driver_probe_device+0x94/0x16c
[ 41.858286] driver_probe_device+0x40/0x120
[ 41.864107] __driver_attach+0x94/0x190
[ 41.869582] bus_for_each_dev+0x5c/0x94
[ 41.875056] driver_attach+0x20/0x30
[ 41.880270] bus_add_driver+0x104/0x1f4
[ 41.885745] driver_register+0x74/0x120
[ 41.891221] __platform_driver_register+0x24/0x30
[ 41.897564] init_module+0x74/0x1000 [mt7915e]
[ 41.903657] do_one_initcall+0x70/0x2cc
[ 41.909130] do_init_module+0x44/0x240
[ 41.914520] load_module+0x1f5c/0x2874
[ 41.919909] __do_sys_init_module+0x1d8/0x2ac
[ 41.925905] __arm64_sys_init_module+0x18/0x20
[ 41.931989] invoke_syscall.constprop.0+0x4c/0xe0
[ 41.938331] do_el0_svc+0x50/0xf0
[ 41.943285] el0_svc+0x4c/0xcc
[ 41.947981] el0t_64_sync_handler+0xe0/0x110
[ 41.953892] el0t_64_sync+0x15c/0x160
[ 41.959192] INITIAL USE at:
[ 41.962238] lock_acquire+0xfc/0x2c0
[ 41.967365] _raw_spin_lock+0x60/0x74
[ 41.972580] mt76_free_pending_rxwi+0xc0/0x5d0 [mt76]
[ 41.979206] mt76_dma_cleanup+0x1dc/0x650 [mt76]
[ 41.985395] mt7915_eeprom_get_power_delta+0x1830/0x2464 [mt7915e]
[ 41.993137] mt7915_unregister_device+0x5b4/0x910 [mt7915e]
[ 42.000270] mt7915_eeprom_get_target_power+0xb8/0x230 [mt7915e]
[ 42.007837] mt7986_wmac_enable+0xc30/0xcd0 [mt7915e]
[ 42.014450] platform_remove+0x4c/0x64
[ 42.019753] __device_release_driver+0x194/0x240
[ 42.025922] driver_detach+0xc0/0x100
[ 42.031137] bus_remove_driver+0x54/0xac
[ 42.036612] driver_unregister+0x2c/0x54
[ 42.042087] platform_driver_unregister+0x10/0x20
[ 42.048344] mt7915_ops+0x244/0xffffffffffffed58 [mt7915e]
[ 42.055391] __arm64_sys_delete_module+0x170/0x23c
[ 42.061735] invoke_syscall.constprop.0+0x4c/0xe0
[ 42.067990] do_el0_svc+0x50/0xf0
[ 42.072857] el0_svc+0x4c/0xcc
[ 42.077466] el0t_64_sync_handler+0xe0/0x110
[ 42.083289] el0t_64_sync+0x15c/0x160
[ 42.088503] }
[ 42.090157] ... key at: [<ffffffc000c65c10>] __this_module+0x450/0xffffffffffffa840 [mt76]
[ 42.098951] ... acquired at:
[ 42.101907] __lock_acquire+0x718/0x1df0
[ 42.105994] lock_acquire+0xfc/0x2c0
[ 42.109734] _raw_spin_lock+0x60/0x74
[ 42.113561] mt76_get_rxwi+0x1c/0xac [mt76]
[ 42.117929] mt7915_debugfs_rx_log+0x804/0xb74 [mt7915e]
[ 42.123415] mtk_wed_start+0x970/0xaa0
[ 42.127328] mt7915_dma_start+0x26c/0x630 [mt7915e]
[ 42.132379] mt7915_dma_start+0x5a4/0x630 [mt7915e]
[ 42.137430] mt7915_dma_init+0x45c/0x7b0 [mt7915e]
[ 42.142395] mt7915_register_device+0x310/0x620 [mt7915e]
[ 42.147967] mt7915_mmio_probe+0xcec/0x1d44 [mt7915e]
[ 42.153192] platform_probe+0x64/0xbc
[ 42.157019] really_probe.part.0+0x98/0x2f4
[ 42.161367] __driver_probe_device+0x94/0x16c
[ 42.165887] driver_probe_device+0x40/0x120
[ 42.170234] __driver_attach+0x94/0x190
[ 42.174235] bus_for_each_dev+0x5c/0x94
[ 42.178235] driver_attach+0x20/0x30
[ 42.181974] bus_add_driver+0x104/0x1f4
[ 42.185974] driver_register+0x74/0x120
[ 42.189974] __platform_driver_register+0x24/0x30
[ 42.194842] init_module+0x74/0x1000 [mt7915e]
[ 42.199460] do_one_initcall+0x70/0x2cc
[ 42.203460] do_init_module+0x44/0x240
[ 42.207376] load_module+0x1f5c/0x2874
[ 42.211290] __do_sys_init_module+0x1d8/0x2ac
[ 42.215813] __arm64_sys_init_module+0x18/0x20
[ 42.220421] invoke_syscall.constprop.0+0x4c/0xe0
[ 42.225288] do_el0_svc+0x50/0xf0
[ 42.228768] el0_svc+0x4c/0xcc
[ 42.231989] el0t_64_sync_handler+0xe0/0x110
[ 42.236424] el0t_64_sync+0x15c/0x160
[ 42.240249]
[ 42.241730]
[ 42.241730] stack backtrace:
[ 42.246074] CPU: 1 PID: 2329 Comm: insmod Not tainted 5.15.127 #0
[ 42.252157] Hardware name: GainStrong Oolite-MT7981B V1 Dev Board (NAND boot) (DT)
[ 42.259712] Call trace:
[ 42.262147] dump_backtrace+0x0/0x174
[ 42.265802] show_stack+0x14/0x20
[ 42.269108] dump_stack_lvl+0x84/0xac
[ 42.272761] dump_stack+0x14/0x2c
[ 42.276066] print_irq_inversion_bug.part.0+0x1b0/0x1c4
[ 42.281285] mark_lock+0x8b8/0x8bc
[ 42.284678] __lock_acquire+0x718/0x1df0
[ 42.288592] lock_acquire+0xfc/0x2c0
[ 42.292158] _raw_spin_lock+0x60/0x74
[ 42.295811] mt76_get_rxwi+0x1c/0xac [mt76]
[ 42.300008] mt7915_debugfs_rx_log+0x804/0xb74 [mt7915e]
[ 42.305320] mtk_wed_start+0x970/0xaa0
[ 42.309059] mt7915_dma_start+0x26c/0x630 [mt7915e]
[ 42.313937] mt7915_dma_start+0x5a4/0x630 [mt7915e]
[ 42.318815] mt7915_dma_init+0x45c/0x7b0 [mt7915e]
[ 42.323606] mt7915_register_device+0x310/0x620 [mt7915e]
[ 42.329005] mt7915_mmio_probe+0xcec/0x1d44 [mt7915e]
[ 42.334056] platform_probe+0x64/0xbc
[ 42.337711] really_probe.part.0+0x98/0x2f4
[ 42.341885] __driver_probe_device+0x94/0x16c
[ 42.346232] driver_probe_device+0x40/0x120
[ 42.350407] __driver_attach+0x94/0x190
[ 42.354234] bus_for_each_dev+0x5c/0x94
[ 42.358061] driver_attach+0x20/0x30
[ 42.361627] bus_add_driver+0x104/0x1f4
[ 42.365454] driver_register+0x74/0x120
[ 42.369282] __platform_driver_register+0x24/0x30
[ 42.373977] init_module+0x74/0x1000 [mt7915e]
[ 42.378423] do_one_initcall+0x70/0x2cc
[ 42.382249] do_init_module+0x44/0x240
[ 42.385990] load_module+0x1f5c/0x2874
[ 42.389733] __do_sys_init_module+0x1d8/0x2ac
[ 42.394082] __arm64_sys_init_module+0x18/0x20
[ 42.398518] invoke_syscall.constprop.0+0x4c/0xe0
[ 42.403211] do_el0_svc+0x50/0xf0
[ 42.406517] el0_svc+0x4c/0xcc
[ 42.409565] el0t_64_sync_handler+0xe0/0x110
[ 42.413827] el0t_64_sync+0x15c/0x160
[ 42.674858] mt798x-wmac 18000000.wifi: HW/SW Version: 0x8a108a10, Build Time: 20221208201745a
[ 42.674858]
[ 42.692078] mt798x-wmac 18000000.wifi: WM Firmware Version: ____000000, Build Time: 20221208201806
[ 42.735606] mt798x-wmac 18000000.wifi: WA Firmware Version: DEV_000000, Build Time: 20221208202048
Tested-by: Daniel Golle <daniel@makrotopia.org>
Fixes: 2666bece0905 ("wifi: mt76: introduce rxwi and rx token utility routines")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Acked-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/ee80be41c2a8d8749d83c6950a272a5e77aadd45.1693228333.git.lorenzo@kernel.org
|
|
No functional changes, just cosmetic ones.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/71e046c72a978745f0435af265dda610aa9bfbcf.1693157578.git.lorenzo@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add some new info in Wireless Ethernet Dispatcher wed_txinfo_show
debugfs handler useful during debugging.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/3390292655d568180b73d2a25576f61aa63310e5.1693157377.git.lorenzo@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Clarify the difference between "interface" and "phy_interface" in
struct plat_stmmacenet_data, both by adding a comment, and also
renaming "interface" to be "mac_interface". The difference between
these are:
MAC ----- optional PCS ----- SerDes ----- optional PHY ----- Media
^ ^
mac_interface phy_interface
Note that phylink currently only deals with phy_interface.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://lore.kernel.org/r/E1qZq83-005tts-6K@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The D-Link DUB-E250 is an RTL8156 based 2.5G Ethernet controller.
Add the vendor and product ID values to the driver. This makes Ethernet
work with the adapter.
Signed-off-by: Antonio Napolitano <anton@polit.no>
Link: https://lore.kernel.org/r/CV200KJEEUPC.WPKAHXCQJ05I@mercurius
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
At last, move the last bits out of leftover.c,
the devlink_notify_register/unregister() functions to dev.c
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-16-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Move the generic netlink small_ops definition where they are consumed,
into netlink.c
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-15-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Move remaining tracepoint definitions to most suitable file core.c.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-14-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Cut out another chunk from leftover.c and put linecard related code
into a separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-13-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Cut out another chunk from leftover.c and put rate related code
into a separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-12-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Cut out another chunk from leftover.c and put trap related code
into a separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-11-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In preparation for the trap code move, use tracepoint_enabled() helper
instead of trace_devlink_trap_report_enabled() which would not be
defined in that scope.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-10-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Cut out another chunk from leftover.c and put region related code
into a separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-9-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Cut out another chunk from leftover.c and put param related code
into a separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-8-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Cut out another chunk from leftover.c and put resource related code
into a separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-7-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Cut out another chunk from leftover.c and put dpipe related code
into a separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-6-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Since both dpipe and resource code is using this helper, in preparation
for code split to separate files, move
devlink_dpipe_send_and_alloc_skb() helper into netlink.c. Rename it on
the way.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-5-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Cut out another chunk from leftover.c and put sb related code
into a separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-4-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Cut out another chunk from leftover.c and put port related code
into a separate file.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-3-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In preparations of leftover.c split to individual files, avoid need to
have object structures exposed in devl_internal.h and allow to have them
maintained in object files.
The register/unregister notifications need to know the structures
to iterate lists. To avoid the need, introduce per-object
register/unregister notification helpers and use them.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230828061657.300667-2-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add exit hook and remove OPP table when the device gets unregistered.
This will fix the error messages when the CPU FREQ driver module is
removed and then re-inserted. It also fixes these messages while
onlining the first CPU from a policy whose all CPU's were previously
offlined.
debugfs: File 'cpu5' in directory 'opp' already present!
debugfs: File 'cpu6' in directory 'opp' already present!
debugfs: File 'cpu7' in directory 'opp' already present!
Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth")
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
[ Viresh: Dropped irrelevant change from it ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
Benjamin Berg
Wen Gong
Johannes Berg
Ilan Peer
Felix Fietkau
Juerg Haefliger
Pin-yen Lin
Sascha Hauer
Christophe JAILLET
Ben Greear
Arnd Bergmann
Gregory Greenman
Aditya Kumar Singh
Gustavo A. R. Silva
Jeff Johnson
Kalle Valo
Lorenzo Bianconi
Russell King (Oracle)
Antonio Napolitano
Jiri Pirko
Sumit Gupta