On 5/31/2024 6:49 PM, pgupta@xxxxxxxxxxxxx wrote:
Is there a limit to the number of hardware abstraction layers?
Please note that grouping multiple hardware under one wiphy is still not supported in
ath12k. This patch series is a strep towards such architecture. When the full hardware
grouping support is added, there will not be any restrictions in the number of hardware
which can be be grouped under only wiphy.
My current platform has 3 physical WiFi 7 modules in one machine - one for each
frequency 2.4 GHz, 5 GHz, and 6GHz. Is this currently not supported?
This should work with ath12k as all three will be registered as three different wiphys.
What if I want to connect more than 3 modules including identical modules of the same frequency? My setup will not be utilizing combined frequency modules.
Grouping hardware having same frequency capability will make things very complex, I dont
think it is worthy of the effort especially there is no obvious real use case to combine
such radios under one wiphy.
FYI, in my platform, each module is connected to its own PCIe slot, and has its own antennas so I assume it would be recognized as its own wireless device by the OS (i.e wlan0, wlan1, wlan2, etc.).
Yes, each hardware will be registered as separate phy and wlan
interfaces with respective capability can be created on top of
them.
Vasanth
On Fri, 31 May 2024 15:35:24 +0530, Harshitha Prem <quic_hprem@xxxxxxxxxxx> wrote:
On 5/30/2024 3:58 AM, Jeff Johnson wrote:
On 5/28/2024 8:13 PM, Baochen Qiang wrote:
On 5/29/2024 6:04 AM, Jeff Johnson wrote:
On 5/27/2024 11:35 PM, Harshitha Prem wrote:
To support multi-link operation, multiple devices with different bands say
2 GHz or 5 GHz or 6 GHz can be combined together as a group and provide
an abstraction to mac80211.
Device group abstraction - when there are multiple devices that are
connected by any means of communication interface between them, then these
devices can be combined together as a single group using a group id to form
a group abstraction. In ath12k driver, this abstraction would be named as
ath12k_hw_group (ag).
Please find below illustration of device group abstraction with two
devices.
Grouping of multiple devices (in future)
+------------------------------------------------------------------------+
| +-------------------------------------+ +-------------------+ |
| | +-----------+ | | +-----------+ | | +-----------+ | |
| | | ar (2GHz) | | | | ar (5GHz) | | | | ar (6GHz) | | |
| | +-----------+ | | +-----------+ | | +-----------+ | |
| | ath12k_base (ab) | | ath12k_base (ab) | |
| | (Dual band device) | | | |
| +-------------------------------------+ +-------------------+ |
| ath12k_hw_group (ag) based on group id |
+------------------------------------------------------------------------+
Say for example, device 1 has two radios (2 GHz and 5 GHz band) and
device 2 has one radio (6 GHz).
In existing code -
device 1 will have two hardware abstractions hw1 (2 GHz) and hw2
(5 GHz) will be registered separately to mac80211 as phy0 and phy1
respectively. Similarly, device 2 will register its hw (6GHz) as
phy2 to mac80211.
In future, with multi-link abstraction
combination 1 - Different group id for device1 and device 2
Device 1 will create a single hardware abstraction hw1
(2 GHz and 5 GHz) and will be registered to mac80211 as
phy0. similarly, device 2 will register its hardware
(6 GHz) to mac80211 as phy1.
combination 2 - Same group id for device1 and device 2
Both device details are combined together as a group, say
group1, with single hardware abstraction of radios 2 GHz,
5 GHz and 6 GHz band details and will be registered to
mac80211 as phy0.
Add base infrastructure changes to add device grouping abstraction with
a single device.
This patch series brings the base code changes with following order:
1. Refactor existing code which would facilitate in introducing
device group abstraction.
2. Create a device group abstraction during device probe.
3. Start the device group only after QMI firmware ready event is
received for all the devices that are combined in the group.
4. Move the hardware abstractions (ath12k_hw - ah) from device
(ath12k_base - ab) to device group abstraction (ag) as it would
ease in having different combinations of group abstraction that
can be registered to mac80211.
v7:
- Added linux-wireless mailer to cc.
- Removed Acked-by tag from "[PATCH v6 8/8]" as it has minor change.
v6:
- Addressed smatch error seen on "[PATCH v5 8/8] wifi: ath12k: move
ath12k_hw from per soc to group"
- Rebased to ToT
v5:
- on "[PATCH 8/8] wifi: ath12k: move ath12k_hw from per soc to
group", refactor the ath12k_mac_hw_allocate() api based on ag rather
than ab and update hardware abstraction array size in ath12k_hw_group
as ATH12K_GROUP_MAX_RADIO.
- Rebased to ToT
v4:
- Modified the cover letter
v3:
- Removed depends-on tag of "wifi: ath12k: Refactor the hardware recovery
procedures" as it is merged to ToT
- Addressed the deadlock warning seen during rmmod.
v2:
- Rebased to ToT
Karthikeyan Periyasamy (8):
wifi: ath12k: Refactor core start api
wifi: ath12k: Add helpers to get or set ath12k_hw
wifi: ath12k: Add ath12k_get_num_hw api
wifi: ath12k: Introduce QMI firmware ready flag
wifi: ath12k: move ATH12K_FLAG_REGISTERED flag set to mac_register api
wifi: ath12k: Introduce device group abstraction
wifi: ath12k: refactor core start based on hardware group
wifi: ath12k: move ath12k_hw from per device to group
drivers/net/wireless/ath/ath12k/core.c | 431 +++++++++++++++++++++----
drivers/net/wireless/ath/ath12k/core.h | 87 ++++-
drivers/net/wireless/ath/ath12k/dp.c | 19 +-
drivers/net/wireless/ath/ath12k/dp.h | 2 +-
drivers/net/wireless/ath/ath12k/mac.c | 117 ++++---
drivers/net/wireless/ath/ath12k/mac.h | 9 +-
drivers/net/wireless/ath/ath12k/pci.c | 2 +
drivers/net/wireless/ath/ath12k/qmi.c | 10 +-
8 files changed, 544 insertions(+), 133 deletions(-)
base-commit: f8320064a28242448eeb9fece08abd865ea8a226
With this series I'm seeing a firmware crash upon resume from hibernation, but
I'm not sure if it is the same intermittent crash I reported in another thread
where firmware is not correctly handling a low physical memory address.
Baochen & Kalle, since this issue may be specific to my laptop, can you
validate hibernation on your setups?
I can also see a firmware crash upon resume. I am using ath-202405281746 as code base.
I bisected to:
[PATCH v7 7/8] wifi: ath12k: refactor core start based on hardware group
Thank you so much, Jeff. Identified the possible reason that is causing
the firmware assert with hibernation scenario and will address it in
next version.
