linux-stable/drivers/bcma
Jakub Kicinski 196dd92a00 wireless-next patches for v6.2
First set of patches v6.2. mac80211 refactoring continues for Wi-Fi 7.
 All mac80211 driver are now converted to use internal TX queues, this
 might cause some regressions so we wanted to do this early in the
 cycle.
 
 Note: wireless tree was merged[1] to wireless-next to avoid some
 conflicts with mac80211 patches between the trees. Unfortunately there
 are still two smaller conflicts in net/mac80211/util.c which Stephen
 also reported[2]. In the first conflict initialise scratch_len to
 "params->scratch_len ?: 3 * params->len" (note number 3, not 2!) and
 in the second conflict take the version which uses elems->scratch_pos.
 
 Git diff output should like this:
 
 --- a/net/mac80211/util.c
 +++ b/net/mac80211/util.c
 @@@ -1506,7 -1648,7 +1650,7 @@@ ieee802_11_parse_elems_full(struct ieee
         const struct element *non_inherit = NULL;
         u8 *nontransmitted_profile;
         int nontransmitted_profile_len = 0;
 -       size_t scratch_len = params->len;
  -      size_t scratch_len = params->scratch_len ?: 2 * params->len;
 ++      size_t scratch_len = params->scratch_len ?: 3 * params->len;
 
         elems = kzalloc(sizeof(*elems) + scratch_len, GFP_ATOMIC);
         if (!elems)
 
 [1] https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/?id=dfd2d876b3fda1790bc0239ba4c6967e25d16e91
 [2] https://lore.kernel.org/all/20221020032340.5cf101c0@canb.auug.org.au/
 
 Major changes:
 
 mac80211
 
 * preparation for Wi-Fi 7 Multi-Link Operation (MLO) continues
 
 * add API to show the link STAs in debugfs
 
 * all mac80211 drivers are now using mac80211 internal TX queues (iTXQs)
 
 rtw89
 
 * support 8852BE
 
 rtl8xxxu
 
 * support RTL8188FU
 
 brmfmac
 
 * support two station interfaces concurrently
 
 bcma
 
 * support SPROM rev 11
 -----BEGIN PGP SIGNATURE-----
 
 iQFFBAABCgAvFiEEiBjanGPFTz4PRfLobhckVSbrbZsFAmNb2KwRHGt2YWxvQGtl
 cm5lbC5vcmcACgkQbhckVSbrbZs6hggAqrmgHaiRbPYlLVE0hFVaGeVXslfpK9nj
 ZGr3bwG5FpioxjAsI7NfwEwpq+FoxTUigG/SShw1Rr8lw43Nt7E57+5McK3qWdKC
 5/WndfChPppjtJUpc6PN+UcmCuhcm4TAyMAojbTe5lJ9cJ4yyOWZChDwah3BVZQk
 /tHK4qKq8gpppwgkiJ88VdTVoVv5anIvXHH3lAIteljxk0zkaEM7lIQhIFst/zpX
 cu/cWvKz2Rh6vnYjkzl8BcrbW8e0/VwnzWggtWs4/kIuRVnHRrrGwlnsULShOscM
 fmK+RI2CbJIMucttUOHOXjCg4wwppSit1rH4xOkcwlvrFa7AvDbdHg==
 =Zils
 -----END PGP SIGNATURE-----

Kalle Valo says:

====================
pull-request: wireless-next-2022-10-28

First set of patches v6.2. mac80211 refactoring continues for Wi-Fi 7.
All mac80211 driver are now converted to use internal TX queues, this
might cause some regressions so we wanted to do this early in the
cycle.

Note: wireless tree was merged[1] to wireless-next to avoid some
conflicts with mac80211 patches between the trees. Unfortunately there
are still two smaller conflicts in net/mac80211/util.c which Stephen
also reported[2]. In the first conflict initialise scratch_len to
"params->scratch_len ?: 3 * params->len" (note number 3, not 2!) and
in the second conflict take the version which uses elems->scratch_pos.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/?id=dfd2d876b3fda1790bc0239ba4c6967e25d16e91
[2] https://lore.kernel.org/all/20221020032340.5cf101c0@canb.auug.org.au/

mac80211
 - preparation for Wi-Fi 7 Multi-Link Operation (MLO) continues
 - add API to show the link STAs in debugfs
 - all mac80211 drivers are now using mac80211 internal TX queues (iTXQs)

rtw89
 - support 8852BE

rtl8xxxu
 - support RTL8188FU

brmfmac
 - support two station interfaces concurrently

bcma
 - support SPROM rev 11
====================

Link: https://lore.kernel.org/r/20221028132943.304ECC433B5@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28 18:31:40 -07:00
..
bcma_private.h bcma: use dev_* printing functions 2019-01-10 13:39:19 +02:00
core.c
driver_chipcommon.c bcma: cleanup comments 2022-02-21 10:58:14 +02:00
driver_chipcommon_b.c remove ioremap_nocache and devm_ioremap_nocache 2020-01-06 09:45:59 +01:00
driver_chipcommon_nflash.c mtd: rawnand: brcmnand: Add platform data structure for BCMA 2022-01-23 16:37:18 +01:00
driver_chipcommon_pflash.c bcma: move parallel flash support to separated file 2016-03-07 14:41:08 +02:00
driver_chipcommon_pmu.c bcma: cleanup comments 2022-02-21 10:58:14 +02:00
driver_chipcommon_sflash.c mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR() 2016-04-04 00:07:57 -07:00
driver_gmac_cmn.c
driver_gpio.c wireless-next patches for v6.2 2022-10-28 18:31:40 -07:00
driver_mips.c bcma: Fix typo in comments 2022-09-07 11:00:30 +03:00
driver_pci.c bcma: fix incorrect update of BCMA_CORE_PCI_MDIO_DATA 2019-09-03 16:44:02 +03:00
driver_pci_host.c bcma: cleanup comments 2022-02-21 10:58:14 +02:00
driver_pcie2.c bcma: Adjust block comment 2017-12-07 15:33:02 +02:00
host_pci.c bcma: simplify reference to driver name 2021-10-12 17:50:12 -05:00
host_soc.c remove ioremap_nocache and devm_ioremap_nocache 2020-01-06 09:45:59 +01:00
Kconfig bcma: Allow selection of this driver when COMPILE_TEST=y 2018-07-18 09:34:19 +02:00
main.c bcma: cleanup comments 2022-02-21 10:58:14 +02:00
Makefile License cleanup: add SPDX GPL-2.0 license identifier to files with no license 2017-11-02 11:10:55 +01:00
README
scan.c bcma: Drop the unused parameter of bcma_scan_read32() 2021-08-29 14:44:57 +03:00
scan.h License cleanup: add SPDX GPL-2.0 license identifier to files with no license 2017-11-02 11:10:55 +01:00
sprom.c bcma: support SPROM rev 11 2022-10-19 08:59:37 +03:00
TODO

Broadcom introduced new bus as replacement for older SSB. It is based on AMBA,
however from programming point of view there is nothing AMBA specific we use.

Standard AMBA drivers are platform specific, have hardcoded addresses and use
AMBA standard fields like CID and PID.

In case of Broadcom's cards every device consists of:
1) Broadcom specific AMBA device. It is put on AMBA bus, but can not be treated
   as standard AMBA device. Reading it's CID or PID can cause machine lockup.
2) AMBA standard devices called ports or wrappers. They have CIDs (AMBA_CID)
   and PIDs (0x103BB369), but we do not use that info for anything. One of that
   devices is used for managing Broadcom specific core.

Addresses of AMBA devices are not hardcoded in driver and have to be read from
EPROM.

In this situation we decided to introduce separated bus. It can contain up to
16 devices identified by Broadcom specific fields: manufacturer, id, revision
and class.