Received-SPF: pass (google.com: domain of linux-wireless+bounces-8345-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Feedback-ID:pgupta@hindutoo
From: "pgupta@hindutool.com" <pgupta@hindutool.com>
To: quic_hprem@quicinc.com, quic_jjohnson@quicinc.com, quic_bqiang@quicinc.com,
        ath12k@lists.infradead.org
CC: linux-wireless@vger.kernel.org
Subject: Re: [PATCH v7 0/8] wifi: ath12k: Introduce device group abstraction
Date: Fri, 31 May 2024 09:19:20 -0400
Message-ID: <1717161560.nw3mokq68g8og484@mailapp03.register.com>
In-Reply-To: <cc0fdf88-7046-eb93-265b-35a2d7299952@quicinc.com>
References: <20240528063547.1400700-1-quic_hprem@quicinc.com>
 <396d645d-6f3b-4c1b-9d4b-d056fad36192@quicinc.com>
 <7b92a6cd-187d-4b6d-8cfb-af54365751fc@quicinc.com>
 <d7898dd9-b3d2-45a1-8581-41d16b900a27@quicinc.com>
 <cc0fdf88-7046-eb93-265b-35a2d7299952@quicinc.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Reply-to: pgupta@hindutool.com

Is there a limit to the number of hardware abstraction layers? My current p=
latform has 3 physical WiFi 7 modules in one machine - one for each frequen=
cy 2.4 GHz, 5 GHz, and 6GHz.  Is this currently not supported?=C2=A0
What if I want to connect more than 3 modules including identical modules o=
f the same frequency? My setup will not be utilizing combined frequency mod=
ules.
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 de=
vice by the OS (i.e wlan0, wlan1, wlan2, etc.).

I ask this question because my WiFi7 module manufacturer (Compex) informed =
me that multiple modules (either different frequencies or same frequencies)=
 in the same machine is not supported by ath12k at this time.
Sorry for the intrusion.

Prashant Gupta


On Fri, 31 May 2024 15:35:24 +0530, Harshitha Prem <quic_hprem@quicinc.com>=
 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 ba=
nds say
>> >>>> 2 GHz or 5 GHz or 6 GHz can be combined together as a group and pro=
vide
>> >>>> an abstraction to mac80211.
>> >>>>
>> >>>> Device group abstraction - when there are multiple devices that are
>> >>>> connected by any means of communication interface between them, the=
n 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 na=
med 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=
=2E
>> >>>>
>> >>>> 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 rathe=
r
>> >>>> than ab and update hardware abstraction array size in ath12k_hw_gro=
up
>> >>>> as ATH12K_GROUP_MAX_RADIO.
>> >>>> - Rebased to ToT
>> >>>> v4:
>> >>>> - Modified the cover letter
>> >>>> v3:
>> >>>> - Removed depends-on tag of "wifi: ath12k: Refactor the hardware re=
covery
>> >>>> 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 hibern=
ation, but
>> >>> I'm not sure if it is the same intermittent crash I reported in anot=
her thread
>> >>> where firmware is not correctly handling a low physical memory addre=
ss.
>> >>>
>> >>> 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-202405281=
746 as code base.
>> >
>> > I bisected to:
>> > [PATCH v7 7/8] wifi: ath12k: refactor core start based on hardware gro=
up
>> >
>> >
>> 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.