Thank you for your reply. I have passed this information along to my board manufacturer (Compex) and we are currently working on a solution for the ath12k failing to recognize my module in the board-2.bin Prashant On Mon, 3 Jun 2024 10:33:09 +0530, Vasanthakumar Thiagarajan <quic_vthiagar@xxxxxxxxxxx> wrote: >> 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 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. >> >
